We’ve all been there: you’re in charge of a software project, but things aren’t going well. The code is behind schedule and has bugs, team members keep leaving, and you are getting frustrated with the results. Such situations happen pretty often. So, in this article, we’ll find out the most common reasons for a project failure and provide some tips on how to rescue a software project.
You’ve been working hard on a software project for months, but you’re now unsure of the value it’s going to deliver? Or maybe your customer is unhappy with the progress so far and has pressured you to speed up or change direction? Perhaps you just feel that there isn’t a clear vision for what should be built, or that even if there was one, in the beginning, it’s been lost along the way? Or maybe you can see that something isn’t right because developer morale is crashing and people are leaving, but nobody is saying anything? They are pretty common problems, and the reason is that you’re most likely working on a software project that’s spiralled out of control.
It may seem somewhat alarming at first glance, but it happens too often to count. The project is large and complex, but it was never adequately planned. (Or, if it was, those plans are no longer helpful.) So now you have a massive amount of technical debt to handle. The good news is that the problem can be solved — and doing so doesn’t necessarily require starting over from scratch. There are many strategies to consider when trying to rescue a software project. If you follow these steps carefully and methodically, then in all likelihood, your project will become successful.
It’s worth understanding the reasons for a project’s failure. It may happen because of poor planning, lack of team motivation, or unclearly defined requirements. So, this article may be helpful for those who are already dealing with IT project failures and looking for a way to rescue a software project. It can also serve as a guide on how to avoid such situations. So, first, let’s proceed to the most common “Don’ts” in project planning and management.
List of the Content
- Why do software projects fail
- To save or not to save
- How to rescue a failing software project
WHY DO PROJECTS FAIL: MOST COMMON REASONS
Under-Specified Project Requirements
One of the most common reasons why projects fail is insufficient requirements. An under-specified project is a difficult one to rescue. The problems with such a project start before you even begin, and they multiply quickly as the project progresses. Understanding the implications and challenges of working on a project that hasn’t received enough attention in the planning phase is essential.
Business analysts may allow gathering insufficient information about the future product from the stakeholders regarding inattentiveness or other reasons. If it happened and went unnoticed by the team at the initial stages, it may have unpleasant consequences. First, when the project is under-specified, the scope of work and, consequently, the estimates will likely be inaccurate. It will lead to wrongly assessed timeframes and potentially unfulfillable promises. As a result, under-specified projects are less likely to be completed on time and under budget.
As you can see, insufficient requirements may lead to a total disaster that may be pretty difficult to fix. That’s why paying enough attention to the discovery stage is essential. And even if the team has noticed the lack of specifications later, it’s always a good idea to contact a product owner again and ask all the newly appeared questions. It will help you avoid the situation when you need to ask yourself how to rescue a software project.
Agreeing On The Unrealistic Deliverables
One important thing that may lead to a software project failure is overestimating the team’s capabilities and guaranteeing unrealistic results to a customer. Of course, there are always some aspects of the project that require additional research or asking someone for help. However, such parts shouldn’t make the basis of the whole project because, in this case, at some point, the team may find themselves overly worrying while trying to do IT project rescue.
The responsibility for preventing such a situation mainly lies on the shoulders of a project manager. A PM should be honest with himself and the client about the scope of work that a team can realistically do. You must be sure about what your team can deliver, what will require extra effort, and what can’t be achieved. So, a good PM should ask himself, “Will there be some dependencies we haven’t accounted for?” Or “Will there be some critical piece of knowledge that the team is missing?” Before committing to a specific deliverable, it’s essential to answer these questions honestly.
Want to know what makes else makes a good project manager?
In the article, we’ve described how to hire a project manager that will perfectly suit one’s specific requirements. You’ll find the core skills of a good PM, resources where you can look for the candidates, what is their salary range, and some tips and tricks on hiring a project manager.
Speaking about honesty, we should say that it’s important not to mistake being truthful for being overly blunt. Project managers, sales specialists and product owners often face situations where they must admit that some requirements can’t be met and that implementing particular features is beyond the team’s capabilities. Knowing how to present such information is also critical. It needs to be done with empathy and argumentation of the decision. So, if you can’t meet some of the client’s needs, you should also explain why you’ve made such a decision. It’s always a good idea to say how it usually is – that refusing to implement some features will prevent the team from taking on more risk than they need.
Lack Of Critical Thinking
One of the biggest mistakes you can make in software development is blindly agreeing with what your software service provider suggests. And, from the development team’s perspective, the problem is assuming that your customers know exactly what they want. In fact, they usually don’t. Most often, your clients are not software developers themselves, and they’re not much into technical aspects. That’s why the best thing you can do for them is to help figure out what they actually need.
You may think it’s obvious to everyone why a particular feature is necessary. But most people aren’t trained in product design or user experience, so they often don’t know how to articulate their needs effectively — and even if they do, it’s easy for those needs and desires to evolve along with the project itself. They may not be aware that there is a wide range of solutions you may offer for their needs. That’s why it’s your responsibility to help them understand what they may have missed in their requirements and what may be extensive or unnecessary.
Task prioritizing may also be quite challenging for your client. Of course, they know what they want to be implemented first – but you, as a software development professional, understand that the development process is not always linear. It often requires making exceptions and amending changes. For example, if you blindly use the list of clients’ requirements, you may fix a bug in a feature that isn’t necessary and, because of this, miss the deadlines and fail to deliver the critical functionality. Assuming that customers always know exactly what they need may lead to missed deadlines and budget overruns. So, try not to let yourself get caught in this trap!
To avoid such an unwanted outcome, business analysts should carefully conduct their work. Ideally, when your potential client comes to you and says that they need a software solution, you should immediately assign a project manager to a customer, so he can ask the right questions and make informed decisions. A business analyst usually conducts a couple of calls or personal meetings with clients to understand what they need to implement and how developers can do it. It’s a part of the crucial discovery stage. That’s when the first parts of software documentation are made, and the user stories and acceptance criteria are formed. All this information is gathered in the Software Requirements Specification document. It also contains role and permission sets, business roles, diagrams, and other supplementary files.
What is the discovery stage, and what other stages are there?
In the article, we’ve covered the whole development process from the very beginning to a successful finale. We’ve presented how it looks from the client’s perspective, so a potential customer can figure out in advance what he’ll face while reaching out to a software development company for their services.
TO SAVE OR NOT TO SAVE
When you understand that you need to do software project rescue, take these four steps:
- Assess the existing materials
- Decide if it’s worth saving
- Plan the actions
- Execute them
The most significant part of contradictions appears in the second stage – determining the project’s future. No one wants to throw away a substantial piece of work that requires considerable time and team effort. In most cases, projects can be saved even if the amount of work seems enormous. With proper diligence and planning skills, it is possible to rescue a failing project successfully. However, sometimes it’s necessary to abandon the project and move on to the next one. To make such a decision, you need to consider everything very carefully. In this paragraph, you’ll find some tips to help you make the right decision.
There may be some circumstances that make a project rather challenging to rescue. Then, think it over and decide – to save or not to save. It is a hard decision to make, but sometimes, it may be the best option available. To determine the future of a specific project, ask yourself these questions:
- How vital is this project for the company?
- Does the company have sufficient resources to rescue a software project?
- Is the team interested in continuing the project, or do they not believe it can be saved?
- How many things should be changed, and which ones can be left as they are?
Amend this list with more questions that come to your mind, and use it as a handy tool in the decision-making process.
HOW TO RESCUE A FAILING PROJECT
When you’re running a software project, there are a lot of things that can go wrong. Some of these problems are unavoidable — you won’t always know exactly what your customer wants and will have to iterate as you go. However, you can avoid some common pitfalls. If you find yourself in one of these situations and you’ve run out of ideas, remember that though it may be hard, it’s possible to turn things around with discipline, resilience, and a clear focus on delivering value to the customer.
Let’s shortly outline what you should do to rescue a software project. The first thing you need to do is get the team together and re-plan the work. Once you know where things stand, be honest about what can be done in a given timeframe. If it’s impossible to recover from where you are – don’t be afraid to throw away or replace some pieces of code. Finally, ensure that you treat your customer as a part of the team – they’re just as important as everyone else involved in delivering value through software development.
Well, let’s find out some tips that will help you make your project successful.
Get The Team Re-Estimate The Work
The first thing to do is get the team together and re-estimate the work. This step is critical when at the planning stage, something goes wrong. Though some mistakes may have been made initially, you can fix them now. However, this step requires strong attention to detail and an analytical approach. To avoid missing anything, you can try implementing one of the most popular planning methods, whether it’s story cards, planning poker deck, or some more traditional options, such as using the progress tracking software (e.g. JIRA, Trello, etc.).
There are numerous planning methods, but specialized software is a great option. We won’t take any specific software solution because they’re pretty alike. All of them most often include a line of beneficial tools. They may be dashboards that show burndown charts, velocity data, etc. Such infographics help visualize where the project is going at any given moment and estimate what has already been done and what still requires the team’s attention.
You’re free to choose any method that works best for your team and your project.
With a breakdown of tasks into small chunks, you can plan out how long each piece will take and when it will be finished. It helps prevent bottlenecks as we move through our project since we know exactly where there are blocks and can address them quickly before they become too large a problem.
At this point, let’s come back to being truthful to yourself about the team’s capabilities. So, while setting deadlines, be thoughtful and realistic.
Reconsider Technology Choices
When it comes to asking yourself, “How to rescue a software project,” you should first consider analyzing and re-establishing technology choices made in the beginning. Choosing not suitable technologies happens for several reasons. The most obvious one is the lengthy project duration. If it lasts for years, there’s a big chance that the tools chosen initially will not be relevant at some point in the future.
If your project uses an old framework (and who doesn’t love those?), it’s time for a change! You do not need us to tell you how better modern frameworks are. For example, if we’re talking about web application development, React, or Angular will be much better options than older ones like AngularJS or Backbone. Legacy frameworks were designed with older browsers in mind and were built before ES6 was even released (ES6 being what allows us all these fantastic new features).
Of course, it’s almost an impossible task to transfer your whole project from one framework to another and rewrite it in a different programming language. However, it’s not required. All you need to do is check whether new versions of the tools you’re using have not appeared. Most popular frameworks provide many tools for transferring your software from one version to another. For example, when Angular.js became Angular (which is built on TypeScript), it provided numerous tools and guidelines for shifting your solutions to a newer version of a framework.
Such a decision can help your software become more advanced and allow you to implement all the innovative tools that modern technology provides.
Ensure That You Have Good Relationships With The Product Management Team
A customer and a product owner are the two most important stakeholders. Great relationships between them are a necessity if both sides are interested in successful project execution. A customer should always feel like a part of the project, while a product management team should create a positive environment for it. Some cooperation models imply more or less significant client involvement in the project (e.g., dedicated developers or staff augmentation). However, as a customer, you should never be left uninformed or not engaged in the process at all. If it happens in the future, it will most likely lead to considerable unplanned work.
For example, suppose you don’t even have an idea what’s going on on the other side – you don’t know what stage the developers are on, what challenges they have, and whether they meet the timeframes. All you do is wait for a product owner to contact you. In this case, there’s a great chance you won’t be satisfied with the software, and the product development team will go through the development process all over again and ask themselves, “How to rescue a software project?”
So, let’s see what communication you should expect from a product management team to avoid IT project failures. First, you need to feel and actually be involved in the project as much as possible. Remember that you’re not just some background entity that receives periodic updates. Instead, you’re an active participant who gives input and guidance when needed.
You should always be available to answer questions or provide feedback on how those changes should be made if the product owner has some questions or needs to make changes to the initial plan. If you have any ideas, you should share them with the product management team, because you may think of something they haven’t considered.
We should also mention that if you’ve already faced yourself asking how to rescue a software project, maybe the collaboration with the product management team isn’t going as planned. In this case, it’s worth reconsidering the communication models. As an option, you may want to schedule weekly or daily short meetings, or if you’ve already done it, change the structure of calls to deliver more valuable information to a customer in a short timeframe. And only if it doesn’t work either, you may think of changing a software services provider. Sometimes, it’s the best option even considering how much effort it requires. However, fortunately, there are so many tools that can help you find the best software development company that you don’t have to worry about finding a better option.
Be Realistic About What Can Be Done
As previously mentioned, overestimated capabilities may lead to significant problems. Taking on more responsibility than you can manage will likely lead to a software project failure, and you’ll need to rescue a software project. Let’s see what you can do to prevent this from happening:
- Don’t underestimate the amount of work required. It’s tempting to take on more than is possible, but many things can go wrong if you bite off more than you can chew.
- Don’t overestimate the amount of time available. If you have an unrealistic deadline, people will be under pressure to finish quickly and maybe not do their best work. They might also give up before finishing because they think it’s impossible anyway. Of course, it’s easier to make a potential client choose your company’s services by guaranteeing faster deadlines than others, but remember that it won’t lead to a positive outcome.
- Don’t overestimate the amount of money available for the project. You might end up spending all your budget on something that was only half-done or even nothing at all, leaving no money left over for other projects down the road. If there are insufficient funds available, all people involved may suffer financially. For example, developers may not get paid as much as they expected. Consequently, it will negatively affect team morale.
So, to prevent these unpleasant outcomes, be accurate and realistic during the discovery stage. Sometimes, it may seem like a good idea to exaggerate the team’s capabilities and set shorter deadlines. However, it may only work if the whole team is ready to work long hours and get paid less, which is the least likely. So, be true to yourself about what can be done and when to avoid overloading the team and maintain transparency and good relationships with your customers.
Test The Code Attentively
One of the most common reasons for IT project failures is low-quality testing. Bugs in software tend to turn into snowballs gradually. At the beginning of coding, you may think some bugs aren’t worth fixing because they won’t affect the other code parts. However, practice shows that it’s never true.
When the program contains only a few code modules, some minor bugs won’t be a problem. However, when you have thousands of code lines and the whole program is not working correctly, it’s probably those minor bugs that weren’t supposed to be a problem.
If you’re already in the situation when you need to rescue a software project, it’s worth going through the whole code again and fixing even the minor inaccuracies.
Numerous testing techniques allow you to prevent such situations. For example, test-driven development is an excellent approach focused on testing even the smallest code fragments as soon as they’re written. Test-driven development is a software process in which the code’s behaviour is specified before it’s implemented. In this case, you’ll ensure that each line of the code is thoroughly tested and works as expected.
Software projects often appear troubled at some point in time. Finding yourself in such a situation is scary and worrying. But it’s worth remembering that you’re not alone, and numerous small and large companies have already experienced such cases. All you have to do is pull yourself together and create a proper plan on how to rescue a software project.
What’s even more difficult than rescuing a software project is to admit that some projects are just better to terminate. However, if this thought is not something you can deal with, remember that with the services of a professional software company, even the very entangled projects can be saved.
In the article, we’ve discussed why software projects fail, provided the most valuable information about preventing a project’s failure and efficient tips on how to rescue a software project if it’s already in trouble. By following the steps presented in this post, you’ll manage to turn things around and get your project back on track.
Have some additional questions or need a consultation?
Specialists at Existek have helped our customers to rescue their software projects many times. We know that with the right attitude and a set of hard and soft skills, it’s possible to make almost any project successful, no matter in what condition it is at the moment. We leverage our extensive experience in software development and quality assurance practices to help people get their projects on the right track. If you need a consultation or have other questions, feel free to reach out to our specialists via clicking the “Contact us” button below.
Why do software projects fail?
Many reasons may lead to the project's failure, and the list of them would be endless. However, the most frequent ones can be named. First off, it's the insufficient requirements. Another mistake that companies often make is creating unrealistic expectations. You should not promise something that you can't deliver. And finally, it's the lack of critical thinking. Before agreeing on any terms, consider all available options to make the right choice.
Terminate the project or try saving it?
It may seem that it's always worth trying to save a project no matter what. However, if the team is not enthusiastic about it and thinks it's impossible, then it gets more difficult. Besides, you may just lack the resources to continue development. Especially, if you've been working on a specific product for years, and you weren't ready for development to prolong so much. And sometimes saving a project is just about building a completely new solution. Consider these aspects when you make a decision on rescuing the software project.
What do I need to do to save my project?
First off, you need to decide whether it can be saved. If yes, pull yourself together, and be ready to take the following steps. Performing a complete, detailed re-estimation of the project is crucial. When it is done, review the chosen technologies. For years of development, the trends may have changed, and it would be wise to choose other solutions. Ensure that the relationships with your stakeholders are great. And finally, test the whole code to fix even the most minor mistakes that may also negatively affect the code quality.