The Postimplementation Review

The postimplementation review is a team-driven process that reviews the key project deliverables and the development process, and assesses how well the business case was delivered.

Again, eXtreme project management has a different approach to these reviews than traditional project management, as shown in Figure 18.1.

Figure 18.1. Postimplementation review

The postimplementation review is a vital component in eXtreme project management, as it is the basis of measuring success, updating and reviewing the project metric database, and providing you and your team with a vital feedback mechanism for personal and organizational satisfaction. As discussed in Chapter 9, the postimplementation review also marks the beginning of benefits realization and value analysis.

The Postimplementation Review Focus

Many experienced project managers have experienced traditional postimplementation reviews, in which the focus seemed to be who was to blame. These "witch hunts" are one of the most political and cynical of all organization practices and generally result in the victims (the project manager and the team) being blamed by the senior management, who are the most common cause of project failure (remember Chapter 2). No wonder few organizations have found the postimplementation review process to be an effective activity.

In eXtreme project management, the postimplementation review looks forward as well as backward: forward into the support process and benefits realization process and backward to the development process. It is critical that the postimplementation review be seen as a positive process designed to determine the following information:

• Did the project meet the agreed-on business case?

• What were the successful features of the project?

• What things could have been undertaken better?

• What are the key things learned from the project that can be applied to future projects?

• What do we have to do now to manage the support process?

• When do we start the benefits realization plan?

Figure 18.2 shows a typical postimplementation review form that captures the essential information.

Figure 18.2. Classic postimplementation review form

Don't Forget Your Sliders

As we discussed in Chapter 7, you must define project success using our slider tool before you start detailed planning (see Figure 18.3).

Figure 18.3. eXtreme success measurement

As the project changes throughout the development process, you will be maintaining the business case and, by default, the success sliders. Clearly, the final negotiated version of your sliders is the eXtreme project manager's measure of success during the postimplementation review.

The critical "on" criteria are the ones that must be focused on during the postimplementation review and, although all criteria are measured, only the "on" criteria are the true measure of success.

The Timing of Postimplementation Reviews

Traditional project management approaches included simplistic rules for the timing of postimplementation reviews, such as the postimplementation review will be undertaken after one month of production or 10 production runs of the system.

Our new approach to project management recognizes that the timing of postimplementation reviews is dependent on a complex relationship between the development strategies of the system or product and the production support activities during the initial operation of the system.

As we discussed earlier, once a system or product has been placed into production, the following production support activities would normally be required:

• Defect repair: The correction of errors in function, data, process, components , and documentation introduced during the development or support process.

• Performance tuning: The restructuring of data, functions, processes, or components to improve response times, execution efficiency, and so on.

• Consulting and education: The provision of advice, information, help, and consultancy to clients on use of the new system.

• Adaptive maintenance: The expansion of variable lengths, adjustment of mathematical values, cosmetic changes to reports , and screen layouts not requiring new data. In other words, the adjustment of existing components rather than the addition of new components.

There are other production support activities that are covered in the next chapter.

As shown in Figure 18.4, experience has shown that in the immediate postimplementation phase, defect repair, consulting/education and performance tuning would rise and then fall over a period of time depending upon the size and quality of the delivered system. As the system stabilizes, adaptive maintenance would normally be the most common support activity with an on-going but predictable level of the other categories of support work.

Figure 18.4. Postimplementation profile

Clearly, any postimplementation review conducted at the peak of the postimplementation stabilization activities would result in distorted feedback as business users would still be having trouble with the system. In addition, a key set of data that should be input to the review is the quality of the delivered system or product. This won't be known clearly until the system has stabilized.

In other words, the timing of the postimplementation review is driven by the quality of the system, not the clock.

Try to Keep Your Team Together

There will be pressure to let your team members move onto new projects as soon as you ship. At least try to keep the key members of your team together through the stabilization phase. If they leave, they will be called back consistently to assist anyway. Worse, they don't get to be involved in the learning loop and other feedback processes.

This means that it is critical that you and your team remain involved with the project and the system until the stabilization point shown in Figure 18.4. It also means that you must ensure that tracking of the occurrence and cost of the four categories of support work is rigorously undertaken (this will require team members, the data center, and any help desk function to be coordinated).

Particularly important is the recording of the numerous phone calls that the team will receive from clients and other stakeholders. Although production defects will normally be recorded by data center people, the recording of phone calls is vital (our research has shown that client phone calls can consume 50% of the postproduction support effort). The form shown in Figure 18.5 should be copied and available on the desk of all team members involved in supporting the new system.

Figure 18.5. Phone log (the missing link)

This requires significant discipline and it is the responsibility of all team members to complete this form every time they receive a query regarding the system.

During the postimplementation review, you would also update and finalize the project metric database that you should have been monitoring during the development process.