Why IT Projects Fail

Before exploring trends in IT project management, Joseph Gulla examines some basic research that can establish a solid baseline for a review of trends to follow.

With this post, I am starting a series on IT project management. I like to revisit project management every couple of years because it’s a discipline that changes because the world around IT changes—artificial intelligence, Internet of Things, microservices, APIs and new generations of workers to name a few. However, before I explore trends in IT project management, let’s start with some basic research that can establish a solid baseline for a review of trends to follow.

In “Seven Reasons IT Projects Fail,” I outlined why IT projects fail and how to avoid those pitfalls. This conference presentation has been cited at least 21 times since I wrote it. It’s probably the way the topic was researched and the somewhat surprising results that are of interest to people who study and practice the project management discipline.

The focus of this study was: What factors of the project provided the greatest challenges? For example, is it technical challenges or people issues? When I began the study, I didn’t know the aspects of the projects to focus on. Fortunately, they revealed themselves during the study and I created a template called the five-factor model. My hypotheses that the challenges were mainly technical turned out to be incorrect.

The first two items in the five-factor model are project management and people. I will discuss them here. The other three are business, technical and method, which will be discussed in the next post.  

Project Management

The management of the project is a factor in my model as it is in real life. When a project manager handles a project, what do they do? Basically, they plan, direct, solve problems and communicate. Each of these aspects can be approached in different ways. When I studied project management through George Washington University, the focus was software development projects with big teams so there was a real emphasis on tools and automation.

After the  development plan was approved, the implementation was handled by software that emailed the developer and told them, “Here is you next assignment, you have 30 hours to complete it.” Also, “Post your test cases in this directory” and “Update your estimate to complete if you anticipate taking more or less time with the assignment.” You get the idea—a kind of automated or factory approach.

Over the years of working on projects as project manager or team lead or technology specialist, I have identified some items that constitute a kind of management checklist. These specification items were also improved and reinforced by my research.

Project Management Helpful Checklist

1. Clear project goals? If no, what’s not clear?
2. Firm project scope? If no, is change-management being used?
3. Achievable plan? (Note: The scope of this question is feasibility.)
4. Communication plan in place? If no, what’s needed to establish regular communication?
5. Problems being shared with management? If no, why are they not being shared? Functional management involved at the right level? If no, what can you do to change this?
6. Senior management participating in executive status? If no, should there be senior-management meetings or communications?
7. Are you skilled enough for the project? If not, what specific skills do you need? Can you develop these needed skills quickly?
8. Proactive management including performance measurement? If no, what performance measures could you add to make the project status more numeric and less subjective?
9. Are you consistently telling the truth when reporting status? If not, make a list of items that are being left out and ask yourself why these are not being discussed openly.
10. Dependencies identified and understood? If no, take a specific action to investigate dependencies and work them into the overall project plan.
11. Requirements known or changing but being managed? If no, what can you do to firm up the requirements or put change management in place?

 
Regarding the study that I performed, I discovered that 54 percent of the problems with projects were attributed to poor project management, which was the most significant cause of project failure. You read that right. The main reason IT projects fail is because they are managed poorly. Next, let’s examine the people factor.

The Project Team

With people on an IT project, it comes down to skills, motivation, quantity and continuity. Really? Is that it? Think about it. If you have a big dependency of using a relational database with many rows and tables and subtle data relationships, you better have a skilled database administrator and developers with strong SQL skills. It’s clearly better if they are motivated to do a good job—make that quick, complete and innovative. If they are not motivated, there are always ways to motivate them. I liked to get bonuses for great work. I was coin operated.

Big projects benefit from a right-sized team. A small team that is too small shows slow progress and they can be demoralizing. Also, it’s best if the team stays together for the entire project or release as the benefits of continuity are well know. People also know what it means to lose a key individual in the middle of a project or to try to replace a key person. It can be painful.

These checklist items relating to people were also improved and reinforced by my research.

Project Team Checklist

1. Adequate resources? If no, what additional resources are needed?
2. Sufficiently skilled team members? If no, what skill areas are missing?
3. Turnover in personnel? If yes, why are people moving off the project?
4. Team is motivated to succeed? If no, what could be done to heighten motivation?
5. Do you trust the team and do they know it? If no, what can be done to build trust?

Regarding the study that I performed, I discovered that 14 percent of the problems with projects were attributed to personnel problems. In ranking, this was the third most important area to focus on.

What’s Next?

Next week, I will explore the other three factors in the model: business, technical and method. At the end of that post, I will recap the research percentages for each of the five factors. You now know that project management was the No. 1 problem area and people were third. By problem area, I mean the largest contributor to project failure when not handled well.

---