Symptoms as reported by users are most commonly:
- Inadequate system performance
- Throughput (response time)
- Capacity
- System doesn’t match requirements
- Missing reports/queries
- Incorrect process/work flow
- “It doesn’t do it our way”
- Missing functionality
- System is too unwieldy
- Too many steps
- Ungraceful process
- Project was late
- Project was over budget
- Users have poor access to system information
- There are data integrity and/or data accuracy problems
- There were data conversion problems
- The system was too difficult to implement
- Too much demand on internal resources
- “They want us to shut the business down for how long?”
- “It just doesn’t work!” Or similar statements of abject despair.
- Overwhelming number of problems
- Couldn’t pass critical test(s)
One striking thing about all these symptoms is that they all appear after the fact: in a few cases, after an implementation is cancelled, in a few more when it is demonstrably struggling and in the rest after the system has gone live. That is, there are no early warnings on this list, nothing that suggests “we’re going to have a problem we haven’t felt yet if we don’t do something now.”
When asked for the causes of these symptoms, users and implementers typically list the following (the wording varies from survey to survey):
- The wrong software was selected (usually users).
- The software was configured incorrectly (usually users).
- The requirements/specs were incomplete or incorrect (usually implementers but users sometimes confess to this).
- Scope creep.
- Implementers: “They kept adding requirements.” This is the implementer’s universal first response to complaints about budget and schedule overrun.
- Users: “Then they said, ‘Oh, you want it to work? That changes everything.’”
- Inexperienced/inept implementers (users).
- “They lied” (both). “They” may be a third party!
- Lack of management commitment/support (both). This is the single most commonly cited general cause of failure, but often it is offered without an explanation of exactly what management should have done differently.
- Lack of user skill.
- Implementers: Many flavors (some unprintable), among them:
- “They wouldn’t let us train them.”
- “They have nobody who understands anything [in that department].”
- “They refuse to change how they work.”
- “We showed them over and over again and they just didn’t get it.”
- “5,000 companies use this module every day but they say it just doesn’t work.”
- Users: “We’re accountants/planners/buyers/etc, not IT people.”
- Resistance from users (usually implementers but not always).
- Buggy package (both!).
- Implementation task just underestimated or oversold (users).
Some rather surprising things emerge when we compare the list of commonly reported symptoms of failure to the list of commonly reported causes of failure.
- Almost any commonly reported symptom could be the effect of almost any commonly reported cause.
- There is nothing in either list that suggests how to avoid these results.
To restate the usual perceptions of failure in terms that can lead to actually preventing, we need to take an entirely different view, one that looks at the problem of preventing failure as an exercise in risk management.
I enjoy your piece of work, appreciate it for all the great content .