Discover the Root Cause of High Failure Rate within Custom Software Development

On Oct. 1, 2013 Healthcare.gov first launched and promptly crashed two hours later. A mere 6 people nationwide enrolled in the health care plan that day. The final budget was an astounding $1.7B (initially estimated to cost $93.7M). Various media outlets and analysts attempted to provide reasons for the failure.

Per a Standish CHAOS report, a staggering 31.1% of projects will be cancelled before they are completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. On the successful side, only 16.2% of software projects are completed on- time and on-budget. So what can we do to help our project be one of the 16.2 %?

How do we define a software’s success?

If a software lines up perfectly with each of the requirements and has been delivered on time and on budget, do we call it a success? Many would answer “yes”. What if a project satisfies all the requirements but it fails to receive the system users’ acceptance ? Can we still call the project a success? The answer is NO. A business invests money to not only create software but also to better support the business and its goals. As leaders within the business world, we define a software’s ultimate success as one which complements and enhances the business’s goals. A software’s ultimate success is dependent upon all relevant departments, IT, and non-IT personnel.

The obvious and the …not so obvious failures

Failing to achieve business goals, surpassing budgets, delays, and broken transition management are some of the main areas in which custom software generally fail. In addition, system security and the lack of expansion potential are also common issues many types of software fail to catch. These are all issues many of generally think of when we think of potential reason for project failure, however, there is also one bigger issue many people seem to overlook.

While it is software failure, the issue sometimes stems from a deeper issue. When analyzing many of these instances, the immature business process itself is often causing the problem. Business processes must be setup before it can be improved, matured, and stabilized over time. If the process is underdeveloped, designing a software to implement the immature process results in management of the wrong processes. After the implementation, the business may not receive the expected results. In this situation, people often mistake it for an issue within the software. As such, businesses must be able to simultaneously improve their business processes while updating the software to support the processes.

What are the root causes of these failures?

There are various causes of failure: poor delegation, wrong decision-making, faulty plans, failure to resolve conflicts between team members, inefficient communication, resistance to new procedures, user-unfriendly system, inappropriate transition management, etc. These issues result from not following adequate project management processes.

Surprisingly, many projects fail due to wrong delegation of key personnel. One of the root causes of Healthcare.gov’s failure was the poor choice in project leadership.

Problems within an organization’s culture can also lead to a project’s failure, especially within government projects. Team-oriented mindsets are extremely critical to any project’s success. Many teams, fearing confrontation, fail to address issues outright, allowing problems to continue. A high-trust, accepting environment, and efficient team is crucial for the success of a complex software project.

As a thought leader, what is the check list to establish a successful foundation?

1. Do we have a project committee? Does it have the right people in it?

2. What type of culture and mindset does our project committee have?

3. What process must we follow to make decisions including the software’s role in the business?

4. Is our software project plan executable, measurable, and adjustable when needed?

5. Do we have the right talent and how do we delegate resources?

6. How will the project manager manage communication, progress, risks, experiment costs, buy-in from task holders, and the system’s final users?