Why Specifications Fail the Same Way in Every Practice

What does a specification audit actually look at?

A specification audit reads an issued specification against the drawings, schedules and standards it depends on, records every defect, and then asks a second question: where in the practice's process was this defect introduced?

The first question produces a defect register. That is useful on its own, and the common defect types are set out in Common Specification Defects at Contract Issue. The second question is the one that matters to a technical director, because a defect fixed on one project comes back on the next if its cause is still in the process.

The pattern across audits is consistent. When a practice issues ten specifications in a year and each one contains the same handful of defect types, the author is rarely the variable. The master they started from, the way decisions reached the document, and the way the document was checked are the variables. Two authors in the same practice, one with twenty years' experience and one with two, will usually produce the same defect profile because they share the same master and the same handoffs.

Why the distinction matters commercially

A defect register tells you how much risk is in the document you are about to issue. A root-cause summary tells you how much risk is in every document you will issue this year. Partners tend to fund the second conversation and tolerate the first, because the first looks like a one-off cost and the second looks like a fee-protection decision.

If the same defect appears in three consecutive projects, stop correcting the projects and correct the process that produced them.

What are the eight root causes of recurring specification defects?

Audits trace most recurring defects to eight practice-level habits. They are listed roughly in order of how often they appear and how much of the defect register each one explains.

01. The master is an old project in disguise

The most common finding in a specification audit is that the practice's office master is not a master at all. It is the specification from a project that went well, with the project name deleted. It still carries that project's products, that project's U-values and that project's cross-references. Every new project starts by inheriting another project's decisions, and the author has to find and remove them one by one. Some are always missed.

The tell in an audit is a clause that refers to a site condition, client standard or system the current project does not have. A school specification that mentions a plant room on level 14 was not written for a school. The fix is structural: a master contains only what is true for every project, with everything else either removed or marked as a decision the project must make. The Office Master Specification: A Technical Director's Guide covers how to set this up.

02. Nobody owns the master

A master without an owner drifts. One team updates a fire clause after a project lesson, another team keeps using the copy they saved last year, and the practice ends up with two or three masters in circulation that disagree with each other. Standards get withdrawn and replaced, and nobody is responsible for noticing. Audits regularly find references to standards that were superseded years earlier, still carried forward because no one's job was to check.

The tell is simple: ask three project leads where the current master is. If you get three answers, the master has no owner. The fix is a named owner, a review cycle (quarterly is realistic for standards, with a full review each year) and a single location that every project starts from.

03. Copy-forward without comparison

Even with a good master, most project specifications begin as a copy of the previous project, because that project already had the right sections and the right products. The copy brings its cross-references with it. "Refer to clause 12.4" was correct on the last project, where clause 12.4 existed. On this project, section 12 was reorganised and clause 12.4 is something else, or nothing. The same mechanism produces contradictions: a value changed in one clause and not in the three others that repeat it.

The tell is any reference that points nowhere, and any value that appears in more than one place with more than one number. The fix is not to stop copying forward, which is efficient, but to compare rather than read when the copy is done: every cross-reference resolved, every repeated value checked once against its source.

04. Decisions live in email, not in the document

Open TBCs at tender are rarely open because the decision has not been made. They are open because the decision was made in a meeting, agreed in an email thread, and never moved into the specification. The team knows the answer. The contractor pricing the document does not. An open TBC at contract issue is priced as a risk, or left for a claim later. TBCs in Specifications at Tender sets out the contractual consequences.

The tell is a TBC that anyone on the team can answer from memory. The fix is a handoff with an owner: a decision log that records each open item, who decides it, when, and the step that writes it into the clause. The log does not need to be sophisticated. It needs to exist and to be checked before issue.

05. Drawings, schedules and specification are edited apart

Drawing mismatches come from how documents are produced, not from carelessness. The plan is updated on Tuesday by one person, the door schedule on Thursday by another, and the specification the following week by a third. Each is correct at the moment it is saved. Together they give the contractor three fire ratings for the same door. Audits of practices with a BIM workflow find this just as often as audits of practices without one, because the model and the specification are still edited separately.

The tell is any element whose performance appears in more than one document with more than one value. The fix is to decide, element by element, which document holds the value and which documents refer to it, and then to run a comparison across the set before each issue rather than relying on each author to remember.

06. Performance written as adjectives

"Provide good acoustic separation." "Use suitable fixings." "Finish to an appropriate standard." These clauses read well and specify nothing. They cannot be priced, cannot be tested on site and cannot be enforced when the installed work disappoints. They tend to come from masters written for a prescriptive era, where the product name carried the performance and the adjective was decoration. When the product name is removed for a performance clause, only the adjective is left.

The tell is a clause with no number, no named standard and no acceptance method. The fix is a rule, applied in the master and checked at review: every performance clause states the result, the standard it is measured against and the evidence that proves it.

07. Design responsibility is implied, not assigned

Contractor-designed portions are where specification gaps become expensive. The curtain walling, the roof system, the fire stopping: each is expected to be designed by a specialist, but the specification does not say who, does not say what inputs they receive, and does not say what they must return and when. Two specialists each assume the other owns the interface. Neither designs it.

The tell is a design responsibility matrix that does not exist, or one that stops at Stage 3 and was never carried into the specification. The fix is to assign each portion once, in writing, with inputs, interfaces, deliverables and the stage by which they are due, and to make the specification and the matrix agree. See the design responsibility matrix guide.

08. The review is a proofread, not a comparison

Every practice reviews its specifications before issue. Most reviews read the document from the front for sense and style. That catches typing errors and awkward sentences. It cannot catch an orphan reference, because the reviewer would need to go and look for clause 12.4. It cannot catch a contradiction with the door schedule, because the schedule is not open. It cannot catch a withdrawn standard, because the reviewer would need to check the standard's status. Everything in causes 01 to 07 passes a proofread.

The tell is review markup that is almost entirely about wording. The fix is to review by comparison: identity (do the tags match), extent (is every clause located), performance (do the values agree across documents), references (does every one resolve), status (is every standard current) and decisions (is every TBC closed or owned). The coordination checks in the beginners' guide give the full sequence.

How do you tell which root causes your practice has?

Start from the defect register, not from opinion. Each defect type points to a short list of likely causes, and three issued specifications are usually enough to see the pattern.

Take the last three specifications the practice issued at tender, ideally from different teams. Record every defect against the six types in the table below. Then read across. If leftover master content dominates, the cause is in the master (01, 02). If orphan references and contradictions dominate, the cause is copy-forward (03) and review (08). If TBCs dominate, the cause is the decision handoff (04). Most practices find they have four or five causes active at once, but one or two explain most of the register.

What should a technical director change first?

Fix the master and its ownership first, add a comparison check before issue second, and move decisions into the document third. That order removes the most defects for the least disruption, and it is achievable in 90 days without stopping live projects.

What to leave alone

Do not begin with a practice-wide reclassification, a new template or a training programme. Each of those is a large project that produces nothing measurable for months, and none of them removes a cause. A classification change in particular is worth doing only once the master has an owner, otherwise you reclassify an old project and carry its defects into a new structure.

Do not begin with the people, either. Audits consistently find the same defect profile from experienced and junior authors in the same practice. Training individuals while the master and the review stay the same reproduces the defects with better grammar.

• ✓One master, one owner, one location, one review cycle.
• ✓Every clause in the master is either true for all projects or marked as a decision.
• ✓Every issue passes a comparison check, not a proofread.
• ✓Every open decision has an owner and a date, and is closed in the document, not in email.
• ✓Every repeated value has one source document and the others refer to it.
• ✓Every specialist design portion is assigned once, with inputs, interfaces and deliverables.

How do you measure whether the change worked?

Count defects per hundred clauses and open TBCs at tender before and after. Both are cheap to measure, both move within one project cycle, and partners understand both without explanation.

Four measures are enough. Record them on the three specifications audited at the start, then on the next three issued after the changes. The comparison is the report to the partners. Avoid measures that depend on site outcomes, such as the number of RFIs or variations, because they lag by a year and have too many other causes.

Coordination defects per document

The State of UK Specifications 2026 review found a median of 12 coordination defects per document.

Open TBCs at tender

Count of unresolved TBCs in the issued document. Should approach zero once the decision log is working.

Decision lag

Days between a value being agreed and appearing in the specification. Measures cause 04 directly.

Master drift

Number of master copies in use, and age of the oldest standard reference. Should be one copy and under a year.

Questions technical directors ask about specification audits

What is a specification audit?

A structured review of one or more issued specifications against the drawings, schedules and standards they rely on. It records every defect and traces each one back to the point in the practice's process where it was introduced. The output is a defect register and a root-cause summary.

Why do the same specification defects keep recurring?

Because they are produced by the practice's process rather than by an individual author. A defect corrected on one project reappears on the next while the master, the handoffs and the review method stay the same.

What should a technical director fix first?

The master and its ownership, then the review method, then the decision handoff. That sequence removes the most defects in the shortest time and does not require live projects to stop.

How many defects does a typical UK specification contain at contract issue?

Avoice's State of UK Specifications 2026 review found internal contradictions in 94% of specifications, orphan references in 88%, leftover master content in 82% and open TBCs in 76%. The counts vary with project size; the pattern does not.

Is this a training problem or a process problem?

Mostly process. The same defect profile appears from experienced and junior authors in the same practice, which points to the master and the review rather than individual skill. Training is most effective once the process stops reintroducing the defects.

Does moving to Uniclass or a new template fix these causes?

No. A reclassification or a new template reorganises the content. It does not give the master an owner, move decisions out of email or change the review from a proofread to a comparison. Do those first, then reclassify if the practice needs to.

Where Avoice fits

Most of the eight causes are coordination failures between a master, a set of project decisions and a set of documents. That is the kind of work software can hold in place once the practice has decided what the rules are.

In Avoice the office master is a governed library with an owner, and projects draw from it rather than copying the last job. Practice rules (the values that must agree, the standards that must be current, the words that must not appear) are applied as the specification is written, not discovered at review. The pre-issue technical review is a comparison across the specification, schedules and drawings rather than a read-through, so causes 03, 05 and 08 are checked by the system before a technical director sees the document. Open decisions are tracked against the clauses they affect, which closes cause 04.

The boundary is the same as in every field guide: software can retrieve, compare and flag. The technical director still decides what the practice's standard is.