A new post will be published June 1.
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 by Identifying…
- …the activities required to prepare for and conduct testing
- …the test scope, strategy and methodology to be used for the test
- …the financial control tests (if applicable)
- … the configuration controls and metrics
- … the metrics and status reporting
- … responsibilities for the tasks included in the plan
- … test tools and the environment needed to conduct the test
- … test interactions with other organizations
- … test customers and deliverables
- … the major testing milestones
- … 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.