The horror stories of tech projects gone bad, we have all heard them.

Budget blowout, failure to meet a deadline or just a downright train-wreck that ends up with the whole project in the bin…whatever the type of crash, these stories are sadly all too common.

Whenever I meet a new client for the first time, they usually are full with enthusiasm and excitement about their idea and how it will change the world...which is AWESOME!

But whilst I encourage their enthusiasm, I'm known (for better or worse) for giving the reality check by explaining the core reasons why most tech projects go bad and how I can help them avoid the pitfalls. These conversations are normally met with blank pale expressions as clients realise just how challenging and rare it is for a tech project to be a true success.

Why do I do this? Not because I'm a sadist. I do it because, at the end of the day, I see my job isn't just to take their money and ‘do my best’ but rather to help coach my clients in avoiding all the mistakes made by others (and me) in the past.

So, what are the main reason for technology disasters? There are a few core themes:

1. Poor Or Zero Scoping.

Me: “I would like to suggest we do a full scoping session to kick off your project.”

Client: “Scoping? What the heck is that? Can’t I just tell you my idea and you can build it?”

Me: “Well yes I can. But it will likely end up as another disaster. It's your call."

I hate, literally hate, doing project for clients without a full scoping stage first. Not because it makes my life difficult, but because I know the outcome won’t be as good…the client won’t be as happy as they could have been.

So what is scoping? Basically it involves a few stages

• Project Scoping. This is normally a 3-4 hour session where I ban mobiles and focus all stakeholders on explaining their idea whilst I ask a lot of dumb questions to flesh out the detail. This is also a great time to challenge thinking, suggest alternative approaches and basically get everyone on the same page.
• Wireframing. Next, it is a great idea to wireframe the concepts from the workshop. If you're not familar with wireframing, read more HERE. My team mocks up a set of complete wireframes, presents to the client who then reviews and marks up changes and comments. We go back and forth like this as many time as it takes to nail the wireframes. This is probably, in my view, the most important stage to get right as if wireframing is done properly, all else flows smoothly thereafter.
• Design. Now it’s time to think about colours, fonts, buttons and general look and feel. Once wireframes are clear, the design team creates beautiful photoshop designs of every single view within the software.
• Technology Stack and Architecture. As discussed later, choosing the wrong technology stack can be a disaster, so now is the time to review options with the client and make a clear decision on the best mix of technologies to use based on the requirements (not what some guy down the pub said).

2. How Will It Make People Happy?

What is the need you're trying to solve with the project, either internally or to sell to customers? What are the pain points? Why will this technology make it easier?

I’m still shocked by how many people don’t have a clear vision of the REAL user need and how their platform will make human lives better. At the end of the day, technology is built for people and if it doesn't make them happy, you may as well give up before you start.

I encourage my clients to put themselves in the shoes of their end user and carefully analyse the things that annoy their target market and, more importantly, how their technolgy idea will change it all for the better.

3. Poor Choice of Technology Stack.

Without getting into an argument over .NET vs PHP, Native vs Hybrid apps etc…selection of the right technology stack is super important.

Not only can the wrong choice cause pain in the short-term, but the long term implications around maintenance, updates and scale can be a living nightmare that can evenutally cause a project to die a slow and painful death.

Get someone you trust who does not have any bias to give you advice and help you choose carefully…your are gonna to be stuck with your choice for years to come.

4. Client Pivoting.

Development is like a game a chess, if you interrupt a player in a tournament continuously to change strategy or ask about the weather they will make mistakes. All too often I hear of clients constantly pivoting a project mid-development, usally resulting in a dog's breakfast, a piece of software which is all over the place from both a UX and functionality perspective.

If scoping is done right, pivoting in a project should be next to zero so the development team can just focus on writing good code that is stable, clean and scalable.

I try to encourge clients who want to pivot to park their new ideas for future versions of the platform.

5. Sh*t Developers

Most horror stories tend to blame technology failures on bad developers. But in my experience, this is the least likely reason. Sure good developers will make a difference but an average developer with clear scope and good choice of technology stack will beat a great developer with a chaotic project anytime.

It is possible to deliver a great tech project on budget, on time and that hits the mark…I promise. Just make sure you avoid the common pitfalls above and find a partner who can help you on the journey.