A transformation programme can look impressively busy on paper: a steering committee meets, several teams produce status slides, pilot projects are running and most indicators are green. Yet cycle times remain unchanged, decisions continue to be escalated and alongside the new processes the organisation still works with its old lists and controls.
The cause is rarely too little project management. Change begins only when the executive team decides three things: Which work will definitively stop? Which scarce resources are genuinely available? Which new behaviours become mandatory in operations? Without these decisions, a programme adds activity rather than reorganising capacity and accountability.
This applies particularly to AI. AI is not a list of tools. It changes work, data, decisions, evaluation, access and governance, as well as the capability of the people working with it. The portfolio must therefore be managed not only by project progress, but also by business value, dependencies and operational readiness.
The BCG Applied AI Index 2026 reports a specific measurement practice: 95% of companies classified as “future-built” use business KPIs or measure AI value directly in the profit and loss account.1 The provider's survey covers more than 1,300 CxOs and senior leaders across more than 20 sectors. The figure applies only to the most mature group, not to the overall sample and it does not prove that tracking causes value. It is, however, a useful reference point for the management question: where and when do we want to demonstrate value, quality and risk in practice?
The first decision is not: which project starts next? It is: Which initiatives do we stop, which foundations do we protect, what do we test under controlled conditions and what may be scaled after evidence has been established?
Activity becomes visible, change often does not
A programme quickly produces visible traces. There are roadmaps, workshops, backlogs and alignment meetings with IT and business functions. The CEO receives a project status indicator. This information is not without value. But it primarily answers whether agreed activities are taking place. It does not answer whether an old work loop has disappeared, whether a decision right has shifted or whether a new approach still holds at month end.
The difference becomes visible in concrete situations. A sales team has introduced an AI-supported workflow for proposal development. Information is brought together from CRM, product data and previous proposals. Yet three people still review every version as before because neither quality criteria nor approval thresholds have been adjusted. The function also continues to maintain an old Excel list to safeguard the status. Processing does not simply become faster. It acquires another handover, a new review point and two competing sources of truth.
This is not a client case, but an illustrative example. It shows a typical management question: which old control step is removed, which remains and who decides when there are deviations? As long as there is no binding answer, AI remains an additional layer on the existing way of working.
The economic cost does not arise from licence fees alone. Teams commit the same subject-matter experts simultaneously to day-to-day operations, data cleansing, pilots and decision meetings. The strongest employees move between urgent client matters, project appointments and rework caused by unclear handovers. An initiative is then delayed not because a team is working slowly, but because the organisation has scheduled its time more than once.
The real constraint: three uncomfortable decisions
I would not start by asking for more ideas. I would ask the leadership team to make explicit commitments on the following decisions.
First: Which work ends? Every new way of working needs room. If a new data flow is established, it must be clear which shadow reports will no longer be updated. If an AI system creates a first draft, a decision is needed on when the former complete manual drafting ceases and when human review remains mandatory. A programme without work removal is often a programme with more work.
Second: Which resources are genuinely reserved? An owner without protected time is a role title, not accountability. The leadership team does not have to allocate every hour centrally. But it must decide which appointments take priority, which specialists are available for how long and which other initiatives will wait as a result. A workstream whose data owner can find time only between month-end close and escalations has no robust mandate.
Third: Which behaviours become binding? The new procedure must not sit in the intranet merely as a recommendation. A sales lead must know from when a particular proposal process is to be used. A leader must know when to review, document or reject an AI recommendation. Operations need escalation routes and fallback procedures. This is precisely where a project becomes a way of working.
These decisions involve trade-offs. Stopping too early can damage a worthwhile capability. Running a pilot for too long can block scarce capacity. A binding rule can create more friction during a transition. The alternative, however, is not neutrality. Those who do not decide the conflict leave it to everyday operations, where day-to-day business almost always prevails.
Manage the portfolio, not merely report the projects
Project status indicators show dates, budget or technical risks. They are not enough for a transformation portfolio. The executive team needs a shared view of which business process an initiative changes, which dependencies must be resolved first, which work will be removed and what evidence will lead to the next decision.
Not every initiative needs to demonstrate directly attributable ROI in the short term. An access model, data inventory, shared quality process or safe decommissioning can be foundations without showing their own returns within a few weeks. NIST AI RMF 1.0 places these tasks specifically in GOVERN 1.5 for ongoing monitoring and review, 1.6 for a risk-based system inventory, 1.7 for safe decommissioning, 2.1 for clear accountability and 2.3 for executive accountability.3 The voluntary framework is not a certification commitment. But it makes clear why AI operations do not end with the introduction of an application.
Such foundation work requires a protection period: a deliberately agreed period during which the team works on a necessary foundation and does not have to provide immediate revenue evidence in every status meeting. A protection period is not a free pass. It has an owner, a clear deliverable, access rights, quality criteria and a review date. It protects against hasty reprioritisation without immunising the initiative from evidence.
| Option | Business condition | Resource and next evidence |
|---|---|---|
| Stop | No relevant process benefit, no defensible priority or the dependency remains unresolved. | The owner closes outstanding work in an orderly way; the next evidence is the documented wind-down of spending, contracts and parallel work. |
| Foundation | A shared foundation for several decisions or workstreams is missing. | A named owner with protected time; the next evidence is usable data, access, quality or governance rules. |
| Test | A specific value hypothesis is plausible, but impact and operational risk are still open. | A small team works on the real process; the next evidence is an agreed value and quality gate, not merely a demonstration. |
| Scale | Benefit, quality, accountability and the operating pathway have been sufficiently evidenced in the relevant context. | The business owner and operational accountability take over; the next evidence is the retirement of the old way of working in the agreed area. |
These four options make visible that “continue” is not a management decision. An initiative is given a function in the portfolio or it merely consumes attention.
AI as a change to the operating system
With AI, the gap between project progress and operational change is especially clear. A working prototype does not yet answer whether the underlying data are reliable, who evaluates results, who receives access, how errors are detected or how employees act in exceptional cases.
The AI Operating System is a methodological structure, not additional software. It connects six layers: Strategy & Value, Processes & Decisions, Data & Knowledge, Technology & Integration, Governance & Evaluation and People & Operating Model. Not every layer needs to be discussed at the same depth for a portfolio decision. Their connection is what matters.
For example, an initiative supporting proposal development may make economic sense. Yet it can still fail in operations if product knowledge is outdated, sensitive client information becomes accessible without control or Sales and Legal apply different approval rules. The appropriate decision may then be Foundation, not Scale. The next step is not to improve another prompt, but to make knowledge, access and quality assurance binding.
This view prevents two common errors. The first is to mistake a tool for transformation. The second is to treat governance as a downstream review. Governance and evaluation define who is accountable, how quality and risk are monitored, which limits apply and how a process falls back in a controlled manner. Enablement, in turn, means more than training. It means that leaders and teams can apply the new decision logic in day-to-day work.
Why historic success rates ask a different question
The temptation is strong to turn a low success rate into a general narrative of failure. That would be inaccurate. In an international McKinsey online survey from 2021 of 1,034 respondents, 31% rated the transformation they reported as successful.2 Success meant a very or completely successful performance improvement and the organisation's corresponding capability to sustain the change. The average covers reported transformations irrespective of the number of interventions used. The survey fieldwork took place from 18 May to 29 June 2021 and covered different company sizes and sectors.
The figure is a historic self-report, not a universal failure rate, not causal proof and not a measure of today's AI projects. Its useful question is therefore not: are we among the 31%? It is: have we defined both performance and sustainment as criteria? Many programmes measure the first part incompletely and not the second at all. A solution delivered on time is not yet an organisation that has changed.