The Executive Decisions That Make or Break a Data Programme
They fail because the decisions that only executives can make are the decisions that executives find easiest to postpone.
The Fault Is Rarely in the Technology
When a large data programme fails, the post-mortem goes looking for a technical villain — a migration that would not reconcile, a platform that would not scale, a vendor that overpromised. The technology is rarely blameless. But in my experience it is rarely the cause. The programmes I have watched fail did so months before the technical problem surfaced, in a meeting where an executive decision was needed and was quietly not made.
This is the pattern that recurs across complex data programmes: they are not killed by a single technical fault. They are killed by an accumulation of decisions that were delayed, avoided, or left deliberately vague — each one reasonable in isolation, each one buying a few weeks of comfort, and together guaranteeing that the programme runs on assumptions no one has agreed to.
Data programmes are unusually exposed to this failure mode. Their decisions cut across every part of the organisation; their benefits are diffuse and future; their costs are immediate and local; and, crucially, no single executive owns the whole of the outcome. So the hard calls get deferred to a steering committee that admires the problem and adjourns. Deferral feels safe. It is not. In a data programme, a decision not taken is a decision to let ambiguity set the direction — and ambiguity always sets it towards the path of least resistance, which is almost never the path to the benefit.
There are, in my experience, five executive decisions that determine whether a data programme lands. None of them is technical. All of them are routinely avoided.
The Five Decisions
- Scope — what this programme is not going to do. The failure is not an over-large scope; it is an undecided one. When the executive will not say what falls outside the programme, every stakeholder assumes their priority is inside it, and the programme quietly acquires a surface area it cannot deliver. The decision that matters is the exclusion, and it is the one executives most want to avoid because it disappoints someone in the room.
- Resources — whether the organisation will actually fund the answer it says it wants. Data programmes are approved at an ambition and staffed at a discount. The unmade decision is the honest reconciliation of the two: either the ambition comes down to meet the funding, or the funding rises to meet the ambition. Leaving the gap open does not split the difference; it delivers neither.
- Priorities — what gets sequenced first when everything is urgent. Every business unit wants its data first. Absent an executive priority call, sequencing defaults to whoever lobbies hardest, and the programme optimises for internal politics rather than value. The decision is not a plan; it is a defensible order, and the willingness to hold it when the loudest voice objects.
- Risk appetite — how good is good enough, and what the organisation will tolerate to get there. Data work has no natural stopping point; quality, coverage, and control can always be pushed further. Without an explicit statement of how much risk the organisation will carry — in data quality, in migration cutover, in interim manual controls — teams either gold-plate or cut corners, and no one can tell which until it is too late.
- Ownership — who is accountable for the benefit, not just the delivery. This is the decision most often ducked. A programme can have a flawless delivery lead and still have no one who owns whether the data actually changes how the business runs. When ownership of the outcome is unassigned, the programme delivers an asset that no one is answerable for using, and the benefit evaporates on contact with business-as-usual.
A steering committee that reviews progress but will not make these five calls is not governing the programme. It is watching it.
Making the Decision Unavoidable
If the failure is avoided decisions, then the programme manager’s first job is not planning or delivery. It is to make the necessary decisions unavoidable — to convert a vague discomfort in the room into a specific choice that a named person must make, on a date, with the consequences of each option laid out. That is a discipline, and it looks like this.
- Name the decision, not the problem. Data quality is a concern is not a decision. We will accept ninety-five per cent completeness on these twelve critical fields at cutover, and carry the rest as a managed exception is. The programme manager’s craft is to keep reframing worries as choices until the choice is sharp enough to be made.
- Put the trade-off on the table, honestly. Every one of these decisions has a cost on both sides. The job is not to recommend the comfortable option; it is to show the executive what each path costs — in time, money, risk, and disappointed stakeholders — so that the decision is made with eyes open and cannot later be disowned.
- Attach a clock. An open decision has a carrying cost that compounds silently. Make it visible: state what the programme cannot do, or must assume, until the decision is made, and what each week of delay forecloses. A decision with a deadline and a stated cost of delay gets made; one without drifts.
- Record what was decided, and what was therefore accepted. A decision made and not recorded will be relitigated the moment it becomes inconvenient. Writing down both the choice and the trade-off it accepted is what stops the programme from making the same decision three times and honouring it none.
This is where influence, not authority, does the work. A programme manager rarely owns these decisions; the executives do. But the programme manager owns whether they are framed well enough to be made — and, when an executive is avoiding a call, owns the uncomfortable duty of saying so plainly, in the room, before the avoidance hardens into a delivery failure that everyone will later attribute to the technology.
The Real Test of Governance
The comforting story is that data programmes are hard because the data is messy and the systems are old. Both are true, and neither is why they fail. They fail because the decisions that only executives can make are the decisions that executives find easiest to postpone, and because too few programmes are run by someone willing to force those decisions into the light.
The test of whether a data programme will succeed is not the quality of its architecture or the credibility of its plan. It is whether, when a decision is needed, it gets made — clearly, on time, by someone accountable, with the trade-off understood. Everything else is downstream of that.