The wake up call

Some time ago I had a personal learning experience around the management of the benefits in a project.

The project was going well considering that the product was being developed and deployed on time, with the required quality and within the approved budget. Of course we had experienced difficulties during the project but the team and the product manager had the impression that we were achieving our objectives. And then, suddenly, we received a challenge from our business sponsor: he did not agree with our view of the project being a success and considered that we should reduce our satisfaction level as he challenged the business benefits we were delivering.

What had happened?

On the technical and operational level the project team had been working with a prioritized backlog that was supposed to be aligned with the business objectives. On the strategic level it looked like we had some Key Success Factors defined and agreed but when we looked at them closely with our sponosr we saw that they were described in an ambiguous way. And apparently they were being interpreted differently by the sponsor and the project team.

I have recently read the Strategy Implementation Playbook and according to this guide it seems that we had missed some key aspects in the Benefits Management Process:

1. Identifiying and structuring benefits (done)
2. Planning benefits realization (partially done)
3. Realizing and tracking benefits (failed)
4. Evaluation of benefits (failed)

Accountability for benefits management rests on the project sponsor. The fact that in many cases all or part of the benefits are non cashable makes it difficult to make them tangible and quantifiable in an objective way as they cannot be expressed in monetary terms. In addition, as benefits realization happens some time after transition into use, a delay is generated in the feedback loop towards the project team that does not help to ensure they are following the right roadmap.

For the planned continuation of the next phase of the project we needed to put in place a framework to manage and realize benefits. A good framework I have identified in the mentioned book is this one from APM.

Benefits realization management is not a simple thing. It requires a mature organization with project and program sponsors committed to devote time and resources to follow a benefits management lifecycle as the one presented in the link above. But if we have discipline to apply such a framework we can enter into a virtuous circle as the projects that will be presented for approval will have stronger business cases to support them since benefits realization will be properly tracked. The more accountability on benefits realization the stronger and well defined business cases will be approved by the organization.

A Benefits Realization Plan is a must have

A Benefits Realization Plan (as stated by PMI) is a document outlining the activities necessary for achieving the planned benefits. It identifies a timeline and the tools and resources necessary to ensure the benefits are fully realized over time. It defines:

• Benefits and associated assumptions, and how each benefit will be achieved.
• Metrics, including KPIs, and procedures to measure progress against benefits.
• Roles and responsibilities required to manage benefits.
• How the resulting benefits and capabilities will be transitioned into an operational state to achieve benefits.
• How the resulting capabilities will be transitioned to the individuals, groups, or organizations responsible for sustaining the benefits.
• Processes for determining the extent to which each project or program benefit is achieved prior to formal closure.

An improvement approach

In the case of the project presented previously my improvement approach is:

1. Prioritized backlog but open for changes during the life of the project as long as the items coming represent a similar level of effort as the items discarded from the backlog.
2. What remains fixed is the budget available to make it all happen. It must be aligned with the business case that justifies the creation of the project.
3. As part of the business case we need to have:
   • Key success factors to help us understand what we want to achieve and how we will recognize that we have achieved it. They must use a language understood by every member of the team (technical and business).
   • Business KPIs that guide us to measure if we are moving in the direction defined by the key success factors. However, the map is not the reality. KPIs must be carefully chosen and challenged as the better they represent what we want to achieve the better they will help us to succeed if we hit our KPI targets.
4. We must link components outputs to the planned project outcomes. Each time we include an item in our backlog we must ask ourselves:
   • How does this item help me to achieve any of the business goals? That is, what is the value added by this item?
   • To which key success factors is this item contributing?
   • Do we have valid business KPIs to measure its success?
5. In parallel we need to keep the traditional operational KPIs that measure if we are on time, on budget or which percent of the scope we have already delivered.

Operational KPIs are useful for the tecnical team and the project manager but hiting their targets does not necessarily mean that the project will be a success. We could just be moving very accurately in the wrong direction.

These 5 points being part of a consolidated Benefits Realization Plan should help us increase our chances to realize the planned value of the project and make appropriate decisions if we are missing our targets.

Is your organization mature tracking and realizing benefits from its initiatives? What kind of framework do you use?

Please, add your comments as I am eager to learn from other experiences.