|
The meaning of success and the meaning of failure. When any endeavor (any project in the both the loose and tight senses of the word) is adequately described before being undertaken, success and failure are mirror images of each other: to succeed is simply not to fail; to fail is simply not to succeed. But if the goals – the hoped for results – of an endeavor are less than fully stated, the mere absence of obvious failure need not be the same thing as success. In less than thoroughly planned endeavors, it is possible to avoid everything that had been identified (and feared) as a condition of failure and still not accomplish the desired results. Nowhere is this phenomenon more common than in the practice of acquiring and implementing major business application software.
Failure seems like a simple idea, but when we try to examine it in detail it turns out to be more complex than we might expect. Usually the potential for failure includes quite a few entirely different things: it’s hard, in fact, to imagine anything worth doing at all that couldn’t fail in many more ways than it could succeed. The looseness of the word is important. The prevention of failure is self-evidently important to us, but if the meaning of failure is hard to pin down, then the things we identify as the causes of failure may be even more nebulous. This matters because every potential cause of failure is a risk that must be managed. Any risk we fail to anticipate is unlikely to be managed. The very failure to anticipate risk is, in itself, the greatest danger we face.
Reported statistics on ERP project failure vary from survey to survey, but tend to fall into consistent ranges.
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.
First, almost any commonly reported symptom could be the effect of almost any commonly reported cause. Actually, the relationship between reported symptom and reported cause is even more nebulous than that (if possible). The statements of cause, after all, are matters of interpretation and are somewhat subjective in nature. For example, twenty years ago we, as implementers, might have said that users failed to give us enough time. Today we would blame that on management, having come to learn that users give us as much time as management requires them to give us.
Second, there is nothing in either list that suggests how to avoid these results. The closest we usually come to that are statements like “management should have been more involved” (without explaining what management should have done that they didn’t) or “requirements should have been better expressed” (without explaining which particular requirements were misstated or omitted).
Failure as it’s revealed by analysis. While these lists are anecdotal in origin, they accord well with more rigorous research.
A recent meta-analysis (that is, an analysis of analyses) by Davide Aloini, Riccardo Dulmin and Valeria Mininno of the University of Pisa1 identified ten commonly reported symptoms of failure (which they called “effects”), which they assigned to four “macro-classes”:
(a) Process failure, when the project is not completed within the time and budget.
(b) Expectation failure, when the IT systems do not match user expectations.
(c) Interaction failure, when users attitudes towards IT are negative.
(d) Correspondence failure, when there is no match between IT systems and the planned objectives.
It is important to remember that Aloini, Dulmin and Mininno did not do original research involving ERP projects; their work was an analysis and synthesis of 175 articles on the subject of ERP failure and risk management. Therefore we find it highly significant that, just as we found with our own lists, Aloini, Dulmin and Mininno concluded that every one of the nineteen reported risk factors (cause) could lead to all of the ten reported effects (symptoms). In other words, there appears to be universal agreement among people who have studied the problem that any unmanaged risk within an ERP project can lead to every kind of failure ever reported.
|
