Five Fault Lines: Where Engineering, Procurement, and Operations Are Breaking Each Other's Projects
Photo: cross-functional team collaboration engineering office departments meeting whiteboard, via cdn.pixabay.com
Organizational silos are not a new problem. But in engineering-driven businesses, the consequences of siloed operations are uniquely severe — because the dependencies between departments are tightly sequenced, the cost of misalignment compounds quickly, and the errors that result are often invisible until they have already caused significant damage.
The three departments most frequently implicated in cross-functional breakdown on U.S. engineering projects are engineering design, procurement, and operations. Each operates with legitimate internal priorities. Each makes decisions that are entirely rational from within its own frame of reference. And yet, when those decisions collide at the boundaries between departments, the result is a category of failure that no single team owns and no single team fully understands.
What follows is a structured examination of five specific fault lines where this breakdown occurs most frequently — along with a diagnostic question and an immediately actionable fix for each.
Fault Line 1: Engineering Specifies What Procurement Cannot Source
What happens: Design teams produce specifications that reflect optimal technical performance without systematic input from procurement on market availability, lead times, or cost realities. By the time procurement attempts to fulfill those specifications, the specified component may be on a 26-week lead time, discontinued, or priced at a level that blows the material budget.
Why it persists: Engineering teams are evaluated on technical quality and compliance. Procurement teams are evaluated on cost and delivery performance. Neither team is formally accountable for the gap between those two mandates.
Real-world impact: A manufacturing facility expansion project in the Midwest encountered a six-week schedule delay when a specified valve assembly was found to be available from only one domestic supplier, with a lead time that had not been factored into the project schedule. The design team had selected the component based on performance characteristics; procurement had not been consulted during the specification phase.
Diagnostic question: At what point in the design process does procurement formally review specifications for sourcing feasibility?
Tactical fix: Establish a procurement review gate at the 30% design completion milestone. At this stage, specifications are still fluid enough to accommodate substitutions without significant redesign cost. Procurement should flag any component with a lead time exceeding the project's procurement window or with fewer than two qualified domestic suppliers — and engineering should be required to either accept an alternative or formally document the rationale for maintaining the original specification.
Fault Line 2: Procurement Buys to Budget, Not to Specification
What happens: Under cost pressure, procurement teams approve substitutions or alternative suppliers without adequately communicating the technical implications of those decisions to engineering. The substituted component meets the budget target but introduces a performance, compatibility, or compliance gap that engineering discovers only during installation or commissioning.
Why it persists: Procurement teams often lack the technical depth to fully evaluate the downstream implications of substitutions, and the approval process does not require engineering sign-off on alternatives that fall within a defined cost threshold.
Real-world impact: On a water treatment upgrade project in the Southeast, a pump substitution approved by procurement to recover budget variance introduced a flow characteristic incompatible with the existing control system. The incompatibility was not discovered until commissioning, requiring both a control system modification and a pump replacement — at a combined cost that significantly exceeded the original budget savings.
Diagnostic question: Does your procurement approval process require engineering review for any component substitution, regardless of cost impact?
Tactical fix: Implement a two-tier substitution protocol. Substitutions that are functionally identical — same manufacturer, same model, equivalent specification — may be approved by procurement with notification to engineering. Substitutions that involve a different manufacturer, model, or specification — even if the cost impact is neutral or positive — require written engineering concurrence before the purchase order is issued.
Fault Line 3: Operations Is Not Consulted Until It's Too Late to Incorporate Feedback
What happens: Engineering designs systems and infrastructure based on technical requirements and project scope, with limited input from the operations personnel who will ultimately run, maintain, and troubleshoot those systems. By the time operations reviews the design, construction is underway and modifications are prohibitively expensive.
Why it persists: Operations teams are frequently excluded from early project phases on the assumption that their input is relevant only at commissioning and handover. This assumption is incorrect and costly.
Real-world impact: A chemical processing facility in Texas completed a significant equipment installation before operations personnel identified that maintenance access requirements — specifically, the clearance needed to remove and replace a key heat exchanger bundle — had not been incorporated into the layout. Correcting the access issue required partial demolition of a newly constructed support structure.
Diagnostic question: At what design phase are operations and maintenance requirements formally incorporated into the engineering scope?
Tactical fix: Require an operations constructability review at the 60% design completion stage, specifically focused on maintenance access, operability, and long-term reliability considerations. Provide operations reviewers with a structured checklist — covering access clearances, instrument placement, valve accessibility, and spare parts standardization — to ensure the review is systematic rather than anecdotal.
Fault Line 4: Engineering Change Notices Don't Reach Procurement in Time
What happens: Engineering issues a design revision — a change in material grade, a dimensional modification, a specification update — but the formal communication to procurement is delayed, incomplete, or routed through a process that does not guarantee timely receipt. Procurement continues to fulfill the original specification, resulting in materials that arrive on site that are no longer compatible with the current design.
Why it persists: Engineering change management processes are often designed to document changes for design record purposes, not to trigger procurement action. The two functions operate on different document control workflows that are not formally integrated.
Real-world impact: On a pipeline project in the Mountain West, a wall thickness specification was revised following a revised pressure analysis. The engineering change notice was issued and filed correctly within the design document control system — but procurement, working from a purchase order issued against the original specification, had already placed a mill order for pipe that no longer met the revised requirement. The non-conforming material had to be rejected and reordered at significant cost and schedule impact.
Diagnostic question: Does your engineering change management process automatically trigger a procurement impact review for any revision that affects a previously issued purchase order?
Tactical fix: Integrate the engineering change notice workflow with the procurement purchase order register. Any change notice that affects a specification, dimension, or material grade covered by an open or recently closed purchase order should automatically generate a procurement impact notification — requiring procurement to confirm whether action is needed before the change is formally released.
Fault Line 5: Departmental KPIs Reward Behavior That Harms Adjacent Teams
What happens: Each department is measured against performance indicators that are internally coherent but structurally misaligned with the goals of adjacent departments. Engineering is rewarded for design completeness; procurement for unit cost reduction; operations for uptime and maintenance cost minimization. These metrics, applied in isolation, consistently produce decisions that optimize one department's scorecard at another's expense.
Why it persists: Performance measurement systems are typically designed within departmental hierarchies, not across them. Cross-functional consequences are rarely captured in individual or team KPIs.
Real-world impact: This fault line is less a single event than a chronic condition. Organizations that measure procurement teams on purchase price variance alone will consistently see procurement decisions that create engineering rework and operations maintenance costs. The savings are visible in one column; the costs appear in another.
Diagnostic question: Do any of your departmental KPIs create a financial incentive to make decisions that increase costs or complexity for another department?
Tactical fix: Introduce at least one shared cross-functional KPI for projects involving significant interdependencies between engineering, procurement, and operations. Total installed cost — which captures design, procurement, construction, and commissioning costs in a single metric — is an effective starting point. When all three departments share accountability for a common outcome measure, the incentive to optimize within silos diminishes.
The Common Thread
Each of these five fault lines shares a structural characteristic: they emerge not from incompetence within any single department, but from the absence of deliberate coordination mechanisms between departments. The fix in every case is not to reorganize the departments — it is to build the connective tissue between them: shared review gates, integrated workflows, cross-functional accountability, and communication protocols that treat departmental boundaries as coordination points rather than stopping points.
At Presto Engineering Group, cross-functional alignment is not treated as a soft skill or a cultural aspiration. It is an engineered feature of project delivery — one that requires as much deliberate design as the technical systems it supports.
