Forget Everything You've Learnt About Project Delivery, Part 3: Business Versus Project Outcomes

Forget Everything You've Learnt About Project Delivery, Part 3: Business Versus Project Outcomes

If there is a silver bullet in the whole area of project delivery it is defining the “desired business outcomes”

There are many project managers who still believe that "on time, on budget and to specification" is the only true measure of their performance, for this they can control.

Many are quite happy to deliver a project to these parameters that is totally unusable by the business (for whatever reason) and still consider the project a "success".

The business does not usually define their true "desired business outcomes" because they don't naturally think that way. They'll ask for what they think they want, which is usually inadequate

This brings us to a point few people seem to have talked about — that project outcomes are not the same as the desired business outcomes.

Most projects (as currently defined) deliver project results (outcomes) that do not enable the business benefits to be realized. This point is glossed over by asserting that the benefits come later and are, therefore, not the project's accountability.

Some benefits do come after the conclusion of the project, some don't. Some benefits are realizable when the system goes in, or some other project outcome is delivered, while some others come later.

But there remains a gap between most projects' deliverables and what is needed to generate the business outcomes, benefits and value expected.

This can be easily seen by taking an in-progress project and asking: "If we 'waved the magic wand and installed everything the project is due to deliver today, would the business have the outcomes it needs to generate the benefits?" In 99 times out of 100 the answer is "no". More work is needed that usually has not been identified or planned.

This points to a fundamental problem with most projects — that their target outcomes and deliverables are not the real outcomes the business needs — and the latter have not been defined.

When we talk to sponsors and project managers they are often clear as to what their project is doing, but when you analyse the documentation closely, the objectives are ambiguous and unmeasurable. The links between the deliverables and the benefits are missing. The business has different expectations vis-a-vis what the project is set up to deliver, and so on.

This expectations mismatch is often dismissed by project managers as the business' unrealistic expectations that the project manager has to 'manage down' to what the project will deliver. No one seems to say, "If that's what they business needs, perhaps our project should be refocused to deliver it."

To illustrate the difference between typical project and business outcomes, consider the difference between delivering:

  • a brick making factory — a project outcome, a new asset, and
  • a factory making bricks — a business outcome, generating revenue.
In the latter case, the factory is delivering benefits (revenue), whereas the factory by itself is not delivering any benefits at all.

But the difference is greater than this. If, as project manager, you're accountable for commissioning the new factory and getting production to 60 percent of capacity you're going to take more care in your design and testing phases as you're going to have to live and cope with the project outcomes. As a result the practical delivered quality of the project goes up.

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

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.


Show Comments