Turning Success Criteria into Measurable Controls
How to Define “Done” So Projects Stop Drifting
One of the most common reasons projects “suddenly” get into trouble is painfully simple: the team never agreed – clearly and measurably – on what success looks like.
In engineering and construction, we’re surrounded by activity: drawings issued, bids evaluated, spools fabricated, welds completed, inspections performed, punch lists written and rewritten. But activity is not success.
Success is meeting defined outcomes within agreed tolerances, with stakeholders aligned on what “acceptable” means. When that definition is missing or vague, projects don’t just suffer confusion – they drift. And drift is the quiet precursor to schedule delays, budget overruns, claims, and reputation damage.
Over three decades of participating and managing international EPC projects in the oil and gas sector – onshore and offshore – I’ve learned that strong project controls start long before the first progress report. They start with success criteria that can be tested, tracked, and defended.
Why vague success criteria create real project risk
Teams often think they have success criteria because they have a contract, a scope statement, and a schedule. But those documents can still leave dangerous gaps.
Consider statements like: “Complete detailed engineering,” “Deliver the pipeline,” or “Commission the facility safely.” These sound reasonable, yet they invite multiple interpretations. What engineering maturity is required at each gate? What constitutes “deliver” for a pipeline – mechanical completion, hydrotest, pre-commissioning, commissioning, performance acceptance, handover dossiers? What does “safely” mean in measurable terms – Total Recordable Incident Rate (TRIR) targets, permit compliance, critical safety element verification, process safety leading indicators?
When criteria are unclear, decisions become inconsistent. Engineering may prioritize elegance over constructability. Procurement may chase low price over delivery reliability. Construction may optimize local productivity at the expense of system completion. Everyone thinks they’re winning – until integration exposes that they were winning different games.
The antidote: translate outcomes into measurable controls
A practical way to prevent drift is to convert success criteria into “controls” – measures that are visible, routinely checked, and tied to action. Controls are not bureaucracy. They are early-warning mechanisms that protect the project.
In EPC work, I typically see success criteria fall into six buckets: scope, schedule, cost, quality, HSE, and stakeholder/business outcomes. Each bucket needs a clear definition of “done,” a tolerance range, and an agreed method of measurement.
For scope, “done” is not “engineering completed.” It is the approved scope baseline with defined boundaries and a change control method that prevents silent scope creep. Controls here include a validated WBS, deliverable registers, interface lists, and a change log that is actually used – not updated after the fact.
For schedule, “done” is not a pretty Gantt chart. It is an integrated schedule with credible logic, resource realism, and clear milestones that represent true readiness points. In pipeline work, that could include design freeze dates, long-lead material commitments, stringing readiness, crossings completion, hydrotest packs, and commissioning system turnovers. Controls include milestone integrity checks, critical path validity, and rolling-wave planning for field execution.
For cost, “done” is not “we have a budget.” It is a cost baseline linked to the scope and schedule, with transparency on contingency, escalation, and allowances. Controls include cost-to-complete forecasting discipline and tight alignment between physical progress and cost performance – especially important when invoices and progress claims start diverging from reality.
For quality, “done” is not “we have QA/QC.” It is defined acceptance criteria for each deliverable and a quality system that prevents rework. Controls include ITP adherence, NCR trends, weld repair rates, coating holidays, document turnover quality, and vendor data compliance.
For HSE, “done” is not “zero incidents.” It is a measurable safety management approach that includes leading indicators: permit compliance, toolbox talk quality, SIMOPS planning, critical lift readiness, dropped object prevention, and process safety verifications. Controls include audits, observations, and targeted interventions where leading indicators show weakness – even before an incident occurs.
For stakeholders and business outcomes, “done” is not “the client is happy.” It is alignment on operational readiness, handover requirements, performance guarantees, and regulatory approvals. Controls include stakeholder availability commitments, decision turnaround times, and documented acceptance criteria for handover dossiers and as-builts.
Make controls operational, not ceremonial
Success criteria only protect you when they are embedded into the cadence of the project.
That means they must appear in the project charter or equivalent, be reflected in the baseline plan, and show up in progress reviews as “health checks,” not as a one-time slide. It also means thresholds must trigger action. If the project defines engineering maturity targets by discipline and the target is missed, the response isn’t a debate – it’s a corrective plan: re-sequencing, resourcing, decision escalation, or scope reprioritization tied to procurement and construction needs.
When controls are operational, they create transparency. Transparency reduces surprises. And fewer surprises mean fewer heroic recoveries – which are expensive, exhausting, and often too late.
Why this matters for project managers at every level
Many project managers are promoted because they are competent, hard-working, and trusted. But managing modern projects – especially EPC – demands a specific skill: the ability to define success in measurable terms and use that definition to steer decisions.
This is one of the reasons I emphasize success criteria and common failure drivers in my Project Management Fundamentals course. When participants can translate “success” into controls and early-warning signals, their projects stop being reactive. They start becoming manageable.
Projects don’t fail because people don’t care. They fail because “success” was never engineered into the management system. Define it clearly, measure it consistently, and act on it early – before drift becomes disaster.
