Complex engineering projects rarely struggle because the individual disciplines lack technical capability. The mechanical, electrical, process, civil, structural and controls expertise may all be present.

The greater challenge is getting those disciplines to develop together as one integrated engineering solution.

As projects become more technically complex, the number of interfaces between disciplines, equipment packages, contractors, suppliers, existing assets and operational requirements grows quickly. A decision made in one part of the design can have consequences across several others.

Equipment selection can affect electrical demand. Electrical architecture can influence plant configuration and resilience. Pipework arrangements can affect structural requirements and access. Vendor information can change layouts, while construction sequencing can alter design priorities. Commissioning can then expose dependencies that were not obvious during the earlier stages of design.

None of this is unusual. It is simply the reality of delivering complex engineering projects.

Individually, most of these decisions are manageable. Collectively, they determine whether the project can actually be constructed, commissioned and operated successfully.

This is where engineering management becomes important.

Engineering management is more than the administration of engineering deliverables. It is the coordination of technical decisions, interfaces, information, people and assurance throughout the project lifecycle.

That integrated view is consistent with established systems-engineering practice. INCOSE’s Systems Engineering Handbook considers engineering across the system lifecycle, while the Association for Project Management (APM) similarly recognises the importance of systems thinking and understanding the relationships between different elements of complex projects.[1][2]

Done well, engineering management allows individual disciplines to work as part of a coordinated engineering solution rather than as separate technical functions.

Technical Complexity Is Increasing

Modern infrastructure projects are increasingly interconnected.

The engineering challenge can involve very different combinations of systems:

• Energy infrastructure may combine generation, electrical distribution, thermal systems, controls, storage and renewable technologies.
• Industrial projects may integrate process equipment, automated production systems, utilities, electrical infrastructure, instrumentation and specialist safety systems.
• Healthcare and public-sector projects frequently require new infrastructure to be introduced within operational estates where continuity of service is critical.
• Water and wastewater projects can combine process engineering, mechanical systems, electrical infrastructure, instrumentation, controls and specialist treatment technologies.

Even projects that initially appear relatively straightforward can therefore involve a considerable number of technical interfaces.

The difficulty increases when new systems have to be integrated into existing facilities.

Drawings may not fully represent what is actually installed. Equipment may have been modified several times during the life of an asset. Space can be constrained, shutdown opportunities limited and existing electrical or utility capacity may restrict the options available.

Operational requirements can also have a significant influence on how the engineering develops.

Engineering therefore takes place within a network of technical and operational constraints rather than within isolated disciplines.

Managing those constraints is an important part of engineering management.

The Interface Is Often Where Project Risk Accumulates

An interface exists wherever responsibilities, information or physical systems meet.

Some are obvious. A pump requires an electrical supply. A control valve requires power, instrumentation and a control signal. Equipment needs foundations, access, lifting arrangements, pipework connections and sufficient space for maintenance.

Other interfaces are less obvious:

• a vendor changes an equipment specification after the surrounding design has progressed;
• a revised process requirement increases electrical demand;
• a structural modification affects cable routes;
• moving equipment alters pipework arrangements or pressure losses;
• a developing control philosophy creates additional instrumentation requirements; or
• the construction sequence requires part of a system to operate before the remainder of the installation is complete.

The difficulty is that these issues do not always sit neatly within one discipline.

Where responsibility falls between disciplines or organisations, assumptions can develop. Information can be interpreted differently and decisions can be taken without everybody affected by them being involved.

Sometimes that does not become apparent until much later.

By then, what started as a relatively small engineering interface can have become a procurement change, site modification, programme delay or commissioning constraint.

This is not simply an Asteria view. NASA’s systems-engineering guidance identifies the definition, management and control of interfaces as an important part of successful programmes and projects. It also recognises that interface changes made later in the lifecycle are more likely to create cost, schedule and technical or operational consequences.[3]

For engineering management, the lesson is straightforward: the spaces between disciplines deserve as much attention as the disciplines themselves.

Engineering Progress Is Not the Same as Document Progress

One of the recurring problems on engineering projects is the assumption that progress can be understood primarily through the production of documents.

Drawing registers, document schedules and deliverable trackers are necessary, but they do not necessarily demonstrate that the engineering itself is mature.

A project can appear to be progressing well on paper while important technical decisions remain unresolved:

• a drawing may have been issued while the vendor information on which it depends remains preliminary;
• a specification may be complete while an interface with another package remains open;
• a layout may appear mature without access and maintainability being fully reviewed;
• an electrical design may progress before final equipment loads are confirmed; and
• a controls package may develop before the operational philosophy is sufficiently defined.

Document completion and engineering maturity are therefore not the same thing.

A stronger view of progress considers technical maturity as well as deliverable completion.

That means asking questions such as:

• Are the major design decisions closed?
• Are the interfaces understood?
• Has the required vendor information been received?
• Which design assumptions are still changing?
• Are equipment loads confirmed?
• Are layouts coordinated?
• Have construction requirements been considered?
• Are commissioning dependencies understood?
• Is the engineering sufficiently mature to support the next stage of the project?

Technical assessment and the measurement of technical progress are also established elements of systems-engineering practice.[3]

The important point is that engineering progress should tell the project whether it is ready to make the next decisions, not simply how many documents have been issued.

Design Maturity Must Be Connected to Project Decisions

Engineering does not develop independently from the wider project.

It supports procurement, construction, cost forecasting, programme development, commissioning and ultimately operations.

The maturity of the engineering information therefore needs to be appropriate for the decisions being made from it.

Procurement commitments based on immature specifications can create commercial exposure. Construction released against incomplete designs can generate rework. Programme logic based on assumed engineering dates can become unreliable, while cost forecasts based on developing quantities can create a level of certainty that does not really exist.

The same applies to commissioning. A commissioning plan developed without a proper understanding of system dependencies is unlikely to remain realistic as the project progresses.

Engineering management provides the connection between technical maturity and these wider project decisions.

That does not mean waiting until every detail is known before making a decision. On a complex project, that is rarely practical.

What matters is understanding what is known, what is still uncertain and what that uncertainty means for the decision being made.

Projects inevitably move forward with incomplete information. The important thing is that the uncertainty is understood rather than hidden.

Interfaces Need to Be Managed Deliberately

Technical interfaces should not depend solely on informal communication between disciplines.

On complex projects, they benefit from deliberate management.

Depending on the project, this may involve interface registers, interdisciplinary design reviews, technical action trackers, responsibility matrices, design decision logs and structured coordination meetings.

The particular tool matters less than the discipline behind it.

An effective interface management process should establish:

• what information is required;
• who is responsible for providing it;
• which disciplines or packages depend upon it;
• when the information is actually needed;
• what assumptions are being used in the meantime;
• what happens if the information changes; and
• when the interface can genuinely be considered closed.

This provides traceability and helps avoid a very familiar project problem: the same issue appearing in meeting after meeting without a clear owner, decision or closure point.

Interface identification, control, documentation and change management are recognised elements of established systems-engineering practice.[1][3]

The purpose of technical coordination should therefore be to resolve decisions and interfaces, not simply to report that activity has taken place.

Vendor Information Is Part of the Engineering Programme

Specialist equipment suppliers are often critical contributors to the engineering process.

Their information can determine equipment dimensions, loads, connection details, power requirements, control interfaces, foundation requirements, access requirements and maintenance envelopes.

Despite this, vendor information can sometimes be treated as an external input rather than as an integral part of the engineering programme.

That is where problems begin.

A late vendor drawing may prevent several disciplines from completing their work. A change in equipment dimensions can affect layouts and structural supports. Revised electrical data may influence switchgear or cable sizing. Moving a connection point can require pipework to be reconsidered.

The effect is rarely confined to the package that generated the change.

Engineering management therefore needs to connect vendor information directly to the design activities that depend upon it.

This means understanding not simply when a supplier is contractually required to provide information, but when the wider project actually needs that information to make dependent decisions.

Those dates can be very different.

Engineering and Procurement Cannot Operate in Isolation

Procurement strategy has a direct influence on engineering.

Long-lead equipment may need to be selected before the complete design is mature. Early procurement can protect the programme, but it also fixes certain technical decisions earlier.

There is always a balance between schedule certainty and design flexibility.

Order too late and the programme may suffer. Commit too early and subsequent design development may result in changes.

Before significant commitments are made, the project needs to understand:

• which technical parameters are sufficiently mature;
• which parameters remain uncertain;
• which disciplines depend on the equipment selection; and
• what could happen if the assumptions subsequently change.

This is particularly important where specialist equipment has interfaces with several engineering disciplines.

A procurement decision on a complex engineering project is therefore rarely just a purchasing or commercial decision. It can lock in a significant part of the technical solution.

Constructability Should Influence Engineering Before Construction Starts

A technically correct design is not automatically a constructible design.

This becomes particularly important in constrained or operational environments.

Space limitations, temporary works, lifting routes, installation sequences, access restrictions, shutdown windows and existing services can all influence whether a design can actually be delivered efficiently.

Construction knowledge needs to enter the engineering process early enough to make a difference.

If constructability is considered only after detailed engineering is substantially complete, many of the opportunities to simplify delivery may already have been lost.

This does not mean allowing construction preferences to override engineering requirements. It means making sure that the engineering reflects the physical environment in which it will be installed.

The same applies to maintainability.

Equipment that can be installed but cannot later be safely inspected, isolated, removed or replaced creates a problem that may remain with the operator for decades.

Engineering management therefore needs to look beyond design completion and consider the asset through construction, commissioning, operation and maintenance. Lifecycle thinking of this kind is central to established systems-engineering frameworks, including those described by INCOSE and ISO/IEC/IEEE 15288.[1]

Existing Operational Environments Require a Different Engineering Mindset

Introducing new infrastructure into an operational facility creates a particular type of technical complexity.

The existing asset cannot simply be treated as a blank design environment. Its continued operation forms part of the engineering problem.

Projects may need to maintain energy supplies, process operations, healthcare services, production capacity or essential utilities while significant modifications are taking place.

Engineering decisions may therefore need to accommodate:

• temporary configurations;
• isolation strategies;
• phased connections;
• commissioning sequences;
• contingency arrangements; and
• the interaction between new and existing systems.

Existing systems may also behave differently from what historical drawings and records suggest.

That makes surveys and physical verification particularly important.

The project needs to understand what is actually installed, what needs to remain operational and how the new infrastructure will interact with it.

In these environments, engineering management becomes closely connected with operational risk.

The question is not simply whether the new system will work.

It is also:

How does the project move safely from the existing condition to the future condition without compromising the operation in between?

That transition needs to be engineered just as carefully as the final installation.

Change Is a Technical Interface Issue Before It Becomes a Commercial Issue

Change is inevitable on complex projects.

What matters is how quickly its consequences are understood.

A technical change rarely affects only the drawing on which it first appears. Changing equipment may affect procurement, layouts, foundations, electrical loads, control systems, programme activities, commissioning procedures and cost.

The earlier those consequences are identified, the more opportunity the project has to manage them.

Before a significant technical change is accepted, the project should understand:

• which disciplines are affected;
• which interfaces need to be reconsidered;
• whether previous design decisions need to be revisited;
• whether procurement or construction activities are affected;
• whether programme dependencies have changed; and
• whether commissioning or operational requirements are altered.

This is where engineering management, project controls and commercial management become closely connected.

Technical decisions create programme and cost consequences. Those consequences are much easier to manage when they are identified as the decision is being made rather than reconstructed several weeks or months later.

This principle is consistent with established interface-management practice, where proposed interface changes are assessed for their wider effects and controlled through defined change processes.[3]

Engineering Risk Needs Active Management

Engineering risk is not limited to the possibility of technical failure.

There is also risk in incomplete information, unresolved interfaces and developing design maturity.

Typical engineering risks can include:

• incomplete surveys;
• uncertain existing conditions;
• late vendor information;
• unconfirmed equipment selections;
• changing process requirements;
• unresolved design interfaces;
• limited shutdown opportunities;
• incomplete control philosophies;
• developing statutory or regulatory requirements; and
• insufficient commissioning information.

These risks should influence engineering priorities rather than simply sit on a project risk register.

If one unresolved item is preventing several disciplines from progressing, resolving it may be far more valuable to the project than completing a large number of lower-priority deliverables.

NASA similarly treats technical risk management as a cross-cutting technical-management process and connects technical risk with safety, technical performance, cost and schedule.[3]

Engineering teams therefore need visibility of the risks threatening technical progress, while the wider project needs visibility of engineering uncertainties that could affect programme, cost and delivery.

Commissioning Begins During Engineering

Commissioning is sometimes treated as something that starts near the end of construction.

On complex projects, that is too late.

Commissioning requirements can influence the engineering from a much earlier stage.

Systems need suitable isolation arrangements. Instrumentation needs to support testing. Equipment needs to be accessible. Temporary operating configurations may be required. Control sequences need to be understood, dependencies between systems identified and performance requirements made measurable.

All of those considerations can affect the design.

Complex facilities are also rarely commissioned as one single event. Individual systems may be mechanically completed, energised, tested and brought into service at different times before they are integrated into the complete operational system.

The engineering therefore needs to support a logical progression through:

Construction → Completion → Testing → Commissioning → Integration → Operation

Systems-engineering lifecycle approaches similarly recognise integration, verification and validation as activities that need to be considered as part of the development of the overall system rather than as isolated end-stage exercises.[1][3]

When commissioning requirements are considered early, potential problems can often be designed out.

When they are considered late, a project can discover that an installation which is technically complete is surprisingly difficult to test, commission or operate.

Technical Governance Should Support Decisions, Not Create Bureaucracy

Engineering governance is necessary.

Design reviews, approvals, technical queries, change processes, document control and assurance all provide important safeguards.

But governance needs to help the project make sound technical decisions rather than becoming an administrative objective in itself.

Too much process can slow engineering without improving technical quality. Too little can leave important decisions undocumented or uncontrolled.

The appropriate balance will depend on the complexity, risk and contractual arrangements of the project.

At its most useful, technical governance should ensure that significant engineering decisions are made with the right information, by the appropriate people, with the consequences understood and recorded.

ISO 21502 similarly recognises that project-management practices need to be appropriate to the organisation, project, lifecycle, complexity, size and delivery approach rather than applied through a single rigid model.[4]

Good governance should make delivery more dependable, not simply generate more paperwork.

The Engineering Manager Provides Integration

The engineering manager occupies a distinctive position within complex project delivery.

The role is not to replace the individual discipline specialists, nor does the engineering manager need to be the deepest technical expert in every discipline.

The value lies in integration.

An effective engineering manager needs to understand how technical decisions connect across the project and where they interact with:

• programme;
• procurement;
• construction;
• commercial management;
• project controls;
• commissioning; and
• operations.

That requires an ability to move between technical detail and the wider project context.

At one moment the issue may be a specific equipment interface. At another it may be whether the engineering is sufficiently mature to support a procurement commitment. Later, the concern may be whether a design change affects construction sequencing or commissioning.

The engineering manager helps maintain a common technical picture across those activities.

This aligns closely with systems thinking. APM describes complex projects as systems of interacting elements and recognises the value of integrating project-management and systems-engineering approaches.[2]

As the number of disciplines, suppliers, contractors and stakeholders increases, that integration becomes increasingly important.

Engineering Management Is Ultimately About Project Performance

The quality of engineering management becomes visible throughout the project lifecycle.

Good interface management can reduce rework. Better technical maturity supports more informed procurement decisions. Early constructability input can simplify installation. Clear technical governance improves decision-making, while the integration of engineering and project controls strengthens forecasting.

Early consideration of commissioning improves operational readiness, and better management of technical change reduces programme and commercial uncertainty.

These outcomes extend well beyond the engineering department. They affect how the overall project performs.

Engineering management should therefore not be regarded simply as a technical support function.

On complex projects, it is a core project delivery discipline.

Asteria International’s Approach

At Asteria International, we approach engineering management as part of integrated project delivery.

Our experience across energy, infrastructure, industrial manufacturing, healthcare, decarbonisation, process industries, power generation, water and wastewater has repeatedly shown that technical complexity is rarely contained within individual disciplines.

The challenge is often at the point where those disciplines, suppliers, contractors and operational requirements meet.

Our engineering management approach therefore focuses on:

• technical coordination;
• interface management;
• design maturity;
• engineering risk;
• constructability;
• supplier integration;
• commissioning readiness; and
• the relationship between engineering information and wider project decisions.

This is particularly important on technically complex projects and modifications to existing operational assets, where new infrastructure may need to be introduced without compromising ongoing operations.

The aim is not simply to produce technically correct engineering.

It is to help create engineering that is coordinated, constructible, commissionable and capable of supporting dependable project delivery.

Conclusion

Complex engineering projects are systems of interconnected decisions.

Individual disciplines can perform strongly and the project can still encounter difficulty if the interfaces between them are not properly understood and managed.

That is why engineering management matters.

It provides the structure through which technical information, engineering disciplines, suppliers, project controls, construction and commissioning can operate as an integrated whole.

Good engineering management looks beyond the number of drawings produced or calculations completed. It asks whether the engineering is sufficiently mature to support the next project decision.

It identifies interfaces before they become site problems.

It connects technical change with programme and commercial consequences.

It considers construction and commissioning while the engineering is still developing.

Ultimately, the real measure of engineering performance is not simply whether the design can be completed.

It is whether the resulting infrastructure can be procured, constructed, commissioned, operated and maintained successfully.

For complex projects, that is the difference between managing engineering deliverables and managing engineering for project performance.

References & Further Reading

This Insight draws on Asteria International’s project delivery experience alongside established project and systems-engineering principles. The following sources provide further guidance on a number of the practices discussed.

[1] International Council on Systems Engineering (INCOSE) — Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 5th Edition. The handbook addresses systems-engineering concepts, lifecycle processes and methods and elaborates on the lifecycle processes described within ISO/IEC/IEEE 15288:2023.

[2] Association for Project Management (APM) — APM Body of Knowledge, 8th Edition. Relevant to systems thinking, project complexity and the integration of technical and managerial disciplines within contemporary project delivery.

[3] National Aeronautics and Space Administration (NASA) — NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev 2. Relevant to technical planning, requirements management, interface management, technical risk management, technical assessment and decision analysis.

[4] International Organization for Standardization (ISO) — ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Provides internationally recognised project-management guidance applicable across different organisations, project types, lifecycle models, complexities and delivery approaches.