Fenwick Shared Services: an improvement programme that improved nothing

Diagnosis. The programme has substituted activity for change, and the measurement system rewards the substitution.

1. Wrong measure. 'Ideas generated' and 'workshops held' measure effort, not outcome, and are trivially gameable - which is exactly what team leaders are doing by back-dating implemented ideas. The system is teaching the organisation to report rather than to improve.
2. No baseline. Without a defined invoice cycle time, no improvement can be demonstrated, so nothing can be prioritised by value or defended when resources are contested. Six-day approvals is anecdote, not measurement.
3. No pipeline or ownership. 62 ideas with zero implementations is an intake problem with no throughput mechanism: no triage, no owner, no capacity reserved for improvement work, no decision on what is out of scope.
4. The map became the deliverable. A laminated map is a photograph of a past argument. Value stream mapping earns its keep only as a working instrument.

Role of the value stream map: it converts opinion into a shared, measured picture of where work waits. Redo it as a live analysis of one flow - invoice-to-payment - capturing process time versus waiting time at each step, first-time-right rate, and rework loops. That produces the baseline the programme lacks, identifies which few steps actually constitute the delay, and gives the improvement pipeline a defensible prioritisation criterion. Repeat it at a defined cadence so the map shows movement; the map is a control, not a poster.

Intake. A single visible entry point with a light template: what is the problem, which process step, what evidence, what would 'better' look like as a measure. Deliberately reject the urge to require business cases at intake - that is what killed the 62 ideas. Triage weekly, in public, with a stated reason for rejection so submitters learn the criteria.

Prioritisation. Score against three filters: (a) impact on the measured flow constraint identified in the value stream (invoice cycle time, first-time-right), (b) effort and reversibility, (c) whether it needs a decision outside the team. Prefer reversible, small items early - they build credibility and evidence for the larger ones. Keep a stated WIP limit; a pipeline with more items in progress than capacity is a queue in disguise.

Capacity - the part usually skipped. Improvement has to be funded in time, or it competes with the day job and loses. Reserve a defined slice of each team's capacity (for example, one day per person per month) and protect it visibly. Nominate an owner per item with authority to close it, and a single accountable lead for the pipeline.

Two quarters of sequencing.

• Q1: establish baseline; run 5–8 small items on the constraint step; stand up the triage and the dashboard.
• Q2: tackle 2–3 items that require cross-team change (e.g., approval delegation), using Q1 results as evidence for the business case due in nine weeks.

How you know it works: median invoice cycle time against baseline, first-time-right rate, number of items implemented and validated against a measure, cycle time from idea to decision, and whether ideas are still being back-dated. If the only movement is in volume of ideas submitted, the old system has simply been replaced by a new one.

Content.

1. Baseline and current state: measured invoice cycle time distribution, first-time-right rate, cost per transaction, and where waiting occurs in the flow. This alone changes the conversation from belief to evidence.
2. The constraint and a small number of interventions aimed at it, each with an owner and a hypothesis ('delegating approval below £2k removes the two-day manager wait at step 3').
3. Benefits with stated assumptions, split into cash-releasing and capacity-releasing. Capacity release is real but must not be claimed as cash unless a headcount or volume decision accompanies it.
4. Cost and capacity to deliver, including the protected improvement time - otherwise the case is unfunded.
5. Risks and controls appropriate to a shared-services process: control failure, audit findings, segregation of duties if approvals are delegated.

Handling uncertainty. Present estimates as ranges tied to explicitly stated assumptions, and show which assumption each range is most sensitive to. Where evidence is absent, say so rather than manufacturing a point estimate - a CFO will test one number and discount the whole case if it collapses.

Structure the ask as staged. Seek funding for a first tranche whose outcome is a validated result on one flow, with a decision gate before the larger tranche. That converts the case's uncertainty from a weakness into a design feature: the CFO is not being asked to believe the full benefit, only to fund the test. Include the dis-benefit of doing nothing (volume growth against flat capacity) so the case is a comparison, not a request.

Delivery note: bring two operational managers who ran the Q1 items. Peer evidence on a real flow is more persuasive to a CFO than improvement-team advocacy.