An IT project specification that business and vendors understand

The goal is not the longest specification. It is a shared understanding of the outcome, priorities and how delivery will be verified.

Start with the problem, then the features

A project should begin with what the organisation wants to change. A list of screens and features without context can produce software that works technically but fails to improve the process.

We first establish current workflows, users, data sources, exceptions and constraints. Features follow from that analysis, so requirements reflect real needs rather than a wish list.

What the documentation may include

• Business objectives and intended outcomes.
• Current and target processes.
• User groups, roles and permissions.
• Functional and non-functional requirements.
• Data, migration and integration requirements.
• Security, accessibility and performance requirements.
• Reports, notifications and automation.
• Acceptance criteria and key process scenarios.
• MoSCoW priorities and first-release scope.
• Assumptions, constraints, dependencies and exclusions.
• A product backlog or request-for-proposal pack.

The specification should not prescribe the vendor's technology

Clients need to define needs, constraints and success criteria clearly. They do not need to impose an architecture or technology without a sound reason.

Good documentation gives vendors room to propose solutions while limiting ambiguity about goals and outcomes. It states what must be possible, which conditions apply and how delivery will be checked.

Priorities and first-release scope

Not every need must be addressed at once. Trying to cover every department, exception and future idea in the first release often increases cost, duration and adoption risk.

I organise requirements using MoSCoW or another suitable model. What matters is the decision: what is essential, what is important, what can wait and what is excluded from this phase.

Acceptance criteria protect both parties

“The system must support reporting” leaves too much open. Which reports, for whom, from which data and within what time? Can users export them? What happens if data is missing?

Acceptance criteria define when a feature can be considered complete. They help vendors estimate the work and clients prepare testing and acceptance. They also reduce later disputes about whether a need was in scope.

How we work together

1. Discuss the goal, organisation and current ways of working.
2. Run workshops with process owners and users.
3. Describe processes, needs, data, integrations and constraints.
4. Organise requirements and agree priorities.
5. Prepare documentation, backlog and acceptance criteria.
6. Review the material with stakeholders.
7. Prepare the version for vendor selection or delivery.

What you gain

A clear specification makes proposals comparable, reduces hidden assumptions and supports change control. It does not remove all uncertainty, but makes it visible and manageable.

The document becomes a shared reference for business teams, vendors, testers and acceptance owners. Project knowledge no longer sits only in the heads of a few meeting participants.