Plan for the End Game

All too often project managers fail to plan adequately for the end of the project. Not planning for what happens when a product is released leads to problems and makes a successfully developed product look as though it is a failure. Worse, it puts business continuity and customer confidence at risk.

While IT applications are one example, the same principle applies to any product. When the product is a commercial product, consider the needs of the sales force in addition to the users, trainers, and support staff.

Change is Unpredictable

The main principle is that the implementation of a product is a change event, and that change is predictably unpredictable. When a new product is implemented and deployed it impacts its users and support staff. The first users of the product will have questions. Users will report errors. The questions must be addressed, and the reported errors investigated, responded to with work around solutions, or other information. If there are product defects, they must be addressed. Defects may be in the core product itself or in its documentation or training materials (which are part of the product).

When rolling out computer applications, the concept of hyper-care is applied. Hyper-care recognizes that any time a new application or major change is released, there is need to plan for a high incidence of support requirements. Support will be needed by the users and also by the normal support staff. The product is new to both of them. The users will turn to the customer support staff for support, and the support staff will turn to technical support. Technical support, if they are not the developers, will turn the developers, who may be busy developing other products.

Planning Requires Consideration

Addressing deployment issues requires clever planning. Clever planning takes managing the end game into consideration and allocates the time, resources, and money to make the new product release a success. This seems so obvious that writing about it seems unnecessary; yet, I have run across a number of recent incidents in which experienced project managers and their managers and clients have found themselves in unfortunate situations. They failed to plan adequately for hyper-care and have failed to adequately prepare users and support staff.

In one case, a firm contracted an organization to develop a product but left out of the contract any mention of knowledge transfer to the in-house IT staff that would support the product. The vendor’s staff was to be finished with their work upon acceptance of the product. Acceptance of the product was achieved when the product testing was completed. Full deployment of the product was planned for a fixed date that kept getting closer as the testing progressed.

Related Article: Agile Chartering: Beginning With the End in Mind

The outcome was that the in-house IT team had to scramble to learn the product, without formal support from the vendor. They needed to be able to address bugs and answer questions and issues that the customer support help desk staff could not answer. Since there was little training for the customer support staff, there were many such questions and issues. Customer support was also supporting other products and became overwhelmed with calls. To make things worse, the in-house technicians were scheduled to work on other “priority” projects and had no time formally allocated to the “hyper-care” activity. This, of course, led to high-pressure and a choice between delaying the other projects (even with overtime work) and not supporting the new product. With high-pressure came stress and that resulted in arguments, finger pointing, and dissatisfied users.

This scenario is not limited to vendor based engagements. The same thing happens when the product is developed in-house, and there is poor end game planning.
The cause of this scenario was short-sightedness. Project managers that focus on the development of the product and fail to consider how that product will be deployed and supported are not addressing the entire project. This is often the case because the project manager is a technical person who is expecting someone else to take care of things once the product is delivered. There is a hand-off implied. Development is complete; deployment is someone else’s job

If there is someone else accountable to hand the product over to, then they will make sure that users are trained, and customer support staff is adequately prepared. They will make sure that the end game is part of the overall project plan.

But who will make sure that the developers pass on their in-depth technical knowledge of the product to the technical team that will maintain it and troubleshoot? Even if the development team retains the technical support role, will they have the time to do it or will they be thrashing between new development and technical support activities, particularly during the early life of a product? Will the technical knowledge holders be there forever? Will technical product development people be motivated and capable of transferring their knowledge or will they need an intermediary to debrief them and pass the knowledge on in a structured training? Will there be a clear understanding of the need for support and the number of hours it might require by customer support and technical support people?

Don’t Be Shortsighted – Plan for the End

Don’t be shortsighted. These and other questions should be asked and answered when initially planning the project. The hyper-care effort, documentation, training, and knowledge transfer are part of the project, not something that gets dumped on the business and operational groups that support the product.

End game planning requires that the following are addressed and included in the project plan:

• Formal allocation of “level 3” support by the development team to the technical support team
• Formal allocation of “level 2” support by the technical support team to the customer support team
• Formal allocation of additional “level 1” customer support staff for the hyper-care period
• Structured training to transfer knowledge to technical support, training and customer support teams
• Technical and user documentation that reflects the true nature of the product
• Structured training for the users
• Pilot rollouts to make sure that the product and its training and support work in the real world
• A contingency plan for the possibility that the product fails to perform adequately and must be pulled from production
• Expectation management to prepare everyone for the real world of implementing a new product. No matter how well people have been trained and how well the product has been tested, there will be bugs, problems, and misunderstandings, all of which can be handled if you are ready for them.