The Project Plan Part 7: The Deployment Plan

Planning

The Deployment Plan describes the factors necessary for a smooth deployment and transition to ongoing operations. It encompasses the processes of preparing, installing, training, stabilizing, and transferring the solution to operations. For some projects, deployment can be very complex. For these types of projects it pays to start deployment planning as early as possible to manage the risk of delays due to deployment difficulties.

Here is a list of some things to consider for your deployment plan (this is not necessarily the complete list of considerations; your project may have more):

  • Scope
    • Stakeholders (those affected by the solution)
    • New and changed Business Processes
    • Licensing considerations
    • Approx. # components per platform
  • Deployment strategy & schedule (e.g. phased, site-by-site, push vs. pull, dept. by dept, etc)
  • Organizational Change Management
  • Implications of new and old system and processes in production at the same time
  • Deployment Resources
  • Help Desk Preparation
  • Desktops/Servers Affected
  • End User Training (High level business process and detail usage)
  • Installation Process
  • Installation Validation
  • Support during Stabilization
  • Hand-off to Support and Operations
  • Activation of Monitoring (for computer systems and business processes)
Advertisements

The Project Plan Part 6: The Pilot Plan

Planning

Some organizations define a solution “pilot” as a “limited deployment” for the purpose of managing risk. That can be covered in a Risk Management Plan in lieu of a Pilot Plan. The definition we will use in this post is to use a Pilot to gather information about the solution that can only be discovered by “going live”. The intent of the Pilot is to obtain the information and then pull the solution out of the live environment for additional work.

The Pilot Plan describes what aspect of the solution will be delivered as a pilot and provides the details necessary to conduct the pilot successfully. This includes details on how to evaluate the pilot, the results of which will facilitate a decision whether or not to move the solution to production. Projects often create one or more “pilot” solutions for the purpose of proving the feasibility of solution approaches, experimenting with different solutions, and obtaining user feedback and acceptance on proposed solutions. Pilot solutions usually implement only those subsets or segments of requirements or functional specifications necessary to validate a solution.

The Pilot Plan provides the means to validate business requirements and technical specifications prior to deploying the solution into production. Planning the details of the pilot ensures that the participating project teams identify their roles and responsibilities and resource requirements specific to pilot development, testing, and deployment activities.

A pilot can provide key information on development processes, end-user validation, and production environment usage. It also provides feedback to stakeholders regarding the success of the solution once it is formally released.

Here is a list of some things to consider documenting as part of the Pilot Plan (this is not necessarily the complete list of considerations; your project may have more):

  • Overview – Scope (what part of the solution will be demonstrated as part of the pilot, and the target user profile used to select which users will participate)
  • Success Criteria and Metrics – The success criteria may fall into the following categories:
    • System performance
    • Operations cost
    • Stability –down time
    • User performance
    • User satisfaction
    • Business goals
  • User Preparation and training
  • Marketing Plan – how users will become aware of the pilot and the value to them
  • Conditions for adding additional users
  • Rollback – conditions for rolling back the pilot to pre-deployment state
  • Pilot Evaluation – describes how the pilot results will be evaluated

The Project Plan Part 5: The Migration Plan

Planning

The Migration Plan describes the migration from existing systems or applications to the new solution. This plan is needed whenever you have to salvage anything (data, artifacts, physical objects, etc) from the old environment to the new one. In some projects this can be very challenging and the source of a lot of effort so plan early and carefully.

It is important to have an understanding from your sponsor of the Business Objectives driving the migration. Keep in mind each objective will have associated costs and risks. Examples of these are:

  • Minimize Business Disruption
  • Stay in full compliance with laws and regulations
  • Keep migration costs as low as possible
  • Choose acceptable alternatives that avoid risk to the target implementation date

Here is a list of some things to consider (this is not necessarily the complete list of considerations; your project may have more):

  • Migration Strategies (alternatives, including tools and implications for each)
  • Migration process (how, when and by whom the migration will be performed)
  • Test Environment (Setup, timing, hardware, people)
  • Preparation (Everything needed to be ready to execute the Migration Plan)
  • Decommissioning of replaced resources (timing, disposal)
  • Back-out plan (what to do if something goes wrong with the migration)