Common Reasons for IT Project Failure
More often than not, IT projects fail . Shocking, but true. With all the innovative technologies finding roots in our daily lives, it’s hard to imagine that most attempts to deliver even not-so-innovative projects end in frustration, financial loss and disappointing results, if any. Contrary to popular belief, even of those in IT, technical savvy, expert knowledge and an internet full of how-to articles are not enough to promise success.
With technology being a key driver in today’s business landscape, shouldn’t we have figured this out already? Shouldn’t success in IT projects be clearly outlined based on the collective experience of IT professionals and project managers? Yes, it should be. And it is. It takes a multi-disciplinary approach, crossing all boundaries of an organization, to gather the required skills to effectively manage the complexities of an IT project. There are several proven methodologies to choose from – PMBOK Guide, COBIT, ITIL, CMMI and Six Sigma for starters . However, traditionally, IT staff have not been trained in the frameworks or soft skills needed to handle the bulk of project work outside of the technical tasks. In additional, smaller organizations rarely hire staff dedicated to those specialized fields.
In my experience, technical projects usually don’t fail because of technology. If the wrong technology for a project is selected, that points to lack of planning and analysis – a team failure. If politics get in the way of project success, that points to inadequate stakeholder management – a team failure. If late delivery from a vendor delays progress, that points to poor scheduling and contingency planning – again, a team failure. You might assume the team should be replaced. However, the true culprit for this failure is the lack of structure or institutionalized process to methodically guide the project team to success.
Ultimately, it is a failure of the organization’s leadership. All projects need an executive champion to promote and support (politically, financially, and priority-wise) the project and process throughout its execution. Oftentimes, the organization is completely ignorant of this need and the effects of it not existing. Organization-wide education and formal adoption of a project management methodology is an essential ingredient in getting the people in alignment, all moving in the direction of success. “Organizations must create a sense of urgency at the top, so that executive management and sponsors fully value the practice as a critical competency of projects and programs, and provide the appropriate support and commitment needed to excel throughout the organization.” 
Lack of Planning
People get excited about the promise of a project – efficiencies to be gained, praise from the boss, added bullet points on a resume, and a general sense of achievement. In contrast, the time needed to plan for those outcomes is boring, tedious, and uninspiring. As such, the team is driven to cram past the planning and get to the “real work” of the project, the fun part, the doing.
On a past website project I led, some of my team members were print-based graphic designers. They had no professional experience with web design, much less the technical aspects of responsive, mobile-friendly design. Working under an extremely tight, randomly assigned deadline, the designers and their director decided that they could handle the work without training. They found a piece of software online that claimed to transform any static design to a responsive one with correct HTML5 coding. They purchased the software and completed what they considered to be an acceptable design, all without IT consultation. When their deliverable was received by IT, it was unworkable. The code was non-compliant, the interface did not scale properly on multiple devices, and it was difficult to navigate. There's a saying about software quality: "If it doesn't have to work, we can build it really fast." 
The lack of planning, realistically assessing skill sets needed, and non-communication with IT caused the project to be several months late, only delivering an embarrassingly small portion of the original scope. Many pitfalls can be avoided through the advice and insight shared by planning team members .
In addition to getting excited about the prospect of a successful project, people often bite off more than they can chew project-wise. It’s easy to get lulled into thinking the team can beat the odds and deliver amazing results. People simplify the obstacles and exaggerate the ease of executing the tasks. They often forget about all the dependencies, risks and costs associated with “beating the odds.” 
Several years ago, I worked at a local community college that was 9 years into an 11-year Oracle project to create their own student information system (SIS). The IT department hired additional staff, purchased development software and entered into a very expensive contract with Oracle. The initial timeframe for the project was 2 years. Since the beginning, IT leadership had changed three times, the project switched priorities, and the features of the product kept piling up as more information was discovered. Needless to say, developing and sustaining your own SIS is a Herculean task. Without a clear scope and set of requirements, the project stretched out forever, never getting to any releasable stage. “Organizations must put the necessary resources in place to properly apply requirements management for recommending solutions for projects and programs. At the same time, they must also recognize and develop the skills needed to perform these functions.” 
Key components of projects are committing to making decisions and committing to the decisions made – not just making them. When emotions run high, politics are in play and the project is stalled, someone needs to be authorized to make a decision in the interest of moving forward. Consensus is great to have, but it not always achievable. Other techniques to gain approval can be employed, but at the end of the day, the team must be committed to making a decision, either by agreement, or less preferably, by force . Once the decision is made, whether individual team members agree or not, the team must collectively support the decision. Should the choice prove wrong later on, decision makers need to have the wisdom and self-discipline to know when to cut their losses and cancel a failing or unprofitable project. These values must be enforced at every level, eventually ingraining them into the company culture.
As evidenced in the example detailed under “Scope Creep,” prior leads of the SIS project continued to commit to an unrealistic outcome in the face of repeated failure, at an exceptional loss to the organization. When new leadership arrived, the obvious decision was to cancel the project and revisit the SIS needs. Many stakeholders balked at the wasted time and money, holding to the idea that more time and money would equate to success. This is a common fallacy that many in management are prey to, and they should be disabused of this idea immediately.
A new project was initiated, with informed executive support, to implement a vendor-supplied system used by many community colleges nationwide. Full research and planning was done, resulting in a robust SIS, complete with customizations developed in-house, in less than 2 years. Using the same staff as before, a clear process, limited scope, enforced deadlines and commitment to decision making brought the project in under budget and within schedule.
Educated people, thorough planning, clearly defined scope and requirements, and commitment to decision making are just some of the elements of project success. However, they seem to be the most overlooked and easily dismissed. Cultivating these organizational values through formal methodologies, policies and processes, from the top down, is critical for the continuing success of businesses who use projects as catalysts for delivering customer value.
1 Hemant Kogekar, “Why IT projects really fail.” cio.com.au, December 5, 2013 http://www.cio.com.au/article/533532/why_it_projects_really_fail/
2 Bill Holtsnider & Brian D. Jaffe, IT Manager’s Handbook: Getting Your New Job Done, 3rd Edition, 2012, Chapter 8.9 – Methodologies and Frameworks
3 Aaron Smith et al., “PMI’s Pulse of the Profession: Requirements Management — A Core Competency for Project and Program Success.” pmi.org, August 2014 http://www.pmi.org/~/media/PDF/Knowledge%20Center/PMI-Pulse-Requirements-Management-In-Depth-Report.ashx
4 Watts S. Humphrey, “Why Projects Fail.” computerworld.com, May 20, 2002 http://www.computerworld.com/article/2575401/app-development/why-projects-fail.html
5 Ken Black, “Causes of Project Failure.” pmi.org, November 1996 http://www.pmi.org/learning/causes-project-failure-survey-engineers-4814?id=4814
6 Project Management Institute (PMI), PMBOK Guide, 5th Edition, 2013, Chapter 188.8.131.52 – Group Decision Making Techniques