Benefits Management – the Key to Success in Project Management
As mentioned on the official APMG description of PRINCE2, one of the things that makes PRINCE2 stand out from other project management methodologies is the focus on continuous improvement and the importance of the viability of a project – the project lifecycle doesn’t stop when the product is delivered.
Benefits should be included in the business case of a PRINCE2 project, but are often a tricky factor to define and manage. The reason for their importance is because, although the project is undertaken to produce a product, what the business actually wants is the benefit of that product. E.g. if it’s a new product for sale, the benefits are the sales from the product. If the project is to develop a new content management system, that system needs to make the business more efficient and therefore save money.
Documenting clearly defined benefits can also help ensure buy-in from everyone working on the project – team members’ doubt in its value can be damaging.
It’s crucial that a project manager questions the customer on the benefits they expect once the product is delivered, and moving forward from there. Delivering a successful project blind to expected benefits could mean miscommunication and, ultimately, undeserved damage to the project manager’s reputation in the eyes of the customer.
Consider this story, we’ve all heard similar tales but this one in particular was relayed to me by one of the delegates on our PRINCE2 training course just last week. They had been asked to manage a project developing a new CMS and were given very specific requirements for how they’d like it to work. The project manager delivers this product as specified – but it transpires that the new system is harder for the users to manage which means none of the assumed benefits are achieved. The customer blames the product and, by association, the PM.
Now, this individual came on our course for all the right reasons – they realised that working under a specific project management framework would mean that issues like this could be avoided. But it got me thinking about benefits and the responsibility of the PM to manage these. In essence, benefits realisation management is about outcomes as opposed to outputs.
How to Realise and Manage Benefits in PRINCE2
A useful way of helping the Customer or Senior User to identify expected benefits is by using the 5 Whys method of root cause analysis, a technique used in Lean Six Sigma. Asking the Customer what they want (a new product), why (they don’t sell this but others do), why (if other people sell it, it must be in demand) why etc.
Usually, the Senior User will specify and defend the benefits – this will form the basis of the business case. They will be in line with the business’s high-level strategic objectives, and any benefits management done as part of programme management where relevant. The inclusion of the end user in the PRINCE2 process is another key to its beauty and popularity.
In PRINCE2, the Benefits Review Plan is put together by the Project Manager in the initiation stage of the project. This will document the following:
- The expected benefits as outlined in the Business Case
- How these will be measured objectively – and against which base line value from before the project was initiated
- Who will measure the benefits (usually the Senior User)
- When they must be measured (sometimes some benefits will be achieved while the project is still ongoing) The Project Board must agree on how far along the line the benefits will be measured once the product has been delivered.
- Tolerances
- Dependencies
- Disbenefits
Once created, the Benefits Review Plan will be submitted and approved by the Project Board. It is revised at the end of each stage within the project, usually with separate benefits for each stage of the project.
During the final benefits review, the Senior User will identify and evidence benefits that have been gained.
Dis-benefits
It’s a clumsy term but is used in the PRINCE2 manual to describe how benefits must always be managed alongside expected negative outcomes. For example, perhaps the new CMS will run much more quickly but require more maintenance. A very common dis-benefit is a reduction in productivity during the time taken for users to learn to use a new software product.
Dis-benefits are not the same as risks. Risks are outcomes that might occur, and dis-benefits are outcomes that have been identified and accepted as very likely or certain consequences of the project and its product. Of course, dis-benefits should be analysed to ensure they will not outweigh the benefits!
Dependencies
Benefits of a product will always depend on more than just the delivery of the product by the project. The benefits will depend on such things as effective implementation of this product, which may or may not fall within the project remit.
Dependencies are very important when it comes to identifying where the line of responsibility is drawn. Other individuals or organisations are often dependencies, e.g. the supplier providing the right goods at the right time, or appropriate trainers being available if the project is delivering a new piece of software.
Why Benefit Management is the Key to Project Management
No matter how closely you follow the rest of a project management methodology such as PRINCE2, if the ultimate goal is misguided then it will be hard for anybody to consider the project a success.
Project Managers need to be remembered and reemployed for delivering results, not just products, so it makes sense for responsibility for benefit realisation and management to fall within their hands.
Don’t forget to leave your comments below.