A complex project can contain excellent components and still fail at the interfaces where nobody owns the whole system.
Complex projects are often divided so they can be managed.
The facility is split into packages. The product becomes subsystems. Software is separated into services. Suppliers receive defined scopes. Teams are given local performance targets. The decomposition is necessary because no organisation can manage every detail as one undifferentiated mass of work.
But decomposition creates a second problem: someone has to put the system back together.
That work is systems integration.
Andrew Davies's 2019 APM report treats systems integration, interface management, change control and configuration management as central capabilities in large complex projects. The systems integrator coordinates the network of parties involved in design, construction, testing, commissioning and handover, and manages the points where separately delivered components must operate as one system.
For executives, this is not merely an engineering coordination task. It is a governance function that protects whole-system performance from local optimisation.
The Strategic Context
Complexity increases when a project contains many interconnected parts.
Davies distinguishes between a complex system, where multiple components and subsystems combine to perform a requirement, and an array or system of systems, where several systems each perform their own purpose but must work together to achieve a broader outcome.
The management implication is straightforward: as interdependence rises, the organisation needs greater capability to understand and manage interfaces.
A supplier can fulfil its contract while creating a problem for another supplier. A software subsystem can pass its own test but fail under system load. A machine can meet technical acceptance criteria but be difficult to maintain within the physical layout. A new facility can contain commissioned equipment that does not support the intended operational flow.
Local acceptance is not system acceptance.
What Leaders Commonly Misread
The first mistake is assuming that clear work-package boundaries create clear system accountability.
They create local accountability. The boundaries themselves still require ownership.
The second mistake is treating integration as something that happens near the end.
Late-stage integration is expensive because component teams have already made design decisions, suppliers have demobilised, documentation may be inconsistent and changes have cascading consequences.
Davies's report specifically notes that significant time should be allowed up front for systems integration and that components meeting their individual specifications rarely work perfectly when first combined.
The third mistake is believing that interface management is mainly a technical register.
An interface is also commercial and organisational. Two suppliers may disagree about scope. A design decision may cross contractual boundaries. A change may create a cost for a party that did not initiate it. A user requirement may affect several systems.
The integrator needs enough authority, information and technical understanding to resolve these conditions.
The fourth mistake is allowing the most powerful supplier to become the de facto owner of system architecture without explicit governance.
The organisation that integrates the system needs to understand the whole better than any component supplier does. Otherwise critical knowledge becomes fragmented across contracts.
Related article: Interdependencies Are Portfolio Risk: Why Project Dashboards Miss the System
Reframing the Issue
Systems integration is the management of consequences across boundaries.
This is broader than assembling components.
Every significant change should trigger a whole-system question:
What else becomes true if we change this?
A dimensional change to a machine base may affect guarding, services, foundations and maintenance access.
A change to data structure may affect reporting, interfaces, testing and migration.
A schedule change to one package may affect commissioning order, temporary works, resource peaks and operational transition.
A procurement substitution may affect performance, certification and spares.
The interface is therefore where technical systems and management systems meet.
Integration Must Begin in Architecture
The strongest integration capability starts before detailed delivery.
The project needs a clear representation of the system: major components, interfaces, performance requirements and how the parts combine to create the operational outcome.
This does not require predicting every detail. It requires enough system architecture to prevent local teams from making incompatible assumptions.
A useful integration architecture should identify:
- who owns the overall system requirement;
- major technical and operational interfaces;
- which requirements cross component boundaries;
- where configuration must be controlled;
- how changes will be assessed for downstream consequences;
- when progressively larger levels of integration will be tested;
- who has authority to resolve interface disputes.
The architecture should also include the operator.
Davies notes that early customer or operator involvement improves the chances that the final system will meet its purpose. This is particularly important where project teams can technically optimise a system that becomes awkward in operation.
Configuration Control Is Strategic Memory
Configuration management is sometimes treated as document administration.
In a complex project, it is closer to the project's memory of what system has actually been authorised.
When many design changes occur across multiple components, leaders need to know:
- which version is current;
- why the change was made;
- which requirements it affects;
- which interfaces must be reassessed;
- what has been built, tested or procured against an earlier configuration;
- whether operational and maintenance documentation remains aligned.
Without this discipline, different teams can be working on different versions of reality.
The cost may not appear immediately. It emerges at integration, testing or operations.
The Integrator Needs Authority Without Becoming a Bottleneck
A systems integrator can be internal to the client, performed by a prime contractor or shared through a client-delivery partner arrangement. The exact structure is context-dependent.
What matters is that integration responsibility is explicit.
The integrator requires enough technical competence to challenge component decisions and enough organisational authority to resolve cross-package issues. But centralising every decision would create another problem: slow approvals and loss of specialist ownership.
A stronger model defines interface decision rights.
Local teams should decide within their subsystem boundaries. Decisions that affect shared interfaces, system performance or configuration cross an escalation threshold.
This is similar to portfolio governance: centralise the decisions that require a system view, not every decision.
Related article: Portfolio Governance Is a Decision-Rights System
Decision Framework
Executives can assess integration readiness through six questions.
| Area | Integration test |
|---|---|
| Architecture | Is there an authoritative view of how components combine into the required system outcome? |
| Ownership | Who is accountable for system performance across supplier and work-package boundaries? |
| Interfaces | Are critical interfaces identified, actively managed and assigned owners? |
| Configuration | Can the project state with confidence which design and requirement baseline is current? |
| Testing | Does testing progressively prove components, subsystems and the integrated system? |
| Operations | Are operator, maintenance and service requirements built into integration decisions? |
If the answer to ownership is "everyone", it often means nobody has sufficient authority.
From Strategy to Execution
Immediate action should begin by identifying the project's most consequential interfaces.
Do not attempt to treat every interface as equal. Focus first on those where failure would affect safety, performance, schedule, commissioning, regulatory acceptance or major cost.
For each, define an owner and an evidence-based closure process.
Next, test whether contracts and work packages align with the system architecture. Where commercial boundaries cut across technical dependencies, create explicit mechanisms for joint decisions and change impact assessment.
In the medium term, build integration into the schedule. Do not allow every package to finish independently and then discover compatibility problems at the final commissioning stage. Use progressive integration, test environments, prototypes, mock-ups or staged demonstrations where appropriate.
Configuration management should be integrated with change control. A change cannot be evaluated only for the initiating package. The question is its system impact.
Longer term, capture systems-integration capability as an organisational asset. Organisations that repeatedly deliver complex engineered systems should not rebuild integration knowledge from scratch for every project.
Signals to Monitor
Integration risk may be rising when:
- interface issues are repeatedly discovered during testing rather than design;
- suppliers argue that a problem sits outside their scope;
- component teams report green while system-level milestones move;
- changes are approved without documented cross-system impact;
- different teams use conflicting drawings, models, data definitions or requirement versions;
- operator involvement begins late;
- integration activities are compressed to recover earlier schedule delay;
- system performance measures are weaker than package-level measures;
- senior leadership cannot name the accountable systems integrator.
Questions for the Leadership Team
- Who knows more about the whole system than any individual supplier?
- Which interfaces carry the greatest safety, performance or schedule risk?
- Where do our contract boundaries conflict with our technical architecture?
- How does a design change in one package trigger assessment across affected subsystems?
- Are we testing integration progressively or postponing the hardest learning until the end?
- Does the operator have sufficient influence over system requirements and acceptance?
- What integration capability should remain in the organisation after the project closes?
Closing Perspective
Decomposition makes complex projects manageable. Integration makes the decomposed work useful.
The project is not successful because every supplier has delivered its package. It is successful when the combined system performs reliably in its operating environment.
That requires an explicit management function with a whole-system view, authority across interfaces, disciplined configuration control and early involvement in design and testing.
Systems integration is therefore not the final technical step. It is the connective management capability that must exist from the front end through handover. Without it, complexity does not disappear. It simply moves into the spaces between teams.
About EraNorth Insights
EraNorth Insights publishes practical analysis on strategy, projects, operations, transformation and decision intelligence for professional and organisational use. About EraNorth.