Handling Implementation Problems

This section focuses on implementation problems. Problems are inevitable during a long project so proper expectations and a game plan are useful.

You Can't Expect a Trouble-Free Implementation

I imagine that there have been a few truly trouble-free CRM implementations since the beginning of time, but I have never been a part of one. Even relatively small projects hit problems at some point, and larger projects, being so complex, are pretty much guaranteed to experience several significant problems. This is the case for all implementations, even those that follow thorough, well thought-out selections for both the product and the integrator and that enjoy good executive support. Implementations that don't enjoy a good start or good ongoing support do worse , of course.

Therefore, you should expect to encounter some amount of problems including at least one major problem, a showstopper that forces you to do without an important feature or that requires significant amounts of money for unforeseen additional hardware, software, or development work to address. Don't automatically conclude that the project is a failure just because you hit a snag, even a major one.

The good news is that many problems are, in fact, predictable. For instance, if your project includes such traditionally problematic features as a tricky integration to another system, a deployment to far-away offices with slow network connections, or plenty of customizations in the underlying data model, then chances are that large problems will crop up there, not when changing the color of the screens. What to do? Start by confirming that you absolutely need the problematic feature or functionality. If you do, schedule the associated technical work so that the more difficult areas are tackled first. Once the trickiest bits are in place and tested , it's an easier ride to the finish line. A big goal of the kickoff meeting should be to highlight those areas of technical (and, more rarely, business) risk and to schedule the work for them early on in the project.

Resolving Issues

If you do run into a big issue, don't panic or make rash decisions. Problems may turn out to be less grave than anticipated, and in any case you need to investigate the issues thoroughly before you make a decision. Involve the entire team in the decision rather than looking at them strictly from the technical side. (A strictly business approach is no better, but usually the problems that are uncovered are of a technical nature and the usual, flawed impulse is to find a technical solution). For serious issues, convene a brainstorming session with the entire team to help you uncover novel solutions.

Now for some examples of problems and potential approaches for them. Let's say the problem is poor performance from remote offices. Perhaps it's just the nudge that you needed to upgrade the network despite the hefty cost. If you asked the references about that specific point and they did not report problems, perhaps the tool vendor could audit the situation to isolate configuration improvements. Both alternatives so far are technical solutions. Perhaps a combined business and technical solution would work: can you stage the deployment so that remote offices are last in line? If an upcoming release is targeted towards communication improvements, perhaps that could be the ticket for you. Notice the potential problem with this solution ” it delays facing the problem until the very end, and it is completely dependent on the tool vendor to provide a timely and effective release.

The worse thing you can do when faced with a big problem is to hide it. Hiding problems is widespread because of the political attacks that are sure to follow the admission of a problem. I advocate the opposite strategy: go out of your way to seek out problems because a known problem is much easier to deal with than an unknown problem (although, of course, there's nothing as sweet as a resolved problem). Be very candid about problems, especially with the executive sponsor. What you are after is trust: if you are open about issues, the executive sponsor and the business owner will not spend their energies worrying about hidden issues and will be more cooperative about solving the problems that do occur.

Should You Ever Give Up?

It could be, although it's very rare if you are careful during the selection process, that you will find a problem serious enough to scrap the project rather than patching it together. It's a very extreme measure and of course a costly one, since the tool investment is typically spent by that point, as is some amount of integrator effort and the effort of all the internal players. It's very painful to come to the conclusion that a project needs scrapping, not just because of the financial pain but because the main players have been so involved with it that they just can't contemplate terminating it. (By the way, I think getting attached to a project is, overall, a good thing since a good emotional bond helps you to stick with the project through difficult times). Consider scrapping the project if you are experiencing severe problems in the technical, business, or financial areas:

• Key functionality just is not functioning as advertised. This includes both usability items and performance.

• The business model has changed so drastically that the tool that was chosen no longer meets the need.

• The budget has changed or requirements have increased to the point that you cannot sustain the implementation.

If you have to scrap the project, do hold a post-mortem, however painful it is. It is extremely valuable to understand whether the issue should have been foreseen and avoided, especially since the project may need to be restarted in another form to adapt to the new conditions.