3 Reasons IT Software Projects Fail


  •  Minute Read

You've heard the war stories of companies that tried to implement commercial software solutions or build new systems. Maybe you've even participated in one or two? Many of these endeavors took longer and cost more than expected. Others were outright failures, adversely impacting the company's bottom line. Let's look at 3 reasons that IT software projects may be challenged or fail.

The Standish Group conducts an annual survey to see why some IT software projects are successful and others fail. Year in and year out, the survey shows approximately one-third of the projects are successful: come in on schedule, on budget, and delivers what was promised. Most projects miss the mark—they are completed late or over budget or lack quality, or some combination of these attributes.

But, it doesn't have to be that way. We can be successful! It starts with understanding the most common causes of software project problems.

3 Biggest Factors to Challenged & Failed Projects

1. Lack of User Input

Imagine a software project where the project team delivers the project on time and under budget. But the software does NOT meet the users' needs. Why does this happen?

Project teams have their pants on fire! Everyone wants the software yesterday.

So, how do most project teams respond? They skip the critical step of collaborating with the users. These teams make assumptions about the user needs without even asking.

Oh, you wanted to have data prefill? Didn't know that.

Want your customers to be able to access their policy information online? Why didn't you say so?

Users assume that the project teams already know their needs. That's not always the case. In fact, often, the teams don't know.

More times than not, users see the software for the first time during training, not earlier in the project when requirements are being elicited or when the software is being designed and configured. Not even when the testing is being performed. The avenues for user input is limited, resulting in less-than-stellar software.

"The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later." —Frederick Brooks

2. Incomplete Requirements

No surprise. If the users are not engaged, the requirements—the users' needs—will not be understood. What happens in these projects whether taking a traditional or agile approach? The missed requirements are discovered later. And, the rework starts, resulting in adverse impacts to the project schedule and budget, as well as the team's morale.

3. Changing Requirements

Project teams complain that users don't know what they want and constantly change their minds. That may be true—sometimes. But, what would you expect when the users are not asked for their input earlier in the projects? Furthermore, we live in ever-changing industries that requires that we be able to handle changes.

Leading IT Software Projects

I know that you're smarter than the average Joe. You know that doing the same thing and expecting different results is insane. Let's take a powerful and decidedly different approach.

  1. Engage your users in the requirements process
  2. Progressively elaborate and refine your requirements with the users
  3. Expect (and even invite) change by using an agile, adaptive approach 

Project Risk Coach Tips

Sign up for the weekly Project Risk Coach blog posts and receive the Project Management Plan Checklist. This will allow you to deliver projects with fewer problems and greater value.

"Intelligent leadership, creative communication and depth of technical skill all describe Harry Hall." –John Bartuska, Director of HR–ONUG Communications

Powered by ConvertKit

You may also like