Meridian Self-Service Portal - delivered on time, but was it a success?
Meridian Retail's 'Customer Self-Service Portal' project closed 11 months ago: delivered for £480k against a £500k budget, on the agreed date, and signed off against every documented requirement. The business case promised a 20% cut in contact-centre call volumes and £300k a year saved by redeploying six advisers. Twelve months on, call volumes are down 3%, only two of the five business units have retired their paper forms, and none of the six adviser posts has been removed. The business case was written by the project manager, who left at closure. No benefit owner was ever named, no baseline call-volume figures were agreed with the contact centre, and the only post-project activity was a two-page closure report listing deliverables.
1. Was this project successful? Justify your answer, distinguishing success criteria from success factors.
Read the worked answer
Two different questions are being conflated.
Project success (delivery): measured against the success criteria agreed at the start - time, cost, quality/scope, and stakeholder acceptance. On those measures the project met its criteria: £480k vs £500k, on date, full requirement sign-off, formal acceptance. The project manager delivered what was asked.
Business success (outcome): measured against the benefits in the business case. Here it has failed: 3% against a 20% target, £0 of the £300k annual saving, and only 40% of business units have changed working practice.
Success criteria vs success factors. Criteria are the measures used to judge the outcome. Success factors are the conditions that make success more likely - clear and agreed objectives, a credible business case, visible sponsor support, an engaged senior user community, a realistic plan, competent team, effective change control. Several factors were missing or weak here: no named benefit owner, no agreed baseline, and no authority over the business units whose behaviour drives the benefit. That is the more useful diagnosis, because it explains the shortfall rather than just labelling it.
Verdict: a successful project that has not yet produced a successful business outcome - and the second failure was foreseeable at the definition stage.
2. Identify where benefits management failed and describe what should have been in place at each stage.
Read the worked answer
Definition stage
- A benefits map linking each deliverable to the outcome it enables, and each outcome to the strategic objective.
- Benefits profiles for each benefit, stating the measure, the baseline, the target, the timing, the owner and any dis-benefits.
- Benefit targets validated with the people who must change their behaviour (the contact centre and the five business units), not written in isolation by the project manager. The 20% figure and the six-post saving were never tested for plausibility.
- A named benefit owner with authority over the operational change, agreed before funding.
Deployment stage
- Baseline measures captured before go-live - call volumes by channel and unit, so the 3% figure could be interpreted.
- The benefits realisation plan: who does what, when, to embed the new process (retiring paper forms, re-training, closing the forms channel).
- Tracking of benefit dependencies as a project risk: the benefit depends on a change outside the project's control.
Transition and after
- Handover of the benefits realisation plan and baseline data to the benefit owner.
- Scheduled benefits reviews (e.g. 3, 6, 12 months) with the authority to act on the findings.
What actually existed: a two-page closure report. Nothing in the benefits management process was in place, which is why the shortfall was only discovered by accident.
3. The new operations director asks what can be salvaged now. Recommend actions, in priority order.
Read the worked answer
1. Appoint a benefit owner and re-baseline. Name a single accountable owner (likely the contact-centre head or a business-unit operations lead) and replace the fictional targets with measured ones: current call volume by channel, current adviser headcount, current paper-form volume. A benefit you cannot measure cannot be managed.
2. Diagnose the blocking dependency. The portal works; the benefit is blocked by the three business units not retiring paper forms. This is a business-change problem, not an IT problem. Establish, unit by unit, why: local process, incentives, training, or simply no instruction. Treat it as a change programme with named unit leads and a deadline.
3. Reframe the financial benefit. The £300k saving assumed six posts removed. If natural attrition or redeployment can deliver the saving over, say, two years, restate the benefit honestly and get it approved - an unachievable target that everyone ignores is worse than a smaller, credible one.
4. Reinstate benefit reviews at quarterly intervals with a one-page dashboard against the new baseline, reported to the same forum that approved the business case.
5. Capture lessons for the portfolio: no project should pass definition without a named benefit owner, an agreed baseline and evidence that the benefit dependency sits with someone who controls it.