Menu
Menu
Forget Everything You've Learnt About Project Delivery, Part 6: Outcomes/Benefits Delivery Planning

Forget Everything You've Learnt About Project Delivery, Part 6: Outcomes/Benefits Delivery Planning

If every project was wholly focused on agreed business outcomes and benefits, the success rate of projects would go up immediately

Delivery plans are needed to deliver the business outcomes, the business benefits and the project outcomes — not just for the project

A PMO Manager recently showed me a 60-page business case and a 102-slide post-implementation review report saying, "There is no correlation between what the business case promised and what was delivered!"

This is not altogether surprising. Many organizations are now organized so that one group has accountability from project initiation to business case approval and then another group takes over to deliver the project.

So, those accountable for project delivery are not those accountable for defining and agreeing the benefits (and vice versa). It is not therefore a surprise that on many projects any relationship between the project plan and the business case is minimal.

So, rather than the project being set up to deliver the business outcomes and benefits, the project is set up to deliver 'the deliverables' that, it is hoped, will enable the benefits (and we've already seen the problems with this approach).

Few business cases clearly define how each benefit will be delivered allowing the link between the project and the benefits to be left very loose.

When we do project health checks we try to map what the project is doing vis-a-vis the delivery of the outcomes and benefits in the business case. Gaps are common where the project, as established, will neither deliver nor enable the benefits to be delivered.

In the detailed project planning process the talk turns to 'deliverables', milestones and other terms when everything should be defined in terms of delivering the (true) business outcomes and benefits. Benefits that will be delivered after the completion of the project should still have their own 'realization plans'.

Delivery plans are needed to deliver the business outcomes, the business benefits and the project outcomes — not just for the project.

If every project was wholly and overtly focused on its agreed business outcomes and benefits, the success rate of projects would immediately go up significantly.

But there's another dimension that has to change. In IT projects the systems development lifecycle dominates whereby events build up to a crescendo (or several crescendos if a phased delivery) when the system is installed.

But it doesn't have to be like this. Not everything is dependent on the delivery of the system — many improvements can be delivered earlier, realizing their benefits earlier too.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.

More about SIMMSSIMMS

Show Comments

Market Place