Today, I want to discuss a topic that’s near and dear to my heart: why so many IT projects fail. This is important to me, as there is much at stake here: multiple development teams that will derive their fulfilment from a project delivery and large company budgets dedicated to IT. Buckle up as I share some hard-earned wisdom gleaned from over a decade of navigating the tumultuous waters of the tech world. Let’s go through the main reasons projects fail from my experience:
Ever heard the phrase “biting off more than you can chew”? Well, that’s precisely what many companies do regarding IT projects. They dream big, aiming to conquer the world in a single round. The problem? They end up with a bloated scope that’s as unwieldy as a three-headed dragon.
Here’s the kicker: by trying to do everything at once, they delay getting crucial feedback until it’s too late.
“If everything is important, then nothing is” — Patrick M. Lencioni
In my experience, that’s the primary reason for failure: the bloated scope for even making the first release. The longer we develop without going to production, the more risks we accumulate.
In a rush to showcase flashy demos and prototypes, crucial aspects like security, logging, scalability, performance, and hosting infrastructure often get pushed to the back burner. It’s like building a fancy house without a sturdy foundation or locking the doors. It looks great at first glance, but disaster lurks just around the corner.
There are significant differences between a demo and a production-ready product. In production, the applications deal with multiple scenarios not captured in the requirements phase; those only surface from real users using the application in unexpected ways.
But fear not! There’s a light at the end of the tunnel. The solution? Embrace the power of small, releasable chunks. By breaking down mammoth projects into bite-sized pieces, you reduce the risk of catastrophic failure and gain the flexibility to adapt and iterate as you go.
“Remember, the amount of work may be beyond our control, but how we tackle it is entirely up to us.”
Prioritise the first releases based on business value, a new source of revenue, optimizing process efficiency, or an area of the business that is experiencing many changes in a Legacy system.
The minor first releases reveal the need for the Non-Functional Requirements (NFRs) earlier. It’s even better to add the “shift left” practice. By bringing NFRs into the spotlight earlier in the development process, you can nip potential issues in the bud before they spiral out of control. This proactive approach ensures that critical aspects like security and scalability are addressed from the get-go and sets the stage for smoother sailing down the line.
Combined with reason one, an enormous scope makes project management extremely hard. A program that sees its first release in 2 years often falls prey to an unmanageable state. With abundant modules and features expected at launch from multiple teams, managing such complexity becomes a Herculean task.
Because of this overwhelming complexity, void spaces emerge, allowing inefficiencies to creep in and creating a scenario where accountability is elusive. When numerous teams are tasked with delivering a multitude of features, coordination becomes a logistical nightmare. Each team may have its priorities, deadlines, and communication channels, leading to misalignment and chaos.
Accountability tends to fade into obscurity in this tangled web of interdependent modules and features. Without clear ownership and coordination, deadlines slip, quality suffers, and the project risks spiralling out of control.
To prevent this, it’s essential to break down the project into manageable chunks, establish clear communication channels between teams, and ensure everyone is aligned on priorities and expectations. Fostering a culture of accountability and transparency can help mitigate the risks associated with an unmanageable state, ensuring that the project stays on track and delivers value to stakeholders.
The main reason why projects fail is trying to do too many things at a time. Committing to all-or-nothing strategies. My recommendation is to split the risk. Of course, we might want to do a 1-year program of work of business features, but try as much as possible to slice into small deliveries; this reduces risk, gets value earlier and allows you to stop in case priorities change.
