A delivery leader I spoke with had run what looked like a textbook AI programme. A clean roadmap. Build in phase one, governance in phase two, security hardening before launch, change management once the agent was live. Every box on the Gantt chart in a sensible order. The board liked the plan because it looked disciplined. The agent shipped on time. Then phase two began, and the programme slowed to a crawl. Adding governance to a system already running took longer than building the system had. By the time the controls were in place, the workflows had reshaped themselves around an ungoverned agent, and unpicking that became its own project. She had not made a build mistake. She made a sequencing mistake, in week one, on a slide nobody looked at twice. This issue is about that decision, why it is the quiet killer of enterprise AI programmes, and what to do instead. First, the two words. A phase is something you finish before the next thing starts. A stream is something that runs alongside everything else for the life of the programme. The whole argument is that governance, security, change management, data readiness and process redesign are streams that enterprises keep mistaking for phases.
A responsible-looking roadmap is often a time bomb. The phased plan is seductive because it looks like maturity. Build first, prove value, then invest in controls once you know the thing works. Nobody wants to spend governance money on an agent that might be cancelled in three months. On paper it is prudent. The logic holds for deterministic software, where the system you sign off is the system you run for years. It breaks for AI, because the system keeps changing after go-live. The agent you governed in phase two is not the agent that ships in phase four. The hidden cost has a shape, and it is worth naming. Call it retrofit friction. The moment an agent is live, stakeholders have adopted it, workflows have bent around it, and the data flows are entrenched. Adding governance now means renegotiating all of it with people who have already changed how they work. The friction is not linear. It compounds with every week the agent runs uncontrolled. The same is true of security bolted on after the architecture is set. The same is true of change management started after the people whose jobs changed have already formed their opinions. Every one of these is cheap to design in and expensive to retrofit, and the phased plan guarantees you pay the expensive version.
Five streams, running from day one. Here is what parallel actually means in practice. Governance co-designed with the agent, so the controls and the system grow together rather than one being forced onto the other. Security in the architecture from the first design decision, not added at the gate before launch. Change management started before deployment, because the people whose work the agent changes need to be moving before it arrives, not reacting after. Data readiness written into the deployment criteria, so an agent does not ship onto foundations that cannot sustain it. And process redesign happening before the agent is even chosen, because the right order is to redesign the workflow first and then drop the agent into a structure built to receive it. Five streams, all live at the same time, none of them waiting for the others to finish. Parallel does not mean five fully staffed teams on day one. That would be expensive theatre. It means each of the five has a named owner and a voice in the design before the architecture and the workflow harden. The intensity rises and falls. Security runs hot during architecture. Change management builds as deployment nears. Governance steps up as the agent gains autonomy. What none of them can do is turn up after the system has already shaped how people work. The test for your own programme is simple. Look at the plan and ask whether these five have start dates inside the build window or start dates after launch. If they live in later phases, the programme is already carrying a debt it has not noticed, and the interest is compounding.
The honest part, and the move to make this week. I will be straight with you. The operating model that runs all five streams well, in parallel, from day one, does not exist cleanly anywhere I have seen. I am in a working group with peers who argue about exactly how to design it, and nobody has the finished answer yet. But the pattern is consistent enough that I have stopped treating it as an open question. Defer governance, security and change until after adoption, and retrofit friction is close to guaranteed. So the practical move is not to wait for the perfect parallel model. It is to pull the cheapest streams forward first. Governance co-design and early change work cost little in the design window and a fortune to retrofit. Start those two before the build, even if data readiness and process redesign lag a little behind. You will not get the sequence perfect. You will avoid the failure mode that gets the rest of the programme cancelled. The order you choose in week one outlasts every technology choice you make later.
One question before you close this issue. Look at your current AI programme plan, the real one, not the version on the board slide. Are governance, security and change management funded as streams that start inside the build window, or queued as phases for after launch? Reply ([email protected]) with one word. Streams, or phases. I read every reply myself. I am building a picture of how enterprises are actually sequencing this, and when it is complete, everyone who replied gets what the pattern shows.
A phase is something you finish. A stream is something you tend. Enterprise AI is all streams, and the programmes that survive treat it that way.
New issues arrive by email first. Subscribe here.
