Deployment Plan
The deployment plan outlines the scope, approach, and execution plan for the deployment of the project deliverables. The plan includes, where relevant, information about system support, issue tracking, escalation processes, roles, and responsibilities before, during, and after deployment. The deployment plan is intended to provide clients, stakeholders, and support personnel with a smooth transition to the new product or software being deployed. The deployment plan describes each step of the deployment process at each deployment location, whether there is one site or multiple sites, or one deployment, or a phased deployment planned. The Deployment Plan defines all of the work steps for complete deployment, and who does them.
Process
What information needs to be gathered to create a deployment plan?
- Deployment goals and critical success factors
- Roles and responsibilities of the parties involved in the deployment of the project deliverables
- Task and resource dependencies
- How team members will communicate
- How to track issues and resolve them
- Backout options
- Training plan
- BC/DR Requirements
The anticipated outcomes from the deployment plan include, but are not limited to, or may not always include:
| Outcomes | Description | Samples or Templates |
|---|---|---|
| Release Plan | Describe the activities for a phased implementation or roll-out. Track the dates for the release of various functions, and/or track the formal review points in the testing cycle of your product. Your release plan may also include the following activities, as appropriate:
|
Release Plan Template [docx] Detail Release Plan Example [docx] |
| Production Readiness | Create a Product Implementation Task List. Describe what preparation is required for this new tool or application to operate. Specify any features that need modification to adapt to the new product. Identify the steps necessary to assist the user in preparing for this new product. | Production Readiness Checklist [docx] |
| Communication Plan | Develop a plan to communicate with all interested parties of this project (stakeholders, sponsors, users, developers, Change Review Board) This planning ensures that everyone who needs to be informed about project activities and results gets the needed information in a timely manner. | Communication Plan Template [docx] |
| Issue/Change Request Tracking Method | Use a tool to record:
|
Issue-Action-Decision Log Template [docx] |
| Backout Plan | Plan for what to do when something goes wrong during deployment, including how to go back to prior business processes and applications. Engage the appropriate sections of the Communications Plan. | |
| Training Plan | Outline the training timeline and describe the approach, activities and tasks necessary at each point in the deployment. | Training Plan Template [docx] |
| Business Continuity and Disaster Recovery Plan | Plan for what to do when something goes wrong. Develop a business resumption plan and comprehensive statement of action. |
Follow these guidelines for compiling the information to be included in the deployment plan:
- Identify the resources required to support this product, including facilities, hardware, software, associated documentation, staff, etc.
- Describe any procedures or lessons learned that may help with the support.
- Describe any expected areas of change to the product.
- Describe the plans for transitioning the product to the support organization. Include:
- Roles and responsibilities for each activity
- Resources needed to carry out the transition activities and where those resources will come from
- Schedule and milestones for conducting the transition
- Installation procedures and other information necessary to support
The Deployment planning begins in the design phase and continues throughout the project lifecycle.
The deployment plan is typically drafted by the Project Manager, but its development is a team effort.
Design Specification
The design review process ensures the design of a solution meets the overall project requirements prior to the build phase.
Process
- Approved Project Charter
- Customer and technical requirements
- Vendor specifications for hardware and software (when applicable)
- Standards (when applicable)
- Design Review Checklist [docx]
| Activities | Task | Owner |
|---|---|---|
| 1 | Identify design review documentation required for this project with the project sponsor/team | Project Manager |
| 2 | Prepare design review documentation | Lead Designer |
| 3 | Review & revise design documentation with project team | Lead Designer |
| 4 | Request design review and approval from key stakeholders (this may require a meeting, if requested by stakeholders) | Project Manager |
| 5 | Revise design documentation based on stakeholder feedback and distribute to team | Lead Designer |
| 6 | When design approved, publish & notify project team | Project Manager |
Note: It is the responsibility of the project sponsor and project manager to determine who is included in the design review and approval decision.
- Design document or web page of design components
- Key stakeholder agreement on the design
- Key stakeholder acknowledgement of any changes to the overall project outcomes as a result of the approved design
Production Readiness
The Production Readiness Checklist outlines the list of criteria needed from a project before a major release is deployed in the production environment (e.g. software upgrades, new application deployments, or as determined by the project sponsor and/or production support manager). It is the responsibility of the project manager to gather the information and conduct a Production Readiness Review before the release. The list is to be used as a guide. It may be modified by the project manager with the approval of the sponsor, particularly for smaller projects.
Process
The production readiness review process ensures the readiness of a major release before it is put into production.
The inputs recommended for the production readiness review include:
- Hardware requirements
- End user device requirements
- Performance requirements
- Support requirements
- Architectural review
- Security review
- Completed test plan
- User acceptance
- User guide
- Helpdesk documentation
- Installation guide
- Implementation plan
- Customer communication plan
- Operations guide
- Business continuity and disaster recovery plan
- Standards (when applicable)
The outputs desired from the production readiness review include:
- Completed production readiness review checklist
- Production readiness recommendation
| Step | Task | Responsible Party |
|---|---|---|
| 1 | Following the Project Charter signoff, establish what information on the Production Readiness Review Checklist will be needed for the Readiness Review Process | Project manager, Project Sponsor, Production Support Manager |
| 2 | Propose project implementation date | Project manager |
| 3 | Schedule time on the appropriate review board(s)* meeting agenda for Readiness Review | Project manager |
| 4 | Complete Readiness Review Checklist for Review Meeting | Project manager |
| 5 | Distribute and review Readiness Review Checklist with Readiness Review Team members | Project manager |
| 6 | Facilitate Readiness Review Meeting | Project manager |
| 7 | Recommendation (go/no-go) | Readiness Review Team(s) |
| 8 | If “Go”, prepare for Change Management or Team Implementation Process | Project manager |
| 9 | If “No Go”, complete missing information and start process over | Project manager |
Note: It is up to the project manager and project sponsor to determine the appropriate people and/or groups who should be included in the final Readiness Review discussions. Options include, but are not limited to, project team members and key customers.
Test Plan
The Test Planning Checklist [docx] is a tool to assist in creating an overall test plan for the project. This process does not address the creation of specific test cases. The accepting team (e.g., Production Support) should be involved in the risk assessment and test prioritization activities.
Process
- Requirements Specifications [docx] (for test planning and test design).
- Design specification (for test design).
- (Optimally) Complete description of testable deliverables, with change summary.
- (Optimally) Risk assessment of testable deliverables.
- Test Strategy and Plan: tests (or test groups) documented and prioritized, test environment needs identified, test processes documented.
- Tests (or test groups) mapped to requirements and deliverables.
- Acceptance criteria for exiting test phase.
- Reusable risk assessment and regression test descriptions for testable deliverables.
- Test results summary and product test repository (after test execution).
| Activities | Task | Owner |
|---|---|---|
| 1 | Identify the testable deliverables. If not already done, make a list of new, changed or obsoleted deliverables, with a summary of the change. Also identify any components affected by the changed deliverables. Share this Project Items list with the accepting team (e.g., Production Support). | Project Manager / Test Manager |
| 2 | Gather supporting information for each Project Item, such as system, component type, when it runs, test environment needs, any existing test documentation, etc. | Development Lead |
| 3 | Do a risk analysis. If not already done, determine the risk (High, Medium, Low) for each Project Item if it fails in production. Assign risk regardless of the changes being made. This risk assignment can be used for future projects. | Development Lead / Production Support |
| 4 | Plan the test coverage. Decide how much testing is ‘enough’ for each Project Item. High-risk items will require more testing than low-risk items. | Project Manager / Test Manager |
| 5 | Plan the tests. For each Project Item, group of Project Items, functional areas, etc. (e.g., system interfaces, security tests), describe how to verify it (e.g., parallel run, specific business rule testing). Add more details in the form of test cases as needed. Review the tests with the accepting team. | Test Manager |
| 6 | Map tests to requirements and deliverables. Create a mapping of tests to the project’s requirements, to help determine if the requirements have been met. Examples of a Traceability Matrix [docx]. For projects with multiple tests for deliverables, create a mapping of tests to the Project Items to help determine if every item being deployed to production has been adequately tested. Group and prioritize the tests based on the risk levels of the deliverables they verify. In general, tests for high-risk items should have a higher priority. |
Test Manager |
| 7 | Plan the test environment. Determine what’s needed in the environment to do these tests (e.g., specific server types, copy of production data, DMS II databases, etc.). Document any environment-dependent changes which need to be made for testing (e.g., hard-coded email addresses or test servers). See the Test Environment section of the Test Planning Checklist [docx] for more details. | Test Manager |
| 8 | Plan the test processes. Decide how (and by whom) defects will be captured, prioritized, and tracked (e.g., in the project tracking database, or in a separate bug tracking database like RT or TestTrack); decide what to do with outstanding bugs at the end of the project. Decide how (and by whom) tests will be run and tracked. Decide how (and by whom) the test environments will be managed, and how production changes will be incorporated into the test environment. Decide how any changes to project scope will be managed. | Test Manager |
| 9 | Run the tests. Execute the tests planned in step 5. Several iterations of testing should be expected as defects are found, resolved, and retested, and as each subsequent testing phase is started (Integration, System, Alpha, Beta, Pilot, etc.). | Tester |
| 10 | Track the tests and test results. Keep track of what tests have been run and whether they were successful; Use the mapping from step 6 to keep track of the requirements and Project Items, and their test coverage. Keep track of defects found and resolved. | Test Manager |
| 11 | Summarize the testing. Prepare a summary of the test results (pass/fail) and outstanding issues. The unresolved defects should be included in the the Project Closure Report. | Project Manager / Test Manager |
| 12 | Create a test repository. If a test repository for the product does not exist, create one. Make any corrections needed, then package and store tests and data that can be reused for future regression testing in the repository. | Tester |
Training Plan
The Training Plan describes the approach, activities and tasks required by the organization to ensure the necessary skills are attained to achieve the outcome of the project. It also outlines the timeline by which training will be delivered.
Process
The training activities should be planned during the planning phase of the project, and the tasks should be incorporated into the project plan.
Activities
- Conduct a skills assessment
- Develop the training plan (define course curriculum / training materials, etc)
Once the training program has been developed, it should be presented to a test group to determine if it is appropriate for the intended audience.
Activities
- Refine course / training materials
- Schedule and deliver training
- Review feedback
- Schedule training as close to implementation as possible.
- Develop the training program to provide the trainees with knowledge and skills required to perform their duties.
- Include a process to ensure future employees receive training.