Deployment planning

the difference between technical success and business success

Abstract

You followed the Project Management Institute’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) to the letter. Your project met all the requirements, was completed on time, within budget, and was accepted by the customer, but was a business failure. What went wrong? The PMBOK® Guide doesn’t address a critical aspect of project management planning: deployment planning, which is planning for what needs to happen after the project is delivered. There is no question that the on-going support of the final product or service is the responsibility of the customer, but it is the responsibility of the project manager to ensure the support needs are identified and possibly initially funded by the project. Failing to have a deployment plan will result in change management issues at the project and corporate levels.

The Problem

The focus of project management is on the delivery of a product or service. Often, little thought is given to the care and feeding of the product or service after it has been delivered. The term “throwing it over the wall” is a phrase used to describe the deployment method used. Hopefully, this phrase is the exception rather than the rule; however, it is an accurate assessment that deployment planning is often overlooked as an integral part of the project planning process. Part of the reason for this is the concept that on-going support is the responsibility of the customer. Although this is true according to PMI methodology, this statement fails to recognize that the project manager is responsible for ensuring the support needs are identified and initially funded if needed.

How does the lack of deployment planning impact a project? Have you ever had a project that met all the requirements, was successfully released to the customer, yet never returned the intended value to the organization? The project was technically successful because it met all the requirements and was accepted by the customer, but still was a business failure. Some of the symptoms of the lack of deployment planning include:

  • Help desk swamped with calls on a newly deployed software solution
  • Help desk and support personnel are faced with issues that they are not properly trained to handle
  • Software that is successfully implemented and then degrades into misuse within a short period of time
  • Software that is misused because the users are trained by other users who are not trained themselves or were trained incorrectly
  • Documents are up-to-date the day the system is released and seldom if ever updated after
  • Databases are seldom or never updated because no one has taken the responsibility to keep the data current
  • Operational responsibility for a system falls to the IT department, because no one takes ownership of the system, which often results in an increased head count

All of these are symptoms of a lack of deployment planning—planning for what should happen after the project is delivered to the customer. Although the on-going care and feeding of the system are not the responsibilities of the project manager, it is the project manager’s responsibility to plan for how these should be accomplished. So, what areas should a deployment plan address?

The Solution

Formal Deployment Planning

Deployment planning should address:

  • Pre-release considerations
    • Assumptions, dependencies, constraints
    • Operational readiness
    • Data creation/conversion
  • Timing of release
  • Training
  • Accountability
  • Documentation
  • Transition to support
  • Notification of deployment
  • Operations and maintenance planning
  • Release planning

Tasks such as the Pre-release considerations and the Operations and Maintenance Planning are generally given fair consideration on most projects; however, there are three tasks that continually account for a large number of business failures: the timing of the release, training, and accountability. The details of this paper will focus on these three tasks.

Timing of the Release

As with all other tasks in a project, the how and when the product will be delivered should be identified within the project schedule. With this said, what should be taken into account to ensure a successful deployment process?

  • How and when of software release
    • A major software release may take months to fully deploy
    • How to handle the environment in which part of the organization is using the software and part is not
    • How to handle the situation in which part of the organization is on one release of a software package and the rest of the organization is on a different release
    • Is there a logical order for who should receive the software and when?

Training

Training is such an important aspect of a successful project that entire text books have been written to cover the subject; so, it cannot be adequately covered here. What will be covered are some of the tasks to be considered in building a successful deployment plan. In a deployment plan you need to consider both end-user training and the training of help desk and support personnel.

Some of the points to consider for end-user training should include both initial training and on-going training. Initial training is clearly part of a good project plan and should include considerations such as:

  • What format should be used for training (face to face, web conference, computer based training, etc.)?
  • What are the logistics of the training activities (who, when and where)?
  • Does the project schedule contain a realistic estimate for training?
  • Budget for the training should be considered as part of the project budget. Training is too important to simply assume it can be done at no cost

The problem with including training in the project budget baseline is that it often deals with an order of magnitude type budget estimate. It can be later in the project that training details are clarified and a more accurate budget is determined. For example, you can specify that the Eastern Region will be the first to be trained, but the specifics of how many people, where, how many sessions will be required, and other such variables will affect budget estimates.

On-going training is clearly part of operational responsibility. Nevertheless, to ensure the long-term success of the project, planning for on-going training should be part of a project plan; in other words, to ensure the business success of the product, on-going training is necessary. On-going training should include considerations such as:

  • How will the new user be trained?
  • Who will be responsible for on-going training?
  • Who will be responsible for training the trainers?
  • What format should be used for on-going training?
    • Power users
    • Web-based training
    • Monthly web cast

On-demand training and help/job aids are less of a planning activity than a system design and specifications activity. They are, however, an extremely important feature in the long-term success of a product and need to be included as part of the project plan. Some of the considerations for on-demand training and help/job aids are:

  • If the system is custom built, are on-demand training and help aids parts of the system specifications?
  • Do the project schedule and budget reflect the inclusion of on-demand training and help/job aids?
  • If a system is purchased, are on-demand training and help/job aids parts of the RFP or RFQ and final contract?

The training of help desk and support personnel is one of the activities that is often rushed at the end of the project schedule and, in some cases, it is forgotten altogether. It is often considered a minor activity in the release of a product or service, which is a major oversight. Help desk and support personnel should be included early in the project and their ideas incorporated into the overall planning process.

Accountability

On-going support is the responsibility of the customer. So, ensuring that it will be carried out correctly is a major consideration in the project plan. Who will authorize any changes to the system after the project is closed? This responsibility should be assigned to a person within an organization who can and is willing to make decisions about the on-going care and feeding of the system. Without this, IT is often put into the position of making decisions (owning) about the systems. The project manager should make sure that the owning organization understands what their responsibilities are and is willing to except those responsibilities. These responsibilities include:

  • Decisions on changes and enhancements to the system
  • Document update responsibilities
    • Document input and retrieval protocols (metadata standards)
    • Document retention standards
    • Document ownership and security responsibilities
  • Data update responsibilities
    • Who owns the data and is responsible for authorizing changes?

In Summary

At the technical level, project management considers scope, schedule, and budget; at the business level, project management should consider the value added to the organization. Granted, a good project plan will contain many of the issues mentioned in the presentation. The point is that deployment of the system is too important to be left to chance and must be considered as part of the project planning process. There is value in giving this deployment process a formal name and defining a set of disciplines to ensure that it is completed, along with the other project management processes.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2010, John Schmitt, Mike Anderson
Originally published as a part of 2010 PMI Global Congress Proceedings – Washington, DC

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.