The process
01 / 04
Diagnose.
The visible problem is real. It does not yet tell us which underlying problem deserves the investment.
Begin with the work
Diagnosis is where assumption gives way to understanding.
When work keeps getting stuck, the first explanation is rarely the whole explanation. A report takes too long to prepare, a handoff keeps breaking down, or someone spends every Friday rebuilding information that already exists somewhere else. The visible problem is real. It does not yet tell us which underlying problem deserves the investment.
That distinction matters because a technical solution can make the wrong process faster, more expensive, and harder to change. Small and midsize businesses have little reason to absorb that kind of waste. Before I recommend a model, an automation, or a custom tool, I need to understand what is happening inside the work itself.
Editorial image
hidden systems made visible
01 · Follow the work
Follow the work, not the assumption
You arrive with a reasonable theory: a task takes too much time, information is scattered across several systems, or your team has already identified AI as a possible answer. I treat that theory as a useful starting point, then test it against the way the business operates.
I trace the work from the moment it begins to the moment it is considered finished. I look at who touches it, which information they need, where they retrieve it, what they decide, and what happens when the ordinary path breaks. Repeated entry, unclear ownership, approval delays, missing context, and manual reconciliation all leave different fingerprints. They also call for different remedies.
The people closest to the work matter here. A process diagram can show the intended path. The person doing the job can explain the exceptions, workarounds, and quiet acts of judgment that keep it moving. Those details tell me which parts of the process should be protected and which parts are consuming time for no good reason.
02 · Measure the consequence
Find the cost behind the friction
A bottleneck deserves attention when its consequences are clear. Those consequences include hours lost to repetitive work, slow response times, preventable errors, delayed revenue, poor visibility, or dependence on one person who knows how everything fits together. The right measure depends on the problem.
I gather enough evidence to explain the cost in terms the business can recognize. Some engagements support precise measurement. Others begin with incomplete data and require a more practical estimate. I will tell you which kind of evidence we have.
This is also where some proposed builds become smaller. When a cleaner workflow, a dependable connection between two systems, or the removal of an unnecessary step resolves the issue, that is a successful diagnosis. The purpose of this phase is to find the appropriate intervention, including the possibility that AI has no useful role in it.
Evidence, not theater
TIME
Repeated effort
DELAY
Slow response
ERROR
Manual reconciliation
DEPENDENCE
Knowledge held by one person
False precision does not make a decision safer.
03 · Establish the boundary
Agree on what deserves to move forward
Diagnosis ends when you and I can describe the problem in plain language, locate it within the operation, explain why it matters, and establish the boundaries a solution must respect. The record of that work changes with the engagement. It takes the form that fits the work: a concise brief, a bottleneck map, a ranked set of opportunities, or a broader implementation roadmap.
Whatever form it takes, it should give you a clear basis for a decision. You should know what I found, how I reached that conclusion, what remains uncertain, and why the next investment is justified. If the evidence says the problem is too small, too poorly defined, or better handled through a process change, I will say so.
Once the problem is understood and worth solving, Design can begin. Until then, more technology would only give uncertainty a budget.
Image placeholder · 02
A decision record built for the work
Replace with Garrett’s supplied supporting image or annotated workflow.
