Why do software projects fail?

Software Development
by: IQ Admin

“Our plan is to invent some sort of doohickey that everyone wants to buy.”
-Pointy-Haired Boss, Dilbert

Thousands of lines of code…dozens of people…customer deadlines…budget constraints. What could possibly go wrong? The short answer is – a lot can go wrong with a lengthy, complex software development project.

Development methodologies and tools have evolved to accommodate uncertainty ; but at the end of the day, even experienced VPs and CTOs experience at least a small pang of anxiety when the CEO asks (perhaps after making commitments to customers, directors and investors), “So when will the project be done?”

Over the past 22 years, IQ has worked on over 100 medium to large development projects. While every project is different, we can spot execution risk areas from a mile away. Here are three of the more common pitfalls:

Ill-Defined Scope and Scope Creep

Thorough product specifications are one the bedrocks of a successful development project. From that spec document, detailed project schedules can be derived, which serve as the guardrails and ‘to do lists’ for the team.

Specs that are written at too high of a level (say, release this module and release that module) don’t integrate dependencies and resource loading, and one misstep can cascade through the rest of a project, resulting in delays and unbudgeted development hours. Further, loose specs may lead to scope creep, which can cause a development project to bog down under its own weight.

One of the most common, and most understandable, complaints from a project leader is that, ‘They just won’t give me the time and budget that I need to do the job right.’ Consider this – if a specification clearly communicates the breadth and depth of a project, it is much easier for a leader to understand the resources required and parse it out to a series of smaller projects.

So, take time to crisply define what you want your software to do, and then review scope and schedule regularly throughout the course of the project, adapting as you go. It’s a painstaking process if done properly. Yet planning yields significant dividends in the currency that a CEO and CFO understand – time and money.

Poor Technical Leadership

So, you’ve taken the time to produce a solid spec, and have developed a comprehensive engineering schedule based on an agreed set of functionalities and features. You are ready to go. Next comes the hard part – leading the team as it works through the daily grind of scrums, code commits, design reviews and unanticipated challenges.

This is one of the most challenging positions in any company: leading down and leading up. Your team is providing frequent feedback regarding problems they are working through, bugs that have popped up and intra-team stress and conflict. Conversely, the management team is constantly requesting updates, making ‘suggestions’ and setting expectations in the marketplace.

It can be easy to deviate from processes that were established at the beginning of a project. But don’t do it! This is the point where you have to double-down on your process and manage from the middle.

Poor Communication & Misunderstandings

This one is so obvious that it’s almost not worth mentioning. But it’s absolutely worth mentioning since it so often the root cause of project slippages and failures.

Setting expectations (internal and external) properly is the foundational layer in an effective communications system. The management needs to know if something has slipped so that they can in turn manage customer expectations. The implementation team must understand how their specific goals impact the overall project. No one enjoys delivering or receiving news that a milestone has slipped. But not addressing these issues as they arise virtually ensures failure. Technical leaders are respected when they communicate frequently and predictably, and discuss both the good and bad news.

There are a million reasons why engineering projects don’t deliver on expectations. However, when you take time up front to really flesh out the specifications, manage from the middle, and clearly and honestly communicate, you’ll reduce project risk and position your team to deliver in a way that exceeds everyone’s expectations, internal and external.