ESA Consultancy

Design review is often treated as a verification exercise: check the drawings, confirm compliance with specifications and standards, identify errors, close comments and move on. That is necessary, but it is not enough.
On complex infrastructure projects, the real value of a design review lies in determining whether the proposed solution will actually work as intended — not only on paper.
This is where design checking ends and technical judgement begins.

Compliance is the starting point, not the conclusion
A design may comply with the applicable standards and still be unnecessarily complex, difficult to operate, vulnerable to particular failure modes or poorly aligned with the overall project strategy.
Standards establish essential requirements, but they cannot account for every project-specific interface, operational constraint or design decision.
A meaningful review therefore needs to ask more than “Is this compliant?”
It should also ask:
• Is the design philosophy coherent?
• Are the assumptions behind it still valid?
• What happens when a component fails or is unavailable for maintenance?
• Can the proposed operating sequence actually be implemented safely?
• Are interfaces between systems clearly defined?
• Has the design introduced complexity without delivering a corresponding benefit?
These questions cannot normally be answered through a checklist alone.

Review the system, not just the document
One of the most common weaknesses in design reviews is reviewing individual deliverables in isolation.
A single-line diagram may look perfectly reasonable. So may the equipment specifications, protection study, control philosophy and layout. The problem may only become visible when those documents are considered together.
A switching arrangement shown on the SLD, for example, has implications for protection, interlocking, controls, equipment ratings and operating procedures. A change that appears minor in one document can propagate through several disciplines and packages.
The reviewer therefore needs to understand not only whether each document is correct, but whether the system described by all those documents remains coherent.
This becomes particularly important on large programmes, where designs evolve in parallel and different contractors or engineering teams may own different parts of the same system.

Technical decisions need project context
There is rarely only one technically acceptable solution.
The best solution depends on what the project is trying to achieve.
Reliability, maintainability, constructability, programme, cost, future expansion and operational continuity can all pull the design in different directions. The role of the reviewer is not necessarily to impose a preferred engineering solution, but to understand the consequences of the available choices.
A technically elegant solution that creates major commissioning complexity may not be the right solution. Neither is a cheaper solution necessarily economical if it restricts maintenance or creates operational risk for decades.
Good design review therefore requires an understanding of why the project has made a particular choice, not simply whether that choice can be justified technically.

Experience changes what you look for
Throughout my career, I have observed that design review is often treated as a secondary project activity, particularly on the client side. Limited resources or pressure to reduce engineering costs can result in reviews being assigned to less experienced personnel.
This can create a significant gap in project assurance: the savings achieved during review can be quickly outweighed by the cost of discovering a fundamental design issue during procurement, construction or commissioning.
Experience also changes the questions you ask. Construction, commissioning and operations reveal where apparently sound designs can create practical problems, expose weak assumptions or become difficult to operate and maintain.
Over time, an experienced reviewer learns to look beyond incorrect calculations or missing information and identify conditions under which an otherwise correct design could fail to achieve its intended outcome.
The objective is not to generate more comments. It is to identify the comments that matter.

A good review should reduce uncertainty
The quality of a design review should not be measured by the number of comments issued.
Hundreds of minor comments can coexist with one unresolved system-level risk that ultimately determines the success of the project.
A strong review prioritises issues according to their consequences and helps the project team distinguish between documentation improvements, technical concerns and decisions requiring escalation.
Ultimately, design review is not about proving that somebody else’s design is wrong.
It is about providing confidence that the design is coherent, compliant, robust and aligned with the way the asset is expected to be built and operated.
That requires engineering knowledge.
But on complex projects, it also requires something harder to specify in a procedure: technical judgement.