Rescuing a Failing CRM Project

This chapter was excerpted from the book Just Enough CRM, by Francoise Tourniaire, with permission from publisher Prentice Hall PTR, copyright 2003.

Express Version

Whether you have inherited a failing CRM project or it's your own project that's failing, start by conducting a candid assessment of the situation to determine if the project is worth saving. The assessment process is similar to a post-mortem for a completed project. Carefully evaluate the three P's (people, process, and politics) that are usually the causes of project problems, as well as the tool, which is almost always blamed but is only infrequently the root cause of the problem.

To be salvageable, a project needs a credible and engaged executive sponsor, even more so than other CRM projects, and a tool with a reasonable fit. Everything else can be overcome, but don't bother with a salvage effort if you don't have those two prerequisites.

Make changes in people, processes, and politics as required and define a new project plan and budget for the project, simplifying the project as much as you can. When you gain approval for the new plan and budget, restart the project at a logical starting point following the same implementation process you would use for any other CRM process.

With a salvaged project, pay particular attention to morale and communication within the project team and with the users, as well as careful project management.

Project Failures

Although the techniques described in this book should yield reasonably smooth and successful projects, you may be reading it specifically because you have been handed a failing project and the responsibility to fix it. This chapter is for you.

Just Enough CRM
This chapter is also for you if you suspect that your project is failing, although no one, not even yourself perhaps, has openly admitted yet. Generally speaking, if the project manager or a business owner thinks that the project is failing, even if other project team members deny it, then the project is indeed failing. Team members may refuse to accept that the project is not going well because they have so much invested in it.

The fact is that it's usually pretty clear when a project is failing, at least from an outsider's point of view: users have lost interest, the project team is struggling, the business requirements have changed drastically, or serious technical issues have been encountered. Frequently the project faces not just one but a combination of problems. And we are talking big problems, serious problems that the team is unable to address or sometimes even to face.

This is not to suggest that CRM projects fail in spectacular ways. More often it's a matter of losing momentum over time as problems pile up, unaddressed, until the project comes to an unceremonious halt. By then, it's usually too late to do anything, so always be thankful that you are intervening before the project slips from failing to failed status.

If you are faced with a failing project, use a three-step recovery process: assess the situation, restructure the project, and restart it.

Step 1: Assess

Why Projects Fail

CRM projects fail because of the so-called "three P's": people, process, and politics. Some CRM projects fail because of a poor tool choice, but it's actually quite rare that the tool itself is the root cause for the failure. True, the tool is a convenient scapegoat and is almost always blamed for project failures, and even branded as the only cause for the failure. The reality is that a properly run project should be able to conduct a successful tool evaluation that yields a solid, well-suited tool. If that selection should turn out to have been ill advised, a solid project team should be able to recover the project without going through a "failed" phase, although certainly there would be some unpleasant moments.

You need to determine how people, process, politics, or the tool contributed to the failure without automatically blaming the tool.

The Assessment Session

Whether you believe your own project is failing or you were brought in to rescue a failing project, start by holding an assessment session. This is very similar to the post-mortem analysis described in Chapter 9, although post-mortem analyses follow projects that went to completion. Bring the entire project team together for the assessment, and as much as possible organize a face-to-face meeting since there are many emotional topics to be discussed. Make sure the executive sponsor attends the assessment.

The assessment should be conducted with the full team, just like a post-mortem, although the key internal players usually reconvene afterwards without the integrator and without the individual contributors to review the results of the assessment and to make the business decision on whether to proceed or halt the project.

It's somewhat easier for an outsider to conduct the assessment session because an outsider has a more objective view and is better able to explore unpleasant areas. If you are managing the assessment session for your own project, keep your emotions in check and make every effort to be objective and thorough, while leveraging the knowledge you have gained from working on the project to probe the issues.

In any case, expect the team's morale to be low by the time a project is in failing mode. Failing projects are depressing for all team members, regardless of their individual levels of responsibilities for the failure. Maintain a tone of reasonable optimism for the assessment session: after all, the project is failing, but it's not dead yet, and recovery can only occur after an appropriately balanced assessment session. This is not the time to despair, but don't allow fake optimism either: the team is in a serious situation that should be acknowledged as such.

The Good Start the assessment by reviewing what went well with the project. It may seem crazy to start with the positives since there won't be many (after all, the project is failing) but it's critical to figure out the pieces that can be rescued if the project will be restarted, which is a very likely outcome. Also, starting on the positive side helps everyone's morale, which can be a big help at this difficult juncture.

Take a look at the three Ps, people, process, and politics. About people: are there key individuals that are contributing to the success of the project despite the challenges? Identify both technical team members and business team members.

About the process: although it has failed to produce a winning result, are there aspects of it that are working? For instance, is the communication process working? Is the testing producing good results? Are end-users appropriately engaged in the project? Is the coordination between the technical team and the business team working properly?

For the political aspect, the very critical question to ask is: is the executive sponsor active in the project and providing tangible support? If the answer is yes, then it's almost always worthwhile to press forward with the project, even if difficult choices must be made.

There may be other positive political aspects, in particular if the business functions are behind the project. Can end-users perceive benefits from the tool, even if only in a few areas based on the functionality released so far? If the end-users are demonstrating any level of enthusiasm during an assessment session, the future of the project is very positive even if the future looks dim right now.

Finally, look at the tool. Tools typically get blamed for any and all problems, and certainly CRM tools are far from perfect, but try hard to isolate the features of the tool that are working well. After all, the team selected it in the first place, so there must have been something attractive about it.

Especially at the beginning of the session, conduct the assessment in brainstorming mode, accepting all suggestions and delaying discussions until everyone has had a chance to participate. If you allow participants to discuss the suggestions as they are made, you run the real risk of shutting off the dialog.

The Bad Once you have a list of positives, go to the negatives, looking again at the three Ps, people, process, and politics, and also at the tool. Are the right people on the project? Are there any areas of weakness? Consider weaknesses at all levels, from the project manager to the business owners and super-users, to the technical team, and to the integrator. People issues are difficult to confront in a group setting, so expect roundabout answers, for example, a suggestion to add someone with a specialized skill rather than a condemnation of a particular individual. Carefully note the nuances. On the other hand, if the level of interaction gets aggressive, you will know that the team is not communicating well and that problem needs to go on your list of issues.

People problems can also arise within the user community. Are the business owners or the super-users not participating appropriately? Are end-users refusing to use the tool? Can you determine whether the reasons behind the refusal are based on (lack of) functionality? Communication issues? Motivational issues?

Moving on to process issues, it's common to find problems with the way the project itself is being conducted. Assessments often uncover that the requirements definition was done too hastily, that the project plan was overly ambitious, that the users have not been involved enough throughout the project, or were not involved early enough, and that testing and QA are insufficient. Besides determining what processes have been weak, probe carefully on when the project went wrong, not just how. This is because, if the project will be restarted you need to know at what point to restart it. If it's just a problem of buggy programming, then you can restart the programming phase (perhaps with different programmers!). But if the problem occurred at the requirements definition phase, you need to go back to that point, which means a great deal of additional time and resources will be needed.

Process issues can also come from the business side. Are the processes that are to be modeled in the tool inefficient, ineffective, or simply the wrong ones? If the project included formalizing processes for the first time it's quite common to find that the newly formalized processes are "wrong" and cannot be used as they are. They looked fine on paper, but once they got automated in the tool the users realized that they were simply not the right processes. If that's the case, go back to the process definition phase and use more effective validation techniques.

The tool is often blamed when the wrong process was automated, so make sure that users can distinguish between a bad automation of a good process (which is a tool or a customization problem) and a correct automation of a bad process (which is a process problem).

Process issues can also arise if the business model is changing, prompting process changes that are incompatible with the tool. If that's the case, the current configuration of the tool (assuming you have started customizing it) may not work any more, but this doesn't automatically mean that a new tool is required. What you need to do is to re-evaluate the tool against the new business model and processes before proceeding with a decision. You may be pleasantly surprised to see that the tool can be adapted to the changes, although it will take time and resources to perform the re-evaluation.

It's always tricky to probe political issues in a group meeting so you can limit yourself to one simple test: is the executive sponsor attending? If not, then you can politely thank everyone and go spend your energy on something else, since the project cannot succeed without the sponsor.

Political problems often take the form of active or passive resistance to the project from the business functions or from the IT group. What is the basis for the resistance? A strong executive sponsor should be able to help resolve the problems, but only if he or she is aware of them in the first place. An out-of-touch executive sponsor points to either a weak project manager or a power-challenged sponsor, both issues that would need to be addressed if a rebirth is to be successful.

Politics often get blamed for the lack of availability of an appropriate budget, and indeed negative politics can derail well-planned budget. However, do not allow politics - or the executive sponsor - to be blamed for failing to get large cost overruns approved. If the project costs are out of control, it's the performance of the project team that must be scrutinized, both at a process level and at the individual level. Likely you have problems with people or processes (or both) rather than political opposition.

Also include careful consideration of tool weaknesses in the assessment. Almost all projects run into some kind of tool problem, so the issue is not so much to make a list of the tool problems you encountered, or even to consider its length, but rather to qualify the impact of the tool issues on the project. Tool issues need not be an automatic death sentence for the project.

Related:
1 2 Page 1
Page 1 of 2
7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon