A client called us last year about a system that had been built eighteen months earlier. It worked. The reports were correct, the screens were clean, the developers had done what they were asked. Nobody in the office was using it.
The reason was simple once we sat with the storekeeper for an hour. In the real process, a delivery is received before the paperwork arrives, sometimes two days before. The software did not allow that. So the store kept its own register, entered everything into the system at the end of the week, and the system became a copy of the register instead of a replacement for it.
Nobody had asked the storekeeper anything. The requirement had come from a meeting of people who were describing how the process is supposed to work.
The gap between the written process and the real one
Almost every organisation has two processes. There is the one in the policy, and there is the one people actually follow to get the day finished. The second one exists because the first one does not cover every situation, and somebody had to keep the work moving.
The real process is not a bad habit. It usually contains years of practical judgement that nobody has ever written down. If your software ignores it, you are not fixing the process, you are asking people to do their job in a harder way while keeping their old method running underneath.
If the software does not match how the work happens, the work does not change. The software gets abandoned.
What we do before writing any requirement
We follow one real case from start to finish. One purchase, one admission, one delivery, one complaint. Not a sample. An actual one, with the actual papers attached to it. And we ask the person doing each step three things:
- Where does this come to you from, and in what form does it arrive?
- What do you write down twice, and where does the second copy go?
- When does this go wrong, and what do you do when it does?
The third question is the one that matters most and the one that is almost never asked. Exceptions are not rare. In most processes we have looked at, the exception is running somewhere between one in five and one in three cases. A system that only handles the clean case is a system that handles most of the work badly.
A small example
In one factory, the written rule was that a fabric roll is issued against an approved requisition. In practice, if a line was about to stop, the store issued the roll and the requisition followed later in the day. Perfectly sensible. But the first version of their inventory software had no way to record it, so stock figures were wrong every afternoon and correct again by evening, which made everybody distrust the whole thing.
Allowing an issue to be recorded with the requisition pending, and showing it as pending, took one afternoon to build. Nobody had thought to ask for it.
Ask the people who do the work
The manager knows what the process is meant to achieve. The person at the desk knows what it actually takes. You need both, and the second one is usually not in the room when software is being discussed.
It costs a few days to find this out properly. It costs a great deal more to build the wrong thing carefully.