Think of a project that failed in some way…now think of why it failed. I’m willing to bet you’re thinking late delivery or over-spending the budget or maybe the end-product did not function as expected.
But those are just root causes; ultimately, the project did not get any benefit realization
Every project needs to articulate its benefit realization within two key documents; the business case which describes the benefits, and the benefits review plan which describes how the benefits will be measured, when they will be measured, and who will measure the benefits.
Although some projects are just enabling or compliance type projects, and yet others may be difficult or impossible to quantify (measure), most projects are there to deliver business benefit.
I don’t want to discuss the development or the contents of the business case, nor how it is used throughout the project. Instead, I want to touch on the benefits themselves.
Benefit Realization – habits
First benefit realization habit:
Include of benefits and dis-benefits within the business case and the benefits review plan. A simple example of a monetary benefit might be a cash saving or a revenue stream over a given period. The definition of a dis-benefit is a negative outcome as a result of the project. An example might be a decentralization of a facility causing staff redundancies and the loss of key skills.
Second benefit realization habit:
Stating benefits is not an exact science and are often only estimates. The use of three-point estimating giving a best-case, most likely, and worst-case will help create a more realistic business case upon which rational business decisions can be made.
Third benefit realization habit:
Use the ‘so what’ test. Use this when brainstorming potential benefits. If someone suggests that a new Computer System would be a benefit, ask them ‘so what’. Their reply might be because it will have a better data base – again I ask them ‘so what’. I think you can see where this is going, keep asking ‘so what’ until you get to the benefit.
Fourth benefit realization habit:
Sensitivity analysis must be used (possibly in conjunction with the second habit) to determine how sensitive the benefits, costs, and risks are to external influences beyond the projects control. An example here is monetary exchange rates.
This refers to the benefits review plan and the need for you to be absolutely sure that the project can indeed deliver the benefit. This will normally need close liaison with the operational area that will use the end-product of the project, and to ensure that it is clearly understood how to benefit will be measured, the timeframe of realization, and that adequate resources will be available to both measure and realise the benefits.
Ensure that each benefit is clearly isolated and that an unambiguous path exists between one or more project deliverables to each realized benefit. Because of the need to create a compelling business case, it is tempting to ‘hitch a ride’ on benefits delivered via other projects or those that would have happened with or without your particular project.
Seventh benefit realization habit:
Recognize that business cases evolve and that dynamic business environments can change throughout the life of the project. Also, that the initial business cases can change and mature as more is known throughout the life of the project. Compounding this problem, are aspects such as risks, changes and issues. It is vital that a business case is reviewed constantly throughout the project say that the trade-off between benefits, costs and risks are continually use to make informed business decisions.