Why Do Software Projects Fail?

Despite advances in the tools, languages and hardware available to developers, software projects still run into trouble — they miss deadlines, hit intractable technical obstacles and run over budget. In our recent webinar Winning Applications: Lessons Learned from 500+ Successful Projects, Integrated Computer Solutions CEO Peter Winston offered a number of ways to avoid most of the roadblocks that can impede your efforts.

In this blog, Winston shares big picture guidance and tackles a few in-the-weeds questions that were submitted by webinar participants but not addressed during the live event. (For a more expansive discussion, listen to the webinar on demand.)

Q: What are the most common reasons software development projects fail?

There are many reasons projects fail, including insufficient budget, but three stand out: unclear objectives, overly optimistic expectations and excessive complexity. Without knowing precisely your aim, meaning you have objectives that aren’t well articulated, it is too easy to build the wrong thing. Something your customers don’t want or need. That’s the first problem.

Next are your expectations. Overly optimistic expectations get you when a project turns out to be harder than you anticipated. What happens if the project has goals too ambitious for the allotted schedule? One tiny speed bump and you’re off track.

The third reason relates to complexity. It is often difficult to identify, understand and effectively manage risk if a project is overly complicated. Check out the section in the webinar on the complexities of building a coffee maker for a vivid illustration of this challenge.

Q: What advice would you give to ensure project success?

Identify risk early. Find it now while you still have the ability to influence it. If you don’t spot risk — and there’s always risk — early, you’ll likely end up paying more in total cost, facing insurmountable problems or missing market windows.

Start project with a surge. Staff robustly with senior engineers in the initial phases to get your project moving quickly in the right direction, as well as uncover unknowns early to add buffer time. You can then reduce staff or rearrange resources (to add more specialists) later in the project, if necessary, to maintain your budget and schedule.

Lead with UX. Do the most difficult thinking up front. UX, or user experience, involves creating solutions to problems that are both functional and engaging. It offers a structured way of identifying problems before engineering encounters them and breaking a project into manageable pieces. UX serves as a proxy for a more detailed Spec. By successfully merging the UX process into the software development process you’ll create a superior product. And potentially quicker. UX design speeds up projects by 30% - 50% in total time, according to the UXPA.

Q: Regarding medical device development, how does your process of defining the UI first fit into the FDA’s chain of evidence?

Our practice is unusual in that we generate a working, high-fidelity prototype initially as proxy to product requirements. The high-fidelity allows for a greater degree of certainty about what’s being agreed to by stakeholders. This typically happens in the first 10% of the project. Creating the prototype in a framework that ports to actual production code creates a cost-efficient way to translate the initial agreement to the final product. This also ends up being high-quality as the translation process is direct.  

After the prototype is formally agreed to with a design review, producing the product requirements is much easier because we’re describing something that’s tangible rather than something that doesn’t yet exist. Similar reasoning applies to software specifications. A physical, operating application is an immense writing aid to defining formal specifications. Doing a high-fidelity prototype first enables much of the formal definition and tracing activities to be done in parallel.    

Q: What UI tools do you use to create initial prototypes? Typically, how long does it take to create these prototypes?

For a UX-centric development company like ICS, building tool-compatibility to products like Figma — a cloud-based collaborative design tool — allows imports of the most recent UI advances with the least amount developer overhead. We’ve also created our own proprietary software tools that further support rapid prototype creation.

As for how long it takes, of course it depends on how deep the UX is and how much of it needs to be ground-up defined. For products in the 5-10 person-year range, we find prototypes take 10-15% of the project budget. This is dominated by the design and approval process rather than development as the tools we use accelerate the coding.

Q: What’s your take on the Waterfall software development life cycle?

Our use of the maligned term ‘Waterfall’ is primarily to emphasize that not everything in the process is iterative. Achieving a high-fidelity prototype and approving it allows you to be definitive and ‘final’ when writing the product requirements. This also strongly informs and enables the next steps: specifications and scheduling. By iterating extensively on the UX prototype, the back-end of the process becomes much more linear, or Waterfall-like.  

For the full story on why projects fail and what you can do to prevent that from happening, check out the one-hour webinar on demand. You can also read more about surging successfully in Closing Your Skills Gap and Surging Successfully Takes the Right Partner.