Specification Before Product: How to Write a Better Project Brief

Start with the outcome, not the catalogue

Describe what the project needs to do before naming a product. Capacity, weather protection, access, durability, operating pattern, visual intent and programme constraints are usually more useful starting points than a preferred model number.

This leaves room to identify the right system while preserving the requirements that actually matter to the architect, developer, council or operator.

A product-first brief can accidentally lock the project into dimensions, materials or operating features that were never tested against the actual site. An outcome-first brief gives the supplier and design team a chance to challenge the assumption before cost, drawings and programme become tied to it.

A strong first page should therefore read almost like a performance summary: what the project is for, who will use it, where it will sit, what conditions it will face and what success looks like once it is operating.

Separate fixed requirements from preferences

A brief becomes easier to price and review when non-negotiable requirements are clearly distinguished from preferences. Dimensions, site exposure, accessibility, structural interfaces and required documentation may be fixed; colour, accessory packages or control options may still be open.

That distinction prevents optional features from being treated as compliance requirements and stops critical constraints from being lost inside a long wish list.

It also helps commercial comparison. Two suppliers may appear to be offering different products when in fact one has priced optional features that the other has excluded. A clear split between mandatory, preferred and optional items makes quotations easier to compare on the same basis.

Define the interfaces

Most project-product problems occur at interfaces: structure to façade, roof to drainage, equipment to power, pool to foundation, court surface to substrate, or modular building to local services.

The brief should identify what the supplied system connects to and which party is responsible for designing, verifying and constructing each adjoining element.

A simple interface schedule can be more valuable than another page of product description. List the item, the interface, the information needed, who supplies it and who confirms it. That turns vague coordination into a visible project task.

Ask for evidence that matches the claim

Certificates, test reports, drawings and technical data are useful only when they relate to the selected product or configuration. A generic factory certificate should not be treated as evidence for a project-specific structural, fire, wind or durability claim.

List the documents the project team actually needs and identify which requirements remain subject to destination-specific engineering or approval.

The more important the claim, the more specific the evidence should be. A wind-rating statement, for example, is more useful when the model, size, configuration and test basis are clear than when it appears as an isolated marketing number.

Keep supply scope and local works visible

Supply-only projects work best when foundations, installation, electrical work, drainage, lifting, site preparation, local engineering and statutory approvals are shown as separate scopes unless expressly included.

Clear scope boundaries are not exclusions hidden in fine print; they are part of making the project buildable and the quotation comparable.

A responsibility matrix is especially useful on international or multi-party projects. The product supplier, local contractor, consultant and client can each see what they own before an issue becomes a variation or delay.

Design the brief for change

Projects evolve. A useful brief records what is approved, what is provisional and what can still change without forcing a full redesign. It also identifies future expansion, enclosure, accessories or additional phases that may affect today's interfaces.

This is particularly valuable for staged sports facilities, outdoor rooms, modular developments and repeat procurement programmes.

Future-proofing does not mean over-specifying everything on day one. It means preserving the interfaces that would be expensive to recreate later: spare power, structural allowance, service access, fixing zones or space for additional equipment.

Finish with a decision record

When the product pathway is selected, retain the assumptions, verified dimensions, agreed options, evidence set, exclusions and local responsibilities alongside the final quotation or submittal.

That decision record becomes the bridge between early research, specification, procurement and the team that eventually receives or installs the supplied system.

It also protects the project from memory drift. Months later, the installer or asset owner can see why a particular option was selected and which conditions were assumed rather than trying to reconstruct the decision from email fragments.

Build a brief that suppliers can actually answer

A strong brief should make it easy for a supplier to respond clearly. That means avoiding contradictory requirements, unexplained acronyms and broad performance statements that have no defined test or project context.

If a project asks for high wind resistance, define whether that means a specific design wind speed, local engineering review, an available test report or simply a preference for a robust system. If it asks for commercial grade, explain what that means in terms of usage, durability, warranty or maintenance.

Good briefs also state where alternatives are acceptable. If a supplier can propose an equivalent material, dimension or control system, say which outcome must remain unchanged. This preserves competition without weakening the intent.

The best result is a response that can be assessed line by line against the brief rather than a collection of brochures and generic claims.

• Use measurable requirements where possible
• Define vague terms such as commercial grade or high wind
• State where alternatives are acceptable
• Ask suppliers to identify exceptions rather than silently ignoring them

Use assumptions as controlled project data

Early projects inevitably contain assumptions. The problem is not that assumptions exist; it is when they disappear into the background and later become treated as facts.

A useful brief labels assumptions directly: provisional dimensions, expected exposure, anticipated service location, likely mounting condition or expected user numbers. Each assumption can then be verified, changed or carried forward deliberately.

This is especially important on international supply projects, where the product team may not control local site investigation. The brief should distinguish information supplied by the client, information verified by Apollo or the manufacturer, and items still awaiting local confirmation.

An assumption register can be simple, but it prevents costly misunderstandings because everyone can see which parts of the design are still conditional.

Turn the final brief into the procurement baseline

Once the project brief is agreed, it should become the common reference for quotations, technical review, submittals and later changes. That prevents the specification, commercial offer and design conversation from drifting apart.

If a change is made after quotation, record what changed and whether it affects price, lead time, documentation, interfaces or local works. This is particularly important when changes appear small visually but alter loads, electrical demand, enclosure, transport or installation method.

For repeat programmes, the same brief can become a controlled template. Keep the core requirements stable, then add a site-specific schedule for dimensions, climate, local compliance and project options.

That is where a good project brief creates long-term value: it becomes more than an enquiry document. It becomes the structured record that connects design intent to procurement and delivery.

Structure the brief so quotations can be compared fairly

A project brief should make competing quotations easier to compare, not harder. If one supplier prices freight, controls and accessories while another excludes them, the lowest total can be misleading even when both offers are technically reasonable.

Separate the brief into product scope, required options, documentation, freight or delivery stage, local works and optional alternates. Ask respondents to identify exclusions and assumptions against those headings rather than burying them in commercial notes.

Where an item is not yet fixed, request it as a clearly priced option. That keeps the core comparison intact while showing the cost of upgrades such as different finishes, controls, screens, lighting, heating or additional accessories.

A comparison schedule can then focus on real differences: configuration, evidence, scope, lead time, serviceability and commercial handover. That is much more useful than comparing one headline number from each proposal.

Treat revisions as controlled decisions, not informal email changes

Projects change after the first brief. Dimensions move, colours change, accessories are added, local consultants revise interfaces and programme dates shift. The risk comes when those changes are discussed informally but never consolidated into one current record.

Each meaningful change should identify what is being revised, why it changed, who approved it and whether it affects price, programme, engineering, documents or site works. A simple revision table can prevent teams from working from different versions.

This matters especially when drawings and quotations evolve at different speeds. The latest drawing should not silently invalidate the commercial scope, and a revised quotation should not introduce a configuration change that the design team has never reviewed.

Before order release, perform one final brief-to-quotation check. Confirm dimensions, model, options, finish, evidence, interfaces, exclusions and destination responsibilities against the same revision.

• Current brief revision
• Current drawing revision
• Current quotation revision
• Approved options and exclusions
• Open assumptions still requiring confirmation