The calculation of financial value in a project, benefits minus investment, should also factor the time value of money and risk. Most project proposals or business cases include some form of financial indicators; Internal Rate of Return and/or Net Present Value (NPV), which both consider the time value of money. However, when it comes to risk when included in the business case, it is usually presented as additional or supporting information, and not factored into the calculation of financials of the proposed project. At best, the decision is made on a most-likely scenario of benefits and investments. Sadly, in most cases, these most likely scenarios are really sunny-day or optimistic scenarios. Have you ever seen a business case presented for consideration that is weak?
There are two reasons that explain why business cases are, for the most part, optimistic:
- Investments are underestimated because it is done at an early state and proponents simply don’t know enough of the project to properly assess the cost. In addition, assumptions are generally positive: things are going to work well, integrate easily, resources will be available, etc.
- Assumptions on benefits are confident and optimistic, otherwise, the project would not be proposed in the first place. Phrases like “slam dunk” and “no brainer” are frequent. Let’s just do it!
The two bullet points above have one thing in common: uncertainty, which is why factoring risk is so important. This article presents three ways to incorporate risk:
- Factor delivery risk into the calculation of time and cost for delivery
- Factor benefit risk into the calculation of benefits
- Factor both, delivery and benefit risk, the acid test
This article will show you how to factor delivery risk. The next two installments of this article will cover benefit risk, as well as how to consider business risk, and the combination of both delivery and benefit risk.
Delivery risk
Delivery risk can be assessed from the initial stages of project approval. At that point, there is no risk registry. However, an assessment is always possible. At the idea level, it can simply be a paragraph or two where the proponent explains why and based on what assumptions s/he thinks delivery will not hit major roadblocks. Later in the approval process, at the business case level, an assessment of delivery risk can be done against a list of risk factors. As an example, for software development projects, typical sources of delivery risk are integration with other systems, data migration/conversion, multiple user groups, new technology, etc. Assessing the project against each factor and using some form of ranking and thresholds, the overall delivery risk can be defined as low/medium/high. Simple.
When it comes to factoring delivery risk into the estimate of investment, a medium to high delivery risk project will likely:
- Take longer
- Cost more, including the burn rate during the additional time required
- Deliver an output that does not have the expected quality. While most projects will ensure, through testing, that the output meets requirements, fitness for use is harder to ensure.
From agile practices, we all know now that the natural progression of things is not linear. When a project gets in trouble, it doesn’t increase in linear increments of 10% or 20%, but most likely 30%, 50%, 80%, 130%, etc. The Chaos Report stated that, in challenged projects, variations in time and cost were above 200%, which is three times the baseline. Yes, this was years ago and delivery has improved, but successful projects are still at 29%. In any case, we can all agree that when a project gets in trouble, time, and cost increase significantly.
Once you have assessed a project as a medium to high risk, the next step is to generate a scenario that incorporates the impact of risk on time and cost. A simple approach is:
- Use a factor to increase time say, 50% for medium delivery risk, and 75% for high delivery risk. The time for a one-year project with high delivery risk would extend from 12 to 21 months. Simple.
- For cost, you need to factor burn rate for the additional time, plus other costs, like equipment, services, that could also increase if they are not based on strong assumptions.
For major projects or programs, simulation is another option. This takes time and costs money, but in the context of millions or billions of investment, it makes perfect sense.
In terms of quality, we can assume that, in a challenged project, meeting requirements will take longer and cost more, as the project will go through additional cycles of testing and defect fixing. This will likely be reflected in the extension of time and cost already discussed. The discussion of fitness for use will be covered in the third installment of this article.
Conclusion
When deciding to invest money, somebody else’s money, into a proposed project, the assessment of risk cannot be a comment or supporting information in the business case. Not factoring risk into the estimates is simply irresponsible, as it will present the investor with an optimistic assessment of the project. Would you fund a project with your own money without knowing the risk?
