IT projects are infamous for running over budget and over time with uncontrollable scope. Statistics vary depending on how you look at it, but overall, according to Gartner, at least 25% of IT projects fail. All projects are tough; since they are about bringing something new to life, they inherently bear a level of unpredictability that can turn what seemed like a good idea into an epic failure. With technology projects, there is somehow another layer: the expectation that it is going to be easy, because technology is presented to us as a seamless, painless, “plug-in, forget-it & get-on-with-your-life” answer to our business problems. Here are the things that can, and often do, go wrong with IT projects:
You don’t really know the “why?” (or lost track of it down the road)
A lot of organisations start IT projects without truly asking why they do it in the first place. Perhaps an executive was convinced he needed a new system after seeing a great product demo, or an IT department decided that a system is getting old and needs to be replaced. You need a really good reason to introduce IT change, a reason that will translate into tangible value for your organisation. Without it, there is no direction for your project, no target to aim for. Organisations who do business cases are better placed to get their IT project successfully implemented, but the challenge remains in keeping that “why?” in sight throughout the life of the project. If you don’t, you’ll risk going down the wrong track.
You have to work with a really bad piece of technology
Yes, technology is certainly getting better and today there are lots of really good, accessible, simple (dare I say “cool”?) applications that have truly changed the way we think about business systems. But sometimes the technology doesn’t work out, either because it’s not the right fit for the organisation, or the system is technically so flawed or limited at its core that it just doesn’t support the way you need to do things. And when the technology doesn’t work, you have limited options: spend a lot of money to make it do what you need, compromise on your requirements, or cut your losses altogether and call it quits.
You have an unreliable vendor
A great piece of technology is no guarantee of project success and there are enough stories of failed IT projects using best-in-the-world systems. Technology vendors or implementation partners also play a critical part. Unfortunately sometimes vendors turn out to be unreliable. Even if you have done your due diligence, and the vendor ticked all the boxes, you always run the risk they will turn out to be unreliable (such as not having the right resources in place, or not having enough resources altogether). Having a great system to start with but an unreliable vendor is like giving the best produce you can get to a bad chef: easily ruined, it can leave a bad taste in your mouth and kill your appetite altogether.
Your stakeholders are unavailable
When implementing new technologies, it is vital for the organisation who will use it to have people available to drive and support the project. That means a sponsor who is fully engaged (ie. interested and committed), a governance group that can make decisions, subject matter experts who can bring knowledge to the table and leaders who truly promote the idea of IT change across their teams. Without these people involved, you may be able to deliver a great system on time, budget and scope, but if no-one ever uses it, you can hardly call it a success.
You don’t have a project manager (or you have a really bad one)
In an article by Hemant Kogekar in CIO Magazine exploring the reasons why IT projects really fail, the author notes: “The major success factor for projects – large or small – is the PM.” Sometimes the technology looks so easy (you sign-up online, set-up your account, and voilà, you’re done) that organisations get caught into thinking they don’t need to do anything else. It doesn’t mean you have to go and hire a project manager every time you want to put in a new system; you can well have an internal (preferably qualified) resource taking that role, but you need it in place. The project manager is the one that connects all the project pieces and keep them together on the right path. Without the glue, your project won’t hold.
Comments