The gap is not in the analysis, it is in what the analysis produces
Most recommendations do not fail because the thinking was wrong. They fail in the interval between the workshop and the operating environment, where the recommendation has to survive an engineering team, an uninspected data landscape, a process that was described rather than observed, and assumptions that were never written down.
That interval has traditionally been bridged by effort: more workshops, longer documents, a team of analysts who translate the recommendation into a specification that engineering can be held to. That bridge was always imperfect, and the imperfection was expensive in a way nobody could see, because the translation happened after the engagement and was paid for by the client.
A recommendation is an opinion and a working system is a checkable claim
The distinction that matters is between advice and artefact. A recommendation can be well argued and wrong, and nothing in the argument will reveal which it is. A working system, with a defined process behind it, a named owner, a measured baseline and a test set, cannot be wrong in the same way: it either handles the real cases or it does not.
This is why the most valuable thing a consultant can now bring to an organisation is not a longer analysis. It is the ability to make the client's own reasoning concrete enough to be tested, and then to stay in the room while the test runs. A firm that has not adopted those tools is selling the part of the job that has become routine.
Judgement does not disappear, it moves to a different question
It would be convenient to describe the change as a substitution of judgement by automation, and it would be wrong. The questions that matter are still questions of judgement: which process is worth redesigning, where the real constraint lies, which exceptions the business is willing to pay for, what the organisation will accept as accountable, and what a leader should refuse.
What changes is the object the judgement is applied to. Working from a slide, the consultant reasons about a described process. Working from a prototype connected to real data, the consultant reasons about a specific process with its contradictions exposed, and disagreements become concrete enough to settle. A debate about whether the intake step should be removed is abstract; a debate about what the prototype does with the minority of orders carrying two delivery dates is not, and it gets decided. The same problem in turning expert knowledge into repeatable delivery capability.
The deliverable changes shape
If the advice-to-implementation gap is the real problem, then the shape of the deliverable has to change, because the deliverable is what the client actually receives.
| Deliverable | What it contains | What it replaces |
|---|---|---|
| Structured business design | The process as a specification: fields, states, decisions, owners | Slides describing a process in prose |
| A working prototype | A narrow path end to end against real data, with failures visible | Screenshots and a requirements document |
| A running application | In use by real people, with evidence retained and a named owner | A handover pack and a plan for a future build |
| A measured implementation outcome | A baseline, a current reading, and a review that decides what happens next | A benefits case that assumes the benefits |
None of this removes the need for analysis, and a prototype does not substitute for understanding the business. The analysis becomes more focused, because prototyping forces the vague parts of the recommendation to become specific.
What this does not mean for the profession
Consulting judgement is not being made redundant, and firms that invest heavily in it will continue to be the ones clients turn to when the decision is genuinely unclear, when two organisations have conflicting interests, or when nobody in the business agrees what the problem is. That work is not automatable in any interesting sense.
What is changing is the part of the work that is currently billed as analysis but is in fact translation: turning a described process into a specification, a specification into a build, a build into an integration, and a recommendation into a change that people accept. That part was always mechanical enough to be delegated and expensive enough to be worth delegating well. A firm that develops strong engineering will not find its judgement devalued; more of the engagement will be the work it is trained for.
A sequence for working in this way
The shift is not a change of method so much as a change in what is produced and when it is produced. A workable order of work looks like this, and it deliberately puts evidence before documentation.
- Sit inside the operating environment and observe the work before writing anything about it, so the process being redesigned is the one that actually runs.
- Establish the baseline before proposing anything, so the size of the problem is a number rather than a complaint.
- Write the business design as a specification with decisions, states, owners and exception paths, signed by the person who owns the process.
- Build a narrow end-to-end path against real data and let it fail in public, because the failures are where the remaining judgement is located.
- Put it in front of real users early enough to change the design, and record what they do rather than what they say they will do.
- Agree the review date and the measures at the start, and treat handover as the beginning of the operating model rather than the end of the engagement.
The change in the deliverable is best understood as a change in what the client is left holding. A report is a description of a business that might exist. A running application, owned by a named person, with a measured baseline and a review date, is the beginning of one. The method is in from consultant recommendation to working business system, and the engineering that makes a prototype credible in business application engineering.