Software project failure, and how to avoid it

You’ve got a great idea that you want to build on, or an existing business looking to expand your operations online and at some point, it’s going to need tech.

No doubt you’ve done your research, spoken to clients, and you’re building knowledge on where your market is, how to maximise your opportunities, and plan to build a framework that will bring you success. You’ve listened, you’ve had valuable feedback and data, and this has been used to improve your project. You’re quick to change and can adapt to meet your market…

So, why is it that when it comes to businesses building tech, the emphasis moves from understanding the business to understanding the tech?

When tech agencies and businesses get together, there often becomes a rationale that “we know everything we need to know, so let’s now build it”.

The thinking stops, the listening stops, and the build begins.

People stop listening, instead of asking “what can we learn from this?” and continuing to explore.

Recently, I was asked to observe a journey between a client and its tech agency from the first meeting to the end. The result was not positive.

The client was annoyed they had lost time and did not get what they asked for.
The agency was shocked as they thought they understood the brief.

The failure was not obvious to the client until the end. So, wanting to understand how it happened, the client and I held a retrospective (thanks retrotool.io !) to identify when the project passed the point of no return. We reviewed the planning sessions, communication flow, the build, and the final presentation to the client. We were shocked by the findings…

Projects going wrong is not uncommon, a survey of professional Project Managers (2017) found that 49% of projects experienced scope creep and/or increased cost. It also found that the failure rate of IT projects is 14%. What is confronting is that this survey was taken amongst professionals who have experience in handling this type of work, and yet even they get it wrong.

The illusion of understanding

So, how and where did the project go wrong and who is to blame? Did the client properly brief the agency? Did the agency not understand the brief? Both client and agency believed they had understood one another.

Are they talking the same language?

This is where the feedback from our retrospective (thanks Retrottl.io !) got very interesting. We identified that critical failure happened in the first 30 minutes of the very first meeting.

In this case, there was a moment when the client and agency reached an illusion of understanding of what they are going to do together, and the build started.

Both believed that no other questions needed to be asked.

The retrospective (shout out again to the online retrotool.io guys for a great product!) showed clearly that the path of failure started in the very first meeting. Every action from the point of agreement led to failure, so what could be done differently?

3-dimensional thinking

Don’t ask ‘how’, ask ‘why’. You are in a world of conceptual thinking. In our experience, planning any new project is totally conceptual. It takes creative thinking, vision, understanding of business, and expertise in technology to work. You are moving into unknowns and the key is to gain understanding in your journey.

Your project also must work today, work tomorrow, and be planned well enough to be improved and updated in the future without becoming unstable or slow.

Many projects we see come to a full exploration-stop without questioning in the planning, or during the build.

And here lies the rub. Earlier I talked about the retrospective and in it we saw:

Height – The client framed the build from the point of their business. They believed they were clear about what they believed they wanted to build.

Width – The agency translated the client brief into build features and applied it across the width of their tech stack knowledge.

But there was no Depth, and depth is where business experience, technical experience and project-build experience comes together to build a holistic strategy that continually questions whether the build remains relevant to the client’s business.

“You’ve got to start with the customer experience and work back toward the technology – not the other way round” – Steve Jobs

Steve Jobs also said that one of the first things he learnt was, “what we were missing was to provide benefits to our Users.” So the ‘why’ needs to include ‘is there a benefit to users?’

Agencies asking business questions is ‘push back’ to better understand ‘why’. In our mind, the project is not an endpoint in exploration, but rather the test-bed for exploration that will provide ongoing data which we will all (client included) be able to make knowledge-based decisions as we progress.

Depth results in becoming a better business

A really keyword in Steve Jobs’ quote was ‘benefits’. Too often this gets confused with features. Agencies love to build features, but the question is, does the user value them?

How do you identify ‘Depth’ in an agency? Having left us over price, a client once told us that they had returned to us their replacement agency did exactly what was asked of them, and that wasn’t good enough to give the client the edge in business.
As an agency, we spend about 80% our time talking potential clients out of starting to build anything.

Here’s a checklist to evaluate your tech. journey:

Exploration is critical: can you run your project manually? Here is where you will learn what users like and dislike about your project.
Exploration does not stop when a build begins (it is not a hard stop).
Pile up everything you know and label it ‘the why’, then ask yourself ‘does it benefit the users?’
Don’t think MVP, build a MEP (Minimum Economic Platform) What is the simplest, stripped-down version of what you need?
Ask your clients and prospective Users and keep asking them – not just at the beginning, but continuously. Their feedback will shape the product into its best iteration.

What journey is the User going to take? Avoid the Qantas $40m platform that no engineer used. Guess who Qantas didn’t consult during the planning and build?
Test your intuition and get feedback from your Users – you’ll quickly know if you are right or wrong.
If you run out of questions, you have either stopped asking, or actually have enough data to make a knowledge-based decision – which is it?
Lastly, what are you learning about your business and your project? As you start your build, you should be continuously learning.

Choosing an agency

An agency should work as a bridge between business and tech. It should interpret your needs into tech, but also push back and demonstrate Depth – what questions are they asking you? Do they focus on the tech or the user journey?

It takes 3-dimensional thinking that goes beyond the high aspirations of the client and the width of an agency’s technical stack. It takes a depth of understanding to answer the questions that have not yet been thought of from the information we do not yet have.

Does the agency understand ‘the why’ of your project? Do they get what you’re trying to achieve?

“The important thing is not to stop questioning” – Albert Einstein

Jonathan Castletine-Jackson is the doorman into u2i, a bespoke IT Development agency that builds relationships to understand your business before it builds your tech.