Describe the problem, not the solution
Specifications written as screen layouts constrain the supplier to your idea of how it should work, which is rarely the best one. Describe what has to happen and let them propose how.
“We need a screen with these fields” produces what you asked for. “This is how we currently do this and here is where it goes wrong” produces something better.
What to include
- The process as it happens today, step by step, from the person who does it
- The exceptions — what happens when it does not go normally
- The systems involved, named, with whether they have APIs
- Volumes — how many of these per week, and the peak
- Who does what, and who is allowed to see what
The exceptions matter most
Every process has exceptions, and they are usually where the complexity lives. A specification describing only the happy path produces an estimate for a system that cannot handle real work.
- What happens when something is rejected or returned?
- What happens when a step is skipped?
- Who can override, and under what circumstances?
- What happens at month end or year end?
- What are the one-off cases everyone knows about?
Include real examples
Thirty real records, documents or cases, including the awkward ones. That tells a supplier more about the actual complexity than any amount of description.
It is also what lets them spot the thing you did not think to mention, which is usually the expensive part.
Say what success looks like
| Weak | Better |
|---|---|
| Improve efficiency | Reduce quote preparation from 40 minutes to 10 |
| Better reporting | Produce the weekly figures without manual assembly |
| Fewer errors | Eliminate the pricing errors that reach customers |
| Save time | Remove the two hours a day spent re-keying |
A stated measure makes the project accountable and it frequently changes what gets built.