Plant CAPEX projects rarely fail spectacularly. They slip. A vendor is four weeks late, the shutdown window moves, a scope addition is absorbed without a change order, and eleven months later the line starts one quarter behind plan with an overspend nobody can fully explain. The patterns behind that outcome repeat across companies, sectors and countries.
1. Project ownership is a part-time job
The project is assigned to a maintenance manager, a plant engineer or a production superintendent who already has a full role. Whenever operations and the project compete for the same hour, operations wins — correctly, because a line down today costs money today. The project loses an hour a day, quietly, for a year.
The control: separate project ownership from operational responsibility. Not necessarily a permanent hire — but someone whose only measure of success is the project.
2. Long-lead items are tracked by hope
The critical equipment has a 26-week lead time and a single line in the schedule. Nobody tracks the intermediate milestones — PO issued, drawings approved, manufacturing started, FAT scheduled, shipped, cleared customs — so the first hard signal that delivery has moved arrives four weeks before it was due.
The control: a milestone-level expediting tracker for every long-lead item, updated on a fixed cycle with the supplier, and linked to the schedule so a slip immediately shows its impact on the installation window.
3. The shutdown window is assumed, not planned
Installation depends on a production window that was pencilled in nine months earlier. Nobody re-validates it against the current demand plan, and nobody runs a formal readiness check before it opens. The window arrives, three prerequisites are incomplete, and the plant either extends the outage at a cost per hour or defers to the next window a quarter later.
The control: treat the window as a hard constraint with a documented readiness checklist, reviewed at 90, 30 and 7 days, with a named owner per prerequisite.
4. Changes are absorbed, not processed
Operations asks for an extra transfer point. Quality wants a different finish. The change is technically minor and everyone agrees to it in a meeting. Twenty of those over a project consume the contingency and three weeks of float, and because none of them was ever assessed, the overspend has no traceable cause.
The control: a change register where every scope-affecting request is logged with cost and schedule impact before approval — including the ones judged to have no impact, because that judgement is exactly what needs to be on record.
5. Progress is a percentage somebody feels
The status says 70% complete. It said 70% last month. Nobody has defined what earns progress, so the number reflects effort spent rather than work delivered — and the last 30% takes as long as the first 70%.
The control: a written progress measurement rule per work type — engineering earned on issued revisions, procurement on PO and delivery milestones, installation on physical quantities, commissioning on completed protocols — agreed before the baseline is frozen.
6. Risks are listed once and never revisited
A risk register was produced for the capital approval. It has not been opened since. The risks that materialise are usually the ones that were on it — customs delay, integrator resource conflict, utility capacity — but without review cycles nobody acted while acting was still cheap.
The control: a monthly risk review with named mitigation owners and due dates, and an early warning threshold that forces escalation before the impact is unavoidable.
7. Reporting describes activity, not position
The monthly report lists what happened. It does not say whether the project will finish on time, what it will finally cost, or what decision is needed this month. Executives read it, learn nothing actionable, and stop reading it.
The control: every report opens with three numbers — forecast completion date, estimate at completion, and the variance of each against baseline — followed by the decisions required. Activity narrative goes in an annex, if at all.
The pattern behind the patterns
None of these seven is an engineering failure. Each one is a missing control, and each control is cheap relative to what it prevents. What they have in common is that installing and running them takes consistent weekly effort from someone whose job it is — which brings the problem back to the first pattern.
If you recognise four or more of these in a live project, the issue is not the project. It is that nobody has been given the time and the authority to run the control system.