Itâ€™s a dirty secret, many IT projects fail; maybe even as many as 30% of all IT projects.
Amazing, given the time, money and mojo spent on them, and the seriously smart people working in IT.
As a vendor, it is painful to see this. We see it from time to time (often helplessly from the sidelines), we think about it a lot, weâ€™d like to see eliminated along with malaria, cancer and other â€śnasties.â€ť
They fail for a lot of reasons, many of them unrelated to software.
At EventTracker weâ€™ve helped save a number of nearly-failed implementations, and we have noticed some consistency of why they fail.
From the home office in Columbia MD, here are the top 10 reasons IT projects fail:
10. â€śIt has to be perfectâ€ť
This is the â€śif you donâ€™t do it right, donâ€™t do it at allâ€ť belief system. With this viewpoint, the project lead person believes that the solution must perfectly fit existing or new business processes. The result is a massive, overly complicated implementation that is extremely expensive. By the time itâ€™s all done, the business environment has changed and an enormous investment is wasted.
Lesson:Â Value does not mean perfection. Make sure the solution delivers value early and often, and let perfection happen as it may.
9. Doesnâ€™t integrate with other systems
In almost every IT shop, â€śseamless integration with everythingâ€ť is the mantra. Vendors tout it, management believes it, and users demand it. In other words to be all things to all people, IT project cannot exist in isolation. Integration has become a key component of many IT projects and it canâ€™t exist alone anymore.
Lesson:Â Examine your needs for integration before you start the project. Find out if there are pre-built tools to accomplish this. Plan accordingly if they arenâ€™t.
8. No one is in charge, everyone is in charge
This is the classic â€ścommitteeâ€ť problem. The CIO or IT Manager decides the company needs an IT solution, so they assign the task of getting it done to a group. No one is accountable, no one is in charge. So they deliberate and discuss forever. Nothing gets done, and when it does, no one makes sure it gets driven into the organization. Failure is imminent.
Lesson:Â Make sure someone is accountable in the organization for success. If you are using a contractor, give that contractor enough power to make it happen.
7. The person who championed the IT solution quits, goes on vacation, or loses interest
This is a tough problem to foresee because employees donâ€™t usually broadcast their departure or disinterest before bailing. The bottom line is that if the project lead leaves, the project will suffer. It might kill the project if no one else is up to speed. Itâ€™s a risk that should be taken seriously.
Lesson:Â Make sure that more than just one person is involved, and keep a new interim project manager shadowing and up-to-date.
6. Drive-by management
IT projects are often as much about people and processes as it is about technology. If the project doesnâ€™t have consistent management support, the project will fail. After all, if no one knows how or why to use the solution, no one will
Lesson:Â Make sure you and your team have allocated time to define, test, and use your new solution as it is rolled out.
5. No one thought it through
One day someone realized, â€śhey we need a good solution to address the compliance regulations and these security gaps.â€ť The next day someone started looking at packages, and a month later you buy one. Then you realized that there were a lot of things this solution affects, including core systems, router, applications and operations processes. But youâ€™re way too far down the road on a package and have spent too much money to switch to something else. So you keep investing until you realize you are dumping money down a hole. Itâ€™s a bad place to be.
Lesson:Â Make sure you think it all through before you buy. Get support. Get input. Then take the plunge. Youâ€™ll be glad you did.
4. Requirements are not defined
In this all-too-common example, half way through a complex project, someone says â€śwe actually want to rework our processes to fit X.â€ť The project guys look at what they have done, realize it wonâ€™t work, and completely redesign the system. It takes 3 months. The project goes over budget. The key stakeholder says â€śhey this project is expensive, and weâ€™ve seen nothing of value.â€ť The budget vanishes. The project ends.
Lesson:Â Make sure you know what you want before you start building it. If you donâ€™t know, build the pieces you do, then build the rest later. Donâ€™t build what you donâ€™t understand.
3. Processes are not defined
This relates to #4 above. Sometimes requirements are defined, but they donâ€™t match good processes, because these processes donâ€™t exist. Or no one follows them. Or they are outdated. Or not well understood. The point is that the solution is computer software: it does exactly what you tell it the same way every time, and itâ€™s expensive to change it. Sloppy processes are impossible to create in software making the solution more of a hindrance than a help.
Lesson:Â Only implement and automate processes that are well understood and followed. If they are not well understood, implement them in a minimal way and do not automate until they are well understood and followed.
2. People donâ€™t buy in
Any solution with no users is a very lonely piece of software. Itâ€™s also a very expensive use of 500Mb on your server. Most IT projects fail because they just arenâ€™t used by anyone. They are a giant database of old information and spotty data.Â Thatâ€™s a failure.
Lesson:Â Focus on end user adoption. Buy training. Talk about the value that it brings your customers, your employees, and your shareholders. Make usage a part of your employee review process. Incentivize usage. Make it make sense to use it.
1. Key value is not defined
This is by far the most prevalent problem in implementing IT solutions: Businesses donâ€™t take time to define what they want out of their implementation, so it doesnâ€™t do what they want. This goes further than just defining requirements. Itâ€™s about defining whatÂ valueÂ the new software will deliver for the business. By focusing on the nuts and bolts, the business doesnâ€™t figure out what they want from the system as a whole.
Lesson:Â Instead of starting with â€śhey I need something to accomplish X,â€ť the organization should be asking â€śhow can this software help us bring value to our security posture, to our internal costs, to our compliance requirements.â€ť
This list is not exhaustive â€“ there are many more ways to kill your implementation. However if your organization is aware of the pitfalls listed above, you have a very high chance of success.