The Project Triangle is the classic view of a project's success; have the project objectives been delivered to Time, Cost and Quality / Scope criteria? However, while this is appropriate for measuring the success for the project team it doesn't take account of the key reason why the project should be undertaken - the benefits.
The Benefit case is the responsibility of the Project Owner (typically the Project Sponsor) so this is his/her success measure. The Benefit case should be part of the initiation of the project and kept under review during the project. Ideally a Benefit Realisation Plan should be produced during the project to make this more specific and determine how and when it will be measured. Measurement can be many months after the project is closed down.
A project which fails in one dimension can still succeed in the other. A good example of this is the Sydney Opera House construction project. This project failed spectacularly on the classic TCQ dimension of success. But in terms of benefits delivered, there is more positive news. In strict financial review terms the picture still doesn't look great but what is difficult to quantify is the contribution of the Opera House to establishing Sydney (and some say Australia) on the world stage through this iconic structure and world class performing arts centre.
Success should be measurable
In a race, the winning line should be clearly marked and the same applies to both dimensions of Project success.
For the Project Team, the definition of success should be agreed within the Project Definition in a SMART way. This is likely to involve the Time, Cost, Quality/Scope triangle in some way. If all 3 factors are defined, I will always look to define the priority order. So if the project is under pressure, which factor does the Sponsor really want to achieve at a possible (slight) loss to the other factors? A classic example in IT Projects is that the implementation date of the new system is the critical success factor and the Sponsor may reluctantly accept some reduction in scope or maybe a slight overspend to achieve this.
For the Project Owner, the definition of success starts with the Benefit Case. However, this may need augmentation by a Benefits Realisation Plan, created during Project execution, to more specifically define who and how the benefits will be realised and thus concretely define the Success line.
An Analogy to help understanding
Cook is captain of a sailing ship and crew. Captain Cook has been asked by the Government to deliver some living animals to a remote island in 1770 which are intended to breed and then support a colony on the island in 2 years time. He needs to deliver the animals alive on the island in 2 months time navigating the difficult waters to get there in his sailing ship.In terms of Project roles:
- Project Owner => Government
- Project Manager => Captain Cook
Captain Cook and his crew of merry men can consider the project successful if they deposit the animals alive on the island within the next 2 months. However the Government will only deem the project successful if the animals breed sufficiently to support the colony in 2 years time i.e. the benefits have been realised.
As an aside, after the ship set off, the Government determined that there was an island 100 miles away from the original identified island that would better support life. A carrier pigeon was sent to the ship with the change of plan and the Captain sent one back saying it would take an additional two weeks to get there. He achieved this revised target. This is project change control in the 1700's!!!
1 Comments
You never cease to surprise me Mr Willcox. That was simply brilliant, thank-you.
ReplyDelete