One of the digital transformation books I ghostwrote was organized around the people-process-technology structure, PPT, the venerable model that says transformation succeeds or fails across those three dimensions. Writing a book around a structure forces you to test it, and I had unusual test material: my own decades inside transformations at a major national retailer. So I checked the structure against everything I’d lived.
It held, and the version that held is sharper than the one on the consulting slides. I’ve come to resent those slides a little, because they draw the three thirds as equal partners, and in every transformation I lived through they were nothing of the kind.
Running my own failures through the frame
Take every crisis from the transformations in this cluster and sort it.
I’ve been called into more than one mess labeled a technology problem that contained no technology problem at all.
The war to get departments off paper: purely a people problem, job fear expressed as tool preference, solved by retraining. The near-rollback after the big-bang cutover: reads as technical, was process: we had no adequate process for validating production-scale performance before go-live and no pre-decided rollback criteria. The six-figure query optimization: a process gap in migration planning that never asked who re-tunes the query layer.
The server under the desk: a process gap in asset management, wearing a technology costume.
| Crisis | Looked like | Real cause |
|---|---|---|
| Getting departments off paper | Tool preference | People: job fear, solved by retraining |
| Near-rollback after big-bang cutover | A technical failure | Process: no production-scale performance validation and no pre-decided rollback criteria |
| Query optimization after migration | A database problem | Process: migration planning never asked who re-tunes the query layer |
| Server under the desk | A technology problem | Process: a gap in asset management |
Score it: of the crises that threatened those transformations, technology itself caused approximately none. The machines did what machines do. Every fire started in the other two thirds.
Why does the people-process-technology order matter?
The structure’s real content is the sequence, and the sequence is the opposite of how organizations naturally spend. Technology is the easiest third: you can purchase it, it arrives on a schedule, it demos beautifully, and vendors line up to sell it. Process is harder: you must examine, redesign, and enforce it, and it fights back through every exception request. People are hardest: you must convince them, retrain them, and give them credible answers about their own futures, and no purchase order accomplishes any of that.
So the natural failure mode writes itself: fund the technology, gesture at the process, hope about the people, and then watch the people and process problems present themselves as mysterious technology failures, because that’s always how they present. The slow system that is “slow” because nobody redesigned the process feeding it. The failed rollout that “failed” because the workforce using it badly was never brought along. I’ve been called into more than one mess labeled a technology problem that contained no technology problem at all.
Of the crises that threatened our transformations, technology caused approximately none. Every fire started in people or process.Share on X
What is the funding inversion in people, process and technology?
From the podcast
Ben “The Automator” Christensen puts the same point in terms of what the vendor conversation costs you, on Leaders and Their Stories:
If you start from the technology end, you’re probably paying homage to some vendor who has some new sexy tool for you.The budget follows whichever end you start from, so the order is a funding decision before it is a methodology.
The structure also works as a budget observation, the form executives can act on. In every transformation I’ve seen from the inside, the spending ran technology first by a wide margin, process a distant second, people last, usually as a training line item negotiated downward late in planning. The risk ran in exactly the opposite order.
The technology, the funded part, performed. The crises came from the starved thirds: the unexamined process assumptions and the unconvinced, untrained people.
If you want a single structural intervention with more effect than any platform choice, it’s inverting a slice of that budget, moving real money from the technology column into process examination and workforce transition, and defending it when the technology column comes asking for it back. It always comes asking.
My take
Move real money out of the technology column. Every crisis we faced in those transformations was a people or process problem dressed up as tech, and the funded third performed fine. Budgets run in the opposite order of the risk. Fund process examination and workforce transition properly, then defend that money when the technology side comes asking for it back. It will come asking.
Using PPT as a diagnostic, not a slide
The practitioner’s version of the structure is one question. When something in your transformation is failing, require the technical explanation to survive one question: what would this failure look like if the technology were working perfectly? If the answer is “exactly like this,” and it usually is, you’ve located your problem in the other two thirds, and every dollar spent on the technical fix is a dollar spent decorating the symptom.
When an executive builds a book on a structure like PPT, the structure gives the book a skeleton and nothing more. Readers can get the model from a search engine in four seconds.
What they can’t get is an author who ran his own scars through it and can report where it held. A book that only explains the model wastes the reader’s time and the author’s scars, and I’d rather not write that one.
For more from this series, see The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
