I run the delivery side of AI work.

I have spent more than ten years running complex programmes — first inside delivery organisations, now independently. Across a hundred-plus projects the pattern that repeats most often is not a technical one. Teams can build the thing. What they struggle with is deciding what is worth building, saying honestly what it will cost, getting it adopted, and keeping it alive once the initial enthusiasm fades.

So that is the work I sell. Some weeks it looks like strategy: shaping an AI programme so the first funded phase proves something instead of consuming budget. Some weeks it is forensic: an estimate whose engineering rows sum to zero, a specification with another product’s requirements pasted into it, a red project where nobody can name the scope baseline. And some weeks it is construction — a quality system taken from a blank page to a passed certification audit in twelve weeks, or a PMO that runs out of a repository instead of a slide deck.

A large share of my written-up work is estimates, discoveries and decisions not to build — treated as deliverables in their own right. Most consultants publish only the builds. I think the decision paper that stopped a contract from closing on a sixty-per-cent scope gap did the client more good than most builds do, and I keep a register of every estimate against what actually happened, because an estimator who never looks back is guessing with confidence.

The credentials underneath it are classic delivery management — PMP, SAFe 6.0, PSM — applied to a domain where the usual estimates do not hold. AI work has genuine uncertainty in it. Pretending otherwise produces plans that break in month two; I plan for the uncertainty instead.