Start from the process, not the technology
The useful first document describes what happens today, who does it, how long it takes and where it goes wrong. It should read sensibly without mentioning any technology at all.
If the document only makes sense with the word software in it, you are starting from the solution rather than the problem, and that is how projects go wrong.
Four things to prepare
- The process, step by step, from whoever performs it
- The cost — frequency, duration, who does it
- Thirty real examples, including the awkward ones
- Your systems — named, with whether they have APIs
With those four, any competent supplier can give you a real estimate. Without them, every estimate is a guess.
Include the exceptions
- What happens when something is rejected or returned
- Who can override, and when
- What happens at month end
- The one-off cases everyone knows about
- The steps nobody mentions because they are obvious
Exceptions are where the complexity lives. A description covering only the normal path produces an estimate for something that cannot handle real work.
Then decide what success means
| Weak | Better |
|---|---|
| Improve efficiency | Reduce quoting from 40 minutes to 10 |
| Better visibility | Know where every job is without asking |
| Fewer errors | Eliminate pricing errors reaching customers |
| Save time | Remove two hours a day of re-keying |
A stated measure makes the project accountable and frequently changes what gets built.
The conversation is free
Bring those four things and you will get a straight answer, including whether the honest answer is that building is not worth it.
A clear written scope is worth having whoever eventually builds it, and it is yours either way.