Table of Contents
TL;DR
I have written a book built on the people-process-technology framework, and I have lived multiple transformations. Cross-checking one against the other: every crisis we faced was a people problem or a process problem wearing technical clothing. The paper resistance was people. The near-rollback was a process gap. The server under the desk was a process gap. The framework is correct, and the order is the entire point: technology is the easiest third and the only third executives fund enthusiastically.
One of the digital transformation books I ghostwrote was organized around the people-process-technology framework, PPT, the venerable model that says transformation succeeds or fails across those three dimensions. Writing a book around a framework 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 framework against everything I had lived.
It held. But the version that held is sharper than the version on the consulting slides, so here is the field-tested edition.
Running my own failures through the frame
Take every crisis from the transformations in this cluster and sort it honestly. The war to get departments off paper: purely a people problem, job fear expressed as tool preference, solved by retraining, not by any property of the technology. The near-rollback after the big-bang cutover: reads as technical, was actually 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.
Score it: of the crises that genuinely threatened those transformations, technology itself caused approximately none. The machines did what machines do. Every fire started in the other two thirds.
Why the order matters
The framework’s real content is not the list, it is the sequence, and the sequence is the opposite of how organizations naturally spend. Technology is the easiest third: it can be purchased, it arrives on a schedule, it demos beautifully, and vendors line up to sell it. Process is harder: it must be examined, redesigned, and enforced, and it fights back through every exception request. People are hardest: they must be convinced, retrained, and given 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 is 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 have 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
The funding inversion
Here is the framework restated as a budget observation, which is the form executives can act on. In every transformation I have 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 leverage than any platform choice, it is 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.
Using PPT as a diagnostic, not a slide
Here is the practitioner’s version of the framework. 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 have located your problem in the other two thirds, and every dollar spent on the technical fix is a dollar spent decorating the symptom.
And when an executive builds a book on a framework like PPT, the framework is the skeleton, never the flesh. Readers can get the model from a search engine in four seconds. What they cannot get is the author who ran his own scars through it and reports where it held. That is the difference between a book that explains a framework and a book that vouches for one, and only the second kind gets cited.
For more from this series, see the The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.