Understand how to conduct Design Reviews in engineering projects to review requirements, calculations, interfaces, documents, risks, and maturity before the next decision.
Check it out!
Design Review in engineering projects is a structured technical review performed at defined points in development to verify whether requirements, design bases, calculations, drawings, models, specifications, interfaces, and implementation criteria have sufficient maturity for the next decision. The process identifies inconsistencies, gaps, risks, and open items, records comments in a traceable manner, and concludes with a technical decision: proceed, proceed with conditions, revise, or stop development until critical issues are addressed.
In this article, Design Review does not mean an assessment of visual identity, user experience, or graphic design. The focus is on reviewing engineering designs, systems, and infrastructure, including electrical, telecommunications, electronic security, automation, SPDA, Data Centers, and other multidisciplinary solutions.
The method can be applied to PDF documents, CAD drawings, BIM models, design narratives, calculation spreadsheets, lists, diagrams, specifications, and digital management environments. The tool used varies according to the project; the need for criteria, competent reviewers, comment control, evidence, and a formal decision remains.
What is Design Review in engineering projects?
Design Review is the process of critically examining a technical solution before it is consolidated into contracting, procurement, fabrication, installation, integration, or operation. Based on documents and evidence, the review seeks to demonstrate that the design is consistent with the requirements and sufficiently developed to support the next stage.
The review may be internal, independent, multidisciplinary, contractual, or owner-led. In smaller projects, it may take the form of a documented technical analysis. In complex projects, it may be organized as a formal event with entry criteria, a document package, review team, agenda, comment log, responses, conditions, and exit criteria.
The central question of the review
The review should determine whether the solution meets the requirements, whether criteria and assumptions are consistent, whether calculations and selections are verifiable, whether disciplines use compatible references, whether documents describe the same solution, whether risks have been addressed, and whether any open items are incompatible with the decision to proceed.
The conclusion should be proportional to the expected maturity. A conceptual design does not need to contain every execution detail, but it should provide enough information to select an architecture and reject infeasible alternatives. A Detailed Engineering Design should guide procurement and execution without depending on essential decisions left to the field.
Design Review is more than a drawing check
A review limited to geometry or graphic appearance may fail to identify systemic problems. Design Review should consider requirements, bases, calculations, drawings, diagrams, models, lists, specifications, interfaces, installation, integration, testing, operation, maintenance, risks, and pending decisions.
A drawing may be correct in isolation and still be incompatible with the specification, bill of materials, BIM model, available electrical capacity, or implementation sequence.
In this context, Design Management structures the design process, its interfaces, and decisions throughout the life cycle, while Project Assurance adds an independent layer of confidence for critical decisions. When the organization needs to define levels of authority and specialized accountability for deviations and technical approvals, the Technical Authority framework complements the process.
Difference between Design Review and related methods
| Method | Central question | Main outcome |
| Design Review | Is the design consistent, complete, and mature enough for the next decision? | Comments, open items, conditions, and decision to proceed |
| Design Coordination | Are the disciplines and documents coordinated with one another? | Resolved clashes and interfaces |
| Clash Detection | Are there geometric clashes according to the configured rules? | List of clashes and model occurrences |
| Constructability | Can the solution be implemented under actual conditions? | Adjustments to access, sequencing, methods, and logistics |
| Value Engineering | Are there alternatives that provide a better relationship between function and resources? | Recommendations for greater value |
| Verification | Does the technical output meet the specified requirements? | Evidence of technical compliance |
| Validation | Does the solution meet the actual needs of the user and project? | Evidence of fitness for intended use |
| ECM | How will a change be requested, assessed, approved, and implemented? | Controlled change and updated configuration |
These processes may occur in a coordinated manner. A review may identify a clash that requires design coordination, a field difficulty that calls for constructability analysis, or an alternative that requires Value Engineering. If the approved solution is changed, the change process should control the effects on documents, contracts, equipment, and testing.
Independence and technical responsibility
The designer should review their own work before issue, but this verification does not necessarily replace multidisciplinary analysis, owner review, or an independent review required by contract.
- self-checking verifies discipline completeness and consistency;
- peer review challenges calculations, assumptions, and technical decisions;
- multidisciplinary coordination verifies interfaces;
- owner review confirms requirements, operations, and asset interests;
- independent review adds impartiality to critical decisions;
- formal approval authorizes use of the document within defined limits.
The review does not automatically transfer technical responsibility from the author to the reviewer. The scope, limits, and effects of approval should be clear.
Design Review should lead to a technical decision. The review does not end with a list of comments: it should demonstrate the maturity achieved, identify conditions, and indicate whether the design may proceed to detailing, contracting, procurement, or execution.
When to conduct Design Reviews throughout the life cycle
Technical review creates more value when it follows the maturity of the design. Waiting until Detailed Engineering is complete to perform the first analysis concentrates problems and turns the review into late rework.
Complex projects may establish progressive milestones. Each review should have an objective, expected package, entry criteria, exit criteria, and an associated decision.
Requirements review
Before selecting the solution, it is advisable to review the problem, requirements, constraints, and success criteria. The review may examine the objective, functional scope, capacity, performance, criticality, availability, safety, field conditions, maintenance, interfaces, acceptance, budget, and schedule.
Vague or excessively prescriptive requirements compromise subsequent stages. Design Review should separate mandatory needs, preferences, assumptions, and decisions that remain open.
Conceptual Design Review
The conceptual review assesses whether the proposed architecture is suitable to proceed to development. The package may include design bases, alternatives, diagrams, arrangements, estimates, risks, interfaces, and implementation strategy.
The review should verify consistency between requirements and architecture, justification of alternatives, capacity, expandability, interfaces, dependencies, risks, compatibility with existing installations, preliminary feasibility, and information still required.
Preliminary Design Review
The preliminary review examines whether the solution meets the requirements with acceptable risk and whether there is a sufficient basis to proceed to detailing. It may be associated with completion of Basic Design, FEED, or an equivalent stage.
Architecture, preliminary calculations, key sizing, critical equipment, interfaces, spaces, power, communications, contracting, estimates, schedule, risks, and the test plan are normally assessed.
Preliminary approval does not mean that every detail is complete. It means that the concept can be detailed without depending on a foreseeable structural change.
Critical or Final Design Review
The critical or final review verifies whether the design has reached a maturity compatible with procurement, fabrication, installation, integration, and testing. It may be associated with release of Detailed Engineering or issue for construction, provided the criteria are defined.
The package should allow review of completed calculations, coordinated drawings, specifications, lists, interfaces, vendor data, installation, maintenance, migration, testing, residual risks, and documents affected by open items.
Open items need to be classified. Some may be closed later without blocking progress; others prevent contracting, fabrication, or safe execution.
The expected maturity must be linked to the decision gate. A preliminary review authorizes detailing; a final review may support procurement or execution. Using the same checklist at every phase creates premature requirements or weak approvals.
Understand how Stage-Gate structures phases and decisions in engineering projects
Review before procurement
Before going to market or issuing a purchase order, Design Review should verify whether the package describes what will be supplied with sufficient completeness and consistency.
The review may identify missing requirements, discrepancies among documents, undefined equivalency criteria, interfaces left between packages, undefined testing, insufficient documentation, long-lead items, and undefined integration responsibilities.
An incomplete package transfers uncertainty to pricing, exclusions, change orders, and disputes.
Vendor Document Review
Vendor documents need to be reviewed against requirements, specifications, interfaces, and field conditions. Document approval should not be confused with unrestricted acceptance of the solution.
The process may cover fabrication drawings, datasheets, lists, diagrams, power and network requirements, dimensions, weights, access requirements, certificates, FAT, SAT, manuals, and interfaces with other vendors.
Review before execution and in retrofits
Even an approved Detailed Engineering package may require a readiness review before mobilization. This analysis verifies documents, work fronts, materials, access, permits, interfaces, and operating conditions.
In retrofit projects, the review should include the existing condition, intermediate phases, work windows, contingency, rollback, temporary systems, and coordination with operations.
What should be verified in a Design Review?
Requirements and traceability
Each relevant requirement should have an origin, an owner, a means of compliance, and a verification method. The review should identify requirements that are unallocated, duplicated, contradictory, lack measurable criteria, were changed without updating the baseline, or are not covered by testing.
A traceability matrix can link each requirement to the corresponding document, calculation, design element, test, and acceptance evidence.
Design bases, assumptions, and criteria
The design needs to state current and future capacity, loads, environmental conditions, availability, service life, standards, technical limits, contingencies, maintenance requirements, and data received from other disciplines.
Critical assumptions cannot remain hidden only in spreadsheets or in designers’ memory.
Calculations, sizing, and margins
The review should verify the method, inputs, results, consistency, and auditability. It is advisable to examine data sources, spreadsheet and software versions, assumptions, factors, margins, worst-case conditions, units, rounding, and consistency between calculations and selections.
Consistency among documents
Examples of inconsistencies include different quantities between a drawing and a list, a power supply incompatible with the diagram, a route without sufficient capacity, divergent codes, calculated capacity different from the datasheet, incompatible cable identification, different revisions, and details not reflected in the quantities.
Interfaces among disciplines and systems
| Interface | Review questions |
| Architecture x systems | spaces, finishes, doors, visibility, access, and aesthetic integration |
| Structure x installations | openings, loads, supports, bases, and clashes |
| Electrical x telecom | power supply, grounding, segregation, UPS, and continuity |
| CCTV x network | bandwidth, PoE, VLAN, synchronization, storage, and cybersecurity |
| Access control x architecture | frames, hardware, egress routes, and emergency conditions |
| Automation x equipment | signals, protocols, points, logic, and responsibilities |
| Fire protection x other systems | interlocks, shutdowns, doors, and alarms |
| SPDA x electrical and architecture | air termination, down conductors, equipotential bonding, routes, and materials |
| Operations x design | access, isolation, switching, maintenance, and training |
Each interface should have an owner, input information, due date, output document, and closure criterion.
Physical and functional coordination
Coordination may be part of Design Review, but it should not be limited to geometric clashes. The review should examine interferences, clearances, installation and maintenance spaces, segregation, accessibility, functional interfaces, elevations, coordinates, shaft, tray, and technical-room capacity, and conflicts among the model, drawings, and design narrative.
The article Design Coordination in BIM examines federated models, clash detection, BCF, and coordination cycles in greater depth. Design Review has a broader scope and can be applied without BIM.
Constructability, testability, and maintainability
The review should verify whether equipment can reach the site, whether access is available, whether routes accommodate installation and expansion, whether the sequence is compatible with operations, whether systems can be isolated and tested, whether measurement points are available, and whether maintenance can be performed.
Constructability in Engineering Projects should be treated as a complementary analysis.
Safety, standards, and owner criteria
There should be evidence of compliance with electrical safety, emergency, fire protection, grounding, cybersecurity, maintenance, risk, identification, accessibility, and mandatory documentation requirements.
How to conduct a Design Review step by step
1. Define the objective, scope, and associated decision
The plan should identify the stage, purpose, disciplines, documents, criteria, requirements, participants, cut-off dates, versions, recording method, comment classification, and approval criteria.
2. Verify entry criteria
Entry criteria may include a document list, identified versions, approved design bases, calculations, federatable models or coordinated drawings, interfaces, risks, previous responses, open items, and responsible parties.
3. Distribute the package and prepare the reviewers
Reviewers need to receive the documents in advance, with clear objectives and applicable criteria. The meeting should not be used for the first reading of the design.
4. Perform individual and multidisciplinary analysis
Individual analysis examines technical depth. Joint analysis addresses interfaces, dependencies, and system-level decisions.
5. Record technically useful comments
| Field | Expected content |
| Identifier | unique issue code |
| Document | code, title, and revision |
| Location | page, sheet, detail, object, or coordinate |
| Discipline | origin and responsible party |
| Category | requirement, calculation, interface, safety, document, or construction |
| Severity | critical, major, minor, or observation |
| Comment | objective description of the problem |
| Reference | requirement, standard, specification, or decision |
| Required action | correct, clarify, supplement, assess, or decide |
| Responsible party | person or organization in charge |
| Due date | response and closure date |
| Response | technical disposition provided |
| Evidence | supporting document or record |
| Status | open, answered, accepted, rejected, pending, or closed |
Avoid comments such as “verify,” “improve,” or “incompatible” without explaining the problem and the affected criterion.
6. Classify severity
| Class | Characterization | Typical effect |
| Critical | safety risk, essential requirement not met, or infeasible solution | blocks progress |
| Major | significant inconsistency, unresolved interface, or insufficient evidence | requires correction or a formal condition |
| Minor | localized adjustment with no structural impact | may be closed in the next cycle |
| Observation | recommendation without demonstrated nonconformity | does not block progress but should be assessed |
7. Respond to and disposition each comment
The author should provide a technical response indicating whether the comment is accepted, rejected, or addressed through an alternative treatment. Responses such as “acknowledged,” “will be checked,” or “addressed” are insufficient without evidence.
8. Verify closure and configuration
A comment should only be closed after the evidence has been verified. Revised documents, cross-references, lists, quantities, models, interfaces, changes, tests, and the correct issued revision should be confirmed.
When a correction changes the baseline, contract, equipment, performance, or schedule, Engineering Change Management should control its implementation.
A closed comment does not mean the change has been implemented. When a response changes the solution, documents, contracts, configuration, tests, and evidence need to be updated. Without this control, the review decision does not correspond to the design actually issued.
9. Issue the decision and report
Possible statuses include approved, approved with conditions, additional review required, not approved, scope partially approved, or decision deferred due to insufficient information.
The report should record participants, documents, limitations, conclusions, critical comments, conditions, responsible parties, deadlines, and decision authority.
Tools for Design Review: CAD, BIM, Engios, and NetBox
PDF and redlining
PDF review remains valid for design narratives, specifications, reports, diagrams, and drawings. There should be standardization, preservation of the original, linkage between markup and record, revision identification, and closure control.
CAD and overlays
CAD designs can be reviewed through discipline overlays, version comparison, layer analysis, external references, and coordinates. Source, scale, units, naming, versions, alignment, conflicts, and incorporation of corrections should be controlled.
The absence of BIM does not prevent coordination or Design Review.
BIM, federated models, and BCF
In BIM, the review can use federated models, checking rules, filters, viewpoints, clash detection, and BCF. Coordinates, levels, parameters, classification, authorship, and revision should be verified before analysis.
Clash detection alone does not verify requirements, calculations, functional logic, contracts, or operations.
Engios as a governance environment
Engios can structure projects, documents, revisions, responsible parties, comments, approvals, evidence, deadlines, and decision history. It can support issuance, coding, workflows, comment matrices, dashboards, traceability, and connections to contracts and deliverables.
NetBox as a source of context
NetBox does not replace CAD, BIM, or authoring software. In networks, Data Centers, and infrastructure, it can serve as a source of truth for assets, racks, devices, circuits, interfaces, addressing, sites, and connectivity.
During Design Review, it can help verify compatibility with existing infrastructure, capacity, dependencies, addressing, migrations, and consistency between the logical design and inventory.
Integration among environments
A mature architecture can combine CAD or BIM for authoring, PDF for issuance, BCF for issues, Engios for governance, NetBox for infrastructure, calculation tools as evidence, and a CDE for distribution.
The authoring tool does not replace review governance. CAD, BIM, and PDF represent the solution; Engios can control issuances, comments, responses, approvals, and evidence; NetBox can preserve the context of infrastructure and connectivity.
Learn about Engios as a technical management platform for engineering
Governance, deliverables, and contracting
Roles and responsibilities
| Role | Typical responsibility |
| Owner | defines requirements, criteria, authority levels, and the decision to proceed |
| Review coordinator | plans the review, distributes the package, consolidates comments, and controls closure |
| Design author | presents the solution, responds to comments, and revises documents |
| Discipline reviewer | assesses technical depth and compliance |
| Multidisciplinary coordinator | verifies interfaces and consistency |
| Operations and maintenance | assesses use, access, maintenance, and continuity |
| Procurement and contracts | verifies the package, responsibilities, and contractual effects |
| Execution and commissioning | assesses implementation, testing, and acceptance |
| Independent reviewer | challenges assumptions and critical decisions |
Deliverables
Deliverables may include a review plan, document list, checklists, redlines, comment log, interface matrix, inconsistency report, meeting minutes, response matrix, closure report, conditions, maturity assessment, and open-item dashboard.
Approval needs to state its limits. “Approved,” “released for purchase,” or “released for construction” should not be used without defining their effects and the accepted open items.
Contractual scope
The contract should clarify disciplines, stage, maturity, documents, review cycles, schedule, meetings, consolidation, severity, format, vendor documents, additional reviews, reviewer responsibility, and acceptance criteria.
Design Review in Owner’s Engineering
Within Owner’s Engineering, the review protects the owner’s interests by verifying whether designers, suppliers, and contractors comply with requirements, contracts, interfaces, and acceptance criteria.
The scope may include independent review, comment consolidation, response verification, management of conditions, equivalency analysis, vendor document review, and decision support.
Design Review must protect the owner’s interests. Approval should consider requirements, interfaces, operations, risks, contracts, and acceptance criteria, preventing the review from being limited to confirming the solution proposed by the supplier itself.
Deepen technical governance with the Owner’s Engineering framework
Examples in A3A systems
Structured cabling. Topology, outlets, routes, fill ratios, distances, technical rooms, grounding, identification, and certification.
CCTV. Coverage, position, lighting, resolution, retention, bandwidth, storage, power, network, and cybersecurity.
Access control. Architecture, doors, hardware, power, controllers, network, fire systems, elevators, egress, and emergency conditions.
Electrical installations. Demand, capacity, protection, selectivity, voltage drop, short circuit, grounding, diagrams, shutdowns, and testing.
SPDA and surge protection devices. Risk analysis, method, air termination, down conductors, grounding, equipotential bonding, surge protection devices, and interfaces.
Data Centers. Availability, topologies, capacity, redundancy, concurrent maintainability, power, cooling, telecommunications, security, and expansion.
Retrofit and migration. Existing conditions, sequencing, windows, contingency, rollback, temporary systems, and As-Built documentation.
Common mistakes
- reviewing only at the end;
- starting without criteria;
- using reviewers without requirements;
- treating the meeting as a presentation;
- recording vague comments;
- confusing preferences with requirements;
- not classifying severity;
- accepting responses without evidence;
- closing comments without updating documents;
- ignoring interfaces;
- considering clash detection sufficient;
- allowing parallel versions;
- not controlling changes;
- approving without conditions.
Closeout checklist
- [ ] objective and decision are clear;
- [ ] package and revisions have been identified;
- [ ] critical requirements have supporting evidence;
- [ ] key calculations have been examined;
- [ ] documents describe the same configuration;
- [ ] interfaces have been reviewed;
- [ ] critical risks have defined treatments;
- [ ] constructability, testing, and maintenance have been considered;
- [ ] comments have been classified and answered;
- [ ] corrective evidence has been verified;
- [ ] changes have been formalized;
- [ ] conditions have an owner and due date;
- [ ] decision and authority have been recorded;
- [ ] the released package corresponds to the approved revision.
An effective Design Review does not seek to eliminate all risk or turn the reviewer into a co-author of every document. Its role is to verify maturity, expose relevant problems, and create a technical basis for decisions before inconsistencies become incorrect purchases, rework, change orders, integration failures, or operating difficulties.
Technical references
[1] NASA. NASA Systems Engineering Handbook. Technical reviews, design maturity, Preliminary Design Review, and Critical Design Review.
[2] ISO/IEC/IEEE 15288:2023 — Systems and software engineering — System life cycle processes. Life-cycle processes, requirements, architecture, integration, verification, and validation.
[3] ISO 9001:2015 — Quality management systems — Requirements. Design and development controls, inputs, outputs, reviews, and changes.
[4] ABNT NBR 16277:2017 — Auditoria de projetos — Orientações para desenvolvimento e execução.
[5] Project Management Institute. PMBOK Guide — Eighth Edition. Governance, quality, risks, requirements, deliverables, and decisions.
[6] ABNT NBR ISO 21502:2021 — Gerenciamento de projetos, programas e portfólios — Orientações sobre gerenciamento de projetos.
[7] ABNT NBR ISO 19650 series — Organization and digitization of information about buildings and civil engineering works, including BIM.
Frequently asked questions
It is a structured technical review that verifies requirements, calculations, documents, interfaces, risks, and design maturity before a decision to proceed, contract, procure, or execute.
No. Design coordination verifies coordination among disciplines and documents. Design Review has a broader scope and also examines requirements, bases, calculations, risks, documentation, implementation, testing, and maturity.
No. The review can be performed using PDF, CAD, design narratives, calculations, spreadsheets, and other documents. BIM expands model and interface analysis, but it is not a requirement for the process.
The Preliminary Design Review verifies whether the preliminary solution meets the requirements and can proceed to detailing. The Critical or Final Design Review verifies whether the design is mature enough for fabrication, procurement, installation, integration, and testing.
The composition depends on the project and may include the owner, coordination team, designers, discipline reviewers, operations, maintenance, safety, contracts, execution, commissioning, and independent review.
Each comment should have an identifier, document, location, category, severity, description, reference, responsible party, due date, response, evidence, and closure status.
Not automatically. The author’s technical responsibility remains according to applicable law and contract. The scope and effects of the review and approval need to be expressly defined.
Engios can control documents, revisions, comments, responsible parties, approvals, and evidence. NetBox can provide context and a source of truth for assets, racks, circuits, interfaces, and connectivity.
Additional technical materials
Solutions
- Requirements, Evidence, and Acceptance Criteria Management
- Document Governance and Document Management System
- Electronic Technical Document Management and Revision Control
- Engios — Management Platform for Engineering Companies
Engineering services
- Design Coordination and Integration
- Detailed Engineering Design
- Project Management — Owner’s Engineering
- Site Survey and Technical Survey
- EPCM — Engineering, Procurement and Construction Management
Technical guides
- Complete Guide to Engineering Consulting
- Project Management: Complete Guide to Engineering, Governance, and Control
- Complete Guide to Engineering Bidding and Contracts
- Complete Guide to Cost Engineering and Estimating
Whitepapers
- Owner’s Engineering: Executive Framework for Contracting, Governance, and Acceptance
- Digital Technical Governance for Engineering Companies
- Engios — Technical Management Platform for Engineering Companies
- Contracting Engineering Consulting with Traceability and Governance
Technical articles
- Design Coordination in BIM
- Constructability in Engineering Projects
- Engineering Change Management in Engineering Projects
- Detailed Engineering Design
- Stage-Gate in Engineering Projects
