It all starts with the Business Case
Before starting the Project a high level Business Case should have been drafted with a statement of the expected benefit case and a stab at the project costs. This allows the Organisation to choose between potentially competing initiatives before kicking off Project Initiation for the initiative with the best Business Case. This process can encourage overly creative Business Cases as per the cartoon in my previous post!
If for any reason the Project has been initiated with any thought to the Business Case, I would look to produce something during the this phase. Of course, you may need to find a Sponsor first remembering that the Sponsor should own the Business Case not the Project Manager.
If for any reason the Project has been initiated with any thought to the Business Case, I would look to produce something during the this phase. Of course, you may need to find a Sponsor first remembering that the Sponsor should own the Business Case not the Project Manager.
A Business Case may start high level and be refined in the early part of the Project
You may start with a high level business case and flush out some more detail as you proceed through Analysis and Design. So ensure you plan these activities. Sometimes a good way of driving to a detailed Business Case is through the use of Project Stages so that an agreed deliverable for the first Project execution Stage, is a firm detailed Business Case (as a minimum) and potentially a Benefit Realisation Plan as well.
The Business Case should be kept under review during Project Execution
A common mistake is to forget the Business Case during execution. At whatever level it is produced, it should be kept under review. I recommend a strategy for ensuring this happens remembering that the Sponsor really owns this. A good way of ensuring that this happens is the concept of Gated Reviews at various points in execution, say at the end of a formal Stage or maybe even just at the end of a phase of the plan.
What is the content of a Benefits Realisation Plan?
The Benefits Realisation Plan should answer the following questions:
- What is the benefit that will be captured including the target level? (if there is a range of levels over time, this should be described)
- Who is accountable for securing the benefit?
- How will it be measured? (processes, tools, techniques and resources involved in undertaking the measurement)
- When it will be measured?
Even with a financial benefit, the process to calculate this may be non trivial. For non financial benefits, a proxy measure is likely to have to be devised. For example, "Improved customer satisfaction" might be via a survey before and after the Project has been implemented. The exact process should be documented and agreed.
Monitoring and Control of the Benefits Realisation Plan or should I say policing?
This is a problem faced by most organisations as the Project team has typically been disbanded by the time that the benefits start to be properly realised. The Sponsor may not be motivated to ensure the measurements get made especially if the benefits were "over-egged".
An ideal solution is for a PMO to take ownership of monitoring & control of the Benefit Realisation Plans. An alternative / additional approach I have seen in one organisation is to have a Projects Approval Board (PAB) which sits above individual Project Boards. The PAB has to authorise new Project Stages based on submissions of a revised Business Case by the Sponsor (sometimes accompanied by the Project Manager). A special review was timetabled post Project completion (at an appropriate time in line with the Benefit Realisation Plan) where the Sponsor had to attend the PAB and present on Benefit Realisation measurements against the agreed Plan. In addition, the achievement of the benefits was often written into the Sponsor's personal objectives for the year. This is probably the best example I have seen of policing the Benefit Realisation Plan and keeping Sponsors "honest"
Conclusion
A plan to deliver the Project objectives is considered common place but this isn't always the case for the Project Benefits. As ultimately the benefits of the Project should be the reason for undertaking the Project this makes little sense. So start with a Business Case, drill down into more detail as more information is known during Project execution and when agreed move onto agreeing a Benefit Realisation Plan which will determine the what, who, when and how with regard to assessing whether the expected benefits have been realised. The organisation also needs a method of policing the process post Project completion. With these elements in place, benefits stated in Business Cases are more likely to be realistic, all efforts within Project execution should be focused on achieving the stated benefits as should some post delivery actions to correctly exploit what has been introduced by the Project.
0 Comments