SMEs and ERP (Extreme Risky Projects)
11/03/2012 3 Comments
We have been building information systems (IS) for more than 50 years now and still have not learned to do it successfully. Business literature as well as academic literature is full of cases reporting and explaining what when wrong. It is reported by the Standish Group that almost 70% of the IT project is not successful, meaning that they went over budget, over time, did not met with the initial requirements or were simply canceled. Although research on the phenomenon of IS failures has evolved enormously it looks like not a lot has been learned. In the early days of the computer era, most IT failures where noticeable in the development of bespoke applications. Nowadays we see IT failures in ERP implementations.
IT failures can be classified in correspondence, process and interaction failures (Lyytinen et al., 1987). Correspondence failures occur when the outcome of the developed and implemented information systems does not match with the design. Process failures are errors in the development or implementation process. Examples here are running over time or over budget. Interaction failures occur when the users refuse to use the system for all sort of reasons (resistance, not useful, no ease of use, …). Most IT failures however show a combination of all aforementioned characteristics. The occurrence of these characteristics is in no way logical. One characteristic can provoke another.
The most frequent failure factors found in 2011 for software development projects are: ‘delivery date impacted the implementation/development process’, ‘project was underestimated’, ‘risks were not re-assessed, controlled or managed’ and ‘staff were not rewarded for working long hours’ (Cerpa and Verner, 2011). We see these factors also in ERP projects. Additional For ERP projects Kim (2011) found that user resistance is also critical for the high failure rate. Kreps and Richardson (2007) state that large-scale IS projects suffer from recognized and well-documented problems including: ‘scope creep’, ‘escalation of costs’, ‘failure to meet the expectations of the stakeholders, who persistently overestimate the capacity of IT to solve operational problems’, ‘failure of the technicians in the project to engage with all stakeholders in the project, resulting in solutions that baffle the end-users and sometimes miss the point completely’.
What can we learn from all these findings?
I think that everything points towards an alternative approach of bringing IT into organizations. Small, discrete projects that are well manageable seems to be of key importance. ERP projects are by definition large projects with long implementation times. Is this really the solution for SMEs? We should adopt a less imperative view of technology and how information systems are socially as well as technically constructed. ERP systems are not born out of our theoretical insights in information systems, but were build by large enterprises and implemented manu military. It should be clear that ERP systems will not install themselves in organizations, nor can its use be taken for granted.
For SMEs, Snider et al (2009) found six critical success factors for successfully implementing ERP: 1) operational process discipline, 2) small teams (less than 5), 3) sufficient project management capabilities (with strong leadership), 4) external end-user training, 5) management support (commitment), and 6) a qualified external consultant.
ERP projects are indeed extremely risky projects and before starting one, an SME should contemplate if the internal organization is really ready to take the challenge. In that process an independent software vendor should be as honest as possible and not hide away the real risks of an ERP project and even be brave enough to advise his SME prospect to waive an ERP project when the risks are not taken seriously.