Why Do So Many Information Systems Implementations Fail and What Can Be Done to Improve Our Success Rate?
Information Systems (IS) implementations normally fail due to a lack of ownership, planning and execution by the organization. The software and hardware tend to do what they are supposed to do. Their features and limitations are typically known, at least if we take the time to investigate. However, it is the organizational issues among and between business units and teams that actually require most of the effort when running an IS project.
The root causes of IS project failures include weak scoping, lack of executive management ownership, poor project management, lack of scope controls, improper infrastructure and inappropriate technology choices.
Weak scope leads to a project whose requirements are too broad to be met by any single system. Similarly the team will be too broad with differing opinions as to the ultimate purpose of the project and therefore application. After all, if the team members are each interpreting the goal(s) of the project in different ways it will be difficult, and time consuming, to arrive at consensus on each aspect of the project.
Lack of executive management ownership leaves the project team without an effective sponsor. Having such a sponsor helps mitigate the various issues that will arise as the project team seeks to design and implement a new system. Maintaining focus on the business goals of the system along with championing the system and breaking down barriers between groups are major functions for the executive owner.
Project management is key to delivering on any sort of solution, technology or otherwise. Knowing the team roles, responsibilities, timelines and dependencies allows for issues to be identified proactively and resolved in a timely manner. Exit strategies must be defined that rely on understanding the current project risks. Without effective project management the actual status of the project remains hidden.
Once an IS implementation is started its scope may be altered. This may be due to changes in business strategy, organizational construct or external influences (e.g. legal or competitive changes). The risk to the IS project is that such changes may require additional effort (time, resources) ultimately reflected as some cost. Without a formal process, such as a change control board, these alterations in scope can repeatedly delay a project and add significant cost, negating any prior understanding of ROI.
The IT infrastructure must be appropriate for the IS implementation. Requirements for access to data in specific formats or of a known quality may or may not be met by the current technology. The ability to leverage certain standards required by the new system, for instance LDAP for authentication, must be understood before beginning the project. It could be that implementing a new system may require changes to aspects of the organizations’ IT infrastructure.
Finally, businesses may choose the wrong technology for their situation. These choices may lead to the “square peg in a round hole” syndrome where the implementation team tries to implement the tool to meet the business need even though the product is not appropriate for the task. Careful alignment of business strategy and IT strategy along with conscientious investigation of product capabilities compared to business requirements will mitigate this risk. An exit strategy is also necessary to prevent mistakes in product choices from undermining the project’s success.
Mitigating these risks means addressing each one through people and processes. By assuring that the project’s scope is well defined we can assign an appropriate team and have a clear objective to meet. Having a strong executive sponsor who is actively involved in the project, through recurrent status updates and meetings, will mitigate roadblocks from other parts of the organization. Following a standard project management process, led by an effective project manager, will assure that resources (human and other) are available as needed and that risks are quickly identified and escalated.
The creation of a change control board that is responsible for understanding scope changes and weighing them against project costs will reduce the risk of the project becoming mired in a constant state of change. Having IT and business management actively involved in the project will likewise assure that the business vision for the system and the IT infrastructure support are in line with the system’s needs. Finally, by following a process where the system requirements are compared to the candidate solutions and evaluated by both business and IT, we can minimize the likelihood of choosing inappropriate technologies to meet a given need.
Large information systems projects do not have to fail as often as they do. The challenge to the leadership of business and information technology is to realize that the majority of the risk in such projects is related to our processes, communication and planning – all human-centric aspects. Focusing significant effort in these areas will dramatically increase the probability of success for our large enterprise IS projects.
Tags: enterprise applications, enterprise systems, Information Systems, project management, project scope