Project Success Is More Than On Time and On Budget
A project can finish on the agreed date, inside the agreed budget, having delivered everything in the agreed scope, and be a failure. That is not a paradox and it is not a rhetorical flourish. It happens several times a year in most large organisations, and the people involved usually know it at the time and have no framework in which to say so.
The three constraints measure delivery performance, which is one real and useful thing. Success is a wider question, and it decomposes into four, only the first of which a project manager can answer before they leave.
Four questions, answered at four different times
Did we deliver what we said we would? This is delivery performance, answered at handover. It covers scope, schedule and cost, and it is what the project manager gets measured on, because it is the only one of the four whose answer exists while they are still in post.
Is it being used? Adoption is answered about three months later, and it is where most of the gap between delivery and success opens. A system that works perfectly and that forty per cent of its intended users have found a way around has been delivered and not adopted, and nothing in the delivery measures will show it.
Did the intended change happen? The outcome is answered somewhere between six months and two years out. Quote turnaround fell. Complaint volume dropped. The depot dispatched earlier. Outcomes are the reason the project was funded and they are also the first thing to become unmeasurable, because by then four other things have changed as well.
Was it worth what it cost? The value question gets answered rarely and usually never, because everybody involved has moved on and no mechanism exists to bring them back. Section 2.1.2 of The Standard for Project Management is explicit that success is assessed more broadly than against a baseline, and the practical obstacle to doing so is almost entirely about who is still there to do the assessing.
What a project manager is actually accountable for
No project manager can be held to a benefit arriving eighteen months after their contract ends. What they can be held to is leaving the later questions answerable, and that comes down to three things done at the start.
Name the measures. What number, observable by somebody, would show that the outcome happened? Quote turnaround, taken from the same system that measured it before. Referral volume. The proportion of cases handled without a workaround. A measure nobody could collect is not a measure.
Name the owner. Somebody who is not on the project, and who will still be in post, has to own each measure after closure. That is a conversation at initiation, and it is awkward, which is why it rarely happens: it asks an operational manager to accept accountability for a benefit the project is claiming.
Put the measurement in a calendar. A date, an owner and a standing item somewhere that outlives the project: a service review, a quarterly business review, an annual planning cycle. Benefits that depend on somebody remembering are not measured.
On time, under budget, and still quoting in the spreadsheet
An insurer replaced the underwriting workbench used by its commercial lines team, a fourteen-month programme touching about ninety underwriters. It delivered on the agreed date, four per cent under budget, with every item of scope accepted and signed. On delivery performance it was among the better programmes the company had run, and the project manager was congratulated in writing.
At three months the picture looked different. Around sixty per cent of underwriters were still building anything above a certain premium in the old spreadsheet, exporting the result and keying it into the workbench afterwards. The reason was not resistance. The workbench's referral path, for cases needing a senior underwriter's approval, took two days against a few hours under the old arrangement, and for a broker waiting on a quote, two days is the whole race.
The programme had delivered exactly what was specified. The referral path had been signed off by the underwriting director eleven months earlier, at a point when nobody had walked a real case through it from end to end. The outcome the business case had funded, a reduction in quote turnaround, never arrived. Turnaround went up.
Fixing it cost about six weeks of work once somebody noticed, and the noticing was the hard part, because nobody was measuring adoption after the project closed. A named adoption measure with a date and an owner, agreed at initiation, would have surfaced it at four weeks instead of seven months.
The reverse case is worth stating as well. A depot automation project at a logistics company ran eleven weeks late and about nine per cent over budget, and is remembered inside that business as a success, because the dispatch time it was funded to improve improved by more than the business case had claimed. Delivery performance and success are separate measurements, and they diverge in both directions.
For a PMP® candidate, the distinction is worth holding precisely, because situations get built on it. A project delivering to plan with an unhappy sponsor is usually describing an outcome that did not arrive, and a response defending the baseline answers the wrong complaint. A project described as late with a delighted sponsor is telling you the same thing from the other side. The question is what the project was funded to change, and whether it changed. Practising on situations where delivery and success point in different directions is what a structured PMP exam preparation course does with value.
On a live project the useful half-hour comes at the start and not the end. Write down the one number that would show the outcome happened, the name of the person who will own it after closure, and the date it will be looked at. Then send that to the sponsor. If the sponsor will not name an owner, that is worth knowing in month one, because it means the outcome belongs to nobody, and a benefit belonging to nobody does not arrive.
Interested in going further?
Delivering perfectly into an outcome that never arrives is a demoralising way to succeed, and it is commoner than the reverse. Omega's PMP® Exam Preparation works through situations where the baseline was met and the outcome was not.
Assessing project success beyond the baseline sits in The Standard for Project Management, published inside the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A015: When Delivering the Scope Destroys the Value
A125: Budget vs Cost Baseline vs Funding
A203: How to Handle Competing Constraints in a PMP Scenario
A047: Sustainability vs Cost: How Should a Project Manager Decide?
A123: The PMBOK 8 Finance Performance Domain: What It Really Covers
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
