The RIBA Plan of Work 2020 organises a project into eight stages, from Stage 0 (Strategic Definition) through to Stage 7 (Use). Each stage has a defined purpose, and each purpose implies a different depth of specification. The problem is that the Plan of Work doesn't spell out exactly what your specs should contain at each gate. It gives you outcomes and deliverables, not clause-by-clause templates. That ambiguity is where most specification issues begin.
Architects who treat specification writing as a Stage 4 activity, something to tackle once the design is "done", consistently underestimate the coordination effort involved. Specifications aren't just documents. They're the contractual thread that ties design intent to what actually gets built. Starting too late, or with too much detail too early, creates rework that compounds through every subsequent stage.
At Strategic Definition and Preparation and Briefing, you have no business writing specifications. This sounds obvious, but it's worth stating because some practices begin compiling product lists or referencing standards before a brief is even agreed. The risk here is premature commitment. A client brief might shift significantly between feasibility and concept, and any specification work done at this point will almost certainly need to be discarded.
What you should be doing instead is establishing the project's specification strategy. That means deciding which classification system you'll use (Uniclass, CAWS, or both for legacy reasons), which standards framework applies, and how specifications will be coordinated with other consultants. If you're working under a BIM Execution Plan, this is where specification authoring responsibilities get assigned. Tools like Avoice can help even at this stage, because setting up a classification framework early means your specification structure is already in place when you reach Stage 3.
Concept Design is where specification writing technically begins, but only in outline form. The RIBA Plan of Work expects an outline specification at the end of Stage 2, and "outline" is the operative word. You're describing intent, not products. An outline spec might say "high-performance aluminium curtain walling system with thermal break" without naming a manufacturer, a product range, or a U-value target.
The trap at Stage 2 is specificity. Architects who have a favourite product in mind often write their outline specs around that product's performance characteristics, effectively locking in a selection before the design has been spatially coordinated. This creates two problems. First, it limits your options at Stage 3 when you need to coordinate with structural and services engineers. Second, it gives quantity surveyors a false sense of certainty in their cost plan, which leads to uncomfortable conversations later when the spec changes.
A good Stage 2 outline spec reads more like a brief for the specification writer than a spec itself. It sets performance parameters, identifies key standards (Part L, Approved Document B, BS EN references), and flags areas where the specification will need particular attention during technical design.
Spatial Coordination is the stage where specification writing becomes genuinely difficult. The design is developed enough to start making real product decisions, but not so developed that every junction detail is resolved. You're caught between two pressures: the need for enough specification detail to coordinate with consultants, and the reality that many details are still in flux.
The RIBA Plan of Work expects the specification to be "developed" at Stage 3, which in practice means moving from outline to performance-based specifications. A performance spec defines what a building element must achieve (fire rating, acoustic performance, thermal conductivity) without mandating a specific product. This gives you enough detail for coordination meetings and cost checking, while preserving flexibility for Stage 4.
The most common mistake at Stage 3 is mixing performance and prescriptive clauses in the same specification. One section might describe a roofing system by its performance requirements, while another section names a specific flooring product by manufacturer and product code. This inconsistency confuses everyone, from the QS trying to price the job to the contractor trying to understand what's fixed and what's substitutable. Avoice addresses this directly by flagging inconsistencies between specification types across your document, ensuring that a performance spec in one section doesn't contradict a prescriptive selection in another.
Technical Design is where specifications become fully prescriptive. Products are named. Standards are cited with specific clause numbers. Installation methods are described. Tolerances are stated. This is the specification that will form part of the contract, and it needs to be airtight.
The level of detail required at Stage 4 surprises architects who haven't written specs recently. A single window schedule item might require references to Part L compliance data, Secured by Design certification, BS 6375 weather performance classification, acoustic attenuation figures, and ironmongery specifications, all for one window type. Multiply that across every building element and you begin to understand why specification writing at Stage 4 typically accounts for 15 to 20 percent of a practice's fee on a given project.
Scope creep in specifications almost always starts here. A well-intentioned architect adds a clause about maintenance requirements for a cladding system. Then another clause about cleaning access. Then a performance warranty requirement that wasn't in the employer's requirements. Each addition seems reasonable in isolation, but collectively they shift risk onto the contractor in ways that weren't priced, leading to disputes during construction.
The discipline required at Stage 4 is knowing what to leave out. Your specification should cover what the contract requires and nothing more. Every clause should trace back to either a design requirement, a regulatory obligation, or an employer's requirement. If it doesn't, question whether it belongs there.
Manufacturing and Construction (Stage 5), Handover (Stage 6), and Use (Stage 7) are often treated as post-specification stages. That's a mistake. Specifications remain live documents through construction, and they need to be managed actively.
During Stage 5, contractor substitution requests need to be assessed against the original specification intent, not just the named product. If your Stage 4 spec was purely prescriptive with no performance benchmarks, you have no objective basis for evaluating alternatives. This is why experienced specifiers include performance criteria even in prescriptive specs: they give you a framework for assessing "or equal" submissions.
At handover, the specification becomes the benchmark for snagging and defects assessment. Clauses you wrote at Stage 4 about surface finishes, installation tolerances, and commissioning requirements are now the standard against which the contractor's work is measured. Vague specifications produce vague snagging lists, which produce arguments.
After working with practices of all sizes, certain patterns emerge repeatedly. The first is treating specifications as a copy-paste exercise. Taking clauses from a previous project and dropping them into a new spec without checking whether the standards have been updated, whether the products are still available, or whether the performance requirements match the new design. Standards change regularly. BS 8233 was revised, Part L requirements tightened, and product certifications expire. A specification full of outdated references undermines your professional credibility and creates legal exposure.
The second common mistake is poor coordination between the specification and other project documents. A door schedule that specifies FD30S fire doors while the specification calls for FD60 is a problem that will surface on site, not in a design review meeting. These coordination gaps are exactly the kind of issue that AI-powered specification tools are built to catch. Avoice, for example, ingests project documentation including schedules, drawings data, and material libraries, and can flag inconsistencies before they reach the contractor.
The third mistake is writing specifications in isolation. Specs need to be coordinated with the structural engineer's specification, the M&E consultant's specification, and the landscape architect's specification. Junction details, interface conditions, and sequencing requirements all live in the gaps between consultant specifications. If nobody owns those gaps, nobody specifies them.
Specification writing for RIBA work stages is ultimately about rhythm. Too much detail too early wastes time and constrains your design. Too little detail too late creates risk and rework. The right approach is progressive specificity: outline at Stage 2, performance-based at Stage 3, fully prescriptive at Stage 4, and actively managed through Stages 5 to 7.
Building that rhythm into your practice requires two things. First, a clear specification strategy agreed at the start of every project, including classification system, authoring responsibilities, and review gates aligned with RIBA stage sign-offs. Second, tools that support progressive specification development rather than treating the spec as a monolithic document written once at Stage 4. Avoice is built around this principle, allowing firms to develop specifications incrementally through project stages while maintaining consistency and standards compliance throughout.
The practices that get specification writing right aren't necessarily the ones with the biggest teams or the most experience. They're the ones that treat specifications as a design tool, not an administrative burden, and invest in systems that make progressive specification development practical rather than aspirational.
