Software development projects can — like other product development projects — fail spectacularly and fail too often. The result usually causes blown budgets or delivery dates, and/or more. While there are many reasons that can send your project off the rails, here are the three main reasons your software dev projects fail.
It’s inevitable that software dev projects will face some challenges just by the nature of it being software development. Changes during the course of the project – dependencies discovered in legacy code, integration challenges, etc. – and unexpected developments make it necessary to alter course given new needs.
That said, too often, problems with these projects arise that cause major issues, can send the budget and timeline way off course and can even cause some software dev projects to fail.
The good news: These problems can usually be prevented.
Here are the three main reasons that software development projects go off the rails and what you can do to prevent them from happening.
1. Lack of Clarity Regarding the Requirements for the Project.
Ask any software developer and they will tell you this is an extremely common problem. Teams are asked to create a “something” but aren’t given the full details or requirements for the project. Yet, they are asked to get started creating that “something”.
Often there is pressure to get started because there is some deadline — whether real or presumed — to get the project done. So, teams are forced to start working without clearly defined requirements. So, the teams do as required and get started.
While Agile methodologies have attempted to reduce the likelihood of these issues, sprints can fail and the balance between spending a sprint (in part or in whole) on requirements gathering versus trying to prototype and provide other value can be challenging.
What happens next is that the team delivers the first part of the project and either the client or whoever is in charge realizes that what is being built isn’t what they envisioned.
Immediately they ask for changes.
Those changes immediately increase the amount of time it’s going to take to finish the project and will add to the budget.
So, if there is a strict deadline and budget, they’ve both now been blown.
Furthermore, the team of engineers shows their clear frustration because they’ve just wasted time on something that needs to be redone.
While it may seem like it will cost more money, spending the time up front to ensure that the current work plan or sprint covers the likely, anticipated, and valuable requirements is necessary.
And it doesn’t have to be all requirements since many things can change for good reasons. But projects should be based on clear, agreed-on sets of requirements at all stages … from the start of the project.
The client and the production engineers should all know what’s intended to be built, why those items are there, and what risks have been accepted. This way all stakeholders enjoy the benefits of a clear agreement and understand what the likely changes may be. Controlling and conquering risk, not defining every requirement, is actually what teams need to aim for.
If you do this, you’ll also have a happier team of engineers.
2. Lack of Commitment of Adequate Resources
Too often companies try to save money by building what they might call a “lean” development team.
Keep in-mind that lean doesn’t necessarily mean small teams. Plus, if your budget is small or under pressure, you can design your development teams to be small and agile, but remain fully-aware that a team with a limited number of engineers can only accomplish so much.
Same could be said for surgeons/surgical teams. There’s only so many hands that can work together on a patient. And if you’re missing a role — like an anesthesiologist — you’re not likely to end up with a good result.
So all that said, there is nothing wrong with a lean team.
There is everything wrong if your lean team doesn’t have the skills required to complete the project.
The three major issues here are:
- The team doesn’t have the required skills to handle all aspects of the project
- The team is too small to get the job done on deadline
- The team doesn’t have enough access to the right stakeholders, and commitments for their involvement to make the project succeed
The first problem is common because most engineers don’t have all the skills needed for a project from beginning to end. That’s why you hire different engineers to handle the different aspects of the project. This is especially true for projects involving legacy systems or tough-to-navigate architecture
Often engineers will say “yeah, sure I can do that”, in an effort to be a team player and be a valued member of the team. But be careful, if they don’t have the right experience it can send the project off the rails in a number of different ways.
Similarly, be sure to hire the right resources — either internally or externally — with the proper dev experience to get complete your project properly the first time around. This includes proper documentation.
The second problem is simply relying on a team that is too small to get the job done. At one company we worked with, they needed to keep V1 of their platform working while they were developing V2. The problem was that their team wasn’t big enough. They could either keep V1 alive and fix the bugs that arose OR they could work on V2, but not both. They ended up splitting the team to work on both and it caused nothing but problems.
The lack of a project manager exacerbated that situation, which leads us to the third reason your software dev project fail.
3. Lack of Adequate Control Actions and/or Activities
When we talk about adequate controls, we are referring to several potential issues.
- Lack of project management
- Client demands distract the team from the process (and remember sometimes the “client” is an internal client)
- Lack of discipline within or between teams
First, make sure you also have a project manager (PM) that works closely with your CTO to ensure things are working on time, on budget and with the right team.
A PM can help see and fix problems before they happen. They are also going to be a good gauge to tell if you have the right team in place. Further, the PM is the bridge between the engineering team and the client. This allows the engineers to focus on delivering product, as opposed to having to listen to the client’s changes, etc.
And sometimes you need a systems integration engineer that can also serve as a PM of sorts, but with an engineering background to help bring the teams together and make sure they are working in sync.
The PM also can handle the problem noted above which are the client demands.
We’ve all been there. You are working on the project, and midstream, the client makes changes.
OK, this is going to happen. But how you’ve structured the process for these changes will have a huge impact on your team.
In many cases, the client speaks to the engineering team, who is looking for very clear instruction, and the client doesn’t know how to give clear instruction. This isn’t necessarily their fault, because engineering is not their expertise.
That said, this process is asking for trouble…and will cost you more in time and budget.
With a PM in place and a structured means to handle changes, the PM can spend time with the client to fully understand the new requirements, then translates those requirements into a structured set of directions that can then be passed onto the engineering team and incorporated into the appropriate sprints.
The last point is the lack of discipline and/or communications between teams. This causes more issues than just the obvious. If the teams aren’t working in a disciplined environment with appropriate communication, you could easily have part of the project being built that will not work well together, if at all.
Again, this is where a project manager or systems integrator becomes invaluable. They are responsible for ensuring the discipline and communication between the teams (and within the teams). Further, a systems integrator can ensure that what is being built by separate teams will actually work when the different parts are brought together.
Note that you don’t have to have a PM or a systems integrator on staff. You may not need one full time or you don’t have budget for a full time person. Both functions can be easily outsourced to ensure a smooth project.
While there are certainly other reasons why your software dev projects can fail, but these are the main three that we see regularly. And they can cause huge delays and massive budget overruns.
Fortunately, these problems are preventable with the right planning, resources, and team from the start.
Have more questions about your software dev project? Reach out to us here to set up a quick call.
Share this Post