Software Risk Management
Far too often, as many of us IT practitioners realize, software development projects run into serious trouble and frequently fail to meet the objectives specified early in the project. Why is this? After all, we are the professionals. Shouldn’t we have a firm grasp on all of the moving parts of a project? Shouldn’t we be the ones that can sufficiently estimate the level of effort required? Shouldn’t we be the ones that protect against scope creep through rigorous process, issue management and risk management? And yet far too often we get into the middle of a project and realize that there are certain risks that we did not account for or identify early enough to make a positive difference in the outcome of a project.
Obviously, there are a variety of reasons that projects can fail. As Roberto Meli states in his article “Risks, requirements and estimation of a software project” the most typical reasons for project failure are “indeterminate, ambiguous, undefined, or generic – in short, poorly formulated – project objectives” and “inadequate allocation of resources for carrying out project planned activities.” Well, this is no new news to those of us in the industry, but how many times do we fall victim to this? Well According to a Standish Chaos study, it happens over 60% of the time as only 32% of projects accomplish the original goals of the software development effort in terms of scope, cost and timing.
So, if this is the current state of the industry, what is the key factor in moving us up the curve of software development evolution? I contend that it stems from inadequate understanding or lack of focus on the risks inherent in any software development effort. Let’s face it; these types of project are fraught with risk. From the inadequacies of estimating models, the varying proficiency levels of the software professionals on the project, users that change their minds related to the requirements to contractual issues that surface because they were not adequately stated or adhered to during the project development effort, every project has certain risk factors that we have understood for several decades now. However, these risks are typically not fully accounted for and more importantly, they are not managed so that they can be detected early enough in a project lifecycle to make a difference.
That is why a software development effort must have a comprehensive risk management framework and program that will not only identify these nagging risk factors but tracks, manages and allows for successful risk mitigation.
There are a number of programs and frameworks out there that purport to assist in this endeavor. These frameworks, while typically adequate in theory have one core problem: they are not implemented in a systematic and systemic program of activity. Far too often we go through the detailed process of identifying risks at the beginning of the project without institutionalizing the maintenance and management of these risks within our software development activities.
In addition, as Robert Charette discusses in his article, “Essential Risk Management” the distinction between Problem Management and Risk Management is unclear and improperly implemented. We tend too often to think (or operate) as if Problem Management Is Risk Management and yet this is not the case at all. Whereas Problem management most appropriately addresses problems that we are experiencing right now and must be addressed right now, Risk Management focuses on problems that have a probability of occurring in the future. Risk Management is a perspective of assessing the causality of a particular event occurring. As Charette clearly states “problem management equals risk management if you do not look past today”. A proper risk Management program is part of a broader decision support mechanism that deals with both problems and risks. How a problem is dealt with today will introduce new risks based on the decisions we make today to resolve each problem.
Therefore, our risk management programs must be top-down approaches that provide executive, management, stakeholders and staff with the tools and techniques to identify, assess, decide and act against and within risk boundaries. It needs to drive the acquisition of and utilization of a body of knowledge that will increase our learning as an organization as it relates to risks to our software development efforts. It must support comprehensive decision making and allow us to visualize potential problems that can occur based on the decisions that we make throughout the lifecycle of a software project. And it must give us some way to quantify the impact of risks. Some risks may have a higher probability of occurring and yet have a relatively low consequence or impact while others may be low in probability of occurrence and yet their impact could devastate the outcome of the project.
There are many articles available on the internet that provide some solid guidance related to Risk Management. I have provided some useful links that describes risk management principles and strategies here.
Visualizing your Risks Making sense of risks by letting them tell a story – Norman Fenton and Martin Neil
Without a comprehensive end-to-end set of principles, strategies, knowledge base, processes, and measurement dashboards to define, assess, decide and act as it relates to project risk we will continue to repeat the same mistakes that have led to project failure time and time again.
Follow me on Twitter at www.twitter.com/peterdeyoe