A 14-day operations diagnostic should hand you three things you keep

A 14-day operations diagnostic should leave you holding three things: a process map that shows how your business really works and which problems to solve first, a clickable prototype that shows how a system would solve them, and a roadmap of every fix in order of value. You should be able to use all three without the team that produced them.

Most operations audits end in a report nobody acts on

Executives who have paid for an operations audit before tend to describe the same outcome: a long document, broadly accurate, that nobody could act on. The analysis was not wrong. It stopped at the point where someone had to decide what to build and get the team to use it.

Underneath sits a harder problem, which is diagnosis itself. In a survey reported in Harvard Business Review in 2017, 85% of executives agreed that their organizations were bad at diagnosing problems, and 87% said this carried significant costs.¹ The sample was 106 executives, so treat the figures as directional.

1. Bad at diagnosing problems85%
2. The flaw has significant costs87%

Most executives say their organizations are bad at choosing the problem, and that it costs them

Statement	Agreed
Bad at diagnosing problems	85
The flaw has significant costs	87

Source: Wedell-Wedellsborg, Harvard Business Review, 2017; 106 executives¹

A diagnostic exists to close exactly this gap: to choose the right problem before money goes into a solution.

The process map shows where time and money leak

The first artifact is a map of how work actually moves through your business, drawn with the people who do it. In a 14-day diagnostic the mapping takes days 1 to 7: four or five calls with your team, with each process drawn live while people describe it. A useful map puts every process, leak and fix in one place. Each handoff, re-entry and wait is marked, costed in hours and money, and paired with the change that would remove it.

Judge the map by one question: could a new hire use it to understand how a job moves from sale to invoice? If not, it is too abstract to build from.

A clickable prototype lets your team try the fix first

The second artifact is a clickable prototype, built in days 8 to 14 on your own data and jobs. It shows how the system would solve the problems on the map, and it gives your team something tangible to try before you commit to a full build. It is not yet the system your team runs on every day. Its job is to make the fix concrete enough to argue about.

The case for doing this early is old and well documented. Barry Boehm and Victor Basili put avoidable rework at 40–50% of the effort on software projects, and noted that better systems come from requirements that emerge through prototyping.² A change on a prototype costs hours. The same change after launch costs weeks.

This is also where adoption starts. When the people who will use a system have shaped its screens, they have a stake in it. When they first see it at launch, they arrive with a list of reasons it does not fit.

The roadmap puts the highest-value fixes first

The third artifact arrives on day 14: every leak the map found, what each is worth and how to fix it, in order of value. A diagnostic usually turns up many problems, and a handful of them cost most of the money. A good roadmap names those, puts a number on each and says plainly which problems are not worth solving yet. You then decide what to build, what to set up and what to skip.

Change	Hours	Effort	Owner
Signed-contract notice	25	2 days	Sales lead
One client record	60	3 weeks	Operations lead
Budget against hours	20	1 week	Finance lead
New proposal template	3	2 weeks	Not yet: low return

Source: Verticulate illustration

Be wary of a roadmap that recommends doing everything. Its job is to make choices.

The roadmap is also the page you forward. Many owners we work with need a partner, a board or another executive to agree before they go ahead, so it has to make sense to someone who was not on the calls.

Five questions to ask any diagnostic before you sign

1. Will I own the map, the prototype and the roadmap if I stop after the diagnostic?
2. Which of my staff will join the mapping calls, and for how long?
3. Will I see the maps as they are drawn, or only at the end?
4. Is the prototype built on my own data and jobs, and who on my team will try it?
5. Will the roadmap tell me what not to do?

A provider that answers all five clearly, in writing, is selling a diagnostic. One that answers with a description of its methodology is selling a report.

Most of your team’s time goes into the first week

A diagnostic run this way starts with a one-day onboarding, where access is set up and you meet the people who will run the calls. In days 1 to 7, your team joins four or five mapping calls: the consultants ask the questions and your people answer. Days 8 to 14 go on building the prototype, and the roadmap arrives on day 14. That is the price of a map drawn from how the work really runs, instead of how the owner remembers it.

You should be able to stop after day 14

If you stop after day 14, you should be able to hand all three artifacts to a competent developer or a new operations hire and have them start work the next morning. If you cannot, the diagnostic has not finished its job. That is the standard we hold our own diagnostics to, and the one we would apply to anyone else’s.