What to Write Down Before Anyone Quotes

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

1. The process as it happens today, step by step, from the person who does it
2. The exceptions — what happens when it does not go normally
3. The systems involved, named, with whether they have APIs
4. Volumes — how many of these per week, and the peak
5. 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

A stated measure makes the project accountable and it frequently changes what gets built.

Frequently asked questions