What a specification must contain to get a firm price

You want a firm price. The provider asks for a specification. You send a forty-page document and they reply that they cannot commit. That is not obstruction: your document probably describes very well what the system must do, and not at all what happens when it does not.

The six elements that are almost always missing

1. The exclusion list. This is the most frequently absent item and the one that produces the most change orders. Writing what is included is not enough: anything not mentioned becomes a negotiation topic mid-project. A good document explicitly says "migrating history prior to 2020 is out of scope" or "the application is not intended for mobile use".

2. Acceptance cases. Written before development, not after. Cases drafted at the end describe what was built rather than what was asked for, which makes acceptance useless as a control mechanism.

3. The defect classification grid. What counts as blocking, major, minor. Without it, the end of the project becomes a negotiation about the definition of a bug, usually at the moment both parties are least able to conduct it calmly.

4. The name of the person who arbitrates. One person, with a committed response time. Waiting for a decision on a business rule is the leading cause of delay on fixed-price projects, ahead of technical difficulty. If three departments must agree to validate a rule, the provider needs to know that before committing to a date.

5. The systems to integrate with, with documentation or a contact. An integration discovered mid-project is the classic cause of overrun. Naming a package is not enough: say whether its API is documented, who maintains it, and whether a test environment is available.

6. Quantified non-functional requirements. "It has to be fast" is not a requirement, it is a future dispute. Give volumes, target response times, concurrent user counts, an expected availability window.

What is not necessary

Many specifications devote pages to technical choices that should not be there. Mandating a language, a framework or an architecture before discussing the need reduces competition and removes the possibility that the provider proposes something simpler.

Likewise, detailed mockups of every screen are rarely the best investment at quoting stage. A precisely described user journey is worth more than thirty screens that will be reworked anyway.

The shortcut that works

If your document does not contain those six elements, you have two options. Spend several weeks producing them internally, which assumes framing skills are available. Or buy a short framing phase from a provider, who will produce the document and a firm price on that basis.

In the second case, require that the document belongs to you, including if you award delivery to someone else. A framing document you cannot put out to tender is not framing, it is a lock-in mechanism.

The quick test

Ask yourself one question: if the provider who wrote this document disappeared tomorrow, could another one price the project from the document alone? If the answer is no, the document is not sufficient, however thick it is.