Operational Readiness

Definition

Operational Readiness (often shortened to OR or ORAT — Operational Readiness and Activation Testing) is the structured set of activities that prepares the operating organisation to take over and run a new facility, plant, system, or product. It runs in parallel with construction, commissioning, and integration, and its goal is simple: on the day operations starts, every person, procedure, spare part, training record, license, and interface is in place.

Why It Matters

Engineering and construction deliver an asset. Operations have to run it for the next 25 to 50 years. The most common reason flagship projects underperform in their first 12 months is not engineering quality — it is a gap between what was handed over and what the operating team was ready to receive. Operational readiness closes that gap by treating "the ability to operate" as a deliverable in its own right.

Scope

• People: recruitment, training, certification, shift rosters.
• Process: standard operating procedures, emergency procedures, maintenance routines.
• Systems: CMMS, asset registers, control system access, integration with corporate IT.
• Spares and consumables: initial stock, supplier contracts, warehouse setup.
• Permits and licences: environmental, operational, safety, regulatory sign-off.
• Interfaces: with neighbouring assets, customers, utilities, emergency services.

Real-World Construction Example

A new international terminal at a regional airport reached substantial completion on schedule. Two weeks before opening, the airport's OR team identified that immigration staff had been trained on the old e-gate firmware, the baggage handling system had no signed-off failure-mode procedures, and the airfield rescue service had never rehearsed an evacuation from the new air bridges. The opening was deferred by 30 days. The cost of the deferral was significant, but a "go live with workarounds" would have damaged the airport's reputation for years. The OR plan, when properly resourced from day one, prevents almost all of these surprises.

Real-World IT / Agile Example

A bank's new digital-onboarding platform passed all functional and performance tests. On launch morning, the call centre received 8,000 calls in two hours because customer support had never been trained on the new identity-verification flow. Compliance had not approved the standard scripts. The product launched but cost the bank a quarter of customer goodwill. A modern DevOps equivalent of OR — "launch readiness review" — would have caught all three gaps weeks earlier.

The OR Plan

• Readiness register — every readiness item, with owner, due date, evidence required, and current status.
• Phased gates — typically OR-1 (12 months out, scope locked), OR-2 (6 months out, training underway), OR-3 (1 month out, dress rehearsal), OR-4 (1 week out, go/no-go).
• Dress rehearsals — full-team simulations of normal and abnormal operating scenarios.
• Independent assessor — operations is a stakeholder, but the OR assessment should be independent of both delivery and operations to avoid conflicts.
• Clear no-go criteria — written before they are needed, signed by accountable executives.

Best Practices

• Start OR at FEED (front-end engineering design), not at handover. The decisions that drive operability are made at concept.
• Embed the future operations team in the project from year one, not from commissioning.
• Treat OR as a workstream with its own budget, schedule, and risk register.
• Track readiness by evidence, not by intent. "Training scheduled" is not the same as "training delivered and assessed."
• Rehearse the abnormal. Smooth go-lives come from drilling failure modes, not from polishing the happy path.

Common Mistakes

• Starting OR three months before go-live. Twelve to eighteen months is the realistic minimum on capital projects.
• Confusing commissioning (the asset works) with readiness (the people and systems are ready to run it).
• No dedicated OR manager — accountability defaults to project director and gets dropped.
• Skipping dress rehearsals because the schedule is tight.
• Treating training as a tick-box rather than a competency.
• Leaving spare parts and maintenance contracts to the last weeks.

Expert Tips

• Use a structured readiness scorecard covering people, process, systems, spares, permits, interfaces. Report it monthly to the steering committee.
• Hold OR gate reviews independently from project gate reviews. The two viewpoints catch different defects.
• Rehearse failure modes, not just normal operations. The first 90 days exposes every weak procedure.
• Lock the go/no-go criteria early. Late renegotiation is how unsafe launches happen.
• Capture lessons from previous launches. The same gaps repeat across an organisation; structured lessons learned save the next project months.

Practical Lessons Learned

• A great asset launched badly is remembered as a bad asset.
• The OR budget always looks expensive until the first month of operations.
• Operators trust delivery teams that take readiness seriously; the relationship pays back for years.

Key Takeaways

• OR delivers "the ability to operate" as a project deliverable.
• It must start years, not weeks, before go-live.
• Evidence-based readiness scorecards beat intent-based ones.
• Dress rehearsals and failure-mode drills are non-negotiable on capital and digital launches alike.
• An independent assessor stops politics from rewriting the readiness status.

Related Encyclopedia Entries

• Handover Management
• Quality Gate
• Punch List
• Lessons Learned
• Risk Management
• Incident Management

Related Research Articles, Case Studies & Tools

• Project Controls Academy: Operational Readiness
• Readiness Scorecard Template
• Learning Tracks: Handover & Operations
• Airport terminal opening deferral
• First-year performance after capital launches