Most Plant 3D projects don’t fail during requirements gathering. They fail because nobody was monitoring requirements while the work was already underway.
The process basis will change. Procurement constraints will shift. Operating conditions get revised. That is not a failure. That is engineering. The problem is not that requirements evolve. The problem is when those changes are not tracked and the team keeps working from the previous version.
The other problem, which gets even less attention, is simpler: the team is not always producing what the client actually needs.
The Deliverable Gap
Before asking whether your requirements are being tracked, ask a more basic question: Does everyone agree on what the engineering team is supposed to produce?
This sounds obvious. It rarely is. A client assumes the project includes instrument index sheets for every service. The engineering team assumed those were out of scope. Nobody wrote it down. Six weeks before the project closes, someone asks where the instrument index is.
That is a deliverable gap. It is one of the most common and expensive requirements failures in Plant 3D projects, and it has nothing to do with design complexity. It happens because the list of deliverables was never fully defined, agreed upon, and signed off at the start of the project.
A complete deliverable list covers more than drawings. It includes data sheets, specifications, vendor document requirements, isometric outputs, BOM formats, tie-in schedules, and any client-specific reporting requirements. Each item should have a clear owner, a format, and a delivery milestone. If any of those are missing, the team is working toward a finish line that has not been drawn yet.
The Change Tracking Gap
Once the deliverable list is established, the next requirement is a process for handling change. Not a process to prevent change. A process to track it.
The process basis changes. A vessel pressure rating gets revised. A fluid service is reclassified. A tie-in location moves. Each of those changes has downstream consequences in Plant 3D: line designations, pipe specs, equipment nozzle ratings, isometric annotations. If the change is logged and communicated, the team can respond. If it is not, the team keeps working from the previous version and the gap widens quietly.
The cost shows up later. Labor costs run 30% higher on projects where work proceeds on incomplete or outdated information. That premium is not caused by one missed change notice. It is the accumulated cost of many small gaps between what the design reflects and what the project actually requires.
The question to ask is not whether your project will have changes. It will. The question is: when a change happens, who knows about it, and who is responsible for updating the affected work?
In most firms, the answer is informal. Changes travel by email and verbal conversation. There is no single place to see the current state of the requirements. Engineers find out about changes when they run into the consequences.
What Gets Missed Without a Process
Three patterns show up repeatedly when requirements are not actively managed.
The stale BOM. Procurement acts on a BOM extracted from the model at a point in time. Engineering keeps designing. The BOM ages. Nobody flags the delta until a wrong order is placed or a fabricated part arrives to the wrong spec. The cost of that gap is documented in change orders, expediting fees, and field rework.
The missing deliverable. The team produces everything they understood to be in scope. The client needed more. The discovery happens at project close, when there is no schedule float and no budget to absorb the work. This is not a scope creep problem. It is a deliverable definition problem.
The undocumented assumption. An engineer makes a design decision based on a process condition that was current two weeks ago. The condition has since changed, but the change never reached the design team. The drawing goes out. The assumption is wrong. Finding it requires a review, a revision, and in some cases a procurement correction.
None of these are caused by engineers making bad decisions. They are caused by the absence of a process that keeps the design aligned with current requirements.
What the Numbers Actually Say
A 2025 peer-reviewed study of 127 construction practitioners found that design changes account for 56.5% of cost overruns and 40% of schedule delays. Planning errors account for another 34.5% of cost overruns and 23.1% of delays. Together, those two causes explain the majority of project failure. Both are manageable with structured protocols. The same study says so directly.
Separate EPC research adds that 27% of cost overruns trace specifically to inadequate or incomplete scope definition at the start of a project. That is the deliverable gap in cost terms: the team did not have a complete picture of what the project required, and the difference was paid for in change orders.
The research points in one direction. Unmanaged design changes and incomplete scope definition are not bad luck. They are the leading documented causes of cost and schedule failure. Structured protocols to track changes and define deliverables completely are the recommended corrective.
The question is whether those protocols are in place before the next change order arrives.
Sources
- Impact of Change Orders on Cost Overruns and Delays in Large-Scale Construction Projects: Engineering, Technology & Applied Science Research (February 2025)
- Model Planning and Controlling System for EPC of Industrial Projects: Construction Institute
- Cost Overruns in Construction Projects: Neuroject (2024)
- Cost overruns of infrastructure projects: distributions, causes and remedies: ScienceDirect (2025)