Section 11.4. Preparing for Implementation, Deployment, and Operational Transfer

11.4. Preparing for Implementation, Deployment, and Operational Transfer

Your project is coming down the home stretch. Deliverables are coming out on schedule, results are being tested and verified and everything looks good. A few pieces of rework here and there, a couple of tweaks to the schedule and you can see the home stretch in front of you. Now what?

One of the areas that some IT project managers overlook at this point are the connections to external plans such as implementation, deployment, or operational transfer. Depending on the nature of your project, you will have to contend with one or more of these types of plans. As with testing, these plans are sometimes discrete phases of your IT project plan and other times they are external plans tied to your IT project. If they're internal, you're far more likely to manage them in terms of updating the schedule and communicating key data such as delays, changes, or requirements. When they're external, these same elements can cause major issues. It's important that throughout your project you place milestones to remind you and the project team to update or communicate information regarding these additional plans.

11.4.1. Implementation

In some IT projects, implementation is a phase of the IT project that describes how the project's deliverables will be implemented (this is sometimes the same as a deployment plan, depending on the IT project). This might describe a phased approach or an "all or nothing" approach. The implementation plan may be discrete tasks within the project plan that follow testing tasks. If a separate implementation plan exists, you should have milestones within your IT project plan indicating points at which you need to communicate about the implementation or points at which you need input from the implementation team. Many IT project managers are good about keeping an eye on implementation because that's essentially where project success is defined. However, it's easy to let critical information or important changes slip through the communication cracks when it comes to implementation. A flawless implementation can greatly increase the perception of project success, so it's important that your management activities during this phase address implementation. In some cases, management or oversight of the implementation phase can be delegated to a team member. Make sure your implementation plan includes plans for a rollback in case things go wrong. A clear roadmap for rolling back the implementation will help keep people cool, calm, and collected if the going gets rough during implementation.

Cheat Sheet…
Delegating Project Management Tasks

During the work phase of the project, you're mostly likely going to have your hands full just keeping track of the issues and changes in the project and managing the critical path tasks. Rather than taking on the world, you can delegate portions of the management task to others. If you recall from our discussion earlier in the book on managing high performance teams, many people on a team find satisfaction in gaining new experiences or skills, while others enjoy additional responsibility and authority. Delegating management of these end phases such as implementation, deployment, or operational transfer, whether they're part of your formal IT project plan or part of external plans, can be just the opportunity junior team members are looking for. Finding members of your project team that would enjoy the tasks associated with managing these sub-plans can provide a coveted opportunity for a team member while at the same time offloading some of your management tasks. It's a win-win situation that can help build project management skills in your IT department. Word to the wisedelegating means handing over responsibility and authority, but it doesn't mean handing it off and never thinking about it again. Allow others to do the job while you check on progress occasionally and provide support and assistance as needed.

11.4.2. Deployment

A deployment plan describes how the hardware or software will be installed, tested, and turned over. This may be the same as an implementation plan in some projects. In other projects, a deployment team is responsible for product deployment, whether internally or externally. As with an implementation plan, the deployment plan should be kept up to date with the IT project plan so that changes are reflected in these plans. It's not uncommon for a change to be made (especially during the testing phase) that requires a change or update to the deployment plan. If this is not properly communicated, the deployment team will be unable to start or complete the deployment in a timely and satisfactory manner. As with your implementation plan, your deployment plan should include a discussion of potential risk as well as related contingency plans. A rollback plan should be included in case deployment goes terribly wrong. In that case, the deployment team should have a clear cut plan for rolling back to the last known good state.

Enterprise 128 …
Don't Just Lob It Over the Fence

Sometimes an IT project team can be so exhilarated to complete a project and so exhausted by the process that they almost lob it over the fence to the deployment team, which can cause all kinds of problems. A software development company (whose name is not used to protect both the guilty and the innocent) was working on a major product release. When the code was complete and sent for integration and regression testing to the test engineers, all the developers rejoiced and decided it was a great time to take a break from all their hard work. Friday noon rolled around and most of the senior developers packed up in a few vehicles and took off for parts unknown for a no-e-mail, no-cell phone camping trip…. The only problem was that critical changes required for this customer installation were not included in the final released code. That meant the deployment team would be unable to install the released code on the customer's machines. The deployment team discovered this as they began to create their installation disks for the customer, around 1:00 P.M. that Friday. With most of the developers gone, the deployment team had to scramble. They pulled together a few of the software engineers who'd not gone camping along with one of the senior testers. They cobbled together an installation CD that would work so the deployment team could jump on an airplane Sunday afternoon. It took all Friday night, all Saturday and part of Sunday morning to fix the problems, but the deployment team's dedication to making this beta deployment a success made all the difference. Ultimately, the deployment team had to perform some tricky on-site changes and install an overlay to the code to get everything set for the customer.

Lesson Learned: Don't assume because tasks or code is complete that everything is just fine. Make sure that your implementation or deployment teams have what they need to get the job done. After all, the project isn't complete until the user has signed off on it and implementation or deployment is that critical link between code complete and a satisfied user.

11.4.3. Operational Transfer

Operational transfer is the process of handing off the project's deliverables to the user on a permanent basis (sometimes referred to as project cut over). It assumes that the implementation or deployment has been successful and that you and the IT project team are ready to pass ongoing management of the project's deliverables to another team or to the user/customer.

The operational transfer plan is a document that describes how the deliverables of the project will be integrated and managed. The goal is to have a smooth, seamless transfer of the project's deliverable to the permanent team that has responsibility for this on an ongoing basis. It is used to help define the people and processes needed in the functional arena to ensure success. Remember that how well the project is handed off is a large part of user and stakeholder perception about the success of the project, so mistakes here will impact the perception of success even if the project meets or exceeds all other expectations.

An operational transfer plan should include:

• Tasks to hand off the project's deliverables

• The strategy to be used during handoff

• The key resources needed

• Task owners

• Timing of transfer tasks

• Cost of transfer tasks

• Schedule for transfer

• Risks and contingency plans for risk

• Formal acceptance of handoff by customer/client/user

If this list looks familiar, that's good. It is a scaled down version of a project plan. In fact, you could use the entire IT project management methodology described in this book to create an optimized operational transfer plan. Though many organizations do not do so, there are clear benefits to stepping back and starting at the beginning. What is the problem to be solved? What is the mission or objective? What are the potential solutions? What are the criteria for selecting the best solution? If you step through the IT project methodology we've discussed, you'll find that you have a clear, concise, and easy-to-manage operational transfer plan. Many IT project managers avoid going through the same IT project management process described in this book for any number of reasons. However, doing so will yield far better results for your IT project and for the users/customers to whom control is ultimately transferred.

In order to develop an effective operational transfer plan (which often can be done in parallel with later stage project work tasks), you should follow several key steps, listed here.

1. Identify and involve key functional and process owners to help define the plan.

2. Perform a needs analysis to determine the needs for both an operational plan and long-term, ongoing operation of project deliverables.

3. Define requirements for final operational test and for trigger points for transfer.

4. Prepare for transfer of all relevant IT project assets. This might include source code, installers, system configuration, and documentation. Ensure all relevant documentation is accurate and current.

5. Where intellectual property is concerned, ensure that ownership of property rights is clearly determined and agreed to. For example, does the copyright transfer to the owner or remain with your company?

6. Determine support that will be required after transfer. Clearly list responsibilities for ongoing supportwho is responsible for the activities and costs of on-going support?

7. Determine the logistics of the actual operational transfer.

8. Determine changes to user/stakeholder processes and procedures created by this operational transfer and modify processes/procedures as needed.

9. Understand risks to operational transfer and develop contingency plans.

10. Tie your operational transfer plans to training plans, support documentation, release notes, and Service Level Agreements (SLAs) where appropriate.

11. Create a handoff checklist with roles and responsibilities clearly delineated to avoid gaps.

12. Keep your operational transfer plan updated and include milestones that tie into the IT project plan so both plans are kept up to date and in sync.

Operational transfer is an area where many IT projects fall on their faces, which is unfortunate because it's a huge opportunity for success. A smooth transition can improve your project success rate tremendously, so make sure your IT project plan includes an operational transfer component. You may choose to create a separate operational transfer plan and tie it to your IT project. The time and effort you spend creating this transfer plan will help in terms of fewer customer complaints, higher user satisfaction, and a higher overall perception of the project's deliverables.