A regional contractor showed me their change order analysis for a completed year. Forty-one million dollars of work, 214 change orders, and a pie chart. The largest slice, 63 percent, was labeled “design issue.”<\/p>\n\n\n\n
I asked what they had done with that finding. Nothing, because there was nothing to do with it. “Design issue” is not a category. It is a shrug with a percentage attached. It tells you where the money went and nothing about how to stop it going there again.<\/p>\n\n\n\n
The firms that actually reduce this number do one unglamorous thing first. They classify. Not into two buckets but into categories specific enough that each one points at a different fix: a different checklist item, a different review phase, a different reviewer, a different detection method.<\/p>\n\n\n\n
This article is that classification. Nine types of constructability issues<\/strong>, what each one looks like on real drawings, what causes it, how it gets detected, and what it costs when it is not. For how reviews are scheduled and governed, see the article on the constructability review process. For the verification prompts themselves, see the constructability review checklist.<\/p>\n\n\n\n Precision here prevents an argument later. Several distinct things get called constructability issues, and only some of them are.<\/p>\n\n\n\n Constructability issue<\/strong> is a condition in the design documents that will make the work difficult, expensive, slow, unsafe, or impossible to build, price, sequence, operate, or maintain as shown. The design may be entirely correct and still contain constructability issues.<\/p>\n\n\n\n Design error<\/strong> is a condition that is wrong: a calculation mistake, a code violation, a structural member undersized for its load. Errors are a design quality problem with professional liability implications. Constructability issues usually are not.<\/p>\n\n\n\n Omission<\/strong> is required information that is absent. It sits between the two: sometimes a document completeness issue, sometimes a standard-of-care question.<\/p>\n\n\n\n Clash<\/strong> is a geometric interference between two modeled elements. A subset of one issue type, not a synonym for the whole field.<\/p>\n\n\n\n That distinction has consequences beyond vocabulary. Presenting results as mistakes incites a defensive reaction from the design team and creates an exposure risk that obstructs progress. Presenting the same observations as conditions of constructability keeps the focus of the discussion on the procedural aspects of buildability, where it belongs, and where it can be addressed most efficiently.<\/p>\n\n\n\n The mechanism is straightforward once you see it. Different issue types are invisible to different detection methods, and a firm that does not classify cannot tell which method it is missing.<\/p>\n\n\n\n Consider two firms with identical field problem rates. Firm A runs excellent model coordination and no checklist review. Firm B runs a strong checklist and no coordination. Both feel like they are doing constructability review. Firm A leaks missing details and specification conflicts constantly. Firm B leaks spatial conflicts in congested zones. Neither one can see its own blind spot, because both measure the same undifferentiated total.<\/p>\n\n\n\n Classification makes the blind spot visible. When 40 percent of your field problems trace to a category your review process has no method for detecting, that is a diagnosis rather than a complaint.<\/p>\n\n\n\n Read the last column carefully. Clash detection is blind to five of nine categories. That is not a criticism of coordination, which does its job well. It is an argument against treating coordination as the constructability review, which is a substitution I see constantly.<\/p>\n\n\n\n Issue types map onto reviewers with surprising consistency, which makes review team composition a design decision rather than a staffing convenience.<\/p>\n\n\n\n The practical use of that table is to check your review team against it. If your reviews are staffed by a project engineer and a VDC manager, you have good coverage on four categories and effectively none on sequence, tolerance, operability, or code. That is a predictable pattern of field problems waiting to happen.<\/p>\n\n\n\n Nine is a working number. Fewer and the categories stop pointing at distinct fixes. More and reviewers stop applying them consistently.<\/p>\n\n\n\n Required information is absent. The most common category on nearly every project and the easiest to detect mechanically.<\/p>\n\n\n\n What it looks like: a detail bubble referencing a detail that was never drawn. A wall type on plan that does not appear in the schedule. A finish schedule entry for a room number that no longer exists. Dimension strings that do not close. A specification section calling for a submittal on a system the drawings do not show.<\/p>\n\n\n\n Root cause is almost always issuance mechanics rather than negligence. Sheets get renumbered between issuances, details get relocated, a consultant’s scope changes and their callouts do not get updated. Nobody decides to omit a detail. The set drifts.<\/p>\n\n\n\n This category is where AI-assisted review produces its clearest wins, because reference integrity is pure matching across a large set. A human checking 900 sheets for orphaned callouts will miss some. Software will not.<\/p>\n\n\n\n Two documents say different things. Both are complete. They disagree.<\/p>\n\n\n\n What it looks like: drawings show a 4 inch cavity, specifications require 5 inch insulation. Architectural plans show a slab elevation the structural drawings contradict. A door schedule specifies hardware inconsistent with the rated assembly on the plan. Two sheets detail the same waterproofing transition differently.<\/p>\n\n\n\n The dangerous property of this category is that each document is internally defensible. A trade prices what they read, installs what they priced, and the conflict surfaces when two trades meet at the interface with incompatible work already in place.<\/p>\n\n\n\n Root cause is usually parallel document production without a reconciliation pass. Drawings and specifications are frequently produced by different people on different schedules.<\/p>\n\n\n\n Two elements cannot both occupy the space shown. The classic clash.<\/p>\n\n\n\n What it looks like: a duct main crossing a beam at an elevation that requires a penetration the structural drawings prohibit. A stair landing that does not align with the floor level. A shaft that changes dimension between floors with no transition. Equipment shown in a room where the equipment plus its clearance exceeds the room.<\/p>\n\n\n\n This is the category model coordination handles well and sheet review handles poorly, because plan-only review cannot see vertical conflict. If your review does not include sections and a model, expect to leak this category into the field.<\/p>\n\n\n\n Everything fits geometrically, and there is no room to install it, work in it, or get a body between components.<\/p>\n\n\n\n What it looks like: a plenum where ductwork, cable tray, sprinkler main, and structure total more than the available depth once hangers and insulation are counted. A pipe chase sized for the pipes but not for the installer’s hands. Electrical working clearance obstructed by other trades’ work. A congested corridor where four trades must all install above the ceiling in sequence.<\/p>\n\n\n\n The distinction from category three matters. A clash detection run on modeled centerlines will pass a plenum that no installer can actually work in. Congestion is about constructability, not geometry, and it is one of the strongest arguments for having someone who has installed ductwork look at the sections.<\/p>\n\n\n\n The work can be built. It cannot be reached afterward.<\/p>\n\n\n\n What it looks like: a damper above a hard ceiling with no access panel. A valve behind millwork. An air handler with less coil pull space than the coil is long. A rooftop unit with no replacement path once the parapet and screen are complete. A control device in a ceiling the infection control plan will not allow anyone to open.<\/p>\n\n\n\n Root cause is structural in the review process rather than in the design. The person who would notice these conditions is the owner’s facilities manager, and they are almost never invited. Design teams locate devices where the systems require. Contractors review for installation. Nobody reviews for the following twenty years.<\/p>\n\n\n\n Each element is buildable. The order required to build them is not achievable.<\/p>\n\n\n\n What it looks like: equipment that cannot be set after the enclosure is complete, with no rigging opening shown. A detail requiring shoring in a space the detail leaves no room for. Formwork that cannot be stripped because adjacent work encloses it. A phasing plan where the temporary condition has no structural support. Finish work scheduled before wet trades above it.<\/p>\n\n\n\n No automated method finds this category, and that is unlikely to change soon. It requires reasoning about temporary conditions that appear nowhere in the documents, using knowledge of how crews actually work. It is the single strongest argument for having a superintendent in every review.<\/p>\n\n\n\n Two systems meet, and their tolerances are incompatible or the transition between them is undefined.<\/p>\n\n\n\n What it looks like: a cast-in-place structure with a tolerance of plus or minus three quarters of an inch receiving a curtain wall system that accepts a quarter inch. A storefront meeting a masonry opening with no defined joint. A precast panel joint dimension that assumes structural accuracy the structural specification does not require. A floor finish requiring a flatness the slab specification does not deliver.<\/p>\n\n\n\n Tolerance conflicts are quietly among the most expensive findings because they surface at fabrication or installation, well past the point where anything is cheap. Trade partners find them immediately and are rarely asked in time.<\/p>\n\n\n\n The documented assumption about the site or existing structure does not match reality, or the site cannot support the construction the design requires.<\/p>\n\n\n\n What it looks like: a crane with no position that reaches all structural picks. Staging shown on ground needed for phase-one work. An existing utility at an undocumented depth crossing the new footing line. A renovation detail assuming a wall assembly that turns out to be different. Delivery access requiring a turning radius the site does not provide.<\/p>\n\n\n\n Detection requires a site walk and, on renovation work, reality capture. Document review alone cannot find this category, which is why the schematic design review should include somebody who has physically stood on the site.<\/p>\n\n\n\n The design is buildable and will not pass, or the sequence it requires is not permitted.<\/p>\n\n\n\n What it looks like: a phasing plan assuming a lane closure the agency will not approve. An inspection sequence requiring access to work that will be concealed by the time the inspector arrives. A rated assembly penetrated with no listed firestop configuration available. An egress path that works at completion and is blocked during a construction phase. Temporary conditions that violate occupancy requirements in an operating facility.<\/p>\n\n\n\n This category carries the sharpest consequence, because the remedy is often a stop-work order rather than a change order. On infrastructure and healthcare renovation work it deserves its own dedicated review pass.<\/p>\n\n\n\nKEY TAKEAWAY<\/strong>
Classification is not administrative tidiness. Each issue type has a different detection method and a different economical point of discovery. A firm that cannot separate a missing detail from a spatial conflict cannot know whether it needs better checklists or better coordination.<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\nKey Definitions: Separating Issues From Errors<\/strong><\/strong><\/h2>\n\n\n\n
Finding type<\/strong><\/strong><\/th> Nature of the problem<\/strong><\/strong><\/th> Who resolves it<\/strong><\/strong><\/th> Liability character<\/strong><\/strong><\/th><\/tr><\/thead> Constructability issue<\/strong><\/td> Buildable in principle, problematic as documented<\/td> Design team with contractor input<\/td> Generally none<\/td><\/tr> Design error<\/strong><\/td> Incorrect engineering or code compliance<\/td> Design team<\/td> Potential professional liability<\/td><\/tr> Omission<\/strong><\/td> Required information absent from the documents<\/td> Design team<\/td> Depends on standard of care<\/td><\/tr> Coordination clash<\/strong><\/td> Two modeled elements occupy the same space<\/td> Trade detailers, VDC<\/td> Usually contractual, not professional<\/td><\/tr> Field condition<\/strong><\/td> As-built reality differs from documented assumption<\/td> Contractor with design confirmation<\/td> Depends on the contract<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n FIELD REALITY<\/strong>
Write findings as conditions, never as accusations. “Detail 7\/A-502 is wrong” starts a liability conversation. “Detail 7\/A-502 shows a 4 inch cavity; the specified insulation is 5 inches” starts a revision. Same finding, entirely different week.<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\nObjectives: What Classification Buys You<\/strong><\/strong><\/h2>\n\n\n\n
\n
Objective<\/strong><\/strong><\/th> Indicator<\/strong><\/strong><\/th> What good looks like<\/strong><\/strong><\/th><\/tr><\/thead> Findings are classified<\/strong><\/td> Share of log entries with a category assigned<\/td> 100 percent, applied at logging<\/td><\/tr> Categories drive action<\/strong><\/td> Checklist items added per category per year<\/td> Every high-frequency category grew<\/td><\/tr> Detection is matched to type<\/strong><\/td> Share of each category found by its intended method<\/td> Missing details found by checklist, not by field<\/td><\/tr> Discovery moves earlier<\/strong><\/td> Median phase of discovery by category<\/td> Sequence issues at SD, details at CD<\/td><\/tr> Field leakage falls<\/strong><\/td> RFIs classifiable into a review category<\/td> Declining year over year<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Why Taxonomy Changes Outcomes<\/strong><\/strong><\/h2>\n\n\n\n
Issue type<\/strong><\/strong><\/th> Primary detection<\/strong><\/strong><\/th> Secondary<\/strong><\/strong><\/th> Blind to<\/strong><\/strong><\/th><\/tr><\/thead> Missing or incomplete information<\/strong><\/td> Checklist \/ AI review<\/td> Estimator during pricing<\/td> Model coordination<\/td><\/tr> Conflicting information<\/strong><\/td> AI document comparison<\/td> Checklist review<\/td> Model coordination<\/td><\/tr> Dimensional and geometric conflict<\/strong><\/td> Model coordination<\/td> AI dimension checks<\/td> Visual sheet review<\/td><\/tr> Spatial congestion and clearance<\/strong><\/td> Model coordination<\/td> Section-based review<\/td> Plan-only review<\/td><\/tr> Access, operability, maintainability<\/strong><\/td> Checklist with O&M input<\/td> Model review<\/td> Clash detection<\/td><\/tr> Sequence, means, and methods<\/strong><\/td> Superintendent review<\/td> Schedule analysis<\/td> All automated methods<\/td><\/tr> Interface and tolerance<\/strong><\/td> Trade partner review<\/td> Detail-level checklist<\/td> Clash detection<\/td><\/tr> Existing conditions and logistics<\/strong><\/td> Site walk, reality capture<\/td> Superintendent review<\/td> Document review alone<\/td><\/tr> Code, permit, and inspection<\/strong><\/td> Code review, AHJ consultation<\/td> Checklist<\/td> Model coordination<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n INDUSTRY INSIGHT<\/strong>
The most under-detected category across the industry is access, operability, and maintainability, because the people who would catch those findings work for the owner’s facilities group and are almost never in the review. It is the cheapest gap to close in this entire article.<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\nStakeholders: Who Finds What<\/strong><\/strong><\/h2>\n\n\n\n
Reviewer<\/strong><\/strong><\/th> Categories they find best<\/strong><\/strong><\/th> Categories they systematically miss<\/strong><\/strong><\/th><\/tr><\/thead> Superintendent<\/strong><\/td> Sequence and means, logistics, access<\/td> Specification conflicts, schedule reconciliation<\/td><\/tr> Estimator<\/strong><\/td> Missing information, conflicting information<\/td> Spatial congestion, sequence feasibility<\/td><\/tr> BIM \/ VDC Manager<\/strong><\/td> Dimensional conflict, spatial congestion<\/td> Detail omissions, code and permit conditions<\/td><\/tr> Project Engineer<\/strong><\/td> Reference integrity, schedule reconciliation<\/td> Means and methods, tolerance interfaces<\/td><\/tr> Trade partner<\/strong><\/td> Interface and tolerance, installability<\/td> Cross-discipline coordination beyond their scope<\/td><\/tr> Owner facilities<\/strong><\/td> Operability and maintainability<\/td> Everything construction-phase<\/td><\/tr> Code consultant<\/strong><\/td> Code, permit, and inspection conflicts<\/td> All physical constructability<\/td><\/tr> AI-assisted review<\/strong><\/td> Missing and conflicting information, threshold checks<\/td> Sequence, means and methods, novel conditions<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n The Nine Categories of Constructability Issues<\/strong><\/strong><\/h2>\n\n\n\n
1. Missing or Incomplete Information<\/strong><\/strong><\/h3>\n\n\n\n
2. Conflicting Information<\/strong><\/strong><\/h3>\n\n\n\n
3. Dimensional and Geometric Conflict<\/strong><\/strong><\/h3>\n\n\n\n
4. Spatial Congestion and Clearance<\/strong><\/strong><\/h3>\n\n\n\n
5. Access, Operability, and Maintainability<\/strong><\/strong><\/h3>\n\n\n\n
6. Sequence, Means, and Methods<\/strong><\/strong><\/h3>\n\n\n\n
7. Interface and Tolerance Conflict<\/strong><\/strong><\/h3>\n\n\n\n
8. Existing Conditions and Site Logistics<\/strong><\/strong><\/h3>\n\n\n\n
9. Code, Permit, and Inspection Conflict<\/strong><\/strong><\/h3>\n\n\n\n
Category<\/strong><\/strong><\/th> Typical frequency<\/strong><\/strong><\/th> Economical discovery phase<\/strong><\/strong><\/th> Typical impact if missed<\/strong><\/strong><\/th><\/tr><\/thead>