When I said it was going to be easy, I lied.

When I said it was going to be easy, I lied.

I didn’t know it at the time. I was standing at the front of a kickoff room, a slide behind me that said twelve months, and a chief financial officer in the second row who wanted to believe me. I told him the hard part was behind us. The business case was approved, the vendor was signed, the team was hired. What remained was work, but known work. I meant every word.

I believed it because I believed what everyone in that room believed: that a transformation with enough money, a good enough platform and experienced enough people will succeed. Two programs took that belief apart.

The first had everything. It was one of the largest merchants in the UK, turning over billions of pounds a year, on systems that dated from the 1980s. So it did what an enterprise of that size does. It signed a cloud ERP deal for some 24,000 users, expected to be worth hundreds of millions of dollars to the vendor over fifteen years, and it gave the programme a name that sounded like a promise. I spent six months inside it, leading the team that kept its integration platform running around the clock ahead of the first major release. Nobody in that building was short of money, talent or intent.

The second had almost nothing. A logistics business that had outgrown Xero, moving its finances onto Microsoft Business Central and connecting them to the fleet management system that ran its trucks. The whole thing cost less than $200,000. The team was five people.

If I’d asked you on day one which enterprise would move, you’d have picked the first. So would I.

By the end of 2019, the business had halted the programme and written off £108 million. The vendor paid back £4.2 million. The business was left running its main systems on the same green screens it had set out to replace.

The logistics business went live. It switched off Xero, and for the first time its trucks and its ledger were in the same picture.

One of those programs spent several hundred times what the other did. In what other field does that happen? A surgeon with a tenth of the training doesn’t outperform the teaching hospital. A builder with a tenth of the steel doesn’t put up the better bridge. But I’ve now watched the under-resourced beat the lavishly resourced often enough that I’ve stopped being surprised by it.

Here is what I’ve learnt about why. The small program couldn’t afford to do everything, so someone had to choose. They got some of it wrong. They decided anyway.

Large programs rarely have to choose. When two executives disagree, there is budget to do both. When a hard question comes up, there is money for another workshop, another option paper, another quarter. Money doesn’t cause the failure. It pays for the postponement.

You may have your own version of this. The go-live you celebrated, with the cake and the all-staff email. The steering committee that reported green for most of a year and red in its last month. The spreadsheet that was supposed to die and was back within a quarter, kept by the same person, who had stopped mentioning it. If you’ve sat through a post-implementation review where everyone agreed the program was a success and nobody could say what had changed, you know what I’m talking about.

Transformation, I’ve come to believe, has very little to do with what you have, and almost everything to do with how you behave when a decision lands in front of you. It isn’t decided by your budget, your platform or your people. It’s decided by what you’re willing to decide.

The seat where indecision lands

I’m a business analyst by trade, and I keep choosing to be one, which needs explaining, because I’ve sat in most of the other seats. I’ve been a project manager with a date on my name, and I hit the date. I’m less proud of that than I used to be. On one program, for a social enterprise that assembled and packed goods for other companies, we went live on schedule, and within days the assembly line stopped. One design choice, the method the system used to build an assembly, didn’t match how the floor actually worked. It took three days to change the method, correct the data and retrain the people. The plan had been green the whole way. On another I badly underestimated the state of the data and how much change the people could absorb, and the program cost twice what I’d said it would. On a third, the system we had to integrate with was one the firm I worked for had built, and it was not good. The best call I made from that seat was one I wasn’t allowed to make. The same social enterprise had been sold a system to run a warehouse where stock went wherever there was space and people found it from memory. I stopped the project for two weeks, without permission, brought in a warehouse specialist, and fixed the floor before we touched the software. Nobody had decided the warehouse was ready. Somebody had to decide it wasn’t. I’ve run service delivery, which is where you find out what a go-live actually left behind. I’ve led teams and built them from the ground up, onshore and offshore, and I’ve built advisory practices from nothing for consulting firms that weren’t mine — one of them a Microsoft business applications practice that grew from a handful of consultants and took the firm to Gold Partner status. None of that is this book. I mention it because every one of those seats has a view, and I know what each of them can see and what it can’t.

The executive sees the steering pack. The vendor sees the contract. The program manager sees the plan, and I know how completely a plan can fill your field of vision, because for years it filled mine. A plan can be on track while the enterprise it is meant to change stands perfectly still. The analyst sits between the person who is supposed to decide and the system that needs the decision, and watches the gap. It usually looks the same. A workshop, a process on the screen, and a question with two right answers: whose version of the customer record wins, which team gives up its way of working, what gets left out so the date holds. Two department heads look at each other, then at the person above them, who looks at their phone. Then somebody turns to me and says, “Just put both in the requirements.” It is not the seat most business books are written from, and I’ve come to think that’s a loss, because it is the one seat in a transformation from which you can watch a decision fail to be made. That is the seat I chose, and it is why I’ve stayed in it.

Every decision an executive doesn’t make arrives, eventually, on an analyst’s desk disguised as a requirement.

I have sat in that seat through over a dozen end-to-end enterprise programs: banks, logistics businesses, government agencies, retailers. Some of those programs went live on time. Some went live late. A couple did not go live at all. What I’ve learnt, across all of them, is that the outcome had almost nothing to do with which of those categories they fell into. The technology was not once the reason an enterprise failed to move. Not once. The technology, I’ve found, is the one part of a transformation that reliably does what it’s told.

What failed was upstream of it. A portfolio funded at sixty per cent across fourteen initiatives because nobody would rank them. A chart of accounts debated for eleven weeks because the question belonged to two executives and neither would own it. A pilot the board loved that consumed forty per cent of a sponsor’s attention and carried four per cent of the value. A vendor allowed to write the roadmap because the client had never written one. None of these are technology problems. All of them are decisions, and in every case the decision was available to be made, by a person with the authority to make it, and wasn’t.

What this book is

This is not a book about ERP. ERP is in it, because ERP is where I learnt this, and because an ERP program remains the most honest stress test I know of an enterprise’s ability to decide. It touches every function, spends every kind of resource, and cannot be finished without a hundred trade-offs that only someone senior can make. If you want to know whether an organisation can move, watch it try to replace its core systems. But the subject here is the moving, not the systems.

The argument runs like this. Every transformation draws on six enterprise resources: capital, capacity, attention, data, architecture and risk. At any given moment one of the six is the constraint on everything else, and in my experience that constraint is almost never physical. It is a decision no one has made. The discipline this book describes, which I call DECIDE, is a way of finding that decision, making it, and making it hold. It is not a methodology. There is no certification program. You have been sold enough of those. It is a lens, a language and a discipline for the person at the top of the enterprise, and it asks more of that person than most frameworks are willing to.

I have tried to write the case as I would make it to a client: plainly, with the strongest counter-argument given its hearing before I take my position. Where I say “most” or “never,” I mean it as testimony from the programs I was in, and I have said so. Where I lean on someone else’s numbers, they’re in the notes. Where I lean on someone else’s thinking — and I do, from a shelf most of my readers will recognise — I’ve said so where it happens, in a line, and moved on.

The shape of the argument

The book has four parts, and they follow the order in which I learnt this.

Part I, Why It Keeps Failing, is the diagnosis. It says that transformation fails at the leadership layer before it fails anywhere else; that a strategy is what you fund at the expense of something else, and most transformation strategies aren’t; and that delivery is not value, and the gap between them is where the money goes. Underneath all three sits a decision nobody is making.

Part II, What Leaders Must Own, starts with what that decision is about: six resources every transformation draws on — capital, capacity, attention, data, architecture and risk — and, at any given moment, the one of them nobody is deciding about. It then takes the three that nobody manages, one at a time: the capacity of people to absorb change, the shape of your future costs, and attention. Of each it asks the only question that matters at the top of an enterprise: what part of this cannot be delegated? It ends with attention, because that is where I’ve watched most transformations actually stall, and because the person they stall in front of is usually the person reading this.

Part III, The Discipline, is DECIDE, one chapter per step: declare the intent, expose the demand, constrain the load, invest fully, defend the decision, evaluate the value. It is short on ceremony and long on the moments where the discipline bites — the trade-off between two of your direct reports, the initiative everyone knows is dead, the vendor roadmap that has quietly become your strategy.

Part IV, The Enterprise That Moves, is what it looks like when this holds: an enterprise that has designed how it runs rather than inheriting it from its systems; that runs its systems of record — ERP, CRM, portfolio, analytics, AI — as one system of change, with no finish line, because change has become an operating condition rather than a program; in which AI multiplies discipline rather than exposing its absence; and which can change direction without chaos. The toolkit at the back holds the one-page version for your board and a starter path for the first ninety days.

Each part opens with a scene from one engagement, told from the seat I described above. Where a failure is on the public record I’ve kept to what is public. Every engagement, mine and others’, is anonymised: no client, employer or colleague is named, and in places the engagements are combined. The decisions in them are real.

Who it’s for, and how to read it

I’ve written this to the executive who owns the outcome: the chief operating officer, the chief information officer, the divisional head with a transformation on their name and a board that wants to know when. If that’s you, the book is an argument about what you personally cannot delegate.

I expect it will also be read by the people who deliver: portfolio leads, program directors, project managers, architects, analysts. They already know most of what’s in here; they usually knew it before I arrived. They’ve been trying to say it upward for years, in language that keeps getting translated into a risk register. If that’s you, this is the case you’ve been trying to make, written to be handed to your boss. The one-page version for that purpose is at the back.

Either way, here is what I’m promising. By the last page you should be able to name the one decision your transformation is waiting on, say why it is yours, and have a way of making it hold. The book is built to get you there rather than to tell you about it. Every chapter ends the same way. A few lines set apart, because they are the ones I hear repeated back to me. A canvas that holds the chapter’s argument on one page, in a shape you can put in front of your executive team without the chapter. And an exercise for that team — half an hour, no pre-work — that turns the argument into a decision. Work through them as you go and you will not finish with notes. You will finish with decisions made.

Read it straight through, once. It is short enough to, and I’ve written it to be read that way: the argument builds, and the six resources make more sense in each other’s company than alone. After that, the toolkit at the back gives you the paths by role and the exercises by chapter, and you can return to whichever part the week demands. I wrote it to be read. I’ve structured it to be returned to.

What I say now

The system from that kickoff room went in. A year after go-live the CFO asked me, without malice, what exactly had been transformed. I didn’t have an answer he would have accepted. I have one now, and it took me over a dozen programs to find it.

I’ve stopped telling clients it will be easy. The system will go in; that part I can still promise, more or less. Whether the enterprise moves is a different question, and it isn’t a question about the system. It’s a question about the handful of decisions sitting in a queue in front of someone who has been too busy, too polite or too uncertain to make them.

None of this is easy. All of it is decidable.

The wall of the program office is covered in initiatives, and the chief operating officer is proud of it.

Fourteen of them, each on its own A3 sheet, each with a sponsor’s name, a traffic light and a go-live date, arranged in three rows under a banner that carries the program’s name. He walks me along it the way you’d walk a visitor along a trophy cabinet. I’ll call him Marcus. He isn’t one person and that isn’t his name, but the wall is real, and so is the pride.

“Two years of work,” he says. “When I got here there was no portfolio. Nobody could tell you what was in flight. Now it’s all here.”

It is all there. I count, because counting is what I do in a first week: fourteen initiatives, eleven vendors, four platforms that haven’t been chosen yet, one ERP replacement with a go-live nine months out that everyone in the building calls “the date,” and one artificial-intelligence pilot in the top row with a green light and a sponsor’s name that is also the chief executive’s.

I’ve been brought in to run the analysis on the ERP. That is the brief on paper. The brief in the room, which Marcus gives me standing in front of the wall, is different. “The board has given us two quarters,” he says. “They want to see the enterprise move. Not the program. The enterprise. I need someone who can tell me where it’s stuck.”

I ask him where he thinks it’s stuck.

“Nowhere in particular,” he says. “That’s the problem. Everything’s green.”

On the Tuesday the vendor comes in to present the roadmap.

You know the session. The account director opens it, the solution architect runs it, and somewhere on slide four a diagram appears with three horizons and a curve going up and to the right. This one has eighteen months on it. Phase one is the date. Phase two is “extended capabilities,” which on inspection means the modules the business hasn’t bought yet. Phase three is “intelligent operations,” which means the AI features the vendor is going to release next year and would like the client to be first to adopt.

I looked at the vendor’s public product calendar last week. The roadmap’s phase boundaries match its release dates to the quarter.

There are nine people from the business in the room. Not one of them asks what the enterprise will stop doing in order to do any of it. Two ask whether phase two can be brought forward. Marcus thanks the vendor for “a really clear plan,” and I understand, watching him, that he means it. It is the clearest plan anyone has shown him in two years, and it belongs to somebody else.

I write two things in my notebook that afternoon. The first is who owns the roadmap? The second is the name of the account director, because I have a feeling I’ll be writing it again.

Wednesday is the steering committee, and the question I ask in it is the one that gets me the engagement, though I don’t know that yet.

It is a well-run meeting. The pack arrived on time. The program director takes the room through the fourteen sheets in the order they hang on the wall, and the room agrees with each of them. Then the date comes up, as it does every fortnight, and the ERP lead says what ERP leads say nine months out: on track, some risks, mitigations in hand. Marcus asks whether there is anything the committee needs to decide. There isn’t.

I ask if I can ask one question. Marcus nods, the way you nod at a new consultant.

“If the date slips,” I say, “which of these fourteen do you stop to save it?”

The silence has a texture to it. It isn’t hostile. It is the silence of a room that has never been asked, and is working out, individually, whether the question is rude.

The program director answers first, because that is his job. “We wouldn’t need to. The PMO exists so we don’t have to choose. We resource across the portfolio.”

“Resource with what?” I say. “The same finance team is on the ledger design and the two reporting initiatives. The same architects are on four of these. The same change lead is on six.”

“We’d re-phase.”

“Re-phase which one?”

He looks at Marcus. Marcus looks at the wall. And Marcus, to his credit, says the honest thing, which is “I’d need to think about that.”

Then the meeting moves on, and the AI pilot gets its update, and the room warms up again, because the pilot is everyone’s favourite child. It has a demo. It has the chief executive’s name on the sheet. It has, though I don’t know it yet, a share of the executive team’s attention that bears no relationship to what it is worth, but that is a later chapter. On the Wednesday it is simply the only initiative in the room anyone seems happy to talk about.

The chief financial officer catches me in the corridor afterwards. I’ll call her Elena, with the same caveat.

“You asked the right question,” she says. “I’ve been asking it for a year. I get the same answer.”

I ask her what she thinks the answer is.

“Half of them. We fund all fourteen and we finish none of them. I sign the releases. I know what we’ve spent and I know what’s landed.” She says a number for what has landed. It is small. “The board’s two quarters aren’t about the program. They’ve seen the program. They want to know whether this business can do something different from what it did last year, and right now I couldn’t tell them yes.”

I give her the answer I’ve learnt to give: the system will go in; whether the enterprise moves is a different question. She has heard the first half before, from vendors. The second half she hasn’t.

“A different question about what?”

“About the nine decisions on Marcus’s desk that nobody’s made.”

She asks how I know it’s nine. I tell her I’ve counted. It’s Wednesday.

By Friday I have a page.

Nine decisions are waiting on the chief operating officer. Some have been waiting for weeks; the oldest, on which of two order-to-cash processes the new ledger will follow, was raised in a workshop four months before I arrived and has a comment thread thirty entries long. Fourteen initiatives are drawing on the same three scarce teams. Eleven vendors hold between them more of the roadmap than the enterprise does. One pilot holds more of the executive’s calendar than the ledger that everything else depends on. And the enterprise has two quarters to show the board it can move.

There isn’t a technology problem on the page. I want to be fair to the people on the wall: the platforms are good ones, the vendors competent, the program director conscientious. The problem is that the wall is an inventory of intentions, and an inventory of intentions is not a strategy, whatever the banner says.

I go to see Marcus at the end of the day and put the page in front of him.

He reads it twice. Then he says: “So what do I do?”

I say: “Decide. Starting with the oldest.”

He says what they all say, and what I would have said in his chair. “It’s not that simple. You’ve seen what we’re dealing with. The platforms. The vendors. The data.”

It isn’t simple. But it is that.

Digital isn’t the problem. Leadership is.

The post-implementation review had one slide for root causes, and I could have written it before I walked in.

Technology complexity underestimated. Vendor performance below expectation. Organisational readiness lower than assessed. Three lines, three passive constructions, nobody’s name on any of them.

You’ve sat through that review. Depending on your seat, you may have presented it. You know the slide I mean: the one where every cause is a noun and nobody is a subject. The program had run two years over, cost close to double the business case, and delivered a platform the business was quietly working around. Forty people nodded, because the slide was true in the way a horoscope is true. It described everything and blamed nothing.

I’d spent eighteen months on that program as the analyst between the executives and the system, and I knew where it had actually broken. It broke in month four, when two general managers could not agree on whose order-to-cash process would become the standard, and the sponsor decided not to decide. Everything after that, the dual configuration, the integration rework, the vendor change requests, the “readiness gap,” was the cost of one absent decision, compounding. None of it was on the slide. It couldn’t be. You cannot write the sponsor avoided a fight into a root-cause analysis and expect to be invited to the next one.

You’ve heard the sentences that go with that slide. Digital is hard. AI is moving too fast. The technology is too complex. The organisation isn’t ready. If you’re honest, you’ve said at least one of them in the last year. I have too, in rooms where saying the true thing would have cost me the engagement. I’ve come to hear them as a single sentence with four endings, and the sentence is: it wasn’t us.

Why we blame the technology

What’s hard is not the technology. What’s hard is leadership at scale: making clear decisions when everything feels important, political and urgent; saying no when every executive at the table has a “strategic” initiative; owning trade-offs in a culture that rewards activity over outcomes. You know how hard that is. You’ve had the conversation with a peer where you both knew one of your programs had to go, and you both left the room with both programs intact. That is the hardest thing I’ve watched senior people try to do, and most of us, most of the time, find a way not to.

So we blame the technology, because a platform doesn’t defend itself in a steering committee. A vendor, at least, can be blamed in a contract dispute. But the executive who didn’t make the call in month four is still in the room, still senior, and still needed for the next program. Digital transformation only looks like a technology problem because technology is where poor leadership finally becomes visible.

In my experience enterprises don’t fail because they lack capability. I have never worked in one that couldn’t, on paper, do what it set out to do, and I doubt you have either. They fail because they avoid clarity: choosing what truly matters, protecting capacity, making prioritisation explicit, owning consequences. And because avoiding clarity feels like nothing at the time, it never appears as a cause. It appears later, wearing the shape of whatever got built on top of it.

If you want to know why your transformation stalled, don’t look at the architecture diagram. Look at how funding was decided, how priorities were negotiated, how conflict was avoided and how accountability was diluted. The technology is a mirror, and AI has made it a less forgiving one. Before AI, an organisation could survive duplicate systems, messy data and confused ownership, because the cost arrived slowly and could be managed by hand. AI removes that buffer. It is not a product, a project or a program; it is an amplifier of whatever discipline the enterprise already has. Where that discipline is weak it magnifies the weakness; where it is strong it compounds the advantage. In the past, bad decisions were expensive. Today they are exponential. So the question I now put to leadership teams is not how they will adopt AI, but what kind of enterprise they are building that AI will operate inside. AI does not adapt to dysfunction. It exploits it.

Technology can’t argue back. That is the whole reason it gets blamed.

Over-governed and under-decided

You know the meeting. The pack lands the night before, ninety pages, with a decision requested on page seventy-one that nobody will reach. The first forty minutes are status. The chair asks if there are any concerns. There are none, because the concerns were settled in the corridor beforehand, and the corridor settled them by agreeing to raise them next time. Everyone leaves with an action to “socialise” something.

I want to give governance its due before I go after it, because I’ve built a fair amount of it. Steering committees, stage gates, business cases, portfolio tools, investment frameworks: these exist for good reasons. Boards need auditability. Capital needs discipline. Large organisations cannot run on a handshake, and nothing in this book argues for less governance in that sense.

But I have watched those same structures become the mechanism by which decisions are avoided rather than made. Most organisations I’ve worked in are over-governed and under-decided. They have every forum a decision could be made in, and no one accountable for the quality of the decisions made across the transformation. So governance becomes theatre. Meetings multiply. Documents grow. Clarity shrinks. And leadership calls it “complexity.”

On one program I kept a private tally. Over two years the portfolio board met twenty-three times, reviewed several hundred slides, and made no stop decisions. Not one initiative was cancelled, paused or descoped in two years, during which the enterprise’s delivery capacity roughly halved under the weight of what the same board had approved. Every meeting was well run. Every pack was on time. By any procedural measure the board was functioning. It just wasn’t deciding.

Ask yourself when your portfolio board last stopped something. Not descoped. Not “paused pending review.” Stopped, with the money and the people reassigned. If you have to think about it, you have your answer.

It isn’t complexity. It’s indecision wearing a process costume.

Negligent, not ambitious

You’ve said “let’s run it in parallel.” So have I. It is the most reasonable-sounding sentence in the room, and it is the one I most want you to hear differently by the end of this chapter.

Every time you approve an initiative without removing another one, you are not being ambitious. You are being negligent. I know how that sounds, and I’ve had a hard time landing it in boardrooms, because it sounds like an insult and is meant as arithmetic. Capacity is not theoretical. It is brutally finite. There are only so many skilled delivery people, business subject-matter experts, architects, change leads and, above all, executive decision hours, and you know roughly how many of each you have. Yet enterprises plan transformation as if capacity were elastic, as if people were an infinite resource, attention replenished overnight, and governance created capacity. It doesn’t. Governance without prioritisation just distributes the overload more evenly.

Parallel to what? Parallel to exhausted teams? Parallel to a fragile architecture? Parallel to a portfolio that was already too big? “Parallel” is almost always code for “we don’t want to choose.” And not choosing is still a decision. It just happens to be the worst one available.

Now layer AI on top. AI doesn’t ask politely for capacity; it demands it. It consumes data engineering time, architecture attention, security focus, legal oversight and executive governance. Yet most organisations I’ve seen introduce AI as “innovation,” which is a way of announcing that nothing about how they prioritise is going to change. So AI becomes another pilot, another backlog, another fight for attention, and its promise collapses under the weight of everything it was stacked on top of.

Think of the initiative in your portfolio right now that everyone knows is dead. There is one; you may already have a name in your head. It has a sponsor who has moved on, a team that has quietly shrunk, and a status that has read amber for three quarters. Nobody has killed it, because killing it means someone admitting it was approved in the first place. Meanwhile the people on it are also on two other things, and those are the people leadership will later describe as “resistant to change.” This is why transformation fatigue exists. Not because people resist change; I’ve rarely met a team that couldn’t handle hard change. They cannot handle infinite change. When everything is a priority, nothing feels achievable, everything feels urgent, and burnout becomes structural. The middle managers who carry it, translating six concurrent programs into one team’s Monday, are the ones who get the label. It isn’t resistance. It’s survival.

The sentence that ends with a full stop

You cannot transform what you cannot say no to. I hold that as the first rule of everything in this book, and it is where the DECIDE Discipline begins.

Saying no is not negativity. It is leadership. It protects architecture integrity, delivery morale, investment credibility and strategic focus. Every strong enterprise you admire is not strong because it does more. It is strong because it does less, better. A mentor of mine used to say that “No.” is a complete sentence, and it ends with a period. It took me years to understand how literally he meant it.

The counter-argument is that saying no is politically expensive, and it is. You’ve been in the meeting where the no was available and the room chose “let’s revisit.” Most leadership teams I’ve worked with don’t lack intelligence, or even courage in the abstract. What they lack is the particular courage to declare what actually matters, shut things down, offend a peer with a refusal, admit a past decision was wrong, or protect the future at the expense of the present. So instead they optimise for harmony. And harmony is expensive. Harmony produces bloated portfolios, compromised architectures, overloaded teams and directionless AI strategies, because nobody wants to be the executive who “killed” something. But leadership isn’t about keeping everything alive. It’s about deciding what deserves oxygen.

Look closely at the high-performing enterprises and what I’ve found is that they are not more innovative. They are more ruthless with focus. They cancel projects early, kill platforms that don’t scale, shut down experiments that don’t compound, and refuse vendor roadmaps that dilute strategy. And they do it publicly. That visibility is what creates trust and discipline, a kind of strategic gravity. People stop gaming the system because the system is predictable.

The enterprises I’ve worked in mostly have the opposite: unclear rules, soft prioritisation, negotiated outcomes, political funding. So teams learn to oversell, inflate urgency, attach their work to whatever is fashionable, and rebrand old work as “digital” or “AI.” Not because they’re dishonest. Because the system rewards noise. Governance is a behavioural system before it is a procedural one, and it will get exactly the behaviour it pays for.

Leadership teams ask me how they can move faster. The honest answer is: by choosing fewer things to move. Speed is not created by acceleration. It is created by focus.

Boring is good

Strong leadership, in a transformation, shows up as few priorities, sharp trade-offs, clear decision rights and boring execution. Weak leadership shows up as endless discovery phases, blurred ownership, competing roadmaps and repeated re-platforming. You can tell which one you have from the steering pack without reading a word of it, by counting how many things it is trying to do.

The leadership teams I meet want transformation to be inspiring. It rarely is. Real transformation is boring, disciplined, repetitive and unforgiving of noise, and it is not a delivery problem: you can implement the best ERP in the world and still fail, deploy the most capable models and still stall, build a world-class data platform and still go nowhere. Delivery doesn’t guarantee transformation. What does is operational leadership, not the inspirational or motivational kind: making trade-offs visible, owning prioritisation, protecting capacity, eliminating ambiguity and saying no early.

That is why I’ve stopped thinking of digital transformation as broken. It is finally honest. It is exposing how decisions are really made, how priorities are really set and how power really works, and most organisations don’t like what they see. The first lie they tell themselves is “We need better tools.” They don’t. They need better decisions. Tools don’t create transformation. They reveal decision quality.

This book starts from the premise that follows. Resource discipline is not the whole of enterprise strategy; markets, customers and capability all have their claim on it, and I’ll say so again where it matters. But it is the pillar that decides whether the rest of the strategy ever leaves the page. Enterprises don’t need more technology. They need fewer, better decisions about how six resources are used: capital, capacity, attention, data, architecture and risk. Those are the real constraints on a transformation; technology is only how those constraints become visible. Most leadership teams think their job is to approve initiatives. It isn’t. Their job is to protect the enterprise from overload, fragmentation, short-term thinking, vendor-driven strategy and political prioritisation, and the DECIDE Discipline is how you do that on purpose rather than by exception.

Until that becomes the job, transformation will always feel chaotic, and the post-implementation review will always have a slide that blames the platform.

Disciplined is boring. Boring is good.

Focus

Technology can’t argue back. That is the whole reason it gets blamed.

It isn’t complexity. It’s indecision wearing a process costume.

Every time you approve an initiative without removing another one, you are not being ambitious. You are being negligent.

Canvas — Transformation Theatre

Core truth: Digital transformation and AI don’t fail because of technology. They fail because leadership avoids clarity, trade-offs and constraint.

The lie we tell ourselves: “We need better tools, better vendors, better platforms.” The reality: we need better decisions, better prioritisation and stronger discipline.

Principle 1: You don’t manage initiatives. You manage constraints: capital, capacity, attention, data, architecture, risk.

Outcome of this chapter: the reader walks away thinking, “Our problem isn’t technology. Our problem is how we decide.”

Leadership Exercise — The Clarity Test

15 minutes, leadership team, no pre-work.

1. Each person writes down, without discussion and from memory, the top five digital, AI or transformation initiatives currently in flight. No portfolio tools, no slides. If the lists differ, you already have a clarity problem.
2. Rank them by resource drain, not importance. For each, which consumes the most executive attention, delivery capacity, architectural compromise, data effort and organisational change? Most draining first. This reveals what is actually costing you, not what sounds strategic.
3. For the top three, ask the only question that matters: “If we could only do one of these well, which would we choose?” No hedging. No “eventually.”

Outcome criterion: one initiative named, by the room, out loud.