A project is the process of creating a new industrial facility — from nothing, through the application of science, engineering, and technology, to a fully functional facility ready to be handed to the people who will operate it. What happens after that handover is another domain with different demands, and it sits outside the project scope as this site uses the term.

Every decision made during a project is made without the benefit of operating experience from that specific facility — and its consequences are often locked in for the life of the plant. The processes, review gates, and documentation standards that project engineering has developed each exist because someone, somewhere, learned what happens when they are absent.

That accumulated practice is substantial. But every project still contains territory that no previous project has mapped. A specific process, a specific site, a specific organisation, and a specific point in time produce conditions that experience can inform but never fully anticipate. Rigour reduces the unknowns. It does not eliminate them.

The clearest way to understand what a project demands — and where it ends — is through an analogy. Consider what it takes to build a road-worthy automobile from scratch and hand it to a driver.

A capital project demands a concentration of expertise and resources that no single organisation maintains permanently. The disciplines required must all operate simultaneously, at full capacity, for the duration of the project — and most of that capacity serves no purpose once the facility is running. Contracting is the mechanism that assembles it when needed and releases it when the work is done.

The second driver is risk. A project concentrates significant technical, commercial, and schedule risk into a defined window. Contracting allows the owner to transfer execution risk to organisations structured to carry it — EPC contractors, subcontractors, and vendors who price and manage that risk as their core business. The owner retains what it is best placed to manage: the business case, the operating requirements, and the long-term performance of the asset.

The contract records the scope, the price, the schedule, and the risk allocation between the parties. For the practising engineer the consequence is immediate — on any project of scale, you are working either for the owner or for a contractor, and which side of that boundary you sit on defines your authority, your accountability, and your relationship to every decision being made around you.

An industrial capital project moves from idea to operating facility through a sequence of defined phases. Each phase narrows the uncertainty of the previous one and increases the capital committed to what follows. The structure exists for a practical reason — early in a project, the cost of changing a decision is low. By the time steel is in the ground, it is not. The phased approach forces hard decisions to be made when they are still cheap to make.

Between each phase sits a gate — a formal point at which the project's sponsors review what has been established, confirm the business case still holds, and decide whether to commit the funds required to proceed. A gate is not a formality. It is the mechanism by which an organisation controls its exposure to a project that has not yet fully proven itself.

In practice, no two projects run identical lifecycles. Phases are merged, expanded, or restructured to suit the scale of the project, the technology, and the requirements of the owning organisation. A small brownfield modification may compress the early phases into a single study. A large greenfield facility may split FEED into multiple stages with separate approval points. The names and boundaries vary — the underlying logic does not.

Instrumentation and controls engineering does not enter a project at detail engineering, even though that is where most of its deliverable volume is produced. The discipline's influence — and its exposure to the consequences of other people's decisions — begins much earlier than most junior engineers realise.

A control philosophy written without I&C input will be handed to the I&C team to implement. A FEED that under-scopes the instrument count produces a budget that cannot absorb reality. A hazardous area classification drawing finalised before the instrument index exists will need revision — at cost — when it does. By the time I&C engineers are busy, many of the decisions that govern what they can and cannot do have already been made.

This is not a complaint about how projects are run. It is a description of how they work. The engineer who understands it will know when to ask questions, when to push back, and when a decision in another discipline's meeting has consequences that belong on the I&C risk register.

The workload builds through detail engineering and peaks at commissioning. The leverage — the ability to shape what gets built — is highest in the phases before the budget is committed. Both matter. They are not the same thing.