Aguila IT Consulting All articles
Procurement & Supplier Management

The missing hour: turning IT project closure into evidence for the next business case

Aguila IT Consulting
The missing hour: turning IT project closure into evidence for the next business case

Photo: Kambai Akau, CC BY-SA 4.0, via Wikimedia Commons

Almost every business case submitted in a UK organisation contains a line committing the project to a post-implementation review. Almost none of them happen. The delivery team disperses, the project manager is reassigned, the finance director has moved on to the next pressure, and closure is treated as an administrative act rather than a point of learning.

The cost is cumulative and largely invisible. Suppliers whose weaknesses were known and never recorded are appointed again. Estimates that were optimistic are repeated because nobody wrote down where the optimism came from. The same integration difficulty, the same data migration overrun, the same unrealistic training window reappear two years later in a different department under a different name.

A review is not an inquest. It is the cheapest assurance activity available to a portfolio, and it can be done properly in an hour.

Why the hour is always the first casualty

Three forces work against it. The first is ownership: once the project board is dissolved, no one is accountable for convening anything. The second is discomfort, because a review held immediately after a difficult delivery can read as an invitation to assign blame, and people sensibly decline that invitation. The third is that the promised benefit has not yet arrived, so the review feels premature. That last objection is reasonable, and the answer is to split the exercise: a closure review now, benefit checks at set intervals afterwards.

Fix the terms before delivery begins

The review works far better when its shape is agreed at kick-off rather than improvised at the end. Three things need to be settled early.

First, a benefits baseline. If the business case claims a reduction in processing time or a fall in support tickets, the current figure must be measured before go-live, not estimated afterwards. Second, a scheduled date in the project plan, treated as a deliverable with an owner. Third, an independent chair, typically from the portfolio office or a peer programme, so that the session is not chaired by the person whose decisions are under examination.

State the ground rules in the invitation: the review examines decisions, not individuals, and its output is a written record with actions.

A sixty-minute agenda that holds

Divide the hour deliberately and keep to it.

Minutes 0 to 5 — purpose and rules. Read the ground rules aloud. Confirm that the note will be circulated within five working days and that actions will carry names and dates.

Minutes 5 to 15 — promise against outcome. Put the original business case on the screen. Compare committed cost, duration and benefits with what actually happened. Do not debate the gap yet; simply establish it.

Minutes 15 to 32 — what actually happened. Three things that went well and three that did not, drawn from the team in advance so nobody is composing on the spot. For each negative, ask a single follow-up: was this a decision we would make again with the same information? This separates bad luck from bad judgement.

Minutes 32 to 45 — supplier performance. Assess the vendor against what was contracted: delivery to milestones, quality of resource, responsiveness, clarity of escalation, behaviour at the commercial edges. Record it against the supplier record, not just in the note, so that procurement can see it at the next sourcing event.

Minutes 45 to 55 — benefit tracking. Agree who owns each benefit, what the measure is, and the dates of the 30-day and 90-day checks.

Minutes 55 to 60 — actions. Confirm owner and date for each. One page, no more.

The 30-day and 90-day checks

At thirty days the questions are operational. Is adoption where it should be, measured by usage rather than by licence count? What is the volume and nature of service desk contact? Has data quality held up in the first month of live operation? Have any manual workarounds survived go-live, and if so, does that tell you something about the design?

At ninety days the questions are commercial and strategic. Have the leading benefits moved? What is the actual cost of running the service compared with the estimate? Are there residual risks still sitting on the register with no owner? And critically, has the problem the project was meant to solve genuinely receded, or has it merely changed shape?

Both checks can be conducted in twenty minutes with the benefit owners and a single page of numbers.

Returning the findings to procurement and governance

The review only earns its keep if its conclusions travel. Three routes matter.

Into procurement: contract terms that were tested and found wanting, exit provisions that proved unusable, references that were taken but not verified, and supplier performance records that should inform the next tender or the next renewal negotiation.

Into governance: business case templates that failed to surface a risk, assurance gates that were passed too easily, and estimate ranges that were consistently too narrow. These adjustments are small individually and substantial in aggregate.

Into a lessons library: a two-page note per project, indexed by theme rather than by project name, so that the next manager preparing a business case can find the three that resemble theirs.

Making it routine

A single review changes nothing. The habit is built by reporting at portfolio level, once a quarter, on how many closures included a review, how many actions were closed, and what the recurring themes were. That one-page summary, presented alongside delivery progress, is usually enough to shift behaviour, because it makes the omission visible to the people who approve the funding.

The hour is cheap. The alternative is repeating the same mistakes with a larger budget and a shorter deadline.

All Articles

Related Articles

The plumbing beneath the AI policy: making responsible AI routine in UK mid-market firms

The plumbing beneath the AI policy: making responsible AI routine in UK mid-market firms

Before the ink dries: an IT integration diagnostic for UK acquirers

Before the ink dries: an IT integration diagnostic for UK acquirers

Seven questions to ask before signing another IT renewal