There is a basic principle that still holds: only a satisfied client returns with the next project. It is therefore in the interest of both parties to deliver something genuinely successful – a plant that fulfils the client's requirements, operates reliably, and is handed over as agreed. Not just "completed".
The thirteen lessons below have been learned and observed over years on both sides of that equation, shared in the hope that naming them helps someone avoid paying for the same lesson.
1. The project ends, the asset remains.
EPC success: mechanical completion, SAT, take-over certificate, handover, and invoicing – milestones to tick.
Owner success: twenty-plus years of reliable, maintainable, diagnosable operation, with shortened outage durations, lower lifecycle costs – outcomes to live with.
The two are related, not the same.
Every decision made during the project – vendor selection, accessibility, documentation, operator training depth – lives in the plant for decades.
Make a plant for operation, for the operator – project success will follow.
2. The cost of a problem is set by the phase where it surfaces.
A change during basic design costs one unit of effort. During detailed engineering, ten. During construction, a hundred. During commissioning – with installed equipment, demobilised teams, lead times, and schedule pressure – potentially a thousand.
The instinct is to solve problems when they appear. The discipline is to find them before they appear.
Every unresolved assumption, requirement, interface or design gap carries a multiplier.
The solution is investing more effort earlier: defining requirements, challenging assumptions, reviewing interfaces, standardising recurring solutions, and involving the right people before the multiplier applies.
3. The most expensive problems begin as assumptions.
Assumed scope, interfaces, operating modes, schedule durations, task ownership, responsibilities... Requirements agreed at contract stage based on an interpretation that was never verified.
Projects do not fail because assumptions exist. No project moves forward without them. They fail because assumptions remain hidden: unwritten, unowned, unverified, and therefore invisible until reality disagrees.
Most disputes, delays, variations, and claims can often be traced back to an assumption no one realised they were making.
Make assumptions visible. Challenge them, document them, assign ownership, and verify before reality does.
4. Every identified scope has an owner. Gaps usually don't.
An EPC divides the plant into packages – gas turbines, HRSGs, electrical systems, DCS, auxiliaries, civil works. Every package has an owner, a contract, a scope, and a budget.
The spaces between them often don't.
Most interface problems are not missing equipment. They are missing ownership. A signal generated by one vendor and used by another. Different alarm philosophies. Different naming conventions. Different assumptions about timing, responsibility, testing, or operating modes.
Every interface has at least four owners: who generates it, who uses it, who documents it, and who tests it. When any of those is unclear, the problem usually appears during commissioning.
The same applies across disciplines – mechanical, electrical, I&C, civil, process, operations, maintenance. Each owns its scope; the dependencies between them are where surprises tend to emerge.
The solution is explicit interface ownership, early integration reviews, cross-disciplinary verification, and assigning responsibility for looking at the plant as a complete system.
5. Plants are designed for the day everything works.
Nominal operation is the easy case. The design that matters is for the day a pump trips, a measurement fails, a controller drops, or a supply is lost.
A power plant is a complex automated system. Single points of failure, redundancy of critical measurements and power supplies, actuator fail positions, degraded operating modes, and protection philosophy belong in the design from the start, not just when a finding surfaces after a failure in service.
What happens when this fails? Can the plant continue operating – at least in a degraded mode – and should it? Who decided? Was it ever verified and tested?
Design for the failure too, not only for the function. The plant will have some bad days, and that is when the design is judged.
6. The same solutions are re-invented.
Every project contains recurring engineering problems. Yet many organisations repeatedly solve them instead of capturing and reusing proven solutions. Different vendors may also bring different approaches within the same project. Each solution may work individually, but the plant becomes harder to integrate, document, operate, and maintain.
A standard solution pays off when applied consistently across packages and vendors within the same project, and when reused across projects. Interface definitions, control logics, measurement loops, alarm philosophy, hook-ups, pump arrangements, documentation structures, and naming conventions all benefit from simplification and consistency.
Build standards, improve them continuously, and apply them consistently across projects and packages (vendors).
7. The schedule is built on declarations, not verification.
Project schedules are often built from subcontractor estimates, package milestones, and declared completion dates – some experience-based, some optimistic – whose interdependencies were never stress-tested against each other. The schedule was coherent on paper.
During execution progress is reported, completion dates are defended, and recovery plans are assumed. Sometimes the schedule becomes more important as a reporting tool than as a realistic prediction of what will happen next.
"Ready for commissioning" is declared before it is demonstrated. The commissioning engineer arrives to find terminations wrong, instruments missing, the cable schedule unrevised since the last design change – and spends the first third of a constrained, expensive, contractually-tied window doing pre-commissioning's job.
The schedule remains green while readiness turns yellow.
Protect the schedule's credibility, and stress-test the interdependencies. Replace declarations with verification, optimism with evidence – and reporting with reality.
8. Package control is not plant control.
A vendor delivers a package that controls itself correctly within its boundary.
The owner bought something different: a plant that behaves as a single machine – with coherent operating philosophy, permissives, trips, alarms, degraded modes.
The integration layer belongs to no vendor by default, not even to the DCS. It is EPC engineering.
Integration testing should not wait for site – it belongs at FAT, with real package controllers connected to the DCS.
Define the plant control philosophy before vendors design their packages, and prepare for an integrated system.
9. Drawings are trusted – sites are real.
In brownfield projects existing plants rarely match their documentation perfectly. Modifications accumulated over decades, drawings drifted from reality, databases remained internally consistent but no longer valid, and assumptions became accepted facts.
Teams approaching a brownfield project with a greenfield mindset assume a few site visits are sufficient. They then discover undocumented cabling, space constraints, interferences, grounding details, and legacy modifications during installation, inside the outage window.
The same applies to "standard" solutions. A package that is standard on paper meets site-specific requirements, legacy systems, local regulations, and the plant's operating philosophy – and stops being standard.
Trust drawings, but verify the plant. The earlier site realities are discovered, the cheaper they are to accommodate.
10. Documentation is produced for handover, not for operation.
The handover checklist asks whether the documentation package is complete. It rarely asks how useful it is.
As-builts may reflect an earlier revision, because red-lining lapsed. O&M manuals get assembled from vendor submissions, not unified. Tag registers are consistent within each system but not across the plant. The checklist passes because completeness was measured, usability was not.
The consequences appear later: fault diagnosis (at 2 a.m.), modifications, outages, engineering studies, training a new engineer – all are slower and more expensive.
The owner did not buy a set of documentation. They bought the ability to operate, maintain, modify, and understand the plant for decades.
Good documentation is hard to specify – owner's requirements should consider standards, best practices, and custom needs.
Treat documentation as part of the product. Define usability early, enforce standards consistently, and review documents from the operator's perspective, not only for project completion.
11. The disputes begin when the team has left.
Handover is often celebrated as the end of the project. In reality, it opens the warranty period, when findings, defects, and responsibilities start being tested.
Who owns the finding? EPC or vendor? Design, installation, or operation? Inside or outside warranty scope?
By then, the project team has often dispersed. The people managing the warranty were not in the design reviews, commercial negotiations, interface discussions, or site decisions where many of the answers were originally established.
And the contractual argument outlasts and out-costs the technical problem beneath it.
Preserve project knowledge beyond handover. Decisions should remain traceable after the people who made them have moved on.
12. Reporting takes the spotlight.
Projects gradually spend serious effort explaining progress – instead of improving it.
Engineers update trackers, presentations, and management reports while unresolved interfaces, technical risks, pending decisions, and outstanding verifications continue to accumulate.
A surprising share of project effort goes into reporting, but mainly into reporting prettily: slides, formatting, dashboards, and polish.
Detailed reporting creates visibility – but does not create much progress. Polish can also crowd out substance: the slide looks good, but the real status, live risks, and decisions actually needed are thin or buried. Management leaves reassured rather than informed.
Reporting should inform decisions, not decorate them. Keep it dense, lean, and honest – and protect the project manager's attention for the project.
12+1. The real decision maker is not on the project organisation chart.
Officially, decisions follow the project structure: steering committee, project manager, discipline project managers, engineering manager...
In practice, outcomes are often shaped by people with no formal project authority – the future O&M manager whose acceptance gates handover, the senior site engineer everyone quietly defers to, the owner's technical advisor, or the executive who determines priorities in the background.
Teams that manage only the chart are surprised by decisions that "came from nowhere" – a choice you thought was closed reopens, an acceptance stalls under schedule pressure, a vendor selection is reversed from above. The influence sat somewhere else.
Mapping where judgement actually sits – on both sides – is project management, not politics.
Closing these gaps requires seeing the project from more angles than the contract typically assigns – the way the owner, the OEM, and the operator would see it together.
Most of these problems ease when all three views are present from the start.
This article draws on direct project experience. For a conversation about your specific situation, get in touch.