Let's discuss your ideas and launch your dream project ASAP.
Why a software development team fails and how to replace it with a capable one quickly
Why a software development team fails and how to replace it with a capable one quickly
Every founder would like their startup, their brainchild to see the world as soon as possible, to become necessary and successful. Every entrepreneur worries about their project and wants to implement it efficiently and quickly. Outsourcing development helps to save a lot of money, but even these investments are not always justified if development fails or deadlines are not met.
What to do if development is not going as planned and when the decision to change the development team is vital for the project.
What to do if development is not going as planned and when the decision to change the development team is vital for the project.
Let's look at the reasons why projects fail:
- Poor communicationAll team members must understand what results are expected of them, why they do what they do, realize deadlines, and discuss and solve problems together. Some cultural differences also take place here. For some developers, it is more important to agree even to impossible tasks and deadlines in order to get a project done than to voice their disagreement and propose another solution. Be careful if your developer never disagrees, but promises you to make the impossible possible. Communication is vital at every level of a software development project.
- Improperly chosen (or not defined at all) project success metrics.Without a proper definition of what the end result should be, the project is doomed to fail. Draw up a specification describing exactly what and how the project does, what it should look like, what tasks it has to accomplish. You should clearly document your vision, business and project needs/objectives in all detail (features, requirements, and functionalities).
- Fuzzy or ill-defined responsibilitiesOften people tend to shift responsibility to each other. If a function fails, it should be clear who is responsible and what steps should be taken to prevent it in the future.
- Lack of clear deadlines and objectives or unrealistic deadlines not agreed upon by the teamA good plan or schedule for large teams can serve as a common boundary, allowing them to work quickly and efficiently in sprints. Progress against the plan should also be monitored regularly. If there is no clear plan and defined deadlines of every task and part of the project - you are not moving to success.
- Frequent changes in goals and objectivesIt is important to keep track of project goals and make sure they are completed on time, otherwise you will get another failed project. It's quite possible that the project will need to be expanded or requirements will change. Often the changes are not planned and require a lot of refactoring. Frequent changes in the end goal can not only destroy team morale, but also make it impossible to complete the project.
- Poor project documentationUndocumented code can lead to years of technical debt and can cause huge problems in the future. It's very important to document the whole life-cycle of the product. Every step of the process, from idea to design and development, has to be well documented to ensure that the project is easy to navigate and trackable. Good documentation can make it easier to track key milestones in a project.
It's important to understand and recognize problems in your project as early as possible and discuss them with the development team. If it makes mistakes over and over again and you don't see tangible positive dynamics, it's better to refuse the services of this team (even if it's your inhouse team) and hand the project over to people who will bring the project to completion and give it new life before it's too late.
Markers for determining if your project is going the wrong way:
- Team members struggle to find anything to report at status or daily stand-up meetings. When the PM asks about tasks that are due to be completed in the next few days, they get vague answers. Team members are confused or unsure about what they should be working on and when. If the project team is asking questions about information that should be well-known - something is wrong. A useful sign is that people stop giving you information or the data you ask for. This usually means that analysts / developers have a problem and are trying to solve it by themselves, and sometimes that’s too optimistic.
- The same bugs are rediscovered in the process of accepting the parts of the project. For example, your team works over a complex project having a problem of not working login form and fixes it. On the next sprint another bug appears - the report form does not work. It is fixed but the original bug with the login form turns up again. It gets fixed but even after that the initial bug keeps popping up again while optimizing for other bug fixes.
- Missed milestones and unkept promises. The development team says that the work will be completed on time but the deadline is postponed. Or after 3 weeks only one task out of ten is accomplished. This situation indicates that the team underestimated the tasks and they don’t really understand what they are doing and how much time it takes. It may also mean that they misunderstood the project and clients expectations. When deadlines are rescheduled more than 2 times and the team asks for more time, but doesn't give any specific dates, when they cannot explain what caused the difficulty and how it can be fixed, you should ask the team to show you the code or a part of the code and explain where there are the problems.
Get an audit for your project
If the project is in the delivery phase and deadlines are postponed, it is likely to be unstable leading to the users’ dissatisfaction with the performance of the project. If you feel that your project is not going as it was planned, you need an audit. It will save you a lot of nerves and time later on. Audit time depends on the phase and size of the project, whether the entire project or the last development iteration needs to be audited.
After the audit you should make an assessment either to fix everything with the current team or switch to a new item.
Many people are disappointed with outsourcing and after a negative experience they switch to building their own in-house team. However, there are a lot of pros and cons in this situation, which we told you about in this article.
If, however, you decide to give outsourcing another chance, how will you make sure that the new vendor is better than the previous one? It is very important to choose your next developer very carefully.
Many people are disappointed with outsourcing and after a negative experience they switch to building their own in-house team. However, there are a lot of pros and cons in this situation, which we told you about in this article.
If, however, you decide to give outsourcing another chance, how will you make sure that the new vendor is better than the previous one? It is very important to choose your next developer very carefully.
How to minimize the risks before you start working with a new development team.
1) The first thing to know before starting development is the technology stack of a new team. So many developers work in different stacks: they can hate each other, argue, constantly quarrel about which development language is better, but none of this is important for you. What matters is that there are many developers in the chosen stack. If the team chooses an extravagant language, there are high chances that you will be dependent on this team for years. So even at the stage of negotiations, find out which languages will be used for writing a mobile app and which for a server part. Go to a freelance website, create a project "finalize mobile app, stack ….. , I will tell the candidate the details" , and see how many responses you get. If there are a lot of responses, the stack is probably popular, you won't have any problems with the team, at least at this point. If there are almost no responses, that's another thing to think about.
2) The second super important issue is the experience. Check the portfolio, ask for references in storerooms, see similar completed projects and reviews of their work.
3) On the first interview, bring the list of the problems of the project, ask the vendor how they are going to solve them. Then determine if the proposed solutions are good for you. You need to find out whether you are on the same page with this company.
4) Make development iterations shorter, 2-weeks sprints and step-by-step acceptance process. Create a plan for the project containing the information on what tasks should be in a particular sprint, when intermediate demos and testing can be done. Break the project into short parts and spread out over the sprints. You'll see pretty quickly how clearly the new contractor is sticking to the plan that was formed. The ideal is to create test cases for each stage of acceptance of the project's part.
5) Update the technologies if necessary if there is a dependence on platforms or services which release an updated version and support the latest frameworks. Developers do not like to work with legacy code as it slows down the development process. It is easier to work with modern frameworks than to continue to support the old stuff. A software project cannot be successful without the flexibility to adapt to business and technology environment changes during the development process.
6) Establish completely open communication and cross-functional sharing so that everybody knows their tasks, deadlines and responsibilities.
1) The first thing to know before starting development is the technology stack of a new team. So many developers work in different stacks: they can hate each other, argue, constantly quarrel about which development language is better, but none of this is important for you. What matters is that there are many developers in the chosen stack. If the team chooses an extravagant language, there are high chances that you will be dependent on this team for years. So even at the stage of negotiations, find out which languages will be used for writing a mobile app and which for a server part. Go to a freelance website, create a project "finalize mobile app, stack ….. , I will tell the candidate the details" , and see how many responses you get. If there are a lot of responses, the stack is probably popular, you won't have any problems with the team, at least at this point. If there are almost no responses, that's another thing to think about.
2) The second super important issue is the experience. Check the portfolio, ask for references in storerooms, see similar completed projects and reviews of their work.
3) On the first interview, bring the list of the problems of the project, ask the vendor how they are going to solve them. Then determine if the proposed solutions are good for you. You need to find out whether you are on the same page with this company.
4) Make development iterations shorter, 2-weeks sprints and step-by-step acceptance process. Create a plan for the project containing the information on what tasks should be in a particular sprint, when intermediate demos and testing can be done. Break the project into short parts and spread out over the sprints. You'll see pretty quickly how clearly the new contractor is sticking to the plan that was formed. The ideal is to create test cases for each stage of acceptance of the project's part.
5) Update the technologies if necessary if there is a dependence on platforms or services which release an updated version and support the latest frameworks. Developers do not like to work with legacy code as it slows down the development process. It is easier to work with modern frameworks than to continue to support the old stuff. A software project cannot be successful without the flexibility to adapt to business and technology environment changes during the development process.
6) Establish completely open communication and cross-functional sharing so that everybody knows their tasks, deadlines and responsibilities.
So you decided to transfer the project to a new team.
Here is how the Transfer Process should look like.
1) Check the contract and intellectual property agreements. Find out who owns the code and how you are protected in case the developer claims a part of your idea. Most development teams just want to write code and make money. They don't want to own your idea or put you out of business. Most transitions go smoothly. However, if they do get into a fight, the best thing you can do is have a frank and honest conversation. They don't want to hire a lawyer any more than you do, so just sit down, talk, listen , and you can probably come up with an acceptable solution.
2) Before you even mention or threaten to fire the current team, you need to make sure you have a copy of all your code and access to your servers. Without access to your code and servers, you have nothing. Ideally you should have access to your code at the beginning of the project, but if you don't (you usually don't), just point out that you read some articles and they recommend that you have a copy of your code in case of force majeure. Once you have access to the code, download it and store it privately somewhere. Also get access to the servers, probably Amazon AWS service, Microsoft Azure, or make a copy of the entire database on your physical server.
3) Obtain (or create) documentation of the project from the previous vendor. Developers should prepare documentation of how and what they did, of the location of each branch of the code, so that the code can be commented out. Code should have a structure and comments. It should not be "spaghetti"-code. If at the stage of acceptance from the previous team it is obvious that the code is chaotic, most likely it will be easier for the new team to rewrite everything from scratch than to deal with it. The decision must be made by someone with a technical background who can look at how everything is laid out in the repository and figure it out.
4) It's better that the transfer process goes through the client's staff, as a vendor who is abandoned in favor of a new one is not motivated to do it in a quality way. Ideally, you should have a product manager and a technical director at the time you decide to hand over the project. The first one is responsible for hypotheses, task priorities, releases, and development plans. The second one - for the architecture, the compatibility of the technologies and services used, the IT infrastructure, and the set of development tools. The trick - when hiring a new vendor, you can introduce them as your employee - a new Team Leader, a responsible technician.
5) Define the timeframe within which the project should be handed over to the new developer, including the delivery of all documentation by the previous implementer.
6) Take ownership. During the course of development, your previous team may have signed up on your behalf, or even used their own accounts to get access to the services that were needed. Transitioning to a new team means that you must take ownership and be in control of every single service and tool that your application relies on so that you can grant access to your new team without needing to go through a middleman or chase down the original developers.
For any services which are owned by the development team, ask them to transfer ownership to you. If that’s not possible, then ask them to help you create a new account of your own and ensure that the application uses your account instead of theirs.
Here is how the Transfer Process should look like.
1) Check the contract and intellectual property agreements. Find out who owns the code and how you are protected in case the developer claims a part of your idea. Most development teams just want to write code and make money. They don't want to own your idea or put you out of business. Most transitions go smoothly. However, if they do get into a fight, the best thing you can do is have a frank and honest conversation. They don't want to hire a lawyer any more than you do, so just sit down, talk, listen , and you can probably come up with an acceptable solution.
2) Before you even mention or threaten to fire the current team, you need to make sure you have a copy of all your code and access to your servers. Without access to your code and servers, you have nothing. Ideally you should have access to your code at the beginning of the project, but if you don't (you usually don't), just point out that you read some articles and they recommend that you have a copy of your code in case of force majeure. Once you have access to the code, download it and store it privately somewhere. Also get access to the servers, probably Amazon AWS service, Microsoft Azure, or make a copy of the entire database on your physical server.
3) Obtain (or create) documentation of the project from the previous vendor. Developers should prepare documentation of how and what they did, of the location of each branch of the code, so that the code can be commented out. Code should have a structure and comments. It should not be "spaghetti"-code. If at the stage of acceptance from the previous team it is obvious that the code is chaotic, most likely it will be easier for the new team to rewrite everything from scratch than to deal with it. The decision must be made by someone with a technical background who can look at how everything is laid out in the repository and figure it out.
4) It's better that the transfer process goes through the client's staff, as a vendor who is abandoned in favor of a new one is not motivated to do it in a quality way. Ideally, you should have a product manager and a technical director at the time you decide to hand over the project. The first one is responsible for hypotheses, task priorities, releases, and development plans. The second one - for the architecture, the compatibility of the technologies and services used, the IT infrastructure, and the set of development tools. The trick - when hiring a new vendor, you can introduce them as your employee - a new Team Leader, a responsible technician.
5) Define the timeframe within which the project should be handed over to the new developer, including the delivery of all documentation by the previous implementer.
6) Take ownership. During the course of development, your previous team may have signed up on your behalf, or even used their own accounts to get access to the services that were needed. Transitioning to a new team means that you must take ownership and be in control of every single service and tool that your application relies on so that you can grant access to your new team without needing to go through a middleman or chase down the original developers.
For any services which are owned by the development team, ask them to transfer ownership to you. If that’s not possible, then ask them to help you create a new account of your own and ensure that the application uses your account instead of theirs.
The average duration of transferring the project is about a week. It depends on the size of the project and the phase of development. One of the most recent cases was when we took back a project from a team that had been working on a prototype for two years and still could not get it right. We implemented our own version of the prototype in a month, and it suited the client completely. You can check our latest projects.
We all make mistakes from time to time. The advantage of those who succeed is that they learn from their mistakes and try to eliminate them and avoid making them in the future. Even if the development process has gone wrong, you always have the opportunity to fix it.
Good luck and be wise in your decisions!
Need consultation on your project?
Tell us about your project