The Machine’s Weakness Is the Programme: MSP and the ERP Implementation

An ERP transformation is not one project. MSP, now PRINCE2 Programme Management, shows how software delivery, process redesign, change management and integration need one benefits-led programme wrapper.

The previous PDCA blog put Eric Kimberling's Welcome to the Machine next to PRINCE2 Agile Version 2 and ended on a promissory note: the project isn't the transformation, and the transformation needs a programme wrapping it. This blog pays the note. If the machine — Kimberling's trillion-dollar ecosystem of software vendors, system integrators and analyst firms — has a structural weakness, it's this: the machine sells projects, invoices at go-live, and leaves. A programme is what's still standing there afterwards, holding the benefits case and asking awkward questions. The best practice for building one is MSP 5th edition, now branded PRINCE2 Programme Management, and it has been institutionalising awkward questions since 1999. If you're commissioning an ERP, a platform migration, or anything else the machine calls "a transformation" on the sales deck, this one's for you.

One contract, four project streams

The transformation the sales deck forgot to decompose

The machine sells you one project: "the ERP implementation", a single line on a contract with a single confident date. Decomposed honestly, it's at least four. The software implementation itself is one stream. Business process redesign is another, and it comes first, because configuring new software around unredesigned processes merely automates the old mess at a higher licence cost. Organisational change management is a third — several hundred people asked to work differently on a Monday morning, which no amount of configuration achieves on their behalf. And integration with existing systems is the fourth, because the new platform lands in an estate full of applications that aren't going anywhere, each with interfaces to build and data to migrate. Four streams, each with its own plan and its own risk profile, and precisely the coordination problem programme management was invented to solve.

The bookends

Only the first and last processes are straight lines

MSP's programme lifecycle has seven processes, and the shape matters as much as the names: only the first and last are linear. Identify the programme comes before any vendor gets near a whiteboard — the mandate, the sponsoring group, a senior responsible owner with their name against the outcome, and an honest answer to whether this is a programme at all. Close the programme sits at the far end, and it closes when the benefits are secured, not when the software goes live. The machine's definition of done is an invoice. MSP's is a changed organisation, and everything Kimberling catalogues lives in the distance between the two.

The cycle in the middle

Five processes that repeat until Monday actually improves

Between the bookends, five processes cycle. Design the outcomes describes the changed organisation — the target operating model, not the software specification, which is roughly the difference between an architect's drawing and a brochure for bricks. Plan progressive delivery sequences the four streams into tranches, each ending at a landing point where the organisation can redirect or stop on evidence. If that sounds familiar, it should: tranches are stage boundaries at programme altitude, and the landing point is where an eighteen-month fiction goes to be re-examined. Deliver the capabilities coordinates the projects themselves and owns the two activities no single stream can: end-to-end testing across the whole estate, and cutover planning for the weekend nobody sleeps. Embed the outcomes covers post-go-live stabilisation — hypercare and adoption, with the business change manager earning their keep. Then evaluate new information feeds what the tranche just taught you back into the design, and the cycle goes round again until the vision is delivered rather than merely installed.

Warning: you might be running a project cosplaying as a programme if…

• The target operating model is the software manual
• Change management means a comms plan and a training video
• End-to-end testing means each vendor tested their own module
• The cutover plan is a tab in somebody’s spreadsheet
• Stabilisation means the same consultants at a higher day rate
• Nobody’s name is against the benefits after go-live

The scoreboard, unrigged

Benefits with names attached

The previous blog called the machine's analyst ecosystem a rigged scoreboard. The programme's answer is the principle the manual states as realize measurable benefits. Benefits get identified during design, mapped to tranches during planning, and measured after embedding, with an owner's name attached at every step. The machine measures success at go-live, because that's when it gets paid. The programme measures it months later, in the operation, because that's when you do.

Names on doors

Accountability the machine can't rotate away

The Kimberling blog covered the bait and switch: the integrator's A-team wins the deal and vanishes at contract signature. MSP applies the same medicine at programme scale, on the client side. The senior responsible owner chairs the programme board and is personally answerable for the outcome — not the delivery, the outcome. The business change manager owns day-to-day adoption of the new capability, deliberately distinct from the programme manager delivering it, because building a thing and getting people to use it are different jobs requiring different skills. The programme office holds the information that makes the landing-point decisions honest. And the sponsoring group above them all keeps the programme tied to strategy rather than to the vendor's release schedule. When those names are on doors, the machine has to negotiate with the organisation. When they're vacant, it negotiates with itself.

The organisations that already run it this way

From Whitehall to the wards

None of this is boutique theory. MSP was developed by the UK government in 1999, and it coordinated the London 2012 Olympic programme, a transformation with a genuinely immovable go-live date. The NHS Transformation Unit bases its approach to change across one of Europe's largest organisations on MSP and PRINCE2. A framework that can carry an Olympics and a health service can carry your ERP — and it was designed by a buyer of transformations, not a seller of them.

How to stop being the market

The programme is the counter-machine

Kimberling's machine profits from organisations that treat a transformation as a purchase. A programme run to PRINCE2 Programme Management turns the purchase back into a managed change: four coordinated streams, seven processes with the learning cycle in the middle, and named people accountable for benefits long after the invoices are paid. Read the previous blog for the threat model, then run the programme as the campaign. And if your current "transformation" is a single project with a confident date on it, the machine has already decided which one of you is the product.