CHAPTER 8
Transition Planning
In general, after IT systems are developed (or purchased) and deployed to meet the business’s needs, they must be maintained in order to ensure continued benefits. A typical development approach is to set up a project team to transform business requirements into a system solution. Then the project team disbands and a maintenance team takes over to ensure that the system continues to deliver the expected business value.
For you hard-core project managers, transition planning will offer you an opportunity to perform some real project management. A transition plan for new systems moving into maintenance has a definite scope, is unique, and has a start day and an end day. Thus, a transition plan meets the definition of a real project, but you can think of it as a mini-project. If you are not a hard-core project manager, consider this step another planning activity that you will want to do correctly.
The transition plan should outline the approach to moving the ownership of the project team’s products, support material, and knowledge—as well as accountability for the system—to the maintenance team. The deliverable of this plan is a maintenance team that is already both effectively and efficiently maintaining the system for the business according to the specifications in the SLA. The goal is to make the maintenance team as effective as possible as soon as possible.
The remainder of this chapter consists of two sections. The first section, “Transition to Existing Maintenance Team,” assumes that the maintenance team already exists and is maintaining other systems. The transition plan consists of the steps both the maintenance team and project team must complete in order to transfer responsibilities.
The second section, “Create New Maintenance Team as Part of the Transition,” assumes there is no maintenance team in existence that can accept the maintenance responsibilities and that the development team project manager will have to both form a new team and transfer the appropriate project team products, support materials, and knowledge to the new team.
Both sections contain an explanation of what needs to be accomplished and suggestions of tasks to include in the transition plan. The sections are not in a project plan format that shows dependencies and start/end dates. They present tasks for you to consider for inclusion in your plan that may also prompt you to think of others that you will need to include for your specific situation. Each transition situation is different, so a one-size-fits-all plan will not work.
Transition to Existing Maintenance Team
This section covers planning for the transfer of the maintenance of a new system from the current development project team to an existing maintenance team. The transition involves two parties.
Since there are two parties involved that have different objectives, conflict will most likely arise. The project manager wants to complete the project quickly. He will have his resources focused on a successful deployment and will not want maintenance items getting in the way. The maintenance manager, on the other hand, will focus on transitioning project team products, support materials, and knowledge, and wants the project team to complete any outstanding documents. She will know that time is running out. If the project team doesn’t finish the transfer before the project ends, the project team will disband without completing the transfer. This would force the maintenance team to develop its own support material and learn through trial and error.
The transition plan will serve as a contract between the project team and the maintenance team. Creating this plan early in the development project’s life cycle, with both parties signing off on its contents, will set expectations, decrease misunderstandings, and improve the chances that all transition tasks will be complete by the time the project is disbanded. The maintenance manager can’t assume that the project team’s project plan will address all the expectations, because she will not have control over project plan changes.
The transition plan will be a contract between the two teams. The plan establishes a common goal, spelling out all of the expectations about who will perform specific tasks in order to ensure a smooth, timely, and complete transition that minimizes total cost and risk to your company. Each team member should actively pursue accomplishing this goal. When conflicts arise over the interpretation of the transition plan, the mutual desire to attain this goal should serve as the basis for negotiating an acceptable solution.
Figure 8-1 shows the three phases of a transition plan for a system being implemented by a project team. The transition is to the existing maintenance team. The columns of the plan show the separate tasks of the two parties. The rows map into the project team’s project phases.
Phase 1 encompasses all the activities up to the first production deployment. Phase 2 begins when the first deployment takes place and includes any additional production deployments and initial system support that the project team must perform. Phase 3 is the closing down of transfer activities. It focuses primarily on the maintenance team’s sign-off on the transition, which confirms that the transfer is complete and that all maintenance activities are now owned by it. Phase 3 can be thought of as a milestone rather than a series of tasks. The majority of tasks should be complete in Phase 2.
Figure 8-1: Existing Team Transition
In Phase 1, the project team is busy, but the workload should be manageable if it is planned appropriately. This is the time for the maintenance team to learn as much as it can about the new system. It should participate in development where appropriate and execute test scripts, which will help the team learn the functionality of the new system and will help the project team complete some of its tasks.
The maintenance team should attend vendor training when it is offered and appropriate. Most important, it should review the documents to be used for maintaining the system and should ask any questions it may have. These questions may indeed be needed for improvement of the quality of the documents. Phase 1 will be the only time when there will be an opportunity for the project team to make document improvements; once the project team enters Phase 2, it will be too busy deploying and initially supporting the system, and it should thus not be distracted with document changes.
Also in Phase 1, the SLA should be developed, presented to the business customer, and approved. Who develops the SLA? There is no set answer. Who does it will have to be decided by the project team and the maintenance team. For purposes of illustration in this section, we assume that the project team will draft the SLA and that the maintenance team will review it.
What documents should be reviewed and transferred? The next chapter, Chapter 9, “Documentation,” describes the following five critical documents that a maintenance team needs to develop for its support of a system:
• Maintenance Manual
• Operations Guide
• Design Document
• Business Process
• System Notebook (may only be in initial development state)
You should take advantage of the fact that the project team is still in place and obtain more documents from it, if they exist. Some project documents will have little value, such as the original project charter. But others will be of interest, including:
• Original Requirements List
• Functional Design
• Statement of Work for any vendors
Either in Phase 1 or Phase 2, any maintenance team budget changes will need to be addressed. It is also possible that changes to the chart of accounts for tracking team members’ time will be needed. Also, any licensing or vendor maintenance invoice payments will have to be transferred. Tools (spreadsheets) and reports for managing the financials will also need to be developed or modified.
In Phase 2, the project team will kick into high gear with the first deployment of the system. Do not anticipate, therefore, that the project team will have any time to dedicate to helping the maintenance team learn the new system. The maintenance team at this point is not responsible for the support of the newly deployed system. It can, however, assist the project team in providing that service. In doing this, the maintenance team will gain valuable experience that will help it perform its functions when it eventually takes over responsibility for the system. During this phase, any training that the project team can deliver to the maintenance team should be informal and secondary to production issues.
Besides planning all the tasks to be accomplished, you will need to define the exit criteria that signify that the final turnover has occurred. It is reasonable to expect that the project team would reach a certain level of quality in production before it disbands. The exit criteria specify the conditions under which the maintenance team will take over responsibility for the system. The criteria can include:
• Specified period of production time reached without incident.
• Specified maximum number of issues open at turnover.
• Specified maximum number of critical defects open at turnover. A critical defect can be defined as a feature of the system that is not usable or that exhibits performance below expectations.
Phase 3 marks the completed transfer, after sign-off by the maintenance team. The sign-off is an important item. The maintenance team can have some leverage on the project team by withholding sign-off, but the reality is that when the project team starts disbanding because of its lack of a budget, the maintenance team will own the system even without the sign-off. The tenacity of the maintenance manager is needed throughout Phase 1 and Phase 2 for all the transition criteria to be completed in Phase 3.
You can see the advantage of having the maintenance team engaged early in the development of the new system. Figure 8-2 shows recommended tightly coupled transition touch points throughout the developments project’s life cycle. The figure assumes that a maintenance team already supports a system similar to the one the project will deliver. Many opportunities for gaining information would be lost if the maintenance team started to engage in transition activities only at Phase 3. Unfortunately, this situation does occur when the process of planning has been poor.
When the transition plan incorporates all the agreed-upon activities, deliverables, and exit criteria, both parties will sign it.
Create New Maintenance Team as Part of Transition
This section covers planning for the creation of a new maintenance team that will assume responsibility for the maintenance of a new system after its deployment. Even though there are more steps involved in setting up a new maintenance team than transitioning to an existing team, this type of transition can be a simpler process overall, because only one party (the development project manager) is driving the effort. Also, in some situations, members of the project team may be transferred to the new maintenance team, so knowledge transfer can be simpler and the productivity of such individuals should be high from the start.
Figure 8-3 shows the groupings of tasks and the tasks themselves. Some of these tasks are addressed in greater detail in other chapters of this book.
Figure 8-3: New Team Transition
The transition plan should start by reviewing the system components to be delivered and the external licenses and contracts that will continue. Then the SLA should be developed, presented to the business customer, and approved.
Next, it’s time to start staffing the maintenance team. To do this, the number of team members and their skill sets will have to be determined. Chapter 7, “Cost Estimate,” provides information that can be helpful. From the cost estimate, the job descriptions and a final organization chart can be derived. A coverage matrix can map the team members to the components they will support. See Chapter 10, “Team Management,” for examples of a coverage matrix and skills matrix.
The final task for staffing will be to obtain staff through your company’s normal process. This task could include transferring people from the project or elsewhere in the company, hiring new employees, or obtaining contractors. Hardware requirements such as PCs, phones, and pagers will need to be addressed for any new employee. With the team members in place, knowledge transfer can begin. Develop the expectations and then set the approach and schedule to meet those expectations. With the skills matrix from the previous step, any skill gaps can be determined, and individual learning plans can be created to fill those gaps.
The previous section, “Transition to Existing Maintenance Team,” already covered the types of documents that will be needed, so we will not repeat that information here. Document production is the responsibility of the project team.
Management processes will need to be created for the smooth operation of the team. Given the time it will take to set up the team, some of these processes may have to be developed well after the team is operational. Other processes will need to be established, such as setting up time tracking for team members, metrics, and a work-tracking tool.
Remember, the transition plan should have a clear completion date that represents when the maintenance team is fully up and running. An assessment of the current state of maintenance on that date should be communicated to the stakeholders. Improvements can be made after that point. After the transition to the maintenance team takes place and the transition is verified as completed, the maintenance team then owns all operations.