Kubair Shirazee

Transformation delivery · Enterprise agility · AI-enabled decision systems



Discovery dies of old age

In June I opened a discovery phase workshop with a council’s complaints team. The wall behind me was already covered. Weeks earlier, the same people had mapped their process on it, sticky note by sticky note.

So my first question wasn’t about complaints. It was about the wall.

Does that still hold true? Or has the world changed between then and now?

It is the question every wall eventually has to answer.

What the room described that afternoon was ordinary and exhausting. Complaints allocated to officers on a spreadsheet, because the case system has no way to allocate them. Three separate contractor portals, each with its own login, opened one after another to find out whether a repair had actually happened. At busy times, a day or two lost before a complaint is even logged, with the acknowledgement clock already running.

None of it was news to the people in the room. The only question was whether anyone would act on it before it went stale.

That is the risk nobody budgets for. Most transformation doesn’t die at delivery. It dies at discovery, of old age.

Discovery phase feature image: a wall of sticky notes fading over weeks and months, until the newest notes ask whether the work is still true.

We have all seen the version that does. A discovery phase enters its fifth month. The interviews are done, the process maps are drafted, and everyone involved quietly knows the report will join the others on the shelf. Meanwhile the person who reported the broken process is still living with it.

Where does a discovery phase actually lose its time?

Not in the workshops. A good session is three hours of the people who run a service telling you exactly where it hurts.

The time goes in three other places.

Discovery drag. Understanding a service gets treated as a research project rather than a working session. Months pass between the first interview and the first decision. The context shifts underneath the work, and the people who gave their time see nothing come back, so they give less of it next round.

The write-up tax. Every hour in a workshop creates a day or more of documentation. The transcript gets typed up, the wall gets redrawn, the findings get formatted into packs for different audiences. Nobody budgets for it, and it is why a discovery method that works beautifully on one flagship project collapses when you point it at a pipeline of a hundred.

The silo. Discovery for a digital fix reliably surfaces things that belong to other teams: a workaround nobody was trained out of, a role that has quietly absorbed three jobs, a system nobody was shown how to use. In most programmes those findings are noted, filed and lost. The same service gets discovered three times by three teams, or not at all.

Drag. Tax. Silo. None of them is a people problem. All three are design problems, which means they can be designed out.

What does a discovery phase need, if not months?

Structure.

At a large London borough council this year, we ran discovery through what became the Accelerated Delivery model: a fixed cycle of nine to thirteen days.

It starts before anyone enters the room. Whatever already exists gets swept up first: complaint records, previous reviews, performance data. From that come a one-page brief, a partly filled map of the service as we understand it, and a few real cases. Where the evidence is thin, the map says so and asks the room to confirm. Nothing is invented to make a document look finished. The fastest way to lose a head of service is to show them a confident map of their service that is wrong.

Then three working sessions with the people who run the service. The first maps the service and its friction, and ends with the room voting on which problem to fix first. The second scores the options for fixing it, including the option of changing the process and touching no technology at all. The third turns the chosen option into a delivery plan for its first slice, the smallest change worth shipping.

Two things make it fast, and neither is clever.

The decision gets made in the room. The person who owns it confirms the choice before anyone leaves, with the people who gave the evidence watching. Not in a follow-up meeting. Not at a board six weeks later.

And governance moves at the same speed. Between sessions, the relevant leads see the outputs and can object in writing by a deadline. If they don’t, the cycle proceeds. Silence is alignment.

If a role owns a decision, it is named. If it only owns an interest, it is kept informed. I’ve written before about who can say yes. This is the same principle with a stopwatch on it.

The result, on the council’s own backlog: use cases moved from analysis to a delivery-ready plan in weeks rather than months.

Where does AI actually help?

Not where most people expect. The AI didn’t make anyone think faster. It took away the write-up tax.

A three-hour session leaves behind a transcript, a few dozen photographs of a wall, and a room full of context that starts evaporating at five o’clock. In my experience, turning that into usable documentation took even a good business analyst two to three days per session, and longer in elapsed time when they were juggling several discovery workshops at once.

We industrialised it. The inputs are fixed: the transcript, the wall photos, and the materials prepared before the cycle. The outputs are fixed: the updated service map, a register of pain points, packs for other teams, draft messages back to the service, and an action list. In between sit people.

Before anything is produced, the pipeline plays back what it understood, and someone who was in the room confirms or corrects it. Errors are cheapest there. Every claim in every output traces back to something said in the room or written on the wall. Where the evidence is missing, the output says to confirm.

None of it touched live records before a data protection impact assessment, and the pipeline ran inside the council’s own systems.

The same write-up now takes less than a day.

The write-up tax in a discovery phase: a three-hour session used to mean two to three days of write-up; with AI-assisted discovery the same write-up takes less than a day.
The write-up tax: the session stays three hours; the write-up shrinks from days to less than a day.

The most important part is the least exciting. Any trained operator can run the pipeline, with no skill at writing prompts. The capability lives in the process, so it survives a resignation, and three cycles can run in parallel to the same standard.

A method that depends on one person’s prompting is still a pilot. We made the AI part deliberately boring.

The analysts didn’t disappear. They moved from typing up what was said to challenging what it meant.

The AI does the assembly. People do the judgement.

Why should one session serve more than one team?

Because the quietest failure in transformation is the insight that dies in the wrong inbox.

Digital, Data & AI runs the session and takes the build. But once the write-up costs almost nothing, the same session can serve more teams than that. Every session also produces three numbered handover packs: behaviour frictions for the change leads, workforce issues for workforce planning, and training needs for learning and development. Each item is marked on a shared map of the service as it really runs, so a change lead and a workforce lead can stand at the same picture and point at the same problem.

Take the complaints spreadsheet. A missing allocation function is a fix for Digital, Data & AI. Who allocates the work, and how, is a workforce question. Why nobody was ever shown a better way is a training one. One afternoon of evidence can feed all of them.

The effect is organisational. Teams that used to commission their own separate discoveries start working from one account of the service, gathered once, with the service’s own staff.

Discovery stops happening three times over. And teams that never got a discovery of their own, often training and workforce, finally get the evidence.

What won’t it fix?

Three things, and it is worth being plain about them.

It won’t fix a decision nobody is willing to own. If the person who should confirm the choice in the room won’t, the cycle produces a beautifully documented stall. That is the subject of my last piece, The pilot worked. Nothing changed.

It won’t stop the wall ageing. Even a fast cycle has gaps between sessions, and the complaints room is proof: the first question that afternoon was whether the work was still true. Speed buys you a fresher picture. It doesn’t buy you a permanent one.

And it won’t remove the friction of moving decisions into the room. Sign-off layers took years to grow, and the people who built careers on them will resist a faster way of deciding, quietly and effectively. Treat that as part of the delivery, not a surprise.

What it does change is the cost of being thorough. Rigour used to be the slow option. Without the write-up tax, it is just the option.

I closed that June session by reminding the room that we were trying to find good, not perfection. Good, this month, beats perfect, next year, while someone is still living with the broken process.

Within two weeks of that session, a prioritised backlog, shaped with the solutions architect, was with the delivery team and ready to build.

The recipe, slide by slide

If you want to try it, here is the cycle in eleven slides: the steps and the rules that keep it safe.

The recipe · 11 slides
Discovery recipe, slide 1: Discovery dies of old age. How to run discovery in weeks, not months, and let AI take away the write-up tax.
Discovery recipe, slide 2: where discovery loses its time. Drag, the write-up tax and the silo. None of them is a people problem.
Discovery recipe, step 1: sweep existing evidence before anyone enters the room, and draft a one-page brief, a partly filled service map and a few real cases.
Discovery recipe, step 2: session one maps the service and its friction, and the room votes on which problem to fix first.
Discovery recipe, step 3: session two scores the options, always including changing the process and touching no technology at all.
Discovery recipe, step 4: session three plans the first slice, and the decision owner confirms it in the room.
Discovery recipe, step 5: governance moves at the same speed. Leads can object in writing by a deadline. Silence is alignment.
Discovery recipe, step 6: industrialise the write-up with fixed inputs and fixed outputs, run by any trained operator.
Discovery recipe, slide 9: keep people in the loop. Play back first, trace every claim, protect the data. The AI does the assembly; people do the judgement.
Discovery recipe, slide 10: one session feeds four teams. Digital, Data and AI takes the build; change, workforce, and learning and development get handover packs.
Discovery recipe, slide 11: write-up in less than a day, down from two to three days, and a prioritised backlog with the delivery team within two weeks. Download the full recipe as a PDF below.

So here’s my question

How old is the discovery your next decision rests on?

If you have a discovery phase in its fifth month, or a wall that has quietly gone out of date, I’d love to compare notes over a virtual chai.

This follows The pilot worked. Nothing changed., on what an AI operating model has to settle. Related: Who can say yes, and does everyone know it?, Nail it before you scale it and the What-Why-HOW-Done Canvas.

Thank you for reading. If you’re new here, I’m Kubair Shirazee, I help people, teams, organisations and communities navigate past the status quo and explore better ways of collaborating and delivering impact.


More writing