Operational-Readiness Assessment Within the SDLC

Defines how an Operational-Readiness Assessment should determine whether the complete Solution, operating model, people, processes, suppliers, controls, documentation, and support capabilities are prepared for Production and sustained Operations.

Best Practice: Define the Purpose and Intended Outcome of Operational-Readiness Assessment Within the SDLC

An Operational-Readiness Assessment provides decision-ready evidence that the enterprise can operate, support, monitor, secure, recover, maintain, and govern the Solution after Production introduction.

Benefits: Producing decision-ready evidence that the enterprise can actually operate a Solution — not just that it was built correctly — closes the gap between ‘the Solution works’ and ‘the enterprise is ready to run it,’ which are genuinely different questions with different evidence.

Best Practice: Define Readiness Outcomes

Readiness should address ownership, support model, staffing, skills, monitoring, alerting, logging, access, Incident response, Problem Management, maintenance, capacity, resilience, recovery, supplier escalation, documentation, knowledge transfer, and operating metrics.

Benefits: Covering staffing, skills, and supplier escalation alongside monitoring and alerting means readiness assessment catches the organizational gaps, not just the technical ones. A Solution with perfect monitoring but no one trained to interpret its alerts is not actually ready to operate.

Best Practice: Assess Demonstrated Capability

The assessment should evaluate whether required capabilities have been demonstrated through walkthroughs, simulations, exercises, test evidence, support scenarios, recovery activities, and representative operational use. The existence of documents or assigned names alone is not sufficient.

Benefits: Requiring readiness to be demonstrated through a walkthrough or simulation, not just documented, catches the gap between a runbook that reads well and a support team that can actually execute it under pressure. A named on-call owner who has never rehearsed the recovery procedure is not the same as a team that has.

Best Practice: Verify Operational Artifacts and Systems

Runbooks, support records, monitoring, alerts, dashboards, on-call schedules, inventories, CMDB records, access, certificates, backup, recovery, Service information, knowledge articles, and supplier contacts should be current and related to the approved Release and Production baseline.

Benefits: Confirming that runbooks, monitoring, and CMDB records are current and tied to the exact approved Release — not a prior version — prevents a support team’s first Incident response from being based on stale documentation that no longer matches what’s actually running.

Best Practice: Assess Transition and Stabilization

The Release should define handoff, command structure, hypercare or stabilization, issue triage, business communication, rollback authority, supplier participation, success criteria, and the transition from delivery teams to enduring operational ownership.

Benefits: Defining hypercare command structure and rollback authority before go-live, rather than improvising it during a stressful early-Production issue, means the team already knows who decides what when something goes wrong in the first hours after launch.

Best Practice: Govern Gaps and Conditional Readiness

Readiness findings should identify consequence, owner, due date or trigger, interim control, monitoring, decision impact, and closure evidence. Conditional readiness should remain visible through Risk, exception, deferral, or Technical Debt governance.

Benefits: Recording a readiness gap with an owner, due date, and interim control — rather than treating a caveat as good enough to proceed — keeps a known operational weakness visible and tracked to closure instead of becoming a permanent, unaddressed condition.

Best Practice: Maintain Readiness After Production

Operational readiness should be reassessed when material changes affect architecture, suppliers, data, operating procedures, support ownership, recovery, capacity, or regulatory obligations. Readiness is a continuing condition, not a one-time go-live checklist.

Benefits: Reassessing readiness when Architecture, suppliers, or support ownership materially change treats readiness as a continuing condition rather than a one-time go-live checkbox. A Solution that was operationally ready at launch can quietly become unready as its supporting context shifts underneath it.

Best Practice: Apply Operational-Readiness Assessment Within the SDLC Across Solution Types

Custom-Built Solutions require enterprise-created operating capability and knowledge. Acquired Solutions require supplier support boundaries, escalation, evidence, and enterprise integration readiness. Composite Solutions require coordinated end-to-end ownership across multiple teams and suppliers.

Benefits: Assessing supplier support boundaries and escalation paths specifically for Acquired Solutions, not just enterprise-created runbooks for Custom-Built ones, catches a real readiness gap — knowing who to call when a supplier-hosted component fails is not automatically covered by the enterprise’s own operational documentation.

Best Practice: Advance Maturity Deliberately for Operational-Readiness Assessment Within the SDLC

At Crawl maturity, confirm ownership, support, monitoring, recovery, access, and critical runbooks. At Walk maturity, use repeatable readiness criteria, simulations, integrated operational systems, and formal gap tracking. At Run maturity, use continuous readiness evidence, automated control-health monitoring, predictive operational risk, and event-driven reassessment.

Benefits: Starting with confirming basic ownership, monitoring, and critical runbooks at Crawl maturity establishes the foundation that repeatable readiness criteria and simulations at Walk maturity depend on. Pursuing automated control-health monitoring at Run maturity before the basics are solid tends to produce alerts without anyone positioned to act on them.

Best Practice: Avoid Common Antipatterns in Operational-Readiness Assessment Within the SDLC

Enterprises should avoid confirming technical readiness while assuming operational readiness. A Solution that passed its technical tests can still be unsupportable if the people, runbooks, and monitoring needed to actually operate it were never demonstrated, only documented.

Benefits: Avoiding this antipattern closes the gap between ’the Solution works’ and ’the enterprise is ready to run it.’ It catches staffing, skills, and support gaps before Production introduction, when they are still straightforward to correct.

Connections to Related IF4IT Practices and Inventories

Use Technology Portfolio Management (TPM) Best Practices, the Software Technologies Inventory and Attributes, and IT Operating Environments Best Practices to connect the decisions and responsibilities addressed in this chapter to governed technology choices, platform lifecycle, and environment controls.

Use the Non-Functional Requirements (NFRs) Framework for Software Systems to tie quality expectations to validation methods, test evidence, acceptance criteria, readiness gates, and Production assurance.

Apply Service Management Best Practices and Service Catalog Best Practices to define operational ownership, support models, service levels, monitoring, knowledge transfer, and customer-facing service commitments before and after Production.