What should a procurement transformation programme actually include?

Programmes with this label vary enormously in scope. The ones that leave a lasting change behind them tend to cover the same six areas, and a programme missing one usually knows which and has a reason that will not survive the second year.

1. 01Spend and contract visibilityWhat is spent, with whom, under what agreement, expiring when, owned by whom. Everything else is planned against it. The spend side is quick wherever there is a single ledger. The contract side is a document hunt, and how long it takes depends entirely on whether anyone has been maintaining a register. Establish which situation you are in before committing to a mobilisation date, because this is the assumption that most often breaks a plan in its first month.
2. 02Operating model and decision rightsMandate, thresholds, approvals, category ownership and the interfaces with finance, legal and IT. This is where the durability of the change lives, and it is the workstream most often reduced to an organisation chart.
3. 03Sourcing and savings deliveryThe pipeline and the sourcing work itself. This workstream pays for the programme and buys the political capital for the harder changes, which is why it cannot wait for the design to finish.
4. 04Contract and supplier managementThe register, named contract owners in the business, supplier segmentation, the performance framework. The least glamorous workstream, and where the recurring risk sits.
5. 05Process and technologyBuying routes, approval flow, master data and the platform if there is one. It follows the operating model rather than defining it.
6. 06CapabilityThe skills the target model assumes, how they are built or bought, and what happens if they cannot be recruited at the grades available. A model that assumes capability the function does not have and cannot acquire is a design fault, not a training need.

The sequence matters more than the scope, because it determines whether the programme still has support when the difficult decisions arrive.

Visibility comes first and comes quickly, because it produces the pipeline and because everything after it is otherwise planned on assumptions. Early benefit runs in parallel with the design work, on non-contracted spend and near-term expiries, because a programme that spends its first six months designing is judged on the design. Decision rights are fixed before the structure is redrawn. Contract and supplier control follows, because that is what stops the delivered benefit leaking back. Technology comes after the process is decided. Capability runs throughout rather than arriving in a final phase, by which point the behaviours have set.

A programme has to fund its own credibility before it starts spending it.

One qualification on early benefit, and it matters in the public sector. A full regulated procedure takes months, so the benefit available in the first two quarters is the benefit reachable through renegotiation, framework call-off and non-contracted spend. Anything requiring a full process lands later, and a business case that assumes otherwise is setting up a miss that will be attributed to delivery.

Write down the interim operating model as well as the target, because the function has to keep buying things while the change is happening and someone will be judging it in the meantime.

These programmes rarely fail on plan quality. They fail on a small number of governance points that get settled by default, and each one has a mechanism rather than an intention behind it.

1. 01Name the benefit owner outside the programmeA programme director owns delivery. Somebody has to own the benefit, and in practice that is the budget holder whose budget will be reduced, which is why it defaults to nobody unless it is named. The mechanism is the benefit record: the budget line, the month it reduces, the budget holder's name on it, and finance's confirmation.
2. 02Give decisions a route and a clockThe most common cause of drift is not a wrong decision, it is a decision waiting several weeks for a forum that meets monthly. The mechanism is a named decision maker with standing delegation between boards, and a decision log with a response time attached.
3. 03Make the reporting hard to softenReporting that has been optimistic for two quarters cannot become accurate in the third without a difficult conversation, so it stays optimistic. The mechanism is an assurance line that does not report through the programme: internal audit, or a review commissioned by the sponsoring executive rather than by the programme.
4. 04Assume the sponsor will changeOver the length of one of these programmes, sponsor change is close to a certainty. The mechanism is a written mandate that survives the individual, a benefit owner in finance rather than in the sponsoring directorate, and a scope re-confirmation at a set interval so that a new sponsor inherits something explicit rather than something assumed.
5. 05Set the boundary of the programme's own authorityWhat it may change on its own and what has to be escalated. An unclear boundary produces either paralysis or a surprise, and usually both in sequence.
6. 06Decide who owns the change after it closesNamed ownership of the operating model, the pipeline, the register and the supplier framework, agreed before the team disperses rather than in the closure report.

Around the middle of a programme there is a point at which it becomes clear whether the benefit is going to arrive. The signals are consistent and they are visible before the numbers move.

• The pipeline has stopped moving between stages, and the lines that are stuck are the specification and demand ones, which means no budget holder has agreed to anything.
• Delivered benefit is being reported by the programme rather than confirmed by finance.
• The operating model work has produced a structure and the thresholds are unchanged.
• Sourcing resource has been quietly reassigned to business as usual and nobody recorded the decision.
• The technology workstream has become the programme, and other workstreams are reporting progress in terms of readiness for it.

Where several of those are true, the recoverable move is to narrow rather than to accelerate. Take the workstreams that can still deliver, name what is being deferred and say so openly, and re-baseline the benefit case against what will actually be delivered rather than against what was approved. That conversation costs the programme credibility once. Continuing to report the original case costs it the credibility of everything it delivers afterwards.

It is also worth having an explicit stopping point agreed at the start: the conditions under which the programme would be halted or descoped, decided when nobody is defending anything. Almost no programme has one, which is why almost none of them stop.