All writing
Industry insights9 min readAuf Deutsch lesen

AI delivery management: seven skills the certificates do not cover

Gartner forecast that 80% of project management work would be gone by 2030. The admin layer really is dissolving — and a new layer is growing that no certificate covers. Drawn from a register of 48 written-up engagements: what the job of a PM or delivery manager is actually made of now.

In 2019 Gartner forecast that by 2030, 80% of project management work would be eliminated — AI would take over the collection, tracking and reporting that fills a PM's week. More than half the runway has now passed. PMI's own research in 2023 found roughly one in five project professionals using AI regularly. The job is still here.

But arguing with the forecast misses what actually happened. The 80% Gartner pointed at — the secretarial layer — really is dissolving, and it deserved to. What the forecast could not see is that a new layer of work was going to grow in its place, and that nobody would issue a certificate for it.

What the tools genuinely absorb

Let me concede the true part first, because I use these tools daily. Status assembly from ticket systems, meeting minutes, first drafts of plans and risk registers, backlog grooming, the translation of the same information for three different audiences — this work is disappearing into the tools, and no one should mourn it. A status report was never the deliverable. It was the excuse for a conversation.

The trap is on the other side of that convenience. AI produces plausible artefacts at zero cost: a plan that looks like a plan, a risk register that looks considered, an estimate with confident numbers in it. Before, a polished document at least certified that someone had spent effort thinking. That signal is gone. A delivery manager's sign-off used to certify effort; now it has to certify verification — and those are different jobs.

What the work actually demands

I keep a register of my engagements — 48 of them are written up on this site, each tagged with the work it actually required. It is one consultant's sample, not an industry survey, but unlike an industry survey you can read every underlying case. Here is what that register says the job is made of now.

Engagements that required each kind of work, out of 48 written-up cases

AI programme delivery19/ 48
Prototyping & demos14/ 48
Assessment & discovery12/ 48
PMO & portfolio12/ 48
Solution shaping & presale10/ 48
Estimation & unit economics9/ 48
Scope & contract governance8/ 48
Delivery recovery7/ 48
Knowledge & context engineering6/ 48
Regulatory & compliance scope4/ 48
Security & trust boundaries3/ 48
Delivery staffing2/ 48
Service demand across 48 documented engagements
Kind of workEngagements
AI programme delivery19 / 48
Prototyping & demos14 / 48
Assessment & discovery12 / 48
PMO & portfolio12 / 48
Solution shaping & presale10 / 48
Estimation & unit economics9 / 48
Scope & contract governance8 / 48
Delivery recovery7 / 48
Knowledge & context engineering6 / 48
Regulatory & compliance scope4 / 48
Security & trust boundaries3 / 48
Delivery staffing2 / 48
My own register, not a survey: 48 written-up engagements, each tagged with the work it actually demanded (most demanded several). One consultant’s sample — but every underlying case is published, so the denominator can be checked.

Two readings matter. First, more than half of these engagements turned on work done before anything was built — assessment and discovery, solution shaping, estimation, scope and contract governance. The centre of gravity of the role has moved upstream, to the decisions a language model cannot be accountable for. Second, two of the tags did not exist in the vocabulary I was certified in: knowledge and context engineering, and security and trust boundaries. Prompt injection is a delivery risk now, not an infosec footnote.

Seven skills the certificates do not cover

Out of that register, the recurring competences. Each one links to a written-up engagement where it was the difference between a project and an expensive demo.

1. Reading data readiness before promising intelligence

The classic PM asks whether requirements are clear. The AI delivery manager asks whether the data can carry the use case at all — and has the standing to say “the model waits until the foundation exists.” In one financial group engagement the entire first funded phase was a data readiness report, gating everything downstream. That sequencing decision was the project.

2. Conditional scoping

AI features carry a kind of uncertainty fixed-scope contracts were never designed for: nobody can promise model accuracy in advance. The skill is writing scope in three tiers — committed, conditional on evidence, out — and giving every model-dependent requirement a manual fallback, so the product still works if the model is late or wrong. A medtech discovery review is what that looks like when it is done before signature rather than after the dispute.

3. Designing the human gate

The most consequential architecture decision in most AI systems is not the model — it is where a person confirms. Which actions the system may take alone, which need a human verdict, and how an override is recorded as a designed state rather than a failure. A contract-analysis build put a human verdict on every clause, and that single decision carried the compliance story, the trust story and the scope.

4. Demo governance

AI projects die in the gap between the demo and production, so what a demo is allowed to claim is now a delivery decision. What is a real model, what is scripted, what is a rule — said out loud, in the room. One prototype won precisely because it admitted its intelligence was a rulebook — auditable, editable, free per conversation. Honesty was the feature.

5. Estimation under model uncertainty

Estimating AI work with deterministic-software habits produces numbers that are confident and wrong. The craft now includes feasibility spikes before commitments, ranges with explicit assumptions, re-estimation gates at scope lock — and a register of estimates against what actually happened, because an estimator who never looks back is guessing with confidence. Publishing plan-against-actual is uncomfortable exactly once.

6. Evidence discipline at machine speed

When artefacts multiply at generation speed, the scarce resource is knowing which of them record a real decision. Decision logs with owners, assumption registers with reliability grades, a paper trail that survives the people who made it. Seventeen architecture decisions written down before the first sprint cost days and saved the argument that otherwise happens in month four.

7. Verification literacy

The delivery metrics of an AI system are not burn-down and velocity. They are override rate, low-confidence rate, escaped defects, drift — how often the humans corrected the machine, and what happened when they did not. When a team reports “the model works,” the delivery manager's job is to ask for the denominator. Showing the operator's console — including where the prompts live — is what it looks like when verification is a first-class surface instead of a dashboard afterthought.

The old job certified that the work was done. The new job certifies that the work is true — and no tool signs that for you.

What does not change

None of this replaces the base craft. Critical paths still slip, stakeholders still disagree, risk still compounds quietly — and accountability still cannot be delegated, to a contractor or to a model. The certificates behind my own name — PMP, SAFe, PSM — are not wrong. They are simply no longer sufficient, and the market has not yet printed the one that covers the rest.

The disclosure, as usual on this site: I sell exactly this work, so I am not a neutral witness. Which is why the chart above draws on a published register you can check, case by case, rather than on a survey you cannot.

Sources

  • AI delivery
  • Project management
  • Delivery management
  • Skills

Dealing with this yourself?

Thirty minutes, no deck. Tell me where your programme is stuck.