The risk is often not a bad analysis inside one discipline. It is a mismatch between the assumptions carried by several disciplines.
Imagine a large institution evaluating a major energy-infrastructure project. The engineering team has developed a sound concept. Finance has a model. Operations has reviewed the equipment. Procurement has identified a contracting path. Sustainability can describe the emissions benefit. Executive leadership likes the strategic direction.
On a status report, the project looks healthy.
Then the pieces are brought together.
The financial model assumes staffing reductions that operations never agreed to. The engineering schedule assumes a utility upgrade that will not arrive for another year. Procurement is preparing to buy equipment before the commercial team has resolved who will carry performance risk. The vendor's reference projects are smaller and simpler than the proposed installation. Leadership thinks approval is the final step, while the project team still has unresolved dependencies that could materially change cost and schedule.
No single workstream is necessarily wrong. The project is failing in the connections between them.
WORKING PRINCIPLE
Projects often fail at the interfaces, not within the disciplines.
Strong work in engineering, finance, operations, commercial structure, and procurement does not produce a strong project unless the assumptions and dependencies between them also hold.
Silos are not the problem
Organizations divide work into disciplines because complex problems require expertise. Engineers need room to do engineering. Operators understand what it takes to keep facilities running. Finance brings rigor to capital and lifecycle economics. Procurement, legal, sustainability, commercial teams and executive leadership each see risks and constraints that others may not.
That specialization is a strength.
The problem begins when we assume that strong work inside each function automatically produces a strong project. It does not.
Each group naturally optimizes for the questions it owns. Engineering may optimize performance and constructability. Finance may optimize the investment case. Operations may optimize reliability and maintainability. Procurement may optimize competition, process and contractual compliance. A vendor may optimize for a sale. Leadership may optimize for strategic timing and organizational priorities.
The project, however, has to satisfy all of those conditions at the same time.
Six handoffs where good projects commonly break
A system can be technically sound but operationally awkward. The question is not simply whether it works, but whether this organization can operate it reliably under real conditions.
A financial model can be mathematically correct while relying on organizational actions that will never occur. Are the assumptions behaviorally and institutionally real?
A vendor may have a strong product and still be the wrong risk counterparty for a particular project. Who is standing behind the performance?
Ownership, guarantees, operating responsibility and payment structure can quietly change technical risk. Does the commercial structure match how the system actually works?
Leadership may support a project concept without seeing the full sequence required to make it real. What has to happen, and in what order, before the decision becomes an operating asset?
6 / EXTERNAL DEPENDENCIES TO SCHEDULE
A project schedule can look credible until it depends on utility capacity, permitting, financing, or third-party work outside the team’s control. Are those dependencies verified, sequenced, and owned?
The most useful question at each handoff is whether the assumptions made by one function remain valid when they meet the realities owned by another.
The assumptions are where the silos meet
One of the most useful integration practices is also one of the simplest: make important assumptions explicit.
Projects often carry dozens of assumptions that live inside individual workstreams and are invisible to everyone else. Finance assumes the project starts in January. Engineering assumes electrical capacity will be available. Operations assumes a service contract is included. The vendor assumes the owner will provide controls integration. Procurement assumes the scope is stable. Leadership assumes the budget number includes everything needed to deliver the outcome.
Individually, each assumption may be reasonable. Collectively, they may be incompatible.
Integration starts when the team treats assumptions as shared project information rather than private workstream inputs. Which assumptions materially affect cost, schedule, performance or risk? Who owns each one? Has it been verified? What happens if it proves false?
What integration looks like in practice
- Define the decision before optimizing the solution. Make sure every workstream understands what leadership is actually deciding, what alternatives are being considered and which outcomes matter.
- Use one set of major assumptions. Create a shared list of cost, schedule, operating, vendor, utility and implementation assumptions that materially affect the case.
- Test interfaces, not just components. Ask what happens where engineering meets operations, where the financial model meets staffing reality, where vendor scope meets owner responsibility, and where strategy meets the project schedule.
- Bring operators and implementers in early. The people who will maintain, procure, contract, commission or live with the system often expose issues that are invisible in concept development.
- Assign owners to unresolved dependencies. If utility capacity, permits, financing, vendor diligence or a contractual issue remains open, someone should own resolution and the decision should reflect the uncertainty.
- Reconcile before approval. Executive approval should not be the moment when hidden workstream conflicts finally become visible.
The integrator role
The integrator does not need to be the smartest specialist in the room.
Cross-functional integration is sometimes misunderstood as generalism replacing expertise. That is not the role.
The integrator should not tell an engineer how to size a system, tell an attorney how to draft a guarantee, or tell an operator how to maintain equipment. The responsibility is to make sure those answers connect: are the specialists solving the same problem, using compatible assumptions, and producing a combined answer that still supports the decision leadership thinks it is making?
The most dangerous risks may belong to no department
Most organizations are good at managing risks that clearly belong somewhere. Engineering owns design risk. Finance owns financial review. Legal owns contractual review. Operations owns operating reliability.
The harder risks are the ones that do not fit cleanly inside an organizational box.
Who owns the risk that the financial model depends on an operating change facilities will not make? Who owns the mismatch between the vendor's warranty assumptions and the owner's intended duty cycle? Who owns the fact that the preferred technical solution requires a utility upgrade that misses the project's capital window? Who owns the possibility that procurement will change the commercial structure on which the economics were based?
If the answer is “everyone,” the practical answer is often “no one.”
Own the handoffs and the project gets stronger
Good projects do not need less specialization. They need better integration of specialized work.
That means deliberately examining the assumptions and dependencies between disciplines before they become late-stage surprises. It means asking whether a project that is technically sound is also operable, whether attractive economics are institutionally real, whether contractual protections match technical risk, and whether the organization has a credible pathway from approval to implementation.
The objective is not to eliminate uncertainty. Complex projects will always contain uncertainty. The objective is to identify the uncertainty that matters, assign ownership to it, and make sure leadership understands what conditions the decision depends on.
The most dangerous project risks may belong to no department. If nobody owns the handoffs, nobody owns the whole decision.