Breakdown
What Else Is Using the Thing You Want to Replace?
Why a two-week fix turns into a four-team project, and the cheap piece of work that shows you that before you approve it.
One reason changes stall in established businesses is that the output being replaced may have users nobody recorded. Those downstream users can matter more to the true cost of the change than the step being replaced. Map who consumes the output before you scope the rebuild.
The quoting process is slow and nobody disputes it. It runs out of a spreadsheet, a quote takes a few days to leave the building, and a competitor who opened two years ago turns one around the same afternoon. So you decide to change it, and you ask someone to scope the work properly before anything gets bought.
What the scoping turns up
A few weeks in, the shape of the job has changed. That spreadsheet is also where commission gets calculated. The job numbers come out of a column in it. The forecast is pulled from a tab somebody added years ago. A long-standing client’s monthly report is built from a copy of it that goes out at the start of each month.
None of that was designed. It accumulated. Someone needed a number, the number was already sitting there, and taking it was cheaper than building a second source. Do that a dozen times across eight years and the quoting spreadsheet is holding up four pieces of work that have nothing to do with quoting.
So the two-week change now touches finance, sales, operations, and one client relationship you would rather not disturb. Nobody can say with confidence what breaks on the day the old file stops being updated.
Why this is invisible at the moment you decide
You scoped a step. The step is easy to see, because a person performs it and can walk you through it. The people who use what it produces are harder to find, because consuming an output often leaves no trace inside the process you are examining. Nothing in the quoting workflow records that someone opens the file on the last Friday of the month to build a forecast.
Some of those connections were set up by people who have since left. Some live in a habit rather than a document, which is exactly the situation described in why nobody can find it when it was never written down. For a dependency to surface on its own, someone would have to go looking at the quoting process for a reason unrelated to their own work, and there is usually no occasion for that until the thing is being replaced.
The JPMorganChase Institute found that newer cohorts of small businesses reached AI adoption milestones much faster than older cohorts. The study does not tell us why. One possibility worth considering is structural: a younger business has simply had less time for other work to attach itself to the systems already in place. A two-year-old quoting process may have fewer downstream dependencies than one that has been accumulating workarounds, reports, and side uses for eight years.
What usually gets tried
A common move is to build the new quoting system and leave the old spreadsheet in place as a read-only copy, so nothing downstream breaks on day one. That genuinely buys time, and it protects the client report through the first month. What it does not settle is which system is now the real source. Once the two drift, somebody has to keep the old file current by hand, and that maintenance tends to land on whoever noticed first rather than on whoever decided.
The second move is to widen the project to cover everything the spreadsheet touches. That is honest about the scope, and it is sometimes the right answer. It also converts a quoting fix into a four-team program with a different approval path and a longer wait, and the slow quotes you originally cared about get solved last.
The third is to pilot the new system on the quoting path alone. A pilot run that way will tell you the quoting part works. It will not tell you much about the commission calculation or the forecast, because those were not in it, which is a version of the pilot that went well while nothing changed.
The fourth is to declare the downstream uses unofficial and ask people to stop. That can be correct where the use was genuinely casual. Where the output feeds something a client receives or a commission depends on, the work does not stop. It moves somewhere you have less visibility on.
A cheap way to find the dependants first
This part is not technical and does not need a vendor in the room. Take the thing you want to replace and stop asking what happens inside it. Ask what comes out of it: a number, a file, a field other systems read, a document, a recurring email that goes somewhere on a schedule.
For each output, put three questions to the people around it. Who receives this. What do they do with it next. What would they do on the morning it did not arrive in the shape they expect. That third question does the sorting. An answer like asking a colleague for the figure is cheap. An answer that involves rebuilding something by hand, or telling a client the report will be late, is a cost that belongs in the estimate.
Then check the paths where an output travels without a conversation. Recurring emails, shared folders people have bookmarked, and anything that happens on a monthly rhythm are worth walking through, because those uses can continue for years without anyone discussing them. Even a short pass through those dependencies can turn an unknown into a much more useful list, and it is the kind of work worth doing before any tool decision, which is most of what a second opinion on scope is for.
The useful shift is small. In an established business, the unit of change is rarely the process. It is the output, plus everyone standing on it. Once you have that list, you can still choose the big version, phase the downstream moves, or decide the slow quote is cheaper to live with for another year. The difference is that you chose it at the real size instead of discovering the size halfway through. Rebuilding the step is the part you can estimate in advance. Finding out who has quietly come to depend on what it produces is the part that sets what the change actually costs.
See how we work out what is actually wrong
See how we work out what is actually wrong
About the author
Missy Ross
Missy Ross is the Founder and AI Architect of Vero Dawn, an AI architecture and solutions company that helps businesses see what could work better, determine the right solution, and bring it to life. Before founding Vero Dawn she spent 21 years in internal audit across banking and manufacturing, at Audit Director level.