Are Your Software Projects A Success?

Depending on who you listen to, the majority of software projects are failures. In order to determine if a software development project is successful, you must first understand the meaning of success. In this article we’re going to define how we determine whether a project is a success, discuss some known factors that lead to project failure, and ultimately show you how your software development group can help your organization be more in tune with actual business needs (thus, resulting in more successful projects).

Traditionally, we know we can define success in terms of product delivery. If money is spent and no application is delivered, then the project was obviously NOT a success. Software development isn’t quite so cut and dry though. There are other pieces to the software project puzzle that must fit together in order for it to be considered a success. It’s not just about whether or not the project team delivered the product. We have to also take into consideration factors like:

• Was it delivered on time?
• Was the project within the scope of the budget?
• Does the project meet the users’ needs?

If the answer is no to one or more of these questions, then the project could be considered a failure regardless of whether or not a product was delivered. I believe that less than 10% of completed software projects can answer yes to all these additional factors.

Meeting the spec is not the same as meeting the needs

Note that I’ve used the word “needs”above and not “specifications”. This is an important concept to understand. The traditional mindset of software development professionals is that success is measured by whether the spec requirements were met. However, if you ask the business unit, you will find that a badly specified project that meets the specifications is still considered a failure.

Budgetary success

We also need to include the concept of return on investment (ROI) in our definition of success. In other words, can you quantify how much the completed software can:

1. Save your company money
2. Make your company more money
3. Save time which allows your company to become more competitive
4. Meet some legislative requirement

When working with the business unit, I.T. should help them prioritize the development efforts using the above criteria. This way the company will get the most bang for their software development dollars.

Setting expectations

Setting appropriate expectations is a key element in ensuring client satisfaction. For example, let’s say you are bidding on an upcoming project and you give an estimate for completion in 4 weeks. The project ends up taking 6 weeks. The project is not completed on time, and your client is now unhappy. In addition, you spend 2 weeks apologizing and explaining why the product is not ready. Now imagine what would happen if you had given a more conservative estimate of 7-8 weeks. Instead of being 2 weeks late, you could have handed over the finished project 1-2 weeks early.

The more accurate your estimates, the more accurate the ROI calculation. When the estimates are unrealistically short, developers may be working on projects that shouldn’t have been able to be justified by ROI calculations in the first place. This isn’t to suggest that you should always over estimate because your clients will figure out you’re trying to pull a fast one all too quickly. Try to get close, but err on the high side. Make it a habit to under promise and over deliver

Reasons software projects fail

Now that we’ve defined success, let’s look at some specific reasons for why software development projects often fail. Then we’ll dive in and talk about some of the factors that I believe are the main culprits. According to Why Software Fails, an article found at “IEEE Spectrum Online,” the following items were cited in no particular order as some of the most prominent reasons for why software projects fail.

1. Unrealistic or inarticulate project goals
2. Inaccurate estimates of needed resources
3. Badly defined system requirements
4. Poor reporting of the project’s status
5. Unmanaged risks
6. Poor communication among customers, developers, and users
7. Use of immature technology
8. Inability to handle the project’s complexity
9. Sloppy development practices
10. Poor project management
11. Stakeholder politics
12. Commercial Pressures.

Looking at this list, you can see that the majority of these fall into three main categories:

• Communications
• Project Planning
• Technical

The first two categories are by far the hardest of the three. The technical issues are typically much easier to deal with; however, when there are insurmountable technical issues, it is often due to poor project planning. If the project doesn’t have an appropriate level of technical expertise represented within the selected team, then the project is doomed from the start.

What's missing from the above reasons

The list above may look and feel comprehensive, but in my opinion, it’s missing some important ones. Specifically, it’s missing client perception and project size as key reasons for project failure. These factors may not be obvious at first, and your initial thoughts may be that I’m wrong. But let me explain.

People hear what they want to hear, regardless of whether it’s really what you said to begin with. This is how your client’s perception of what you just said can be damaging to your project. For example. Let’s say you just gave your client an estimate for the finished application of 4-8 weeks. Your client agrees that this is a reasonable time frame for the project and gives you the go ahead to get started. You and your team have now been working for 5 weeks and are not quite finished with the project. All of a sudden your client is calling upset because he hasn’t received his product yet. See your client heard what he wanted to hear when you gave him the time estimate for the project. You said 4-8 weeks, but he heard 4 weeks. Now he’s ready to pull the plug and hand the project over to someone else all because of perception. It’s important to make sure that your clients have a clear concise understanding of what to expect during the project or it could mean the end of the road for you and your team.

Large projects = larger change for failure

Another key factor in this discussion is the size of the development effort. The larger the project, the greater the chance of failure. For this reason, it is important to break your project down into smaller parts and deliver the parts that have the highest ROI first. We will delve into how you can accomplish this in the 2^nd part of this series. This next article will show why you may want to consider an agile development approach if you aren’t already doing so.