Not 'Mature' Enough?
In organizations with a project management methodology there is usually a schematic chevron chart that shows in a single simple diagram the steps in the methodology.
Most methodologies are designed from an IT system delivery point of view and, therefore, don’t adequately take into consideration the steps necessary to deliver the desired business outcomes, benefits and value.
Now this may seem surprising except that many Project Management Offices and IT Managers actually assert, “We (the organization) are too immature to manage benefits”.
Er, hello? What do you think the projects are commissioned to deliver???
The different methodology designs
This disconnect between the reason for the existence of projects and how they are run is often reflected in the design of the methodology.
Scenario 1 — No mention of benefits
Where your project methodology does not mention benefits at all then you can be assured that your projects are not being run to deliver the benefits. So, not realizing the benefits will be the (expensive) norm.
The business case will be seen solely as a means to get funding, and the outcomes and benefits promised in the business case will be seen as irrelevant to the delivery of the project.
Scenario 2 — Benefits review at the end
This approach is 'hope on steriods'! You don’t target or run the project to deliver benefits, but go looking for them after the end of the project.
Needless to say, few benefits are found. (Around 20%-30% of benefits are delivered automatically but he project's outputs, the other 70%-to-80% of benefits need to be identified, targeted and actively delivered. These are the benefits you are looking for.)
An effective benefits management process measures the value of the benefits during the project and as they are realized. You don’t need a separate post project step (such as a PIR).
Scenario 3 — Benefits realization is the last step in the methodology
With this scenario at least benefits as a goal are recognized, but the view here is that they happen after the end of the project. The project team, therefore, is not accountable for or focused on the delivery and realization of the benefits.
While this is an improvement on scenarios 1 and 2, the project again is not set up or managed to deliver the benefits — they are "someone else’s accountability". Therefore, as no one is accountable for ensuring all of the pre-requisites to the delivery of the benefits are present. As a result benefits fall through the gaps and value is lost or destroyed.
Scenario 4 — Benefits realization is a continuous process
Hey, now we’re talking about a methodology focused on delivering benefits. Not just at the end or after the project, but throughout the project as well.
When benefits realization is a continuous process, the nett costs of projects actually goes down (as benefits are progressively realized to offset project costs), the likelihood of benefits realization goes up (as it is the main focus of the project) as does the overall value realized and 'banked'.
When you think about it, all methodologies should be benefits-centric and focused; as this is why you commissioned the project in the first place.
Benefits are not an ‘optional extra’ (as in the ‘not mature enough’ comment) but the principal purpose of any project. If the project is not going to deliver the outcomes and benefits envisaged, then it should be never be started.
What type of methodology is your organization using?
Benefits should be the central focus of all of your projects, your project plans, and your language.
Ensure that ‘success’ is seen to be measured by the measured delivery of the business outcomes and realization of the associated benefits and their value.
It really is that simple.
