Specification Writing for Beginners

What is a specification?

A construction specification is the written part of the design information. It states the quality, standards, materials, workmanship and completion requirements that cannot be communicated reliably by geometry alone.

A drawing can show the position and thickness of a wall. A schedule can label it P-04. The specification explains what P-04 must achieve, what the complete construction includes, what evidence is required and how the finished work will be accepted. NBS describes specifications as documents that are read with drawings and models and can form part of the contract documentation. Its construction specification overview is a useful primer.

Think of the specification as an instruction and verification system, not a product catalogue. It should let a competent tenderer understand what is included, let the design team compare proposals on a common basis and let the delivery team check whether the work complies.

Why it matters commercially and contractually

Ambiguity rarely disappears. It moves downstream into a tender query, qualification, substitution, request for information, variation or defect discussion. A coordinated specification helps the project team price the same scope and creates a record of what the designer intended to be provided.

The exact contractual effect depends on the appointment, building contract and issue status. Never assume that the specification automatically overrides a drawing, or the reverse. Check the project's document hierarchy and amendment provisions. If a conflict could affect liability, payment or compliance, raise it with the contract administrator and obtain project-specific legal advice where needed.

Write so the contractor can price it, the specialist can develop it, the site team can build it and the reviewer can verify it.

Three ways to specify

Most real specifications blend prescriptive, performance and proprietary requirements. The useful question is not which type is “best”. It is who is making the decision, who controls the solution and who must prove it works.

Prescriptive specification

A prescriptive clause sets out the materials, components, construction and workmanship to use. It is appropriate when the designer needs close control, has resolved the build-up and can coordinate the chosen solution. That control brings responsibility: copied details, missing components or incompatible products remain problems even when the contractor follows the written instruction.

Use it when the design is genuinely developed. Do not prescribe a partial build-up and quietly expect a specialist to complete the design. If specialist design is required, state its scope, constraints, interfaces, deliverables and review process.

Performance specification

A performance clause states the result the completed work must achieve, leaving more of the solution to a contractor, manufacturer or specialist. Good performance requirements are measurable. They identify the test or calculation method, relevant conditions, evidence to submit and who accepts it.

“Provide good acoustic insulation” is not a performance requirement. A project-specific acoustic value, measurement method, flanking assumptions and evidence requirement can be. Performance wording is not a shortcut for unresolved design intent; it is a precise brief for the party developing the solution.

Proprietary specification

A proprietary clause names a manufacturer, product or system. It can be useful where compatibility, appearance, client standards, testing or maintenance strategy justify a known reference. Check availability, lead time, regional support, evidence and suitability for the actual application before naming it.

If alternatives are allowed, define equivalence in terms of required performance and evidence, not the phrase “or similar approved”. Name the decision-maker, submission route and programme allowance. A named product still needs coordinated performance and execution clauses.

CAWS and Uniclass are organising systems, not content

Classification helps people place and retrieve information. It does not decide what the project requires. A beautifully classified vague clause is still a vague clause.

CAWS, the Common Arrangement of Work Sections, organises information by packages of work familiar to UK construction teams. The classification itself is no longer maintained, although NBS continues to maintain CAWS specification content where customers require it. Existing practices and projects may therefore still issue CAWS-structured specifications.

Uniclass is a dynamic classification used across the asset lifecycle. For a beginner, two tables are especially easy to recognise: Ss identifies systems and Pr identifies products. A wall can be treated as one system while its facing, insulation, membrane and fixings are individual products within it. NBS explains the relationship between specification and classification in more detail.

A practical migration approach

1. Follow the classification and authoring system agreed for the project.
2. Keep drawing tags, schedule types, model objects and specification titles aligned.
3. Create a mapping when a retained CAWS library must connect to Uniclass-coded model or asset information.
4. Do not convert headings mechanically and assume the clauses are coordinated. Review scope and interfaces system by system.
5. Record the edition or release basis used at issue, because classification tables and office libraries change.

Ten golden rules for clear clauses

Good clauses make the required decision visible. They remove adjectives, expose assumptions and give every requirement a way to be checked.

1. Start with scope and location.Say which system, element or scheduled type the clause covers.
2. Write measurable outcomes.Replace “high quality”, “robust” and “adequate” with values, classifications, samples or agreed benchmarks.
3. State design responsibility.Identify who completes each design portion, the constraints they inherit and the information they must return.
4. Specify the complete system.Include accessories, fixings, interfaces and preparation, not only the most visible product.
5. Put a requirement in one authoritative place.Cross-reference it elsewhere instead of repeating it until versions diverge.
6. Define evidence and timing.Ask for relevant test evidence, calculations, samples or shop drawings early enough to affect the work.
7. Use standards deliberately.Confirm scope, edition strategy and project relevance. Do not paste a standard reference you have not checked.
8. Control alternatives.Define equivalence, submission information, approver and decision timing.
9. Delete what does not apply.A short selected specification is safer than a master full of contradictory optional clauses.
10. Review it as living project information.Update decisions, record changes and feed verified lessons back into the office library.

The last rule matters because a specification develops alongside the design rather than appearing at tender. NBS describes this as aliving document that supports continuity of project information.

Common mistakes to remove before issue

• Copying the last project unchanged: old products, standards, values and client assumptions arrive invisibly.
• Specifying by adjective: “best”, “premium”, “approved” and “suitable” leave no common test.
• Mixing responsibility models: the clause prescribes half a solution but assigns the whole design to a specialist.
• Naming a product without the system: interfaces, primers, fixings, accessories and tolerances disappear.
• Leaving hidden choices: brackets, alternatives and “TBC” fields reach tender without an owner or due date.
• Requesting evidence too late: a sample or calculation due after procurement cannot guide a meaningful decision.
• Repeating requirements: the same fire, acoustic or finish requirement changes in one document but not another.
• Treating review as design transfer: reviewing a specialist submission does not automatically resolve unclear responsibility.

Coordination checks before every issue

Coordination is a set of comparisons, not a final proofread. Read the specification horizontally across drawings, schedules, models, reports, room data, cost information and design-responsibility documents.

A compact issue gate

• ✓No unresolved option text or ownerless “TBC”.
• ✓No named product that conflicts with scheduled performance.
• ✓No drawing note that creates a second, weaker version of the clause.
• ✓No specialist design item without inputs, interfaces and deliverables.
• ✓No submission due after manufacture, installation or concealment.
• ✓Every issue has a clear status, date and revision record.

Develop the specification stage by stage

Start before the technical design stage. Early specification work records outcomes and system intent; later work adds selected products, evidence, execution and close-out requirements.

The sequence below uses the RIBA Plan of Work 2020 as a familiar reference. Irish practices and projects using other appointment structures may use different stage names, but the information should still mature with design decisions. NBS also provides a practical guide to planning specifications against the project timeline.

What “done” looks like at the key handoffs

End of concept

Major systems, performance drivers, visible quality, risks and likely design-responsibility split are recorded.

End of spatial coordination

System build-ups, interfaces, identifiers and consultant requirements are coordinated enough to develop technical clauses.

Technical issue

Project-selected clauses define scope, performance, products where appropriate, evidence, execution and completion without unresolved conflicts.

Handover

Approved changes, as-built product information, required records and useful lessons are captured rather than stranded in site correspondence.

Where Avoice fits

Specification writing is a knowledge and coordination task. Avoice is designed to help practices organise that work without removing the professional judgement that makes it reliable.

Instead of beginning with a blank page or an uncontrolled copy of the previous job, teams can use their practice knowledge as a structured starting point, develop project requirements, connect classification and product information, and review clauses against the rest of the project record. That makes the repetitive parts easier to trace while leaving selection, responsibility, compliance and approval with the project team.

The useful boundary is simple. Software can help retrieve, compare, structure and flag. Architects, technologists, consultants and contract administrators still decide what the project requires and whether the evidence is adequate.