Failure is not an Option

Reasons Why IT Projects Fail and How to Overcome Them

According to a 2017 report from the Project Management Institute (PMI):

0 %
of all IT Projects fail

Of those that didn’t fail outright:

0 %
didn’t meet their goals
0 %
exceeded their initial budgets
0 %
were late

We’ll take a look at the 9 top reasons why IT projects failed, followed by suggestions on how to avoid or overcome them

1. Inaccurate Requirements

0 %
of failed projects are due to bad requirements

In order for a project to be deemed successful, all of the following 6 factors must be satisfied:

a.       The project must be delivered on time.

b.       The cost does not exceed the budget

c.       It works exactly as designed.

d.       People use it.

e.       The people who funded the project are happy with it.

f.        It meets the goals that drove the project.

It takes quite of dedication, resources and a dash of luck to build something that does what it’s supposed to do, meets its goals, and makes sponsors happy when you don’t have good requirements to work from – much less within budget and before the deadline is reached.

Requirements often cause projects to fail when sponsors write specification documents with consulting with the development team.

To avoid this problem, involve all concerned parties, be it the business team, development team members and even end users during the requirements elicitation phase of a project.

Account representatives work with end users to document the “what” – the goals of the project.

The development team weighs in on the “how” – the best way to build what is requested.

When both parties work in tandem, it greatly reduces the risk of project failure resulting from inadequate or incorrect requirements.

2. Uninvolved Clients

0 %
of failed projects are due to inadequate client support

Operating inside a vacuum is a recipe for failure when it comes to development. Instead of staying involved during the development phase, the client/project sponsors hand off the requirements, never to be heard from again until the product delivery date. 

This leaves teams with no representative to contact when questions arise. Instead, they are forced to make an educated guess and carry on developing. If they guess wrong, the client doesn’t find out until development concludes. This leads to unhappy clients, products that aren’t fit for release, and complex changes that leave the project overdue and over budget.

To avoid this failure, ensure an appointed business representative participates during the development phase. He/she answers any questions the development team may have about requirements, and constantly reviews all progress to ensure that what’s developed satisfies the original requests.

3. Shifting Project Objectives

0 %
of failed projects are caused by shifting objectives

All IT projects are bound by the triple constraint: time, scope, and budget.

Using a traditional waterfall approach, time and scope are fixed, but the budget is flexible. The development team delivers the solution by a specified deadline. If that’s not possible, teams increase the budget to increase the amount of work they’re able to complete in the allotted time frame.

Using an Agile approach, time and budget are fixed, but the scope is flexible. As very few projects go according to plan, a system was built that allows teams to shift priorities as needed.

While it might not be possible to control changing project objectives, it is possible to minimize their impact by working in a model that supports change when required.

Most Agile teams including Dotnet Professionals operate in a Scrum framework. Scrum teams work in short iterations or sprints that are usually between one week and one month long. At the beginning of each sprint, the team plans its work. During the sprint, the plan cannot change, but each new sprint represents an opportunity to change the plan.


Changes in the plan don’t have to lead to failure. Minimize this risk by reducing the timeframe of plans. Plan work in two-week sprints: determine which task are the most important, and focus on the tasks you’re able to complete during those two weeks. This ensures that the development team is always focused on the highest priority task and consistently releases functional code.

4. Inaccurate Estimates

0 %
of failures are due to inaccurate estimates

During the earliest phases of any IT project, estimates are at best-educated guesses. Because teams know so little about project requirements and dependencies, cost and time estimates may be up to four times more or even less than actual implementation costs and timeframes.

As the project matures, that variability lessens, but the only time it’s ever at zero is when the project is complete.

Estimates are seen as a necessary evil in IT projects because few business sponsors are willing to hand over a blank check. Before approving projects, clients need some sense of whether or not they can afford the cost—and whether or not the cost is worth the investment.

Inaccurate estimates are the result of either:

Poor Estimation Practices

  • Inexperienced development teams often underestimate time and costs, providing estimates that assume everything will go smoothly.
  • The solution is to provide ranged estimates. For example, if developers estimate that the project will take a month to complete, look at the cone of uncertainty for the range that applies to your current project phase.


Upfront Planning

  • Project managers request an estimate during the initiation phase but never bother returning to the team to find out if the estimate is still feasible.
  • Have the development team revisit the plan continuously to determine if the project is still on track.

With proper planning and estimation, teams can usually deliver a minimum viable product on time and within budget. From the client’s perspective, getting less than what you hoped for is always better than getting nothing at all.


5. Unexpected Risks

0 %
of failures are because of unexpected risks

The Project Management Institute categorizes risks as follows:

  • Known knowns are risks you know about and can plan to mitigate.

E.g., you’re dependent on another team completing their coding before you can begin, but that other team hasn’t yet committed to completing the work. As such you can plan for the worst-case scenario.

  • Known unknowns are issues you know about that have the potential to become risks.

E.g., a team you are dependent on has committed to delivering their code on a specific date, but they are notoriously late. Even though you cannot say for certain it’s a risk yet, you know it might become one, so you can plan accordingly.

  • Unknown unknowns are risks that can catch you completely off-guard.

E.g., Midway through coding, you discover a dependency on a 3rd party you have not talked to at all, so there is no guarantee that this they will have the capacity to complete the work you now need from them.

The solution is the same as in the previous point; be sure to make estimations that reflect both known and unknown risks.

In the project initiation phase, your team estimates that it will take a month to complete the coding. However, since there is still such a high potential for unknown unknowns to pop up, relay an estimate of four times that size to the project sponsor.

That extra time will provide a buffer to handle any unexpected risks that crop up. Best-case scenario, you finish three months early. Telling a client that you finished early and under-budget is always preferable to saying that the project will be late and cost extra.

6. Dependency Delays

0 %
of failures are due to dependency delays

The larger and more complex IT projects, it’s more likely there will be several teams involved.

Said dependencies could be internal departments that manage specific platforms or perhaps they can be vendor customizing a product or service the company purchased.

When other teams you’re dependent on fail to deliver on time, it can derail the project.

While there is not a lot you can do to rush other teams along and make sure they finish their part on time, but you can mitigate the risk with proper planning and estimation.

Dependency delays fall into the category of known unknowns, so plan accordingly. Use the cone of uncertainty on estimates from other teams.

In the meantime, have your team work on tasks that aren’t dependent on another team’s changes. If that’s not possible, wait until the other team finishes before beginning your work on the project.


7. Insufficient Resources

0 %
of failed projects are accounted by insufficient resources

Project managers use the word “resources” to refer to people, i.e “not enough resources” refers to not having enough people to complete the work for a project.

In the Waterfall methodology, the budget is fixed, meaning you have the funds to add as many people as needed to complete the work. In the Agile methodology, the scope is fixed, meaning you only commit to the amount of work that your existing team members can complete.

Trying to run projects where scope, budget, and timeframes are all fixed will result in failure if there aren’t enough people. Lacking the proper resources should never be the cause of a failed project rather it should only be the reason why a project never got started. With proper planning, it should be obvious from the beginning that there just isn’t enough resources.

The solution to this problem is to simply make flexible one of the three constraints of a project to account for unexpected risks: time, budget, or scope. If you have to deliver something within a certain timeframe and budget, try committing to a smaller scope. If you have to deliver the full scope within a certain timeframe, wait until more resources become available before beginning work on the project.

Attempting to set all three constraints in stone is a recipe for disaster.

8. Poor Project Management

0 %
of failures are due to inadequate project management oversight

The project budget is being consumed too quickly, or teams are missing targets – these are signs that a project plan is going awry. However, the signs are only obvious if someone is watching.

Creating a plan for a project isn’t enough. A project manager, IT manager, or Scrum Master – it doesn’t really matter who as long as someone is monitoring progress.

If you assign a person with no tangible project management experience, make sure to invest in some training before the project kick-off. Have that person study long-term for a PMI certification, or simply ask him/her to spend a few days reading about the types of planning exercises used in Agile.

9. Team Member Procrastination

0 %
of project failures are caused by team procrastination

Team member procrastination is closely associated with poor project management. It should be obvious that the project plan is about to be derailed, if developers are procrastinating or conversely, the people the developers are depending on are not supplying answers, code, or services.

In addition to monitoring the plan, the project manager must keep a record of issues and requests, and then push those responsible to deliver.

Look for a project manager who is detail-oriented, organized, assertive and isn’t afraid to go through appropriate channels in order to resolve issues.

Improving IT project outcomes by managing risk

IT projects that succeed do so by managing risks:

  • Make sure all involved teams have a voice throughout the project lifecycle to minimize the likelihood of scope creep, inadequate/wrong requirements, missed deadlines and shoddy products.
  • Set one constraint of project management (time, budget, or scope) as flexible. Re-plan frequently to make sure plans are still on track, or to adjust plans before the project goes off-track.
  • When in doubt, apply the cone of uncertainty to estimates from all relevant parties to mitigate the risks of unexpected delays.
  • Make someone accountable for monitoring the plan and for risk management before progress spirals out of control.

Mitigating the risks of IT projects is no mean feat, but if the outcome is improved project success rates, ROI, and team morale; all that hard work is vindicated.

Leave a Reply

Your email address will not be published.