Ah, failure. We don't always like to talk about that.
But the reality? Most software projects fail and some succeed. In fact, fewer than 1/3 of projects are successful. And some large IT projects go so badly that they threaten a company's very existence.¹ That's scary!
In this article we'll talk about common reasons why software development projects fail.
We don't only want to focus on the negative. In a follow-up article we'll also talk about common aspects of successful software projects.
Postpartum or Post-Mortem?
After a custom software development project wraps up, it's helpful for everyone involved to come together, discuss the project and find closure. This process is critical as a team can only learn and improve through the act of retrospection, otherwise they are bound to repeat their mistakes.
Always celebrate the completion of a project. Software development is difficult, complex and worth celebrating. High-five your MVPs, talk about what made this project successful, and modify your process to do more of that with the next one.
But what about when the project isn't successful?
Often, we just want to sweep that one under the rug and hope the next one goes better.
But it's still helpful to have that wrap-up meeting and:
- Talk about what went well
- Talk about what went wrong
- Talk about what you want to change the next time
- Encourage employees to thank and celebrate each other - pick up those who are feeling down
- Make a plan to take steps to prevent future projects from having the same fate
Five Reasons Projects Fail
Every project is unique.
Different clients. Different platforms. Different developers. Different tools.
People have been writing custom software for decades. Tools and processes have evolved but the common reasons for project failure have stayed pretty much the same.
Here's our stab at the five most common reasons for software development project failure.
- Miscalculated Cost and Schedule
Successful projects are delivered on-time and on-budget. Which means there was a date that the client, developers, project manager, and executives all agreed upon and the client agreed to an estimated price. It also means that the development company didn't have to eat any hours in order to make budget.
Restarts are a major contributor to cost and schedule overruns.
Why do projects come in late?
Sometimes the delivery date is artificially forced by someone not directly involved with the project. Or by someone that doesn't have a complete understanding of the work required.
Or sometimes the date is set before the project is fully defined and as extra requirements come in the delivery date isn't modified to accommodate the added time required to fulfill those requirements.
Why do projects not come in on budget?
Sometimes it's related to the schedule. If a project gets behind, a common response is to add more developers to it. This can add to the cost faster than previously anticipated.
The Mythical Man Month book by Frederick Brooks Jr. has argued against this response for decades.
Brook's thesis is that software projects can't be broken up into discrete tasks that developers can check off without talking to each other and without creating a number of complex relationships between the tasks and developers.
Schedule aside, some projects go over budget because complexity was under-estimated. Or the project requirements, scope or scale changed as the project evolved.
- Poor Documentation
Successful projects have clear and concise articulated goals. They define early on, the criteria and results that describe what quality and success look like. These requirements need to be properly documented, in order for the development team to execute the project correctly.
What impact does poor documentation have?
Poor requirements can lead to inaccurate designs and tests, which will likely result in costly rework. Flaws that aren't discovered during development or are discovered too late, end up as incorrect or unused features, causing issues for users or require workarounds to be put in place.²
- Lack of User Involvement
A successful project is quickly adopted by its target users. Why do some projects not end up being used?
Sometimes end users aren't involved in the initial idea or requirements gathering. Software requirements are instead provided by stakeholders running on emotions, intuitions, or even guesses of what the user wants.
Sometimes software projects start from the place of actual user request, but the work isn't reviewed with users during development, to ensure that it's evolving to continually meet that need.
- Poor Management and Tracking
Successful projects don't just magically show up at the finish line. The project is monitored and guided throughout the development process. Effective project management and governance are critical to the success of a project.
Some teams don't include a project manager, or only have one part time, to watch things at a higher level. Sometimes other projects take temporary priority. Sometimes teams change tracking tools midway through a project, which can cause confusion.
Sometimes developers don't check their work in, or don't communicate well with the project manager, causing an unclear picture of where the project stands.
Successful projects are created by teams of people who are all up to date and moving in the same direction.
Creating a custom software application is as much a people/communication puzzle as it is a technology puzzle. So many project failures boil down to poor communication between different members of the team.
Think about the different communication that has to happen for a software development project to be successful:
- Executives to project champions
- Executives to users
- Users to analysts
- Project champions to development leaders
- Developers to project managers
- Project managers to client
Standardized processes and tools can help set the expectations and provide the means to communicate. Eventually, however, team members need to understand the importance of communication and take the personal initiative to do it.
Any of these common pitfalls sound familiar?
If you've been involved in custom software development for any length of time you've probably run into one or more of these issues.
We'll never make the claim that all of our project retrospectives have been easy discussions. But, we've made it a part of our culture to learn from our mistakes and improve our processes and tools for the next project.
In our next article we'll look at what successful software development projects have in common.
1 Delivering large-scale IT projects on time, on budget, and on value. By Michael Bloch, Sven Blumberg, and Jürgen Laartz. From <http://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value>
2 Poor Requirements – What impact do they have? By Brad Matsugu. From http://www.blueprintsys.com/poor_requirements_what_impact_do_they_have/