OUR THOUGHTS AND EXPERIENCES ON WHY SO MANY IT PROJECTS EITHER DON'T FULLY DELIVER, OR COMPLETELY FAIL TO MEET THE BUSINESSES EXPECTATIONS.
One of the most rewarding aspects of technology engineering and consulting is that we get to work with a vastly varied array of companies. Although all very much unique, a surprising and consistent theme always seems to emerge when we speak to businesses with regard to previous IT projects they have undertaken. They never seem to be entirely happy with either the experience, the result or both.
Admittedly, reactions do vary from mild dissatisfaction with previous projects, to outright hostility toward the IT company responsible for a past failure, but it’s not an exaggeration to say that most companies have experienced an IT project “failure”.
We think this is a terrible indictment of our industry, and we want to help both customers and providers reach better outcomes. We just think that would make it a nicer place for everyone to be in.
So, here’s why we think IT projects fail.
THE TECHNOLOGY PROVIDER DOESN’T FULLY UNDERSTAND THE BUSINESS REQUIREMENTS OF THE PROJECT.
When it comes to IT projects, it’s incredibly easy and common for IT professionals to race to the ‘how’, and slide right past the ‘why’. It’s difficult to pinpoint exactly why this happens, but we’d submit that the reason could be that the ‘why’ is often a complex, nuanced and difficult question to answer. To fully explore and understand business objectives, set specific project goals, identify the correct metrics to measure project success, and understand the client’s desired outcomes takes a great deal of effort and resources on the part of the provider; perhaps more than they are willing to invest.
In addition, there is often a sense from the provider that this really shouldn’t be their role in the process, and the client should already have a clear vision for the project and be able to provide all the relevant facts and data needed for success. Unfortunately, clients often hold a different view and enter the process vastly under-prepared to help answer some of these core questions. This disconnect can be the no-man’s land that neither party wants to walk across, and as a consequence the project often starts without a defined and clear vision.
FORM OVER FUNCTION.
There’s no denying that most IT engineers really enjoy exploring new technologies. Most are naturally curious and are often drawn to products and industry trends that offer the latest cutting edge solutions. Although this generally has a positive effect on project outcomes, it can sometimes detract from a more pragmatic view of IT design and lead to over-engineering or worse, indulgent engineering. Although complexity is sometimes necessary to meet all the project goals and anticipate future client needs, unnecessary complexity will mean the overall solution is more susceptible to failure, harder to troubleshoot and more expensive to support.
SCOPE CREEP.
Anybody who has ever managed a project has bumped up against scope creep in one way or another, and it can often sneak up and destroy a project before you know its a problem. Although there are lots of reasons as to why this happens, fundamentally all scope creep emanates from a poor project definition process. Maybe there wasn't sufficient analysis of the requirements to begin with, or the complexities of the project weren't fully understood, or perhaps end users weren’t involved early enough, but all these really boil down to project definition. Get this process right, and scope creep is minimized.
NOT BEING ABLE OR WILLING TO STOP AND RE-TOOL.
Sometimes projects go bad. It could be the technology used, scope creep, or simply poor communication. For whatever reason, it is sometimes necessary to stop, examine, adjust, then start over. Unfortunately, this can often take considerable courage from all parties - courage that may not be present. As a consequence good money is thrown after bad, time is squandered and costs spiral. Sometimes, surrender is simply the best option.
