Start With the Operation, Not the Software
Starting from the operation sounds like advice until you try it, and then it turns into a question about method: what exactly you look at, and what you do with what you see.
The operation is a unit you have to choose
Nobody can study an organization, it's too large and it won't hold still. What you can study is one flow of work with a beginning and an end, and choosing which one is the first real decision you'll make.
A good unit is small enough to follow end to end in a day and consequential enough that the organization cares whether it moves: a customer request from arrival to fulfillment, say, or a hire from requisition to first day, or a change from proposal to production. Pick one and follow it. The instinct to map everything first is strong, and what it produces is a diagram, which is a different deliverable altogether and one that won't help you here.
Choosing badly is recoverable, but it's expensive. Units that are too large stop having a clean beginning, and you spend the first three days arguing about where the process starts when you could have been watching it run. Units that are too small are tidy and prove nothing, because the interesting failures happen at the seams between units, and a unit with no seams has no findings in it. The test is whether you can name the moment the work arrives and the moment somebody would say it's done. If two people in the room give different answers to either question, you've found something already, so write it down before you go looking for anything else.
Follow one, not the average
Trace an actual instance, with its actual timestamps and its actual detours. The typical case is a reconstruction, and reconstructions have a way of being tidy in exactly the places you need them to be messy.
Averages hide the thing you're looking for. Picture a process that takes four days on average and eleven whenever it touches finance: the trouble lives at the finance seam, and the average is actively concealing it. Keep following individual instances until you can predict which ones will be slow, because that prediction is the finding.
The distribution usually tells the whole story. Take a request queue where the reported median is two days and leadership is happy with two days. Trace thirty individual requests and the shape typically comes apart into two populations: most clear in under a day, and a minority sit for a week or more. The median describes neither group, and nobody actually experiences two days. Half the requesters experience a fast process and a quarter experience a broken one, and that quarter are the ones filing complaints, which get read as anecdote because they contradict the dashboard.
What separates the two populations usually turns out to be some property of the request that sends it somewhere different: a dollar amount above a threshold, a customer in a regulated category, a field left blank on intake. The work itself is often identical. Those properties are knowable the moment the work arrives, so the slowness is predictable, and anything that predictable has been designed, whether anyone meant to design it or not. A finding like that is far more actionable than a duration.
What to write down
Four columns are usually enough: where the work went, how long it sat before someone touched it, who decided and what they didn't know when they decided, and what a person supplied by hand that the system should have supplied.
That last column matters most, and it's the one people skip, because supplying things by hand stops registering as an event after the second week. You have to watch for it, since the people doing it have long since stopped noticing. Asking "what did you have to go and find out" recovers more than asking "what are the problems with the process".
Once you know to look, the manual supply shows up in forms you'll recognize. There's the spreadsheet someone keeps next to the system of record because the system doesn't hold a field they need. There's the mental list of which approver is responsive, and the habit of routing around the one who isn't. And somewhere a person is re-keying the same customer detail into a second tool because the two tools don't speak. None of these appear in a process document, and all of them are load-bearing. Remove the person and the flow stops, which is the definition of a component, and it's worth noticing that the organization has quietly turned a person into one.
Write down who as well as what. A workaround owned by a named individual with fourteen years of context carries a different risk than the same workaround owned by a rotating queue. The first is fragile and invisible, and the second is expensive but at least legible.
Nobody can argue with a timestamp, which is why the trace persuades a room that an evaluation matrix cannot.
Separate the delay from the work
Once you have a trace, split the elapsed time into two piles: the time somebody was doing the work, and the time the work was sitting.
The two piles are rarely close in size. Follow enough of these and the pattern holds steady: the doing is a small fraction of the elapsed time, and the rest is waiting, queuing and being handed over. The trouble is that the instinct to improve usually aims at the doing, with faster tools, better templates and more training, all of it pointed at the smaller pile while the larger one sits untouched, because nobody owns it and it doesn't show up on anyone's dashboard.
The arithmetic is worth doing out loud in front of a sponsor. If a flow takes eleven days and the accumulated hands-on time is six hours, a tool that makes the doing forty percent faster removes about two and a half hours from eleven days, which is a real improvement and nearly invisible to anyone downstream. Meanwhile a single approval that sits for three days because the approver reviews in a weekly batch is worth more than the tool, and fixing it costs nothing but a decision about batching.
Waiting is also under-owned in a specific and predictable way. Every step in the flow has an owner, and every gap between steps has none. Ask who's accountable for the three days between submission and review, and the honest answer is usually that nobody has ever asked. Work sitting between two queues isn't on anyone's list, because it isn't in anyone's queue, and that's precisely why it's where the time goes.
Then, and only then, ask what it needs
With a trace in hand, the question changes shape. "What should we buy" quietly gives way to "what's the smallest change that removes this wait".
Sometimes the answer is software, but more often it's a change to who decides, or to what information travels with the work, or to when a check happens relative to the thing it checks. Changes like these are cheaper, faster and harder to procure, which is precisely why organizations that start at the other end tend to skip them.
Move a decision down one level and the wait disappears entirely, provided the person one level down already has the information. Attach the missing field at intake, and a round trip that was costing two days every time it happened simply stops happening. A compliance check moved from after the work to during it turns rework into a constraint, and that's cheaper because nothing has to be undone. None of these require a vendor, and all of them are hard to put in a budget line, which is a quirk of procurement that has nothing to do with what they're worth.
When the answer genuinely is software, the trace tells you which software and, more usefully, how much. A flow with one bad handoff needs an integration, not a platform. The difference between those two purchases is often an order of magnitude, and the only thing that lets you tell them apart is having watched the work.
Why this order is hard to hold
The method isn't complicated, but holding to it is, because from the outside tracing looks like nothing is happening.
There's no vendor, no schedule, no launch, and for the first week no deliverable a sponsor can look at. The pressure to turn that ambiguity into a purchase is real, and it comes from good people who need to report progress. The way through is to make the trace itself visible early. A single annotated flow, showing where a real request waited and for whom, is more persuasive in a room than any evaluation matrix, because everyone recognizes it immediately and nobody can argue with a timestamp.
There's a second source of pressure, and it gets named less often. A trace produces findings about people and their decisions, and some of those findings are uncomfortable in a way a software evaluation never is, since it's easier for an organization to conclude that its tooling is inadequate than that its approval structure is. Starting from the operation keeps surfacing the second kind of answer, and the method survives contact with the organization only if whoever is sponsoring it has agreed in advance to hear that.
Hold the order anyway. The real cost of starting at the other end is subtler than buying the wrong thing: you buy something plausible, deploy it into the same structure, and lose the one window when the organization was willing to look at how it actually works.
If this describes an operation you’re responsible for, the diagnostic is where that conversation starts.
How engagements begin
