What Is EPC? How Engineering, Procurement & Construction Projects Actually Work
EPC stands for engineering, procurement, and construction: a project-delivery model in which a single contractor is responsible for designing the facility, buying its equipment and materials, and building and commissioning it, usually under one contract and frequently for a fixed, lump-sum price. The owner hands over a defined scope and performance requirement; the EPC contractor carries the design and execution risk and delivers a working facility, often "turnkey." It is the dominant model for large industrial projects: refineries, power plants, chemical and process facilities, LNG trains, pipelines, mining plants, and water infrastructure, precisely because it gives the owner a single point of accountability for a project that would otherwise involve dozens of separate parties.
That single point of accountability is the whole proposition, and it is worth being clear about what the owner is actually buying. In a traditional design-bid-build arrangement, the owner hires a design firm, takes the completed design to market, hires a builder, and then owns the gap between the two. When the pipe does not fit, the argument about whether the design was wrong or the fabrication was wrong lands on the owner's desk. Under an EPC contract, that argument happens inside the contractor's organisation, and the owner sees a price and a completion date. The contractor charges for absorbing that risk, and the premium is real, but for a project financed on a fixed budget against a fixed schedule, the certainty is usually worth more than the premium.
The three phases
The three letters describe three phases, but they are not three sequential stages with clean boundaries between them. They overlap heavily, they feed information back to each other constantly, and the interfaces between them are where projects are won and lost.
Engineering
The engineering phase translates the owner's requirements into a buildable design. It typically moves through three levels of definition. Conceptual or feasibility engineering establishes whether the project makes sense at all and produces an order-of-magnitude cost. Front-end engineering design (FEED) develops the process flow diagrams, heat and material balances, plot plans, major equipment lists, and specifications to the point where a lump-sum price can actually be quoted with confidence, usually to a cost accuracy of ten to fifteen percent. Detailed engineering then produces the calculations, drawings, equipment datasheets, isometrics, and specifications that define exactly what will be built and bought.
Detailed engineering is a multi-discipline effort running in parallel: process, mechanical, piping, civil and structural, electrical, and instrumentation and controls, each producing deliverables the others depend on. A vessel cannot be sized until the process conditions are fixed, the foundation cannot be designed until the vessel weight is known, and the structural steel cannot be released until the piping routing is settled. This is the phase that governs everything after it. A procurement requisition is only as good as the datasheet behind it, and a construction package is only as good as the drawings it carries.
Engineering is also, in cost terms, the smallest phase and the most leveraged one. On a typical process plant, engineering runs somewhere in the region of ten to fifteen percent of installed cost, procurement of equipment and bulk materials makes up the largest single share, and construction labour and indirects take the rest. But decisions made in that first ten to fifteen percent determine most of the remaining spend, which is why FEED quality correlates so strongly with project outcomes. The Construction Industry Institute has spent decades quantifying that relationship, and the finding is consistent across sectors: projects that enter execution with poorly defined scope overrun, almost without exception.
Procurement
Procurement converts the engineering output into purchased goods. Engineers issue datasheets and specifications; procurement turns those into requisitions, issues enquiries, evaluates technical and commercial bids, places orders, and then manages expediting, vendor document review, source inspection, shipping, customs, and site receipt. The last part is easy to underestimate: on a large project, the logistics and inspection workload after the order is placed exceeds the effort that went into placing it.
Long-lead equipment drives the whole schedule. Large columns, compressors, turbines, transformers, and heavy-wall reactors carry delivery times measured in quarters, sometimes years, so they have to be ordered before the design that surrounds them is complete. That means procurement and engineering run in parallel rather than in sequence, and a late engineering change can collide with an order already placed. Once a vessel is in fabrication, a nozzle relocation is no longer a drawing revision, it is a change order with a price and a schedule impact attached.
Vendor data creates a second feedback loop that catches teams out. The purchase order is not the end of the engineering conversation; the vendor returns certified drawings, weights, nozzle loads, and foundation details that engineering has to review and then fold back into the plant model. Civil, structural, and piping work that proceeded on estimated data has to be checked against what the vendor actually supplied.
Construction
Construction builds and commissions the facility: site preparation and civil works, fabrication and erection, piping and electrical installation, then mechanical completion and the systematic checkout that proves the plant performs to specification before handover. Work is usually organised by system rather than by area toward the end, because commissioning proceeds system by system, and the punch list for each system has to be cleared before it can be energised or introduced to process fluid.
Field conditions inevitably differ from the drawings. Interferences appear, foundations are found out of position, materials arrive damaged, and the sequence has to be reshuffled around weather and labour availability. Every one of those events generates a field change that has to flow back to engineering for approval and then forward into the as-built record. That record is a contractual deliverable, not an afterthought, and a project that treats it as one ends up reconstructing it under deadline pressure at exactly the moment the engineering team has already demobilised.
Commissioning then proves performance. Pre-commissioning covers flushing, drying, loop checks, and equipment run-ins; commissioning introduces feedstock and brings the plant to stable operation; the performance test demonstrates the guaranteed throughput, product quality, and consumption figures written into the contract. Those guarantees are usually backed by liquidated damages, which is why the contractor's design margins and the owner's test conditions get negotiated so carefully long before anyone builds anything.
How the phases actually overlap
| Phase | Primary output | Starts when | Main risk it creates downstream |
|---|---|---|---|
| FEED | Defined scope, plot plan, major equipment list, ±10–15% estimate | Owner sanctions study | Scope gaps that surface as change orders after lump-sum award |
| Detailed engineering | Calculations, drawings, datasheets, specifications | FEED frozen (in principle) | Late deliverables stall procurement and construction alike |
| Procurement | Requisitions, purchase orders, vendor data, delivered goods | Long-lead items, well before engineering completes | Orders placed on preliminary data; changes become change orders |
| Construction | Erected, mechanically complete facility | Civil works, often before detailed engineering finishes | Field changes that never propagate back into the record |
| Commissioning | Performance-tested plant, as-built dossier | System by system, as completion allows | Missing or stale documentation delaying handover |
Read down that table and the pattern is clear: every phase starts before the one before it has finished. That is not bad planning, it is the only way to compress a schedule enough to make the economics work. But it means the project is permanently operating on information that is provisional, and the discipline that keeps it from unravelling is control of the documents.
Why documentation runs the whole project
In an EPC project the deliverable is not only the physical facility, it is also the engineering record that proves the facility was designed and built correctly. Calculations have to be on file and verifiable. Equipment that falls under a code, pressure vessels under ASME Section VIII, for example, must carry calculation packages an Authorized Inspector can review before certification, and the resulting Manufacturer's Data Report becomes part of the permanent plant record. Every revision has to propagate through the affected documents.
The scale of this is easy to underestimate from outside the industry. A mid-size process plant generates tens of thousands of controlled documents; a large LNG or refinery project generates hundreds of thousands. Each one has a revision history, an approval status, a distribution list, and a set of dependencies on other documents. When a design change lands, the question that determines whether it costs a day or a month is simply: which documents does this invalidate, and did anyone find all of them?
That is where the real risk sits. The project's cost and schedule are governed less by any single calculation than by how reliably information moves between the three phases without being lost, retyped, or left out of date. Interface management, the deliberate tracking of who owes what information to whom and by when, is a named discipline on large EPC projects for exactly this reason. The failure mode is rarely a wrong formula. It is a right formula applied to a superseded input.
It is also why the document- and calculation-heavy parts of EPC are the natural target for automation. They are governed by explicit published rules, they are repeated on every project, and a single change cascades through the whole package by hand. Our walkthrough of the spec-sheet-to-U-stamp workflow traces that cascade for a single vessel; multiply it by the several hundred pieces of pressure equipment on a plant and the shape of the problem is apparent.
Contract structures and risk allocation
The commercial shape of an EPC contract determines who absorbs which surprises, and the differences matter more to engineering than they first appear.
Lump-sum turnkey (LSTK) is the classic form: a fixed price for a defined scope, with the contractor carrying quantity growth, productivity, and most design risk. The owner gets budget certainty and pays a premium for it. The contractor's protection is scope definition, which is why the boundary between the contract scope and everything outside it gets litigated so precisely, and why FEED quality is a commercial issue and not just a technical one.
Reimbursable and target-cost forms pass more risk back to the owner in exchange for a lower base price, faster start, and greater flexibility to change scope during execution. They are common where the process is novel, the ground conditions are unknown, or the owner wants to keep making decisions after execution has begun.
EPCM (engineering, procurement, and construction management) is a genuinely different model, not a variant. The EPCM contractor performs engineering and procurement and manages construction performed by others under contracts held by the owner. The owner sits at the centre of the risk, holds the construction contracts directly, and retains far more control and exposure. It is common in mining and in owner organisations with strong internal project capability.
| Model | Who holds construction risk | Price certainty for owner | Typical use |
|---|---|---|---|
| EPC / LSTK | Contractor | High (fixed) | Project-financed plants, power, LNG, process |
| EPC reimbursable | Shared | Low to moderate | Novel process, ill-defined scope, fast start |
| EPCM | Owner | Low | Mining, owners with strong in-house project teams |
| EP / EPF | Contractor for engineering and supply only | Moderate | Owner self-performs or separately contracts construction |
| Design-build | Contractor | High | Buildings and infrastructure rather than process plant |
Standard-form contracts codify these allocations. The FIDIC Silver Book is the widely used international form for turnkey EPC projects, while the Yellow Book covers plant and design-build with a different risk balance; the NEC suite is common in UK and Commonwealth infrastructure. Whichever form applies, the distinction that matters for engineering is constant across all of them: the engineering phase produces the codified, reviewable record that the rest of the project depends on, regardless of who holds the construction risk.
Why EPC projects overrun
The industry's track record on large capital projects is poor and well documented. Studies of megaproject performance, most prominently Bent Flyvbjerg's work on megaproject performance and the sector benchmarking published by Independent Project Analysis, consistently find that a majority of large projects finish over budget, behind schedule, or both. The causes recur:
- Scope frozen too late. A lump-sum price quoted against an immature FEED is a price for something nobody has defined yet, and the difference emerges as change orders.
- Engineering deliverables late. Engineering is the smallest cost but the longest pole. Late drawings idle a construction workforce that costs money whether or not it is productive.
- Long-lead procurement on preliminary data. Orders placed early are placed on assumptions, and every assumption that turns out wrong becomes a change order at vendor rates.
- Field changes that do not propagate. A modification made on site and never reflected in the calculations or drawings surfaces at commissioning, at inspection, or years later during a re-rate.
- Interface failures between disciplines and contractors. The information handoffs are where the schedule leaks, and they are the hardest thing to see on a Gantt chart.
Every item on that list is fundamentally an information problem rather than a physics problem. Nobody forgets how to calculate a shell thickness. They calculate it correctly against last month's design pressure.
Where software fits
The economics of an EPC project reward two things: speed and accuracy in engineering, and tight control of documents across phases. Those are the same two levers, because most of the engineering hours on a routine job go into producing, checking, and re-issuing documents rather than into original design.
Tools that encode engineering rules, so calculations run instantly and stay traceable, attack the first. Tools that keep deliverables synchronised as a design changes attack the second. Together they address the two failure modes that most often blow EPC schedules: slow engineering and stale documents. The test of whether such a tool is actually useful on an EPC project is narrower than the marketing usually suggests. It has to produce output a reviewer can follow line by line, cite the governing clause for every number, and re-run cleanly when an input changes, because "re-run when an input changes" is the entire job.
DeepMechanix starts at the densest point of codified engineering, pressure equipment design to ASME Section VIII, where the rulebook is unambiguous, the report is the product, and the reviewer has to be able to check every line, and builds outward across the workflow from there. For the stage-by-stage view of where automation changes the economics across the rest of the lifecycle, read where AI fits across the EPC workflow.
EPC is, in the end, a bet on integration. The owner pays a single contractor a premium to make dozens of interfaces somebody else's problem, and the contractor makes money by managing those interfaces better than the price assumed. Engineering, procurement, and construction are the three things being integrated, but the thing actually moving between them is information: a datasheet, a calculation, a revision, an as-built mark-up. Projects that keep that information accurate and current as it crosses each boundary tend to finish on time. Projects that do not spend the last six months discovering what they built.