### 7.2.4 Deployment Plan The Deployment Plan defines the strategy, the roles and responsibilities, and the tasks that must be taken into account to ensure the information system can be deployed, run and managed by the IT operations team. Deployment efforts can impose a great deal of change and stress, both in the IT operations environment and on the information system’s end users, especially if not part of a well-defined and structured deployment strategy. Because the Deployment Plan focuses on the deployment effort's technical aspects, it is closely related to IT operations such as cut-over, rollbacks, back-out procedures for contingency and risk management. ==The PM2 Transition Plan and Business Implementation Plan complement the Deployment Plan== by covering the strategy to ensure that the client organisation is ready to use the system (training, support, etc.) The primary purpose of the Deployment Plan is to: - outline and communicate the strategy applied for the deployment efforts during the project life cycle; - create consensus and awareness of the efforts and responsibilities involved in a successful technical deployment of the solution – IT operations. The Deployment Plan should consider the iterative and incremental nature of PM2-Agile. Furthermore, deployment efforts should contribute to the overall goal of releasing working solutions to the information system’s users at regular intervals. The Deployment Plan must have enough detail to allow the IT operations team to deploy, run, and manage the information system. The Deployment Plan is closely related to the Operational Model as both artefacts are vital elements to ensure that the information system can be deployed and used in production environments The Deployment Plan should include the following sections: - **Deployment in Production** – Details the complete deployment process, including which features are expected to become available, which work packages will be generated, which libraries will be used, environment requirements, generated configuration data, etc. - **Validate the Solution** – Describes the used mechanisms to guarantee that the deployment was done correctly. - **Monitor, Report and Respond to problems** – Describes what are the foreseen mechanisms to help detecting, reporting and solving several different problems. The goal is to identify potential issues before they become real problems and jeopardize the correct system deployment and operation. | Key Participants | Description | |:----------------------------------------------- |:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Team Coordinator (TeCo) | Responsible for creating the Deployment Plan aligned with the Development Work Plan (Release Schedule) and with the project-level Transition Plan, in close collaboration with <br>the Project Manager (PM). | | Agile Team Member (ATeM) | Supports by providing technical advice related to the deployment efforts (data migration, contingency actions, or continuous delivery pipeline details). | | Architecture Owner (ArOw) | Supports by providing technical advice and identifying technical constraints that may impact the deployment approach to be defined. | | Product Owner (PrOw) | Supports by providing insight and information related to the requestor’s organisation reality that may impact the deployment approach to be defined. | | [[Project Manager (PM)]] | Accountable for the Agile Project Core Team’s (A-PCT) deployment approach and the alignment of the deployment efforts with the overall transition activities. | | Representative of the relevant operational unit | Contributes by bringing information related to operational processes and infrastructure, checking the feasibility, effectiveness and efficiency of the Deployment Plan and associated risks. | | **Guidelines** - **Compatible with the Development Handbook** – If the Development Handbook foresees the incremental and iterative development nature of PM2-Agile, the Deployment Plan must foresee a clear strategy to enable this approach. The setup of a Continuous Delivery Pipeline is a strategic decision that must be described and validated in the plan. - **Development and Operations** – The DevSecOps mindset translates to a set of practices involving Software development and Operations. It brings these ecosystems together to create the Deployment Plan. However, if the organisation is siloed with an independent IT Operations department, separated from Development teams, then IT Operations should be integrally involved to account for operational constraints. - **It’s a living artefact** - Revisit the Deployment Plan as the project evolves and feedback from previous deployment efforts is gathered. - **Align with the Release Plan** - Ensure that the deployment efforts are planned with respect to the defined Release Plan. - **Test it first** – Assure the Operations team can understand the Deployment Plan and successfully deploy, operate and manage the solution in a pre-production environment. Perform several dry- runs to guarantee a seamlessly transition to Production. ![[7.2.4 Deployment Plan — Inputs and main roles.png]]