Project Success is in the Eye of the Beholder
A common method of evaluating the performance of a project team is to determine if they met approved scope, time and cost baselines. While PMI and other project management advocates have spent significant effort in elevating the perspective of project managers to influence achieving expected business outcomes, most still consider themselves successful if they have met the triple constraint.
Assessing this this would seem to be a relatively straightforward exercise at the end of each project – if the project’s customer has confirmed that approved scope has been delivered, and actual cost and end dates matched the approved budget and timelines, you’d expect that teams should be able to pat themselves on the back for delivering one more successful project.
In a perfect world, projects never experience any changes and there would only ever be one set of baselines. There would be little doubt that delivering originally defined scope on time and on budget could legitimately be considered success.
However, as we know, change is pretty much the only thing we can count on when managing projects.
Some changes are driven by our customers – as their knowledge of what they want evolves to meet their expected outcomes, they will come forward with requests for scope change which after due analysis and approval would usually result in the creation of new cost and time baselines. In such cases, if the project team has successfully been able to deliver to these revised baselines, then they should be happy.
Where things get murky is when changes to project cost or time baselines are not caused by scope changes.
Sometimes, the ability to avoid these impacts is not within the direct control of the project team. Common examples of this include:
- Resource reductions resulting from decisions to lower the priority of a project.
- Budget reductions due to fiscal tightening measures on the part of the project sponsor.
- Schedule changes resulting from cross-project re-prioritization.
In such cases, it would not be fair to hold the project team accountable to their original baselines as no amount of good planning or risk management could have prevented these impacts. Formal project change control should be executed and new baselines established. Then, if the delivery team is able to achieve the new baselines, all should be well.
But how do we handle the scenario of being over budget, behind schedule, or delivering less scope than expected as a result of inadequate planning, underestimation, optimistic resourcing or ineffective risk management. Such cases should be treated as variances and if they cannot be resolved by the end of the project, then the project team should be held accountable for a miss.
However, when we are managing projects for internal partners, you rarely find strict adherence to this “by the book” approach.
Common reasons for not doing so include:
- Projects which fall behind schedule or run over budget usually do so fairly early in their lifetime, and if the expected remaining duration of the project is long, there is a strong desire to avoid unnecessarily punishing the project manager and their team members by showing their project as being “red” for a prolonged period of time. The demotivating effects of this negative reporting are likely to impact team morale and productivity hence further hurting the project.
- As the project manager is usually reporting up into a senior delivery executive, there is motivation on the part of that executive to demonstrate that their department is meeting expectations.
- Schedule delays usually cause increased resource utilization, and if the company’s funding authorization policies dictate that incremental costs have to be managed through formal project change control, then the only way to get the project team to work beyond approved funding limits is to approve a change request.
So what ends up happening is that the internal sponsor is “encouraged” to approve a project change request which formally incorporates the unavoidable variances within a new set of baselines. While paying more or waiting longer to receive expected scope is bad enough, in some cases, if the funding increases cannot be approved or if project deadlines cannot be pushed back, the only option left might be to reduce scope. Then, if the project team claims that they successfully delivered the project based on the revised baselines, the internal sponsor is unlikely to wholeheartedly agree.
If it is not feasible or reasonable to hold project teams accountable for realizing expected business outcomes and if meeting final baselines hides approved variances, perhaps the better compromise is to treat those projects which were delivered to original baselines plus approved externally-driven changes as successful.
To plagiarize Benjamin Disraeli: ‘There are three types of lies – lies, damn lies, and project success.’
Don’t forget to leave your comments below.