The reasons why software projects fail

Introduction

From startups to Fortune 500 companies, custom software development solutions can have profound effects on business processes, customer experience, and the bottom line.

If they’re done right.

But too often, companies invest significant resources in a custom software project, only to see it fail. The organization’s time and money is down the drain, and there’s a good chance leadership is hesitant to invest any further in custom software.

These projects can fail for a number of reasons, and there are usually more than one at play. The good news is, in most cases, disaster is completely preventable.

Let’s take a look at the most common reasons why software development outsourcing projects can fail, how to prevent obstacles from becoming catastrophes, and what to do when a project is in jeopardy.

Poor vendor qualification

While both sides are often at fault for a failing project, the software vendor is primarily responsible for ensuring effective communication, tracking, and adherence to requirements and constraints. So it makes sense that proper vendor qualification should be the foundation of a successful project.

We can split qualification into two components: technical expertise and industry expertise.

On the technical side, customers should look for vendors that are experts in all mainstream platforms and frameworks, meaning they can select and use the technology that’s best suited to meet each customer’s unique needs.

On the industry side, customers need to look for custom software vendors that have experience working on similar solutions in similar industries.

While no custom project will be a perfect match for any other, a team that can bring some related experience to the table will be much more effective than one that’s never encountered a customer’s industry or needs.

While a qualified vendor can make a project go smoothly, choosing an unqualified vendor is likely to lead to inflated (and inaccurate) timelines and cost estimates as well as an inoperable final product.

To check a vendor’s qualifications, we recommend vetting its completed projects for quality and functionality. If you like what you see, give the vendor a test task to learn how the team manages operations and communications. This will give you a clear sense of the vendor’s expertise as well as what it will be like to work together.

Project management: vendor side

A good vendor will have a skilled manager leading each custom software project. The project manager may not be a subject matter expert, and they shouldn’t be a software engineer, but they should have a clear understanding of the customer’s business.

The project manager will be able to communicate clearly and effectively with their own team and with the client, and they will ensure the customer feels informed and empowered throughout the process.

On the contrary, the project manager may not communicate clearly (or at all) and may have no sense of the business needs underlying the technical aspects of a project. If this is the case, the customer is likely to lose faith in the vendor as they keep paying invoices for a project where they have no visibility or control.

Project management: customer side

When a customer is clear about what he needs from his custom software and presents that knowledge clearly and thoroughly, a project is likely to succeed, if the customer has chosen the right developer.

However, if a customer is uncertain about requirements or constantly changes their mind about features and functions, it becomes impossible for even the most qualified vendor to maintain an efficient, cost-effective project.

Every change to scope, every misunderstanding, and every hasty decision leads to increased timelines and costs. This increases tension between the customer and the developer.

At Syberry, we mitigate these risks by running a thorough discovery phase before we kick off our custom software projects. During this phase, our engineers and business analysts work with the customer’s team to understand the and determine the requirements together.

By putting everything on paper and ensuring both vendor and customer are on the same page before development begins, we can ensure the process goes smoothly from the start.

Underestimation of required resources

Cost and time estimates are closely connected to a vendor’s qualifications and a customer’s ability to communicate requirements. Unclear requirements or inexpert development teams can lead to overages on timeline, budget, or both. In software development, there are three primary approaches to contracts:

1. fixed cost: a vendor commits to a specific cost and timeline for a specific scope of work.
2. dedicated team:  a customer pays for a team of specialists and their hours of work, rather than a specific scope.
3. time and materials: a vendor works toward a specific scope, but with no commitment to a specific budget.

Each approach has its benefits, but each can lead to surprises. In a fixed-cost scenario, any changes to the scope incur changes in cost and timeline as well. In dedicated team and time and materials projects, either party may underestimate the final cost, or a dishonest vendor may underestimate upfront, then inflate the timeline once work begins.

It’s up to each customer to identify the approach that works best for their budgets, but we recommend getting quotes from several vendors before choosing a partner. If vendors are using the same hourly rates, the difference in quotes from one to the next should not be more than 15 to 20 percent. If any quote seems ultra high or too good to be true, it probably is.

What to do when things go wrong

If a project is in midstream and starting to lag, the client should remember he’s still in control and can rectify the issue with simple operational measures. Here are three steps to resuscitating a custom software project instead of throwing in the towel.

1. Determine whether the project is in jeopardy

Does the project have a clear plan and timeline? While fluctuations are normal and expected, every change must come with a valid reason. Is the project manager communicating frequently and clearly? Has the vendor demonstrated results throughout the process? There should be milestones marked in the plan, at which the developers show the customer their progress.

2. Systemize the project’s workflow

If the answers to the above questions were no, the next step is to fix the workflow. Customers can request new project managers, progress demos, and more frequent and detailed progress reports. Monthly status updates can become weekly or even daily. For added urgency, customers can tie payments to project milestones.

3. Bring in a third party

If the restructured workflow isn’t solving the problems, it’s time to bring in a second vendor. The first step is to separate quality assurance from development, hiring a third party to check the primary vendor’s code and progress. If this outside QA assessment highlights significant problems, it may be time to hand over some or all of the project to a new vendor.