Post-mortem Review

Regardless of the outcome of the project, hold a "post-mortem" review with the project team, with the goal of identifying both effective and ineffective practices, together with potential remedies where possible. Lessons from the review are useful to all team members for future projects. Since most CRM projects occur in phases it's quite likely that a similar team or subteam will get to work almost immediately on phase two, so the review will be immediately useful.

For large teams , conduct the review in stages, with each specialty team holding its own review before bringing it to the full project team, although you need to bring at least the key players together to complete a proper review. Schedule it for a few weeks after deployment so there's enough time to experience the production system, but not so far down the line that events are no longer fresh in people's memories.

Two opposite problems to avoid during a review are too much pussyfooting, where no one dares to be frank for fear of offending others and, on the other hand, aggressive attacks on other team members with a design to assign blame to others while shielding oneself. By this stage in the project, it should be easy for the project manager to anticipate which problem is more likely and to encourage everyone to approach the review with an open mind and a quiet temper. It's useful to reinforce the theme of making the next project run more smoothly, rather than either assigning fault or making everyone feel good about the current project.

The review should cover:

• What went well and why, in all areas of the project, whether on the business side (training, perhaps) or on the technical side (the performance tuning approach), and whether mundane (the location of the kickoff meeting) or critical (the executive sponsor stepping in to rescue the project after the technical setback on week 3).

• What did not go so well and why, and what could have been done to change that. If a large deployment issue was discovered the week before the rollout, forcing a postponement, could it have been predicted earlier? Why was that particular test not performed at the beginning of the project? Was it something that should have been checked with the references for the tool? Although the goal is not to rub people's noses in it, it's important to pin down the cause of the problem as well as to define alternative paths to avoid it in the future.

Serious reviews can take several hours. If you are using an integrator, as you probably are, hold a private, shorter, summary review afterwards to examine how well the integrator performed on the project, and whether it should be retained again and under what conditions. You may also use this time to examine any internal issues you do not want to air in front of the integrator staff.

Summarize the results of the review, focusing on any changes that should be made for future projects, and make sure the changes are taken into account. Don't bother with the review unless you can be reasonably certain that changes will be made as a result of it.

CRM implementations have a well-earned reputation to be challenging and not always meeting the lofty goals they started with. To be really successful, start with a kickoff workshop in which the whole team works together to create objectives and perform the gap analysis. Stay on top of the project by using meaningful milestones and frequent, face-to-face status checks. Finally, communicate without hype to the users. That should bring you to a pleasant and relaxed post-mortem.