Skip to content

Let's make systemic software failures a thing of the past!

Much has been written about the well-known car rental company that has sued a prominent global systems integrator for $32 million. This comes after a core website overhaul – a critical part of the company’s digital strategy – went sour. Sadly, this kind of systemic failure is one we see replicated many times in the software industry. But there is a way to prevent these failures and to ensure all parties are celebrating at the end of their engagement, rather than seeing each other in court.

As has been highlighted in the recent Hertz vs Accenture lawsuit, failed software projects cost millions of dollars, and while they often present an opportunity for companies like NearForm to enter stage right and clear up, they're not ideal – for anyone. These failures aren’t just a matter of missed deadlines or lost revenues: the recent Boeing crashes, for instance, were directly traced to software failures.

Software can do better. Our industry as a whole must do better.

The official figures are horrific: the most recent Standish Group Report outlines a mere 29% success rate for software projects, and those are only the official statistics; the unofficial or unreported numbers are probably much worse. The inability to execute on time and within budget is a crisis of the modern software industry.

What went wrong in this instance?

While it’s easy to look at that lawsuit and pick apart the individual components, the root problem comes down to the client deciding to outsource a core competency – the redevelopment of the central piece of e-commerce software its business heavily relies on – instead of taking active ownership and responsibility for its development. Some things are just too important to entirely hand over to a service provider.

The company may need to bring in external help with such a digital transformation in order to carry out the project internally, but it’s not always wise to outsource to an external vendor in its entirety. Instead, bring in expert help where you need it; experts who don't want you to leave it all to them, experts that can not only help you build your own capability and help with capacity but also to strategically advise you on executing your Digital Strategy.

Starting out on the right foot: Discover, Deliver, Transition

In a nutshell, what most enterprises need is not a stop-gap but a deeper engagement that helps to build up their own capability and lays the foundations for continuous innovation and growth within the organisation. When we do this ourselves, we work very closely with the client to design, build, and then transfer or transition the working system back to the client. This ‘Discover, Deliver, Transfer’ process allows the client to build up its own store of modern, software development DNA inside its four walls. Rather than giving money to a vendor to develop the entire thing behind closed doors, focus on a deeper engagement that builds up your own capability.

My instinct is that many organisations do have a strong internal software development capability, we see this first hand. However, lack of trust and internal politics are common key factors that trigger the decision to fully outsource – and external consultants, in a sad pattern that's often repeated, were more likely to be listened to and trusted than the company's own personnel.

I also suspect that complicating factors were at work: once the systems integrator went under the hood with the client, it probably discovered a spaghetti junction of disparate systems that were difficult to work with and refused to interoperate.

Legacy systems and legacy resources

Let me be clear: legacy systems are a reality that we all have to manage, and they can be the downfall of many new digital initiatives. Successful transformation often means you need to work with what’s there; modernising where it makes sense, while also bringing in newer technology and writing new services to meet the requirements of the business.

On the resourcing side, early on in engagement, it’s important to assess what kind of team is needed, and the extent to which internal resources need to be supplemented with partner resources.

In some instances, we help clients hire in new permanent staff with the skills needed to develop and operate the finished system once we transfer it back. We've done this very successfully: recently we worked with a client who decided to spin up a new business unit to pursue an innovative concept they wanted to bring to market. On day one, the business unit had no staff; as they hired and grew in the first few weeks and months, we built the product in parallel, augmenting and replacing our team as they found their own key talent.

A design-led process for transformation

Most, if not all, of our projects, start with a Discovery Phase, following which we develop a high-fidelity prototype in a matter of weeks.

We put a huge emphasis on architecture (which is often and unfortunately overlooked in many Agile projects), and on understanding the systems we’ll be working with, including the client's legacy systems. The development plan is the second key outcome of the Discovery Phase; what it is we are building, why we are building it, and how we are going to build it.

After that, we develop the final outcome of the Discovery Phase -  the work plan; a refined view of what's to be done, the resources needed, and the timeline. These are the 3 valuable outputs of the Discovery Phase: the prototype , the architecture and the work plan.

Following this, we move on to the Delivery Phase. This is always done quickly, usually in 3 to 6 months. It's a real "Avengers assemble" moment where we bring in a team of our very best people to create a Minimal Viable Product (MVP). This involves a close partnership with the Client, often augmenting the team with resources from the client; helping them to build and modernise their software development capability.

A world built on software

In summary, I want to reiterate that clients cannot afford to completely outsource any core competency; and I'd argue that software development is absolutely a core competency - even if you are not a software company. Any large or global organisation has software resources, but it may not have a modern and up-to-date capability, or may even be struggling with capacity. That's what it needs to work on. Companies can't simply throw all that responsibility over the fence to a systems integrator, especially where the end result is one the company hopes will create new innovative business models, or will offer a differentiating customer experience.

The final part of the NearForm process is the Transition Phase. Here we transition responsibility back to the client for the software we have co-created, in a phased, controlled and timely fashion. We are accountable to the client right up until the very final transfer, and thereafter we are always available for further collaboration.

We want to see you, our client, thriving and using the systems we built together. We want you to be capable of adding your own new features as your business thinks of new opportunities and other business models it wants to pursue.

Any piece of software and any organisation must be able to evolve. Embracing that idea, and transforming your own software development capability is the best way to ensure competitiveness into the future.

Let's make those systemic software failures a footnote of history. And let's see software development partners and enterprises working together to make that happen. Damian Beresford is Technical Director of NearForm, and partners with organisations across the globe to help them achieve sustainable innovation through the design & delivery of open software, methodologies and technologies.

 If you’d like to understand how we can help you stay relevant & scale to demand, contact us for an exploratory review and feel free to connect with Damian on LinkedIn. 

Insight, imagination and expertly engineered solutions to accelerate and sustain progress.

Contact