Why do 70% of software projects fail?  

Kind of a scary number. There are lots of reasons, but oftentimes the failure starts during the planning process. More often than not, the project has failed before it even gets started!

This reminds me of a house my wife and I toured a while back.  The realtor allowed the homeowner (who had actually built the house) to join us on the tour of the house. When we entered through the garage on the lower level, he made a statement something like, “I didn’t have a plan when I built this place. I just poured the basement floor and walls, and started building.” Without going into a lot of detail, the place was a mess.  It seemed like the whole thing had been simple cobbled together with no rhyme or reason.  One room upstairs didn’t even have any windows. Needless to say, we didn’t buy the house, and I would be surprised if anyone did. The build of that house failed during the planning process – or more accurately in this case, the lack of.

As a business owner or a company leader,  you may be ready to embark on an internal software project or perhaps you are planning on contracting a software development company to do this.

Before jumping in, however, take some time to think through the questions below:

 

Question 1 – Have we allowed enough time?

One of the main reasons for project failure is underestimating the amount of time the project will take.

For the most part,  a good development team will be able to give you a solid idea of the time required.  Most likely this estimate is longer than you would like.  The temptation is to begin the “time negotiation” game.  This rarely ends well.

 

Question 2 – Have we minimized the feature set for the first release?

Another big reason for failure is “scope creep”.  Designing a really cool application with lots of bells and whistles can be a lot of fun. Getting it finished and usable is a completely different story.

The first goal is to define the minimum set of features you need and get the application into the hands of the users.  Once your team starts to use the software you will quickly learn what is really important.

It’s usually not adding one big feature,  which causes problems, but the addition of lots of little things. These extra feature ideas can come in from everywhere.

Many of the feature ideas are good but not necessary. The best way to manage this is to have a second release in mind as you work through the development process. This way you can push the great idea to the next release and keep focused while delivering the release you are working on.

 

Question 3 – Can we use the agile development process?

In the early stages of software development,  a project started with an extensive requirements gathering,  design and specification phase. In a big project this could take months. Once the design and specification was done the project then began.

Work would continue until the software was built. There was minimal or no interaction with the end users. This process could take months or even years.

By the time the software was done the needs of the end users changed considerably and the software no longer fulfilled the purpose it was designed for.

Sometimes a project is delivered and it does not fulfill the purpose for which it was built. This can happen when the development team writes the software with minimal interaction with the target user.

On the other hand, the agile process allows several small deliveries with a healthy discussion between the end users and the development team. Oftentimes what seemed like a good approach at the beginning of the project does not work as anticipated.

The agile process allows for ongoing changes throughout the course of the project which will lead to a much better final product.

 

Question 4 – Do we have the right end users available with enough time to work through the process?

In relation to the point above, if the end user does not have enough time to use the latest software delivery and provide good solid feedback to the development team, it will have a negative impact on the project.

 

Question 5 – Do we have a strong development team with the right leader?

In software, the right leader can make or break a project. If you are working on a big project make sure you have a leader who has successfully completed a big project. Interestingly enough, software development consists of both art and science. Experience helps manage the art. Skill and knowledge helps manage the science.

 

Question 6 – Who is going to provide ongoing support?

Developing and maintaining a new software package is more like having a baby than buying a new car. It can take on a life of its own.  It takes constant care and maintenance. Things can go wrong when you least expect them to go wrong.

Most likely the software you develop will be performing a critical business function and will bring great value to your company. You become dependent on it. This is  good, but you need to have a team who can fix problems when they arise.

The support team needs to be able to respond quickly and have a thorough knowledge of the software so they can find the problem and get you back into production.

 

Conclusion

Custom software is not for every organization, but more and more companies are creating software to help them solve problems and scale their business to capture new opportunities.

I have been involved in developing software for most of my adult life. I have seen, and been part of,  both triumphs and failures.  

The failures are painful but help to reach the triumphs.

Ah…but the triumphs; there is something about working on a team to build a software product which then allows a business to accomplish things they never thought possible!  

Having an end user catch you in the hall and tell you their job is enjoyable again, or watching a business expand significantly because of a new software package you created for them,  makes the journey all worthwhile!

 

Have questions about how custom software could work for you? Contact me at bob@sevenverbs.com.