5 Ways Custom Software Can Go Wrong

Recently, I was reading trying to jumpstart ideas for blog creation when I came across this statistic:

52.7% of software projects will cost 189% of their original estimate

It jumped out at me and I started thinking about the multiple ways a custom software project can go wrong. Going over the original budget is just one, although a big one. In fact, from the 5 ways, I have listed below going over budget will definitely occur if you don’t pay attention. Knowing how a project can go wrong can help you make sure your project stays on track.

No Strategy

You know what you want your software to do. You’ve thought about this, and have ideas for features and workflows. You may know in your mind how your application will integrate with legacy software or even that it will be replacing a frankensystem.

However, if you don’t spend time planning, defining user stories, workflows, and such you may end up wasting time and money along the way.

If you are researching a company to help you develop an application, make sure that you know how the company plans the work, organizes the work, and delivers the work.

Airship starts work with you in one of two ways: if you have a project already in existence, a brownfield project, we do a tech audit or a tech feasibility study to determine if we can help you.

If you are building something from scratch, what is called a greenfield project, we start with a strategy session. Depending on what you need, our head of Product Design will walk you through a variety of activities to drill down into the specific objectives and users. You will emerge with a course of action from which you can chart your next step.

Sometimes that step means not moving forward. Recently, we began work with a client that had a third-party software their product would need to integrate with. We began to drill down into the strategy and realized quickly that our client’s dependence on this third-party software had the potential to throw a wrench in the process that could end up derailing the entire project.

Our recommendation, go back to the third-party provider to see if they had something that would work for their needs. We knew that unless they were prepared to spend a lot of money, time, and energy that it wasn’t prudent for us to even begin development. That is the reason why you do a tech audit and look at tech feasibility before developing a strategy.

We use an Agile approach to software development. What does this mean to you? It means you work with a team of developers, a product manager, and UAT inspectors to map out a plan of what you want to achieve. The team breaks down your plan into a 12-week delivery cycle consisting of 2-week sprints. Each sprint is planned and paced and then reviewed to plan the next sprint. In this way, you can be assured that your product is being reviewed each step of the way.

Why is this important? You may believe you know how a user will interact with a product but as it is built, you will learn and changes may need to be made for a better user experience or easier to use workflow.

User Research

You may start a project defining a user one way and get involved and realize the software will fit a different user much better.

Defining the “why” will help you ensure that you’ve defined the “who” properly.

And, don’t just think that defining the user at the beginning of your project is all you need to do. Along the way, it is important to continue user research. The results of the research will help you and the team determine the best next steps to take in your products development.

Focusing on Cost

There isn’t an endless budget but companies should focus on the value of what they want to develop not necessarily the cost to develop it.

At Airship, we always ask what is the most important time, money, or features. If getting your project done quickly is your highest priority, you may spend a little more money. However, if money is the most critical factor then you will need to dial into your objectives a bit more to figure out what is necessary for an initial launch. We have a great blog post on developing an MVP.

Sometimes you begin a project and as you work through the first cycle you realize that your priorities are changing. One client began their build with money and time as their top priorities, however, as the product began to come together, their team realized that it was better for them to spend a little more money and take a little more time to create an exceptional piece of software. Constant communication during the sprint cycle of development meant we could pivot and give the client more of what they wanted. Speaking of communication…

Failure to Communicate

Ever heard the line from the movie Cool Hand Luke, “what we have here is a failure to communicate?”

Communication is everything when it comes to software development. We believe so strongly in the importance of communication that two of our client guidelines address just this.

  • Collaboration over task mastering, because you’re looking for experienced experts with perspective and value the collaboration on how to execute your vision.
  • Engagement and shared responsibility in decisions, because the long-term success of a project depends on our client’s providing individuals who have full authority to make choices about what will be in the final product and how money can be spent to accomplish the goals.

We use the SCRUM framework in our iterative development and that means we are in constant communication with you the product owner. Every two weeks we review what has been developed, discuss what is next, and set priorities with you. We give sprint updates, and progress reports and ask that you give feedback not just to the team but also to our CEO, Trent Kocurek in the form of a monthly NPS survey.

Living into our vision of creating transformational change via remarkable experiences can only occur if we are all on the same page and communicating properly.

Integration Issues

Developing a new product that has to play well with others isn’t always the easiest thing to do. APIs or partnering with other technology can be a challenge. That’s why doing a tech audit /tech feasibility study at the beginning of your project will determine if what you want to develop is practical.

If you have an existing product or are building a new product that you want to work with a legacy system or third-party provider NOT spending the time to determine if what you want to create is feasible can at the end of the day cost you a heck of a lot of time, money, and effort.

When we begin to chart a course with new clients, having our lead builders look under the hood and poke around existing systems is required before we can move ahead.

A few statistics on integration –

  • Deloitte and Mulesoft (2022): companies now use an average of 976 applications, with only 28% of these being integrated
  • And, in 2021 Deloitte’s study found that 45% of respondents cite poor integration as one of the main barriers to the effective application of digital technology

Integration is critical to the success of your project. Spending time determining the hows and whys of integration can mean the success or failure of your project.

Creating Custom Software

Developing a custom software product is a collaborative ongoing process. You don’t just build it and leave it alone. Constant enhancements, updates, and maintenance are necessary in order for you to get the maximum benefit out of what you’ve created.

Have you been thinking about replacing a legacy system? Or, perhaps, your off-the-shelf software isn’t enough anymore. We’re not sure we can help you but let’s spend some time talking. Look forward to speaking with you.

Ready to get started?