The Project Management Institute (PMI) encourages its members to advance the profession. One of the ways to do this is by helping others increase their project management skills. The target audiences for this blog are professional PM’s early in their careers as well as those who manage projects but are not PM’s by title or trade. I will be posting every week or so, offering practical tips and tools on the full range of project management topics. I hope you will find this useful and help you advance your career.
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):
- 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)
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 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)
The Test Plan applies primarily to projects that include new and changed software and/or business processes. Doing this planning in advance is key to meeting the target schedule as testing is typically the most time consuming portion of a project. Unfortunately, when many projects are in schedule trouble, testing is usually the first target for cutting the planned effort. Having a solid Test Plan will help mitigate that risk.
There are multiple aspects to the test plan:
Determine the Test Plan Objectives
- To identify the activities required to prepare for and conduct testing
- To define the test scope, strategy and methodology to be used for the test
- To define financial control tests (if applicable)
- To identify configuration controls and metrics
- To define metrics and status reporting
- To identify responsibilities for the tasks included in the plan
- To define the test tools and the environment needed to conduct the test
- To identify test interactions with other organizations
- To identify test customers and deliverables
- To identify the major testing milestones
- To define the sources of information used to prepare the plan
Define the Test Approach:
Give a high-level description of the approach and activities to be followed in testing the solution. If you are using Agile methods, this is where you will plan the release/test cycles.
Identify the Major Test Responsibilities:
Identify teams and individuals who will be managing and executing the tests. It should also specify their responsibilities.
The Features and Functionality to Test:
This is a high-level description (not the detailed test cases). You should consider the following:
- Specific features to be tested
- The types of error testing to be performed
- The types of stress/load testing to be performed
- The type of usability testing to be performed
- The type of reliability testing to be performed
- The type of recovery testing to be performed
- The type of compatibility/migration testing to be performed
- The type of security testing to be performed
- The types of software and hardware to be employed if testing is to be performed over multiple software and hardware configurations (configuration testing)
Document your thoughts on the test process:
You should consider the following:
- How you will define the acceptance criteria
- Deliverables – materials that must be made available or created in order to conduct the tests and that will be developed from the tests to describe the test results.
- Test Documentation – itemize the documentation you will require in regards to recording the test procedures and results.
- Test Data – Where will it come from? How will it be created? Are regular refreshes needed?
- Support Organizations – identify all interfacing organizations (Technology Services, Vendors, etc) that are needed to support the testing. Describe what will be needed.
- Test Setup, Procedures and Walk-thru – general description of the steps the test will go thru to ensure quality tests.
- Tracking and Reporting Status – Define the information test team members will communicate during the testing process. This should include the bug reporting tools and methods as well as a bug classification strategy
Change reinforcement is, in my experience, the most neglected aspect of Change Management. Usually after a project is successfully implemented, the project team “high fives”, celebrates success and then moves on to the next project. A year later, when it is discovered people are not following processes and policies or not using a system as it was intended, management will scratch their heads and wonder “where did we go wrong?”.
The answer to that is that no one was monitoring the change and reinforcing it as a part of a continuing activity both during and after the project. It is the Project Manager’s responsibility to ensure that a Change Reinforcement Plan is in place with defined roles, responsibilities and processes.
Reinforcing change includes assessing the results of change management activities, conducting compliance audits and implementing corrective action. Plan to actively seek out and celebrate early successes. Transfer ownership from the change management team to the Sponsoring Organization. The Organization assumes the role of reinforcing change and rewarding ongoing performance.
Understanding how the people are embracing the change and the effect on the results of the project will be addressed during project close and audit phases of the project. During the project you may want to build in activities to assess the effectiveness of your change management, communication and training plans. This can include:
- Surveys or employee feedback on their understanding of the change, desire to change, knowledge acquisition, skills assessment, and the employees perception
- Testing to ensure employees understand the new systems and processes
- Use of metrics. Several metrics can be put in place post implementation to measure if the people change efforts were successful. These may include: System usage, performance reports, how often is the “old way of doing things” still used.
Based on these forms of evaluation of the effectiveness of the change strategies, modifications can be made to the plans. This may include: re-training, additional communication, one on one coaching, etc.
Managing Change includes the design of Organizational Change Management Plans and individual change management activities. This is the “what you are going to do” to manage the change. Here are the components of the plan to manage change:
Communication Plan – Communication is a key component of explaining what is changing and why to the organization. Be sure to include the “WIFM” (What’s in it for me?) message. These communications should promote awareness of the project, the timeline, and how the changes will impact each affected group.
Training Plan – This plan will not only focus on training for a new system but also new processes. It will provide the specifics of what is changing for each user group. Also, included in the training is reiteration of why we are embarking on the change initiative.
Coaching Plan – Your coaching plan defines how you will support managers and supervisors during the change and how they will interact with front-line employees. The objective is to fully enable these managers and supervisors to:
• Sponsor the change
• Support their employees during the change
• Support their employees in the new, changed environment
The steps to developing a coaching plan:
1. Enable supervisors and managers to be effective change management coaches
Prepare a change management program and deliver this program to supervisors. Several key areas should be addressed with supervisors:
• Why is supervisor involvement important in change management?
• How do I talk with my employees about change?
• How do I coach my group through a change?
• Identifying different ways that people deal with change and how to coach them through it.
• How do I coach individual employees through change?
• What are the expectations for coaching in this project (frequency, timelines, agendas, etc.)?
2. Develop group coaching activities and timeline
Supervisors should prepare for and meet with their groups to discuss the change. Key messages should be provided by the change management team.
Group coaching during a change is an effective medium for distributing information and gathering feedback. It can help to build support for change and ease concern and resistance.
3. Develop individual coaching activities and timeline
Individual coaching sessions are one-on-one opportunities for supervisors and managers to work on change with specific employees. The face-to-face messages received are important as employees work through the change and try to perform in the changed environment. You should develop a matrix with the following components: Coaching Activity, Purpose, Timing, and Audience.
Workforce Transition Plan – A Workforce Transition Plan is a detailed plan to address changes in roles, responsibilities and organization structure. You need to plan how individuals will transition as a result of change and ensure they are transitioned according to organizational values and policies. You should develop a matrix with the following components: Individual or Group, Supervisor, Describe the transition, New Skills Required, Resolution, Communication Needs, Comments.
Resistance Management Plan – A resistance management plan is a proactive approach to managing resistance. During the assessment you identified potential resistance points. As your project implementation progresses, additional areas of resistance may surface. Below are action steps to creating your resistance management plan and the template:
1. Review areas of resistance from the assessment and define what resistance may look like for your change and how it may be identified.
o Brainstorm with the change management team and project team
o Brainstorm with the stakeholders and sponsors
2. For each level with the impacted organization, define a strategy for managing resistance to the change.
o Brainstorm strategies to address the key areas of resistance. This may be changes in functionality, new skills required or certain departments that may be resistant to the change. Some examples of possible strategies include:
• Communication about why we are making the change, benefits to the organization, and WIFM (What’s in it for me)
• Training or job aids to assist in the transition
• Pairing up certain areas of the organization that will be the most affected by the change with positive change agents or project team members
• Engage with managers, supervisors and coaches to help these individuals along in the change
Plan preparation includes activities to prepare yourself and the team for managing the change and the creation of the change management strategy. This allows the team to understand the magnitude of the change and potential resistance from the organization.
Defining the Scope of the Change
Defining the scope of the project for change management purposes means answering the following questions:
- What are the changes that will occur as a result of this project?
- Who will be affected?
- What will be the magnitude of the change?
- How might the affected groups react when notified of this change? What will be their concerns?
Putting the answers in a spreadsheet will help the planning process.
Conduct an Organizational Assessment
You can assess the organizational readiness for change by finding the answers to the following questions:
- How resistant is the organization to the change associated with this project?
- What is the capacity for change within the organization? Is the organization already being required to make changes elsewhere? How much more change can the organization absorb?
- What is the history of similar projects/change within the organization? Did past projects/changes leave a residual effect that could either work in your favor or make the management more challenging?
- What is middle management’s predisposition to change? Is the management team behind the change effort? Are there any that are opposed?
- Anticipated Resistance – are particular departments, regions, etc. impacted differently than others? Were certain groups advocating a different solution? Are certain groups heavily invested with how things are done today?
In the next post I will address the components of “Managing Change” and the ADKAR change methodology.