top of page

Part I: Why 70% of Software Project Fail & How You Can Ensure Success

IN TODAY'S AGE OF AGILE DEVELOPMENT, FORWARD-THINKING MANAGEMENT TECHNIQUES AND NEW-AGE METHODOLOGIES, YOU MIGHT WONDER IF SOFTWARE PROJECT FAILURE STILL EXISTS. THE ANSWER, UNFORTUNATELY, IS YES. THE SOFTWARE INDUSTRY IS LITTERED WITH FAILED PROJECTS; FROM LARGE MULTINATIONALS TO SMALL BUSINESSES, MANY HAVE EXPERIENCED THE EFFECTS OF A FAILED SOFTWARE IMPLEMENTATION. NO ONE IS IMMURE.

So after years of failed projects, why can’t lessons be learnt and failures avoided? This article aims to examine the most common causes of failed software projects and provides advice on how to best recognise and manage symptoms to avoid failure.

What defines a “failed software project?” A software project can be deemed a failure for many reasons. There are many moving parts to a project, and the breakdown or failure of one or more parts could result in failure of the project overall. Five of the most common reasons are outlined below.

NOT DELIVERED ON SCHEDULE One of the most common reasons a project fails is that it is not delivered on schedule as expected. This could be due to a variety of reasons; the vendor may have underestimated the time to deliver the project; or the client may have been too adamant on an unrealistic timeframe. No matter the cause, the unfortunate reality of an overambitious schedule can cause a project to fail, and a project that is not delivered on time can cause significant disruption to the operations of an organisation.

RUNS OVER BUDGET Another common reason for project failure is budget overrun. Whether this is due to unexpected additional work or the vendor having to cut costs to win the business initially, a project that runs over budget is at a significant risk of failure if the client cannot arrange additional funds.

END-USERS DO NOT USE THE SYSTEM Even if the project is delivered on time and within budget, if end-users to do not embrace the system and use it to its capacity then the project is deemed a failure. Why would end-users not use the system? As ridiculous as it may sound, they may not know how to use the system. Often organisations underestimate the amount of training required to ensure staff are competent at using new software. End-users may find the system difficult to use. It may add additional steps to a process but not provide the perceived benefits. Some end-users are hesitant to change and may want to continue doing their job as they have been, regardless of whether the new system makes their job easier.

SYSTEM PROVIDES NO RETURN ON INVESTMENT Often a software system is seen as the light that will lead an organisation out of the dark. Software applications are merely a means to improving certain aspects of a business, they cannot single-handedly change a business without a commitment to improvement. Organisations need to be realistic about what a new software system will provide their business. They need to commit to changing other aspects of the business to support the new software system, if they are to succeed.

VENDOR VS CLIENT RELATIONSHIP A vendor-client relationship should be more of a partnership than a sugar-coated rivalry. No one wants a failed project. The vendor risks their reputation and future prospects if a project fails and a client can often be left out of pocket and at risk of falling behind their competition if a project fails. Therefore, it is in the best interests of the vendor and the client to form a mutually beneficial relationship, where both parties win from an engagement. What can be done to avoid failed projects? We’ve looked at the common reasons software projects fail, now let’s take a look at what can be done to avoid these failures.

SELECTING THE RIGHT VENDOR Selecting the right vendor for you is critical to set your software project on the path to success. You want a vendor who has a track record of experience and proven results. In our experience, the most successful projects are ones where client and vendor are aligned; they have the same values and are striving towards the same goal. Trusting one another is key, and input and engagement from both sides will provide the best results. Don’t just run through procurement; give the business a say and decide together on a variety of criteria to ensure a trusting, ongoing relationship. Price obviously plays a role in selecting the vendor but remember, it is only cheaper if it works. The project should be a collaborative journey, rather than just fulfilling a contract.

ENSURING YOU GET ROI Software projects can be expensive in terms of money, time and effort, so you want to make sure you get the highest return on investment to make it worth your while. Finding the correct partner and building the right business case will help you do this. A concise business case outlines the problems a software system is intending to solve, how this fits into the strategic direction of an organisation, how it will be financed and what ROI will be achieved. Having a strong business case will win the support of management which will aid in the implementation of the software system. At Solentive, we advocate the philosophy of challenging our clients when appropriate; to ensure all the unknown, unknowns have been uncovered and all possibilities have been investigated, ensuring the right solution is developed for your unique problem. This also helps in aligning our goals and clarifying each other’s viewpoints so we are clearly travelling down the same track and there are no nasty surprises along the way.

FUNCTIONAL REQUIREMENTS Before embarking on a system evaluation process, the needs of the organisation must be understood. What areas of the business is the software system intended to support? What functionality is required to support these areas of the business? What do end-users require to make their job easier? How will the impending system fit in with existing software infrastructure? Without a clear understanding of what the software system is trying to solve in an organisation, evaluation of possible software systems cannot be undertaken. Yet, many organisations rush into evaluating software systems without understanding what they actually need. This often results in choosing a system that is not a functional fit and does not support the business as it should.

BUSINESS FIT Once a clear business case is established and the organisational requirements are clearly defined, an organisation needs to consider what type of system would best fit their business. It is easier to assume that an off-the-shelf solution with some customisation will do the job, but if an organisation has unique processes then trying to mould these processes around an existing system may be setting the foundations for failure. On the other hand, an organisation may conclude that it needs a custom solution but may in-fact find that an existing product would better fit their business. There is no rule to determine when an organisation should choose a custom system or opt for an off-the-shelf product. Each organisation needs to determine the best fit for their business. If an organisation lacks the expertise in-house to concisely decide what type of software system they need, then the services of an independent software consultant should be sought. The success of a project highly depends on the type of system that is chosen.

BUILD THE RIGHT SYSTEM FOR END-USERS It is all well and good delivering a project on time and within budget, but if end-users do not embrace the system then what is the point? Solentive’s unique methodology ensures users understand the system and use it to its capacity. We make sure the problem is correctly defined before we develop the solution, and we explore ideas with your customers, your stakeholders and your ecosystem as a whole. The software systems we develop are intuitive, with improved workflow making them easy to navigate. We aim to understand the customer journey and make the users’ life easier – by reducing the time it takes to perform tasks, reducing errors and reducing training time and effort. When end-users feel comfortable and confident in adopting the system, the software project can be deemed a success.

The key takeaways to point you in the direction of success:

  • Select the correct vendor – this is critical in ensuring success. It is best when your goals are aligned and there is input from all sides to ensure clarity.

  • Compile a clear business case – identify the opportunity, benefits and risks of the project and get support from an executive sponsor or team. A business case can also act as a means to evaluate the project once it has been implemented.

  • Write functional requirements – the needs of the organisation must be truly understood in order to deliver the best possible software solution for the client.

  • Identify the best business fit – no organisation is the same and the best software solution for your business will complement your unique processes.

  • Build the right system for your end-users – explore all avenues and possibilities to make sure the right problem is identified and defined before development.

In conclusion, by following the steps above you are pointing your software project in the direction of success. Nobody wants a software project to fail; it is in the best interest of both client and vendor to succeed and the project resulting in a win for all engaged parties.

bottom of page