Writing an IT specification: structure and mistakes to avoid

The specification is the founding document of any IT project. A poorly built document leads to budget overruns, misunderstandings with suppliers and deliverables nobody can use. Here is a proven structure and the traps to avoid.

A standard structure for an IT specification

1. Context and stakes: why this project? What problem does it solve? What business impacts are expected?
2. Functional scope: a description of the features expected, organised into business blocks. State what is included and what is explicitly excluded.
3. Technical constraints: the existing environment, any mandated technologies, security constraints, expected data volumes.
4. Non-functional requirements: performance, availability, accessibility, browser or device compatibility.
5. Project organisation: governance, points of contact, the committee structure, how often progress reviews are held.
6. Provisional schedule: key milestones, non-negotiable deadlines (regulatory constraints, seasonality).
7. Budget and envelope: a budget range or a maximum envelope. Do not hide it.
8. Selection criteria: how the responses will be assessed and weighted.
9. Appendices: mock-ups, existing data flows, application mapping, a glossary of business terms.

The most common mistakes

• Being too vague about the needs: “the tool must be simple and high-performing” gives no usable indication. Prefer measurable criteria: “a page must not take more than 2 seconds to load”.
• Leaving out the budget: a supplier cannot size their response without knowing the financial order of magnitude. That produces proposals which miss the point.
• Ignoring the schedule: with no target go-live date, the project drifts naturally.
• Forgetting maintenance and operations: the requirements have to cover the full life cycle, not just the build phase.
• Not involving end users: requirements written solely by management or by IT miss how the tools are actually used.
• Confusing the solution with the need: describe the “what” and the “why”, not the “how”. The technical choice belongs to the supplier.

A practical tip

Before you send the specification out, have it read by someone outside the project. If they do not understand the need within 10 minutes of reading, the document needs more work.