This article considers the problem - how do projects deliver benefit? It suggests that projects may not have time to deliver benefits - and explains what needs to be put in place to make sure benefits from business change are properly captured.

That’s right: projects don’t deliver benefits.

No, seriously, they don’t.  And at the risk of giving away my secrets, it is worth exploring why they don’t, why this is a good thing, and what we can learn as a result…

The first thing to be clear about is that projects are temporary structures. Organisations launch projects because they have ambitions to improve their business – to make things better – or in project terminology, deliver ‘benefits’. Projects are used to deliver change - classically, projects are launched, do some work, deliver benefits, and then close down.

Benefits mean the business is better as a result of the project. But what, exactly, is better?

In business terms, better is usually set out in terms of improved performance or capability to deliver the business strategy (i.e. it is ‘aligned’). Improving revenue is therefore a ‘good thing’ if the business is trying to grow, and a ‘bad thing’ if the business is not.

But who exactly delivers this improvement or new capability?

It is most certainly not the project team. In our example, improved revenue is the responsibility of the sales team. We don’t expect the project team to get out there and sell. In general terms, improvements or ‘benefits’ can only be delivered by operations, not by the projects instantiated to deliver them.

So rule 1 – projects do not deliver benefits, operations do.

Let us take the logic further.

Einstein once said that “the definition of insanity was to keep on doing the same thing and expecting different results each time”. In light of this wisdom, if the business has improved performance and ‘benefits’ have been delivered then this could only occur if there has been a change.

Change leads to benefits. Or at least, the right kind of change leads to benefits (the right kind of improvements).

But who exactly changes?

It is most certainly not the project team. If the sales team want to improve revenue, then the sales team must change how it works.

So there goes another myth. Rule 2 - projects don’t deliver change, operations do.

So what do projects deliver?

Change does not just ‘happen’. Management cannot decide one day to change, and expect everyone to understand what is needed and start working differently.

There is a lot of work involved in designing the change, constructing systems, processes, policies to specify how the new organisation will work, consulting the change, and preparing training for those whose work will change as a result.

That is what projects deliver – artefacts (or ‘products’) that colleagues working in business operations can use to help them make the necessary changes that deliver improved performance that is aligned with the business strategy.

Fully functional change and the consequential benefits may not occur until several months have elapsed after delivery of a project’s products. Project teams are too expensive to keep them around once the project’s products have been delivered. Apart from a short period of hand-holding, business operations needs to make the required changes as quickly as possible and the project team should not be needed for that. Skilled project team members need to return to their day job, or launch another project to keep them productively busy.

This view of projects gives some interesting conclusions:

•  A good project produces deliverables that are value for money. Whether or not a deliverable is value for money depends on the changes and benefits that the deliverable underpins. If something costs £100 and it pays back £300 it may be worth investing; if it pays back £80 it probably isn’t.
•  Good deliverables are effective ones. They help operations make those changes that are necessary to allow an improvement in performance or development in capability. ‘Help’ means helping operations to change quickly, so benefits can start to be realised and effectively, so that the full value of benefits can be delivered
• Projects should consider what business operations need to make effective change and accrue benefits – projects can then define what deliverables are needed and design them to be cost-effective. In some cases it may pay to spend more time on a deliverable just to be sure it is more likely to be effective.
• Projects should include two risk areas when they conduct their risk planning: that a change will not happen as effectively as needed, leading to poor benefit realisation and that the logic behind the link between change and performance improvement is wrong or incomplete
• And finally, operations are held accountable for delivering the changes and benefits and agreeing with the project what deliverables they need to achieve this. It therefore becomes operations best interest to take an active project board role to make sure that the project delivers the right products to an acceptable level of quality.