Blinded by the plan, ignoring the benefits – David Reinhardt 0

Posted on 22, June 2012

in Category practitioner experience

I fear the wrath of project managers everywhere when I write that delivery against planned timelines is unimportant. The success of a project does not depend on whether the changes were implemented by some, often random, predetermined date. The success of a project depends solely on whether the benefits promised (and paid for) were delivered.

It amazes me how often this perspective gets overlooked, never at the outset of the project of course. In the heady early days, it’s all about benefits models and the associated business case. It’s usually once the project gets underway that the focus slowly shifts from talking about why something is being done to what needs to be done.

We should know better

It’s not as if we – as a collective industry of change practitioners – don’t know what constitutes best practice. PRINCE2® teaches that projects deliver outcomes, not benefits. At the outset of the project, it is important that the benefits case is clear around when benefits are expected and – the bit most often overlooked – how they will be measured and reported on in the absence of a project structure.

Once the project gets underway, a collective madness ensues. Project plans are baselined and the team begin focusing on the deliverables. Little-by-little the deliverables of the project become the end themselves, rather than a means to an end. The project team gets caught in the trap of focusing on completing project products (i.e. the what) rather than remembering the project’s cause (the why).

All too often we see stage gates reviews that the relevant documentation has been produced on time and to some notional quality standard. It’s not often that I’ve seen gate reviews do a genuine and meaningful assessment of whether the content of the documents is meaningful in the context of the project benefits.

Time is of the essence

Is it a matter of time? Typically the effects of a new system will be felt in a specific cycle. There will be an initial surge of activity driven by the project and the newness of the implemented change. People will take it for a test drive and kick its tyres. After a time, some sort of normalisation will take place when people either feel it is in their best interests to continue using the new system or they will fall back on old habits. The nature of the project will determine the length of the cycle.

The actual realisation of the benefits only comes much later, typically once the project is already shut down. The project team have packed up their laptop bags and moved onto bigger and better things and there’s no-one around to look after post-project activities. In reality, this is the most sensitive time in determining a project’s success. It’s only now that it can be determined whether the project has begun to deliver the benefits it set out to deliver.

Fooled by the plan

Strangely, the buyers of change don’t seem to be hopping mad about this either. They too succumb to the focus on deliverables. Delivery becomes the measure of success rather than objective review of whether the project has delivered the benefits it set out to achieve.

Hopefully buyers of projects have made their investment decisions based on the value of proposed benefit against the proposed project cost. Why aren’t they demanding evidence of value for money? Frankly, I don’t know. I do know that in the bulk of clients I’ve observed in 10+ years of IT consulting, benefits reviews are very rare. Rarer still are those that bring conversation around benefits, design imperatives and project objectives into the daily culture of the project.

I’m not against good planning. I’m not even against sticking to the plan. I’m just against task focused project teams perceiving the need to deliver product x against deadline y as more important than delivering the benefits that the project set out to achieve.

Key takeaways

So what should be done differently?

• Ensure that the project is based on a robust benefits case;
• Ensure that stage reviews have meaningful assessment of the content in the project products;
• Ensure that the benefits case includes a mechanism to monitor benefits after the project completes, and that this mechanism has an owner who takes accountability for operating it;
• Ensure that the BA, PMs and project sponsor create a culture where there is talk about the benefits of the project rather than just the deadline;
• Ensure that project sponsors hold the delivery team accountable for delivery of the benefits (this requires post-project monitoring and appropriate mechanisms for holding people accountable);
• Ensure that benefits are measured after an appropriate time is allowed to ‘bed the change’ rather than as part of the project shut-down activities.

This article originally appeared on the BCS Guest Blog on 22 June 2012. Click here to view the original post.