There are at least a dozen oft-quoted industry analyst reports that estimate the failure rate of customer relationship management (CRM) projects. The analysts’ methodologies and standards vary, so the resulting failure numbers are all over the place — between 18 percent and 69 percent.
Most of the numbers seem to center around the question, “Did the project meet expectations?” This is a profoundly fuzzy standard — and, in fact, it can be a self-fulfilling prophecy. Children don’t want to eat their spinach, so it tastes bad, no matter how much they could have enjoyed it if they kept an open mind
Taking an average of those analyst reports, about one-third of you have a CRM project failure on your hands. Whether you were part of an implosion, or whether the project was handed to you after the fact, the real issue is, simply, “What now?”
5 signs of project failure
If people think your CRM project is a failure, do a little forensic work.
1. Did the project come within 20 percent of its original schedule and budget? Was the schedule practically guaranteed to fail? Was the budget realistic, or was it a product of magical thinking?
2. Were any of the following data quality problems made worse during the project?
Data quality is a major contributor to user dissatisfaction, even when the system is actually working fine.
- Duplicate records
- Mis-owned, improperly assigned, or “invisible” records
- Record completeness and fidelity
- Field accuracy, particularly addresses and product numbers
3. How functional is the system?
- For items that were “missing,” or not seriously attempted, had users clearly stated the goals early enough in the project to get them done?
- For the items that were attempted but didn’t make the grade, what’s the key root cause: Lack of understanding, inability to execute or quality/ease of use issues?
- For items that were generally satisfactory but have reliability or consistency problems, is the real issue poor design, architecture and conception, or is it weak implementation, development and deployment skills?
- Are some of the missing functional areas actually provided by subsystems outside the project’s control (such as the phone system, data warehouse, external data feed, or accounting system)?
4. Evaluate user involvement and expectations:
- During the project, were users deeply, continuously involved? This is a key factor to successful agile project management. Were those who are now complaining the loudest engaged in any significant way throughout the project?
- Did the people setting the expectations about what the CRM project would accomplish actually know what they were talking about?
- Was there evidence of Happy Ears, that deadly phenomenon that lets users think that everything conceivably possible in system functionality becomes “the standard we expect.”
- Did the CRM product salespeople set expectations that can only be achieved with tons of customization work, then set expectations about how cheap it would be to get consultants to do it?
- Did significant internal forces try to block the success of the project? CRM implementation is always political, and there are always users who don’t want a project to succeed.
5. Evaluate project management:
- Was this project managed by the user organization? If so, was it the group’s first big project?
- Was there meaningful participation by and cooperation from the IT department?
With all this information, you may well determine that, in an objective sense, the project wasn’t really a failure. It may have achieved the goals that were realistic given the time, attention and budget available. In the eternal wisdom of George Carlin, “Some people say that the glass is half-empty, others say that it’s half-full … Me, I think the glass is too big.”
Sure, users may not be happy. In many “failed” projects, though, the users expected more to be achieved before they started using the system. In other words, it’s not that the project delivered a broken system; it’s that the project at go-live was only fragments of a system that wasn’t as easy or friendly as users had been led to believe.
Assessing why your project failed
A classic reaction to a failed project is to blame the project team, get a new project manager, change consultants and hold a crash “get well” program. In extreme cases, management may throw out the new system altogether.
Although such reactions are emotionally and politically satisfying, they are typically costly, as all changes incur friction and learning-curve effects. Worse still, the get-well program usually heads straight down the stay-sick road described in the mythical man-month.
Let’s see if we can do better by asking a series of tough questions:
- Was the original project conception viable?
- Is the organization ready to handle big advancements in automation, sophistication and management?
- Were users on board with the changes required in discipline and process? Did they want to keep things the way they were, or even more ad-hoc?
- Did the execs invent a micro-management monstrosity?
- Do the IT systems and data sources with which the CRM system must integrate have sufficient flexibility and data quality to support the use cases?
- Were the budget and schedule in line with functional expectations?
- Are there still unstated requirements? Is discovery continuous?
- Are there tricky dependencies on other projects (e.g., the need to integrate with other applications that are changing and have unfunded integration code)?
- Did anyone do a bottom-up cost estimate of what it would really take to complete all the requirements? (My recent favorite situation: a 68-page spec for the behavior of a single CRM field, with no budgetary estimate by any of the three vendors involved in implementing it.)
- Was there a “fixed price or die” attitude held by the project management or executive sponsors?
- Were stakeholders able to dedicate enough time to the project? Were they unable to commit the time to make project decisions smoothly?
- Were there big gaps in the original schedule during which nothing moved?
- Were there competing groups of users, where organizations had conflicting or even contradictory goals?
- Was there real trust between the users and the project team?
- Did any team members suspect each others’ motivations or required skills?
- Were honest questions sometimes interpreted as challenges or even threats?
- Did anyone throw a temper tantrum or threaten to quit?
- Were some people simply unable to work together effectively?
- Was any legal action threatened or invoked?
If you get enough “Yes” answers to those tough questions, the get-well project is already sick. It may make sense to call in a management consultant or organizational development specialist before kicking the new IT project into full gear.
From CIO Magazine
Be the first to comment