An increasing number of businesses are turning to custom software to improve company processes and drive efficiencies, but before selecting a software development partner, they should look out for certain qualities that can give them the confidence that a project will be completed on time, on budget, and deliver what is really needed.

Lost in translation

A big challenge in the custom development process is the ability of the development team to understand exactly what the business or client is looking for, and to accurately translate this requirement to the developers. Without this, the result can be a product that isn’t what the end-user requires.

This is where it helps for a development house to know the customer well: “A long-term relationship means that the development team understands the client, their processes, and their business requirements,” says redPanda CEO, Gareth Hawkey. A deeper knowledge of the customer means that the software development team is able to ‘fill in the gaps’.

“It also helps if the developers and business analysts involved have a strong domain knowledge, with experience in the specific sector in which the client operates,” adds Hawkey. “The development team can then understand what processes are involved and will be able to anticipate wants and needs, as well as identify potential problems before they arise.”

What’s more, a good working relationship with the client means a higher probability of a cultural fit, which builds transparency and trust enabling the development team to effectively interrogate the client’s requirements, and provide sound advice.

It’s about expectations

Planning of the project is vital as businesses want to know how much will have to be spent, and how long the development and implementation will take. Software development projects often fail due to misconceptions of the process and unrealistic deadlines.

While on the surface, some requirements may seem quick or easy, the development process that underpins these may not be and rushing to meet an unrealistic deadline usually results in bugs and ultimately further delays. In addition, upgrading legacy systems or managing third-party software integration takes time, and it is imperative that there is a clear understanding between client and developer on the delivery timeframes before the project starts.

The success of this relies on the relationship and creating awareness about the software development cycle and timeframes involved, requiring buy-in and involvement from the client’s IT professionals as well as senior decision makers.

Pragmatic agility in development

Ensuring that a project is completed within a fixed timeframe and budget, something vital for any business commissioning the development of new software, is also sometimes difficult to balance with the benefits of an agile development process. This balance can be found through a Pragmatic Agile approach to building software.

Hawkey explains that for the development teams at redPanda, this involves three levels of detail. At the start of engagement, the outcomes and objectives are clearly defined so all stakeholders in the project are aiming for the same goal posts. Detailed specifications and designs can then be set out which act as a reference point, and finally, the development can be carried out based on “just-in-time” design and planning.

There is an estimate which states that 80% of software functionality is only used 20% of the time. “This is why we take a pragmatic agile approach”, says Hawkey, “It allows us to provide decision makers with a fixed timeframe, budget and scope, making sure the core functionality is included and finalised, after which we are able to build on the product once it’s been tested in the operational environment.”

Building in a testing mindset

Testing a finished product is always essential, but starting to think about this stage earlier in the process helps to keep the project on track and heading in the right direction, with the best user experience in mind.

Working from the detailed specifications created, acceptance criteria and specific scenarios are defined against which the software will be tested. According to Hawkey, doing this at the outset not only brings the user into the detail of the software project, but allows the developers to focus on what they are good at: developing great technology. He says, “The fact that tests were defined at a business level means that business users, business analysts, developers and software testers all speak the same language and know exactly how the software is supposed to work.”

With this in place, testers can record automated tests that mimic user interaction with the software, and software release cycles are improved due to the high quality of the code. Of this process, Hawkey says, “The end result is true transparency in the process with all stakeholders on the same page and a high level of trust, good quality, robust software without unexpected scope creep, and ultimately, happy customers.”