Every requirements document we have been handed describes the process as someone believes it runs. Every workflow map we have made by watching describes the process as it runs. The gap between the two is where projects go wrong, and it is never in the places anyone flagged as risky.
The steps nobody writes down
A sales rep takes an order over WhatsApp because that is where the customer already is. It gets retyped into a sheet. Someone in operations checks the pricing by hand, because the price list has three exceptions that were never encoded anywhere. The order goes to accounts as a PDF attached to an email, and accounts retypes it a third time.
Ask anyone in that chain to describe the ordering process and you will get four steps, cleanly. Watch it for a week and you will count nine, three of which exist only to repair the damage done by the previous one.
Those repair steps are the whole opportunity. They are also invisible to a requirements gathering exercise, because nobody thinks of them as part of the process. They think of them as the annoying thing they do before the process starts.
What we are actually looking for
Four things, in roughly this order of value.
Steps that only exist to move data between systems. These are the cheapest to delete and the most reliably present. Every one of them is also a place where two versions of the truth diverge.
Decisions that live in someone’s head. The three pricing exceptions. The customers who get approved without a credit check because “we know them”. These have to be found before the build, because a system that cannot express them will get worked around within a month, and then you have built the tenth system that people route around.
The load-bearing spreadsheet. There is always one. It is usually maintained by one person, it has no backup, and half the business depends on it. It is not a sign of dysfunction. It is a sign of a real requirement that no tool met.
Where the work waits. Not where it is slow, where it waits. Queue time dwarfs processing time in almost every business process we have looked at, and no amount of making a screen faster touches it.
Why it has to happen before the price
We quote a fixed fee per milestone, and we cannot do that honestly on top of a requirements document written by someone else. The first two weeks of every engagement are the workflow map, and the deliverable at the end of it is a fixed scope and a fixed price for everything after.
That ordering matters. If the price is set first, the map becomes a negotiation about what fits inside the number. If the map comes first, it becomes the input to a number both sides can defend. It also means the client can stop after two weeks holding something useful. The map is theirs either way, and occasionally the correct answer at the end of it is that the software they need already exists and the process around it is the problem.
The unglamorous conclusion
Most of the value in these projects is subtraction. Six steps become three. The thing we build is smaller than what was asked for, and it fits, and nobody has to be trained to use it because it does what they were already doing with less friction.
That is a much less exciting pitch than a platform. It is also the difference between software people use and software people route around.