I’ve written before (Most Benefits aren’t) about the way that, on so many projects and programmes, Benefits are either poorly defined, or are little more than wish lists.
I’ve come across similar issues with a couple of organisations I’ve been speaking with recently, where they are using a framework to link project deliverables to benefits. Both were using a model that asked Project Sponsors and Managers to identify:
- Benefits (value adding end-results of the project)
- Capabilities or Impacts
- Deliverables (the “stuff” created by the project)
This model is fine, but the issue I’m seeing is that people make two mistakes:
- They don’t understand what “Capabilities” or “Impacts” mean
- They muddle these with Deliverables
So, for example, I’ve seen the following lists of “Capabilities”:
- An empty building (ready to be decommissioned)
- A Target Operating Model (consultants do love TOMs don’t they?)
- A set of service and process definitions
ALL of these are Deliverables.
I still think OpenStrategies’ PRUB-thinking is a far simpler way of making explicit links between Deliverables and Benefits. This basically says: “Organisations run PROJECTS that create RESULTS; if those project results are USED, there should be a BENEFIT to the user.” Or, put another way: unless somebody wants and uses the results of an organisation’s projects there can be no benefits.
What people setting up projects and programmes need to identify, is not “Capabilities”, but Uses. Who will use the project’s deliverables, in what way and for what value?
One of the other things I like about PRUB-thinking is that there is detailed guidance behind the model on how to write effective P, R, U and B statements. That’s the key to avoid sloppy Benefits thinking!
Download the full article “Most Benefits aren’t” (pdf)