The Machine Meets Its Match: Eric Kimberling’s Welcome to the Machine and PRINCE2 Agile Version 2

Eric Kimberling's digital transformation warnings meet PRINCE2 Agile Version 2, with stage boundaries, named roles, assurance and programme governance used as buyer-side protection.

Pink Floyd wrote "Welcome to the Machine" about the music industry chewing up the naive. Eric Kimberling borrowed the title for his 2026 book about digital transformation, which turned out to be the third act of this summer's holiday reading — the same suitcase that carried Drucker's The Practice of Management, and the subject of the two previous PDCA blogs. The casting works uncomfortably well — except in his version, the machine is the trillion-dollar ecosystem of software vendors, system integrators and analyst firms, and the naive newcomer is your organisation, arriving with a signed contract and a press release about its transformation ambitions.

Kimberling's numbers set the stage: by his account, somewhere between 55 and 75 per cent of enterprise software implementations fail, the average cost overrun runs to 189 per cent, and only one ERP project in four is judged a success by the organisation that paid for it. Those figures haven't improved in three decades, and his conclusion is the uncomfortable one: this isn't bad luck, it's a business model. Reading it as a PRINCE2 Agile trainer, I kept having the same reaction on page after page: there's a control for that. So this blog puts Kimberling's diagnosis next to PRINCE2 Agile Version 2 — the 2025 edition built on the PRINCE2 7 base — and checks how the method answers the machine.

The eighteen-month lie

Scheduled honesty beats heroic forecasting

Kimberling's first exhibit is the timeline sold at the pitch: the confident eighteen-month plan that everyone in the room privately knows is fiction, priced to win the deal and renegotiated once you're too committed to leave. The lie works because the buyer commits everything up front against a forecast nobody will be held to.

PRINCE2 Agile Version 2 refuses the premise. Manage by stages means the organisation commits in instalments, planning in detail only the stage it can actually see, with a genuine go or no-go decision at each boundary. Progress iteratively with feedback then fills each stage with working increments rather than promises, and a release map shows what's actually landing and when. A boundary every few months where the business re-decides, on evidence, whether to continue is scheduled honesty — and it's remarkable how quickly an eighteen-month fiction collapses when it has to survive its first stage assessment.

The bait and switch

Eleven named roles versus the vanishing A-team

Kimberling's second tactic is staffing: the sales cycle is conducted by the integrator's finest, and delivery is conducted by whoever was available. The stars who won your confidence dissolve at contract signature, replaced by a rotating cast learning your industry at your expense.

The counter is the least glamorous principle in the method and the one I'd nail to every programme office wall: define roles, responsibilities, and relationships. PRINCE2 Agile Version 2 names eleven roles, from project executive and senior supplier down through chief product owner, product owner, agile coach, team coach, developer and tester — and the senior supplier sits on the project board, personally answerable for the delivery resources they committed. When the people are named in the project organisation rather than implied in a proposal, the switch stops being a quiet substitution and becomes a formal change with a face attached. The distinction between the chief product owner (who owns the project backlog) and the product owners (who own product backlogs) does similar work on the customer side: accountability with names on it, all the way down.

Held hostage by your own system

The method that assumes you're building capability

The tactic Kimberling calls knowledge hostage-taking is the machine's pension plan: the integrator configures everything, documents little, and departs with the only working knowledge of your own system, guaranteeing an aftermarket of dependency that outlasts the project by a decade. His remedy is blunt — build internal capability rather than renting it forever.

Here Version 2 is genuinely stronger than its predecessor. People is one of the five integrated elements inherited from the PRINCE2 7 base, and the new edition surrounds it with organisational change management, co-creation, and the growth mindset — plus two coaching roles, the agile coach working across the organisation and the team coach embedded with one or two delivery teams, whose entire purpose is transferring capability into your people rather than performing agility at them. A project that runs learn from experience properly, and staffs those roles from the client side, ends the project knowing how its own system works. The hostage-takers need the opposite, which tells you exactly how hard to insist.

The rigged scoreboard

Justification, assurance, and six sliders of pre-contract honesty

Kimberling's larger point is systemic: a circular economy of conflicts of interest in which the firms rating the software are funded by the firms selling it, and nobody inside the machine profits from telling you to stop. The project equivalent is the status report that stays green while the delivery turns red, because everyone reporting is invested in continuation.

PRINCE2 Agile Version 2 builds its counter-machine from three parts. Ensure continued business justification forces the stopping question onto the agenda at every stage boundary, in writing. Project assurance answers to the board independently of the project manager, which is precisely the independence Kimberling finds missing in the analyst ecosystem. And before any of that, the Agilometer runs six sliders across the project — flexibility on what is delivered, level of collaboration, ease of communication, ability to work iteratively and deliver incrementally, environmental conditions, and acceptance of agile — asking whether agile delivery actually suits this project before anyone commits. The machine sells the same transformation to everyone; the Agilometer is the instrument that's allowed to say no.

The machine learns to use AI

And so does the syllabus

Kimberling's forward warning is that AI will deepen vendor lock-in unless organisations act deliberately to prevent it — the machine's next upgrade, with your data as the switching cost. Version 2, to its credit, arrived ready for the conversation: the syllabus now includes an explicit learning outcome on using AI to support PRINCE2 Agile, alongside guidance that reaches beyond the project into agile product management and operations. A method that teaches its practitioners to treat AI as a governed capability, inside the same controls as everything else, is a method that read the same warning Kimberling did.

The project isn't the transformation

The programme wrapper the machine hopes you'll skip

Everything above fixes the project, and the machine knows it. An ERP implementation looks like a project; it behaves like an organisational transformation — new processes, new roles, several hundred people asked to work differently on a Monday morning. Kimberling's failure rates live in that gap: the software goes live, the organisation doesn't change, the benefits never arrive, and the machine gets paid regardless. PRINCE2 Agile Version 2 governs the delivery. Adoption is organisational change management, and that sits a level up — in a programme.

The best practice for that layer is the one formerly known as Managing Successful Programmes — MSP 5th edition, now branded PRINCE2 Programme Management. In MSP terms, the ERP implementation becomes one project stream among several: organisational change management gets its own, so does business process redesign (configuring new software around unredesigned processes merely automates the old mess), and so does integration with the existing systems that aren't going anywhere. The programme lifecycle then carries what no single project owns. Plan progressive delivery sequences those streams into tranches; deliver the capabilities coordinates end-to-end testing and cutover planning across all of them; and embed the outcomes covers post-go-live stabilisation — the weeks when the machine has invoiced and gone, and the organisation finds out what it actually bought.

The rest of the machinery targets the same failure mode. A business change manager is personally accountable for adoption, distinct from the programme manager delivering the capability. Tranches end at landing points, where the organisation can redirect or stop on evidence, and the principle realize measurable benefits keeps one question on the agenda after go-live: did anyone's Monday actually improve? None of this is exotic. The NHS Transformation Unit bases its approach to change across one of Europe's largest organisations on MSP and PRINCE2. And I've made the point before, in the NUMMI blog: General Motors held a working proof of a transformed plant inside its own estate for twenty-five years, and with no programme charged with embedding the lesson, it stayed in Fremont. The full programme lifecycle — all seven MSP processes, and what each one does to an ERP — deserves more than a paragraph, so it gets the next blog to itself.

How not to get processed

The informed buyer's method

Kimberling insists his book isn't about despair but about realism — the machine will persist, and the job is to avoid being processed by it. I'd sharpen that for project people: the informed buyer he wants to create already has a method available, and it's been examinable since May 2025. Every tactic in his catalogue works best on an organisation with no stage boundaries, no named roles, no independent assurance and no standing question about justification. PRINCE2 Agile Version 2 installs all four, then adds the agile delivery the vendors promised and rarely define. Wrap that project in a programme run to PRINCE2 Programme Management, and the benefits have an owner after the consultants leave. If you're commissioning a transformation this year, read Kimberling for the threat model and bring the method as the countermeasure, because the machine has a playbook and now you do too. It also closes this summer's accidental trilogy rather neatly: Drucker packed the timeless principles, Kimberling packed the reasons you'll need them, and the sun lounger critic next to mine has formally given up on my holiday reading.