Many software development projects fail. Why is that so? Well, one big reason is lack of risk management. What is risk management?
I would imagine that almost anyone has an understanding of what the word risk means and that there will eventually be undesirable consequences if you do a lot of risky stuff. On the other side of the spectrum, there's the old adage that nothing ventured means nothing gained. Risk management is kind of like that. Too much risk in a project puts it in jeopardy. Too little risk in a project and it becomes irrelevant. Risk management is all about finding the middle path between too little and too much risk. The key to risk management is in learning how to measure risk. The best way to learn how to measure risk is in exploring how to measure ROI or Return On Investment as the two are closely related.
ROI for IT can be hard to measure because a lot of what IT does is what is known as the cost of doing business. It's not so much a question of can you afford email as it is a question of can you afford not to have email. The ROI for software development that is reactive (i.e. process automation) needs to be measured in terms of cost reduction. The ROI for software development that is proactive (i.e. new product line or market) should be measured in terms of that increase in market share or sales. This becomes problematic because maybe market share or sales were going to increase anyway. Believe it or not, one of the biggest barriers to measuring ROI is in identifying the strategic goals for the project. Sometimes an enterprise will engage a big budget initiative without a clear articulation of the strategic goals for the initiative. That is always a recipe for failure.
Here are some more easily measurable indicators that can help you learn how best to measure risk in a software development project.
Release size correlates directly with risk. The bigger the release, the longer it takes to develop, the longer you go without customer feedback, the more likely your software becomes irrelevant.
Requirements churn correlates directly with risk. The more changes you permit in any single release, the more likely you are not to make your implementation estimates, the more the ship date slips, the more disappointed your customers become.
Technology churn also correlates directly with risk. The less familiar your developers are with the target deployment technology, the more likely they are to make mistakes or misunderstand the architecture, the lower the quality of the software.
There is another concept of risk that becomes relevant to large IT efforts who maintain multiple product lines or project initiatives. It is the risk that comes with managing an application portfolio. Financial institutions understand this type of risk very well because it is the same type of risk that comes with managing a stock portfolio.
When you sell a stock, you need to re-invest that money but where? If you re-invest in what appears to be the stock with the highest ROI at the moment, then you may miss out on a better opportunity that you will discover later on. If you wait too long looking for the best opportunity to re-invest, then you will lose money holding the capital in a lower gain yet more liquid-able vehicle.
The same is true for managing multiple applications/projects. Which project or projects should you divert the most resources into? Well, that would be the projects with the highest ROI. But ROI isn't fixed. It changes over time. If you go ahead and commit resources to a project too soon, then you miss the opportunity to quickly develop others whose ROI may eclipse those of the projects you initially identified. If you delay committing resources too long, then those resources are being under-utilized which is also wasteful.
Measuring ROI, identifying strategic goals, managing release size, managing requirements and technology churn, and portfolio management are the six most efficacious steps towards managing project risk.