The contractor designs the plant. The owner lives with it.
1. The owner's review is not acceptance
One misconception on EPC projects is that an owner's review somehow transfers design responsibility. In a proper EPC arrangement, it does not.
When a problem surfaces during commissioning or the first months of operation – which was present in the design all along, unnoticed, because everyone was checking documents – a familiar argument begins: "You reviewed it. You approved it. It's on you."
It isn't. The designer owns the design, and the EPC owns the delivery. Review, comment and approval do not normally relieve either, and most contracts say so explicitly.
The owner doesn't accept the design as a standalone product. It ultimately accepts the completed plant against the contractual requirements, once the required performance has been demonstrated and the defined deliverables have been handed over. Until then, "approved" should mean permission to proceed in the project – not a confirmation that all the assumptions and engineering decisions are correct, or that nothing has been missed.
The contractor demonstrates, the owner judges suitability.
But the owner's behaviour matters too. The boundary starts to blur when the owner prescribes solutions instead of requirements, treats approval as technical certification, or gradually makes the contractor's engineering decisions through the comment register.
That is how design by comment develops: rarely from one major instruction, more often from many reasonable ones that together make the reviewer part of the design.
A stronger owner comment states the requirement, identifies the concern and its consequence, and asks the contractor to demonstrate or correct the solution.
Review does not move responsibility across the table – but the owner can blur the line by stamping or prescribing.
2. Why the owner reviews
The owner is not there only to re-prove calculations or uncover engineering deficiencies.
The designer is measured by technical adequacy, the EPC by project delivery, each vendor by its own package. The owner is measured by how the completed plant operates, is maintained, modified, and performs over the next twenty-plus years.
Every other party has a boundary to its scope. The owner eventually inherits what happens across and beyond those boundaries – because the owner's scope is the whole asset, through its full lifetime.
That is why the review exists. Not to supervise the designer's engineering, but to improve the future asset. The owner will own the consequences, not the design.
Those consequences are already being shaped in the drawings. A drawing is more than documentation. It is an early version of the future plant. Decisions about operation, isolation, access, recovery, maintenance and future change are already being fixed there – long before their real consequences can be seen.
The design office optimises within its own context; blind spots are often structural, not necessarily a failure of competence. Independent review brings a wider perspective, the complete asset and its full life.
The review also builds the owner's understanding while the plant is still being designed. By commissioning, the owner should know what was designed, why, and how the plant is expected to behave.
A valuable review protects the owner's objectives, strengthens the future asset, and improves the project.
3. The specification is the floor, not the ceiling
The owner's review begins with compliance. The design should comply with the contract, the technical specification, applicable standards, and governing codes. That is the contractor's obligation, and one of the owner's first checks. But is compliance alone enough?
A design can satisfy every clause of the specification, every applicable standard, and every code, yet still become the wrong plant to own. The specification may require redundancy, but says nothing about dependency on a common power source or a single utility. It may require installed equipment, but says little about standardisation, commonality or interchangeability across vendors. The delivered plant complies, yet becomes more difficult to operate, maintain, and support throughout its lifecycle. There is no compliance failure; the specification didn't go that far.
It never can. A specification defines the owner's requirements, objectives, and constraints before detailed engineering begins. It cannot prescribe every engineering decision, every interface, every interaction between packages, or every lifecycle consequence that emerges as the design matures. That is not a deficiency of the specification; it is the nature of engineering. That gap is filled by engineering judgement – exercised by the designer during design, and challenged by the owner during review.
When the owner challenges the design, the contractor's demonstration sometimes confirms that the proposed solution is already right. Sometimes it exposes an assumption that changes the design. Occasionally it shows that the owner is asking for capability beyond the contract, and the discussion properly moves into change management.
The question is not only whether the design complies, but whether it is good enough for the future asset – and, if not, whether closing the gap is within the contract or requires a change.
Compliance shows the contractor met the specification; judgement determines whether the minimum was enough.
4. Know where to contribute
The value of a review lies where independent judgement adds something the contractor's own checking cannot – where a design can be correct inside one scope and still create a poor result for the plant.
A proven design should get credit for being proven. The owner does not need to spend much effort on what an OEM has built many times, but on what is specific to this project.
A proven design is proven under a set of assumptions. Site conditions, fuel, utilities, grid requirements, operating modes, controls, layout, maintenance concept and interfaces can all move a standard design away from the conditions under which it was proven.
The further the project moves from the reference envelope, the less useful the statement "this is our standard design" becomes.
The review therefore adds more value where the owner brings knowledge the contractor may lack: operational and maintenance experience, accumulated within its own organisation and circumstances, which it can use to test the design for real-life operability, reliability, maintainability, diagnosability, integration, interdependencies, and lifecycle consequences.
Look at degraded conditions, assess the plant with a pump unavailable or one UPS supply line breaker tripped, evaluate redundancies, recovery options, isolation possibilities – review rare but realistic cases to judge real-life fit.
Under-review leaves risk undiscovered. Over-review spends scarce engineering effort where little additional value remains. The skill is knowing where independent judgement can change the outcome, where it matters.
Review hardest where "proven" becomes "project-specific".
The owner's greatest contribution is its unique perspective, focused on project-specific design.
5. Lenses – Operability
The owner reads one design from several seats at once – operator, maintainer, outage manager, asset manager. Operability is the first seat.
The review begins with intent. Does the design implement the operating philosophy, operating modes, redundancy concept, automation strategy, remote and local operation, alarm philosophy, HMI functionality, information availability, and other operational requirements defined by the contract?
It then reviews behaviour. How will the plant actually be operated? Are operator actions intuitive? Do automation, alarms, permissives and interlocks support operation as an integrated plant? Do equipment failures lead to operational consequences consistent with the intended philosophy?
Normal operation is usually the easiest part. The gaps are more often between operating states – during start-up, shutdown, mode changes, equipment unavailability and recovery.
A good design defines not only each operating state, but also how the plant enters it, behaves within it, and leaves it – however it may leave that state.
Then the review applies deeper experience. Where will operators create workarounds? Which alarms will eventually be ignored? Which information will be missing when decisions matter? Which package philosophies conflict? Which operational assumptions are likely to fail in daily use?
Operability and maintainability review exists specifically to bring that experience into the design process, because it isn't the core experience the design team was working from.
The owner should make sure that credible operating states, degraded conditions and critical transitions are not only designed, but also carried into the test scope.
A plant should not only operate. It should be operable in every state it will actually meet.
6. Lenses – Reliability and availability
Reliability belongs to equipment. Availability belongs to the plant. It comes from the architecture: redundancy, independence, fault containment, recovery, and the dependencies between them.
Redundancy is easy to specify and easy to lose. Two pumps on one distribution board, two transmitters on one impulse line, two controllers behind one network switch. Each discipline verifies redundancy within its own scope; the shared dependency sits on another discipline's drawing. So the test is a list: for every redundant pair, each supply, signal, service and routine it shares.
Then take one train out. Does redundancy survive maintenance, or does the plant run on its last line of defence through every outage? Can standby equipment be exercised in normal operation, changeover included, or does the second or third real cold start reveal a failure hidden for months?
Protection deserves the same challenge. A trip chain resting on one sensor turns a disturbance the plant should tolerate into lost generation. Does the plant trip only when it should?
The owner also reviews recovery. The failed component is rarely the true cost; lost generation and a prolonged restart usually are. For each credible failure: what capability is lost, for how long, and what does recovery need?
Fleet experience adds what no drawing shows: which standby equipment never starts because it is never run, which utility becomes the single point of failure, and where availability drains away through derates, bypasses and disabled functions rather than failures. The design office does not have that experience. The owner does.
Availability is set in the design. The review is where a single point of failure is still cheap to remove.
7. Lenses – Maintainability and access
The plant is built once and maintained for decades, and much of that burden is fixed in the layout. The valve no one can reach, a transmitter behind the hot pipe, a pump that needs a crane that does not fit.
Maintainability cannot be reviewed without a maintenance concept, so ask for it first. Which tasks are done in-house and which by the OEM, at what outage cycle, with what crew and what tooling and crane? A layout can only be assessed with those answers.
Then the review tests tasks rather than drawings. Can each item be removed along a path that exists in the model, to a laydown area that exists? Is pull space for bundles, rotors and large motors reserved as a clash-checked envelope? Is there a lifting point wherever manual handling is unsafe by the site's own rules? Is the frequent work – filters, strainers, lube oil, calibration – reached from permanent access, or from scaffolding at every outage?
Isolation is another part of it. Can each item be isolated, process and electrical, with lockable points, without taking down more of the plant than the task needs?
The typical failure is gradual. A removal path accepted at the 30 percent review, but never modelled as a reserved object, is filled with cable trays and small-bore piping by the 90 percent review, without anyone deciding it. The owner's comment is therefore closed with a modelled space, not with a sentence in the register.
The owner's fitters, riggers and outage planners belong in the model review too, where they can demonstrate maintenance tasks and heavy lifts, chosen at random, in the model, end to end.
Maintenance is the plant's true internal customer, and its voice can only be heard when the owner brings it in.
Review the design for the spanner, not only for the drawing.
8. Lenses – Diagnosability and change
Two failures of imagination cost the owner most, and both are reviewable in the design.
One is diagnosability. When a fault appears years later, can it be found by people who were not there when the plant was built? Control may need only the measurements that regulate the process; diagnosis needs context, what was happening upstream and downstream of the component when it failed. The shift engineer who chases that fault five years after handover was not in the design review, and what the plant tells them has to be enough.
The review takes the trip list and the failure modes the design already assumes, and asks for each one: what does the operator see, in what order, and can the cause be separated from its consequences from the control room? Then it checks what the answer relies on – first-out identification, sequence-of-events recording on one time base across all packages, historian coverage that includes the packaged units and not only the DCS, and access to vendor controller data without a vendor call-out. A packaged unit with a local HMI and no historian connection is a black box the owner has bought and cannot open.
The other is change. The plant will be modified: a unit replaced, a fuel changed, capacity added, a control system renewed. The design should leave room for it. Spare cells in the switchgear, spare I/O and cabinet space, controller loading headroom, valved and blanked tie-in points, capacity on the pipe rack and in the cable trays, and the software sources, licences and versions in the owner's hands, with escrow where the vendor will not release them.
Both diagnosability and change capability are about the future, and that is why the project might skip them: neither is a current problem. They are the owner's problem, for decades.
Design for the faults to be chased and the changes to be made – they will be the owner's issues, years after the project has gone.
9. Lenses – Integration
There are grey zones between packages, between disciplines, and between the new plant and the existing one, and they easily escape attention. The two sides of a boundary are specified at different times, by different disciplines, against different revisions of the design basis. Each document may be correct, and yet the system they form may not exist.
The review traces intent rather than reading packages. It takes one function – a trip, a start permissive, a changeover – and follows it across the P&ID, the cause-and-effect matrix, the logic diagram, the loop drawing, the cable schedule and the HMI. Mismatched tags, a missing interlock, a signal whose failure state is safe on one side and unsafe on the other.
The review also tests ownership. Every interface needs an accountable owner in the register, a person in a role rather than a company, and every cross-boundary signal has four responsibilities: who generates it, who uses it, who documents it, and who tests it. A blank in any of the four is an issue left for commissioning, or at least a risk of incomplete delivery.
For critical control interfaces, the interface register should set the integration test scope at FAT, with real package controllers where practicable, so that two packages don't meet for the first time during commissioning. Where a trip or a changeover cannot be simulated safely at FAT, the review asks how it will be proven at all.
In a brownfield project the existing plant is the boundary that lies most, and the design has to be validated against the site as it is, by detailed survey, before undocumented cabling, tight footprints and legacy earthing are found in the middle of the outage.
Even with an interface matrix, each contract ends at its own side of the boundary. Only the owner's scope covers the whole plant, so the gap between scope boundaries is the owner's whether it is managed or not.
The costliest problems sit at the scope boundaries, where each party looks at its own side.
10. Lenses – Lifecycle
The last lens ties the others together, and the owner is the strongest party to apply it.
Some savings are cheap for the project and costly for the owner. A cheaper component with a worse failure rate. An arrangement that saves a week of construction and costs a day of every outage. One isolation valve fewer, which saves pipework once and forces a unit shutdown for routine work for twenty years. A non-standard vendor for one package, which saves on the purchase order and adds new spares, new tooling and new training to the fleet. Standardisation across packages, one valve type, one instrument make, one motor frame, rarely wins on price, but keeps the spares store small and easy to oversee for the life of the plant. Each is a project saving with an owner's bill attached, committed on the drawing.
The review can make the trade-offs visible. Every value-engineering proposal should state what it saves the project, what lifecycle consequence it creates for the owner – a recurring cost, a longer outage, a spares holding, a lost margin, a risk – and over what horizon the two are compared. A proposal that lists only the saving is half a proposal. The same applies to the operating regime behind the design: the review asks for the assumed duty, starts and load profile, and tests it against the market the plant will run in. A plant designed for base load and dispatched as a peaker will have a different maintenance profile and cost from what the project assumed.
Where the lifecycle requirement is in the specification, the trade-off is a compliance question and the contractor demonstrates it. Where it is not, it is a change, and the owner decides whether the twenty-year bill is worth that project saving.
The project optimises to handover by design. Someone has to optimise for the twenty years after it.
The project is paid to build it once; the owner pays to live with it. Review the whole lifecycle.
11. A comment is only worth its closure
A review does not end when the comment is raised. It should end when the design provides the right solution and the owner closes the concern in writing.
A comment can end in one of three states: incorporated, with the revision that shows it; rejected, with a written technical reason; or deferred, with a named owner and the stage where it will be addressed. The register has a simple test: any three closed critical comments, chosen at random, can each be traced to their evidence within minutes.
Who controls the register controls the evidence of closure. The owner keeps its own register, with the age of open items reported at the standing project meeting, and the contract's review procedure should define the disposition states and the owner's review period, so the register is a contractual record.
The design is also a moving target: each comment is tracked against the revision it was made on, and the register is re-baselined when the package moves, otherwise it describes a plant that no longer exists.
Closure also has to travel forward, because a requirement that cannot be demonstrated has not been completely engineered. The review sets how the design will be proven: which requirement is proven by which test, at FAT, at SAT or in commissioning, and whether the plant carries what the proof needs – measurement boundaries agreed before the guarantee is signed, permanent test connections, instrumentation accurate enough for the guarantee. A finding that stops at the register can be found again at site, at its full cost.
The value of a review is not in the comments raised but in the changes realised.
A comment is closed by a changed drawing or an agreed reason, not by an acknowledgement.
12. Spend the review where it bites
There is always more to review than a team can review properly, so the question is not whether the owner commented enough, but whether the hours went where they mattered.
Leverage is highest on the documents that decide everything downstream – the design basis, the philosophies, the P&IDs and single-line diagrams, the control narratives, the interface register – and it falls with every revision after that. By the issued-for-construction drawings the cost of change is high and the review might change little.
Vendor packages are fixed one stage earlier. Once the purchase order is placed, the vendor's standard design is largely settled, so for packages the review bites at the requisition and the technical bid evaluation, where the project-specific requirements either enter or never will.
A staged review is meant to see a design that can still move, so the package has to be revision-controlled, mature enough for the questions of that stage, and stable enough for the comments to stay traceable; otherwise the review is postponed rather than diluted. Leverage is also lost on the owner's side: the design moves while the owner reads, and a comment returned on the last day of the review period addresses a revision the contractor has already left behind.
Where the owner cannot staff a full review of its own, it can check the contractor's quality control: the inter-discipline check signatures on each document, the revision history, the number of packages re-issued, and, where the contract secures an audit right and a seat in the internal design reviews, the review records themselves. A quality system that passes every package first time may say more about the system than about the design.
Review hours are spent once, and they buy the most at the design basis.
The review changes most where the design can still move.
13. Form follows function
One layer sits beneath all the others: once the engineering is right, the design has to be usable. Every screen, document, tag and label exists to serve someone in a situation, and the review asks of each one who uses it, when, and for what decision.
The principle starts at the equipment. Local instruments, manual valves and labels are placed for the people who will use them, in the situations they will be used in. Does the operator's round pass every reading that matters? Can the valves that must be moved under upset be reached without climbing? Does every item carry one designation, the same on the nameplate, the drawings, the control system and the maintenance system, so that the plant can be understood without translation?
It continues in the control room. The operator interface is designed for the abnormal situation, not for the demonstration. What does the operator see after a trip, and how much of the decision is on that screen? Alarms follow the same rule: an alarm philosophy set by the owner before any package is connected, so that the plant's alarm system does not become a mix of vendor defaults.
It ends in the documentation. One coding system, one numbering scheme, one revision discipline across every vendor, and native files with the model at handover. Manuals and registers are written for the people who will operate and maintain the plant, not assembled for the handover checklist. Completeness is what the checklist measures; usability is measured from the operator's seat.
A usable plant explains itself to the people who run it, without the designers in the room.
Get the engineering right, then make it usable. A correct design becomes an asset when the people who run the plant can read it.
14. A good review protects the contractor too
An owner's review may look like risk. Every comment is a possible change to scope, cost or schedule, and the contractor's project manager is measured on all three. Yet the same review is one of the strongest independent challenges the design will get, at the cheapest moment to improve it.
The owner brings what the contractor might not access elsewhere. A comment from that seat costs the contractor a disposition and can save a redesign, a site modification or a warranty claim.
The review also protects the contractor's commercial position. Vague drawings, loose battery limits and undefined measurement points feed later disputes in both directions. A guarantee schedule assembled from proposal text carries inconsistencies the bidder never reconciled, and those surface at the performance test, when the leverage has reversed.
An answered comment is also a record. A design demonstrated against the owner's concern, in writing, is the contractor's evidence at handover and through the warranty that the design was examined and closed. Responsibility stays with the contractor, but the record makes it defensible.
For this to work, both sides have to do their part. The contractor stages the review, states what is open at each stage, and answers every comment with a reason or a demonstration. The owner states the requirement, the concern and its consequence, asks for demonstration, and returns comments within the review period. Then problems surface earlier, decisions come faster, and the argument moves from positions to evidence.
A contractor gains in the terms it is measured by: fewer requests for information, fewer commissioning surprises, fewer warranty disputes, and a client that comes back.
A good owner's review protects the contractor as much as the owner. Better questions make a better project for both.
15. The blockade is sometimes your own side
Not all resistance comes from the contractor. Sometimes the owner's own organisation is the obstacle. Sourcing, finance, compliance and legal each manage a different risk – price, budget, conformity, liability – and each is right within its own remit. Together they can stop a technically correct decision from being made in time, and a sound comment can die in an internal approval queue as easily as in a contractor's disposition log.
The contract gives the owner a fixed number of days to return a document, and many contracts deem it approved when the owner stays silent; the internal approval of a comment with a cost attached takes longer, so silence becomes approval. A value-engineering saving shows in this year's capital budget, its cost in an operating budget five years away. Procurement prefers the lowest compliant bid, and legal may read an owner comment as a variation to be avoided rather than a finding to be closed.
The review therefore needs a decision path on the owner's side too. Before the first transmittal, it should be clear who can authorise a change with cost, and within how many days, against the contract's agreed review period – and who stands in when that person is away. With delegated limits, a clear escalation route and a regular owner-side decision meeting timed to the review stages, a critical finding reaches someone who can decide before the review period runs out. The owner's own comments deserve the closure discipline the owner demands from the contractor.
This is why the owner's engineer needs more than engineering: enough commercial, contractual and procurement understanding to move the right decisions through the owner's own organisation at the pace the project needs.
A review has authority only if it can turn a finding into a decision, and a decision into a change, before the design freezes around it.
A finding no one is empowered to close is as lost inside the owner's organisation as outside it.
A design review done as a document check protects the review schedule. Done as a decision check, it protects the plant. The owner is not necessarily the cleverest party in the room and does not need to be; the duty to deliver a design that works was, and remains, the contractor's.
What the owner brings is its own experience of operating and maintaining plants, its knowledge of the site and its interest in the whole life of the asset, applied while the design can still move, and recorded so that responsibility stays where the contract put it. Holding that line takes persistence: standing on the technical case against cost and schedule pressure from parties, on the owner's side as much as the contractor's, that have every reason to wave the design through.
Design happens in an office and the plant is run on a site. The review is where the two are connected, and site reality is brought into the design while it can still be changed. Done well, the review is the cheapest engineering on the project; reduced to a document check, it is the most expensive engineering never done.
The owner's review is about taking responsibility for the future asset.
This article draws on real-life power generation project experience on both sides of the EPC contract. For a conversation about your specific situation, get in touch.