Did you know that, in my opinion, no project ever approved has been approved on the basis of the thing, output or deliverable it will build?
Let that sink in for a moment because for some people that simply doesn’t make sense. Surely that is the entire reason for a project – to build a thing, output, or deliverable? What other reason could there be?
Well, it isn’t, never has been, and never will be.
The reason for the project is to deliver the expected, and desired, outcomes and benefits. The thing, deliverable, or output is simply the preferred method of achieving these outcomes and benefits. Too many people get fixated on the deliverable and there are handshakes, and congratulatory notes, and celebrations of successful projects one the deliverable appears. Then everyone turns their attention to the next thing to be built.
And that is major contributor to project failure.
Project success occurs when the deliverable produces the outcomes and they in turn deliver the expected and forecast benefits. If you want proof of this simply refer back to your business case, project initiation document, charter, mandate, work order or whatever it is you call the document that captures the reason for the decision to start the project. Sure it mentions the deliverable but it should make it clear what the expectations are around outcomes and benefits.
And this is what Benefits Management is so important to successful project management.
But here’s the thing, there are three important steps to successful benefits management and if you don’t do all three, don’t bother doing any of them. Here are the 3 steps to successful benefits management:
- Benefits Estimating and Forecasting – this first step is focussed on justifying the investment in any project. It’s outlining the expectations about the outcomes and benefits the organisation is seeking, the costs and risks of achieving them, and then choosing the deliverable best placed to help these be achieved. These can be strategic, operational, financial, non-financial or other forms of outcomes and benefits that are important to the organisation. The key thing is to document them, make them measurable, define roles and responsibilities early for who, how, when, and what?
- Benefits Tracking – once the benefits have been defined then it’s time to turn your attention to tracking their delivery throughout the entire project lifecycle. Yes, even while things are under construction you should be checking that what you are building is still going to deliver the expected outcomes and benefits. This information should be part of your regular reporting. I’ve always said that there is a possible theoretical situation where you may find the deliverable you are producing is wonderful and shiny and slick and perfect, but you realise it will no longer deliver the expected outcomes and benefits. In this case you should be prepared to change it or cancel the project. The achievement of these outcomes and benefits is the sole reason for the project. Please let me know in the comments if you have actually encountered this.
- Benefits Realisation – the final of the necessary three steps to benefits management is benefits realisation. Despite it being the final step you don’t leave planning for it until the end of a project. In fact, quite the opposite. You should be defining who is responsible for this, when it will be done, what metrics will be used, what reports will be produced, the time period to ensure full and permanent realisation etc right at the beginning of the project. You should also make sure that appropriate levels of money, time, and resources are allocated to complete the work. Remember that different projects have different time horizons for realisation of benefits – some realise benefits during the project, some upon the deliverables being completed, but many organisations complete projects that can’t check benefits realisation for significant periods of time after the deliverable appears. I’ve often found difficulties for organisations that do not realise their benefits for months or years after the appearance of the deliverable. The main problem seems to be getting agreement on who will be responsible for completing benefits realisation. Is it the project manager, the asset owner, the product owner, the client, the PMO, the regional manager, Bruce from accounts? The answer to this question is unique to the organisation but this often means that it is put into the “too hard” basket. If you don’t do this essential part of benefits management, you will never know if you achieved the expected and forecast benefits and if you don’t do benefits realisation you are giving people permission to write whatever they want in those project initiation documents.
So, stay focussed on outcomes and benefits, define what they are and how you will check that your decisions are achieving them, and stop being primarily focussed on the thing, output or deliverable.
