I have run a lot of programs. Two large eCommerce replatformings. A multi-region SAP rollout. Four digital transformations of varying severity. The playbook had become a reflex — define scope, structure milestones, lock the team, set governance, design the reporting cadence, work the dependencies.
Then I was handed the program that broke the reflex.
The brief
A retail enterprise. Digital transformation. Several hundred applications across the estate. The deadline was the holiday season, and the unspoken instruction was: do it faster than last time, do it cheaper than last time, and use AI to do both. The CIO’s exact words: "I don’t want a status program. I want a working program."
I treated it as a familiar problem with a tighter timeline. I built the WBS the way I always have. I sized the team by application complexity. I drew up the governance forum. I had a financial plan inside seventy-two hours. Everything looked like a clean run.
The conversation that changed it
Subbu, our AI architect, joined the program in week two. In our first working session he explained how delivery would actually work in this program — and I realised within twenty minutes that my plan was a description of a program I was no longer running.
Prompt-driven requirements. Testing agents that wrote and executed their own cases. A optimisation agent that re-ranked what to move next based on telemetry. Documentation generated alongside the code. A deployment pipeline that learned from its own failures.
My plan assumed five constants: fixed scope, fixed timelines, stable team, predictable cost, structured reporting. The model Subbu was describing had none of them.
The five assumptions that broke
Scope. In a probabilistic model, scope is not a contract; it is a range. The AI agents would surface refactor opportunities mid-flight that hadn’t been in the original inventory. Some were worth taking. The plan had no place to absorb them.
Timelines. Velocity wasn’t a function of headcount. It was a function of how well the agents were tuned and how fast the human reviewers cleared the gates. Some weeks we moved twice as fast as my Gantt chart predicted. Other weeks we moved a third as fast because an agent’s output quality drifted and we had to retrain.
Team. My RACI chart had people in it. My actual delivery system had people, agents, and an evolving allocation between them. The number of humans needed in week six was not the number needed in week sixteen.
Cost. The FTE × effort formula was missing variables. Token consumption. Model usage. Agent runtime. Experimentation cycles when an approach didn’t work. None of these had a line in my financial template.
Reporting. Leadership stopped asking "are we on track?" within the first month. They started asking "how confident are we?" Different question. Different artefact. Different cadence.
The moment of realising
There was a specific Tuesday I can point to. We were reviewing the product backlog and the optimisation agent had re-ordered our priority list overnight based on production telemetry. Two applications that had been in week eight were now in week three. Two others that had been in week three were now in week nine.
The right call was to accept the re-ranking — the agent had spotted dependencies that no human had walked. The wrong call was to update my Gantt chart, get sign-off from the steering committee, then update it again next Tuesday when the agent re-ranked again.
I asked Subbu: "Is this going to keep happening?" He said: "If it’s working, yes."
My plan was a description of a program I was no longer running.
What I changed
I stopped trying to lock the plan and started trying to govern the system. The Gantt became a confidence band, not a line. The team plan became a capability plan — what mix of humans and agents we needed by phase, not how many bodies. The financials grew a consumption side that we forecast weekly. The steering committee got a decision pack, not a status deck.
The deeper change was who was driving the work. For twenty years I had assumed the humans on the program were the drivers and any tooling was assistance. On this program the agents were the drivers — the coding agent re-ranked, the testing agent generated, the deployment pipeline learned. The humans were no longer producing the output. They were navigating the agents producing it, defining the next sprint’s scope, reviewing the outputs that mattered, accepting or rejecting the agent’s re-prioritisations, signing off on what went forward. Once I named that, the agent drives, the human navigates, the rest of the plan reorganised itself around the question of who was navigating which agent at any given week, and whether they had what they needed to navigate well.
None of this was unfamiliar in principle. I had run adaptive delivery before; agile had taught me the patterns. What was new was how deep the adaptiveness ran. It wasn’t just the requirements that flexed. The team flexed. The cost model flexed. The reporting flexed. The governance flexed.
What it left me with
We hit the holiday deadline. The cost came in below the original baseline despite the experimentation overhead. The CIO got the working program she’d asked for, not the status program she had explicitly ruled out.
But the more important outcome was the framework I came away with. Six shifts in how I had to operate. Each one a discipline I had been doing well for twenty years that now had to be relearned.
The shifts are the subject of the essays that follow. Start anywhere.