Production Ready: Ensuring Seamless Transition from Development to Deployment in Custom Software

Early Stages of Production Readiness

In the early stages, production readiness assessments focus on high-level development concerns. This includes identifying high-risk and low-yield development processes or technologies, and ensuring development efforts satisfy design requirements. As the software design matures, assessments shift towards adequate planning, resource allocation, and the identification and implementation of tools, test environments, and long-lead items.

“Regularly review and update your PRR process to adapt to changes and maintain deployment efficiency.”

Comprehensive Production Planning

The system PRR, held prior to the final deployment milestone, provides evidence that the software can be deployed with acceptable risk and no breaches in cost, schedule, or performance thresholds. It also considers what systems and processes should be retained after deployment to sustain and maintain the software through its life cycle. For complex software systems, a PRR may be conducted for one or more system components, with periodic production readiness assessments during the development phase to identify and mitigate risks as the design progresses.

Key Provisions for Production Readiness

Cost Estimate

• The software, as designed, is deployable within the production budget.
• The production cost model is based on a stable detailed design and supply chain, and has been validated.

Risk Assessment

• Development, deployment, and quality risks are identified, with a mitigation plan in place.
• Environment and security risks are known and mitigated.

Technical Baseline Documentation

• The product baseline is stable and under proper configuration control to enable software deployment.
• Technologies are mature and proven in their final form, in operational environments.
• Development processes are stable and demonstrated in a test environment.
• Adequate deployment processes and metrics are in place for the delivery of on-time, quality software.

Technical Plans

• Prior readiness reviews are completed and action items closed.
• The supply chain is stable and adequate to support planned deployment.
• The program is properly staffed with qualified development, quality (engineering and assurance), and deployment personnel.
• The product acceptance system, including acceptance test procedures and associated tools, has been validated and put under configuration control.
• Deployment facilities are ready and required personnel are trained.
• The delivery schedule is executable, considering technical/cost risks and long lead items.
• A plan is in place to mitigate the risk of obsolescence during deployment.

PRR: Production-Ready Review

The PRR is the responsibility of the Product Owner (PO) and is confirmed by the Technical Director (TD), Architect (ARCH), and Quality Control (QC). The review is executed on the Acceptance Criteria Checklist (ACC).

A follow-on PRR may be appropriate in the deployment phase for the prime contractor and major subcontractors if there are changes in system design, imports/exports, or user processes; if start-up or re-start occurs after a significant shutdown period; if deployment start-up is with a new contractor; or if the deployment site is relocated.

Role of the Architect

The Architect establishes quantifiable review criteria tailored to satisfy program objectives. This includes pre-established review criteria for initial and full-scale deployment, and monitoring and controlling the execution of the PRR closure plans.

Key Takeaways

• Context is decisive in creating an organization's repeatable PRR process.
• Understanding the current PRR process and its particulars calls for psychological safety across teams.
• A robust retrospective process creates reusable components for an effective PRR process.
• Cognitive interviews and discussions with relevant teams reveal insights that drive the PRR process.
• The PRR process works if there is a shared understanding of what it means to be production-ready, and individuals feel comfortable enough to speak up and ask about the specifics of PRR.

What’s in it for me

To ensure your custom software is production-ready, conduct a thorough PRR with all stakeholders involved. Establish clear criteria, validate your production cost model, and mitigate risks early. Regularly review and update your PRR process to adapt to changes and maintain deployment efficiency.

---

Hugo Pragt is a driven IT Architect an Infodation, with broad experience in realizing mission critical systems in dynamic environments.