When the Team Gets Stuck
What do you do if your development team can't finish the product?
This is not a question that anyone wants to have to answer, but it happens. The last time I ran into this, I had taken over a new product whose development team was spinning its wheels and unable to make meaningful progress. Each iteration of the product raised new problems that seemed to slow things down further. Something had to be done, quickly.
In this case, the product was in the design/prototype stage. Early-stage paralysis can be caused by several different problems:
- The team doesn't understand the customer need/problem well enough
- The functional requirements or design aren't clear enough, or
- The team lacks sufficient design experience/talent (it's usually more tactful to call it "experience")
First, make sure that the PM information is sufficient, clear, and prioritized. Go over it with the team until you're certain it's understood. Talk about the Vision too. If the team doesn't understand the customer requirements clearly, you either need to do some more homework, or communicate what you've got more effectively. Personas, scenarios, detailed workflows and use cases are usually effective in explaining customer requirements. But it's also essential to link these to specific feature sets, and to provide a clear sense of prioritization among these feature/function sets. The PM needs to make sure that the team always knows what the customer problems are, which functions are relevant to which problems, and which solutions are most important for the current release.
If it turns out that the team is simply not equipped to finish the design, get them help. The most common "missing skill" is product design expertise, though you may need help with media production, back end development, or something else. If you have the ability, you may have to personally step in and work on it, but you probably have other pressing things to attend to. If possible, borrow help temporarily from elsewhere in the company, and if you can't do that, try to bring in a consultant or contractor on an emergency basis. There are plenty of good product designers for hire as contractors, for example. The PM is often in a good position to advocate for more resources, or to support an engineering manager's request.
If you're well into development, or nearing the due date, and progress isn't happening, then consider these possible reasons:
1. The deadline was unrealistic, and Development may have signed up to it under pressure or out of false optimism.
2. The design/specs are flawed, contradictory, or unbuildable.
3. There are organizational problems in Development that are interfering with progress.
4. The design is beyond the technical capabilities of the team.
Each of these requires a very different response. And the response may depend on whether you are doing an agile or waterfall process. (One of the beauties of agile is that you aren't half way through a multi-month or multi-year project when you realize you have a problem.)
#1 is very common. Development often wants to be optimistic, and may estimate based on "best case" scenarios. No project ever achieves best case scenarios for each subproject, so this will always lead to trouble. The solution is a new project plan, perhaps with more frequent milestones. It may be possible to scale back the feature set in order to meet the schedule, and the PM will have to make some major decisions, usually involving senior management. And there may be some real pain involved.
In #2, if the problem is with the design or specs, then the problems must be identified as quickly as possible, before more time is spent building the wrong thing. One common late-surfacing problem that can bring development to a halt is usability - what if it becomes clear that the product isn't sufficiently usable, but Development has done the job it was asked to do? An agile process in designed to address this, but on a long-term development job, it may be necessary to call a time-out, run usability tests or performance benchmarks, and change the design. The later in the process that this happens, the more expensive it is. (It's never cheap, so doing the work/research to get the design right - and validating it by testing it - is really important!)
Case #3, organizational or personal problems in Development, can be very difficult and painful to resolve. It's usually the responsibility of engineering management to solve these, but it will sometimes fall to the PM to identify areas of dysfunction. Sometimes a PM, as a kind of neutral observer, can make valuable suggestions to improve the process. Pointing out inefficiencies or process gaps may be the best you can do - it's up to Development management to fix them. If that fails, you may have to escalate the issue - this is where a good relationship with management is important - they need to trust your observations. In general, the more people that agree about a problem, the more seriously it will be taken. Being constructive and proposing solutions is essential - negative criticism often makes things worse.
In #4, the case where the team is not capable of implementing the design, either you have to change the design, or the company has to change the team. Or both. Design changes may be preferable, but must often be reconciled with customer requirements, business strategy, marketing plans and sales expectations. It may be that adding to the team is preferable (keeping in mind that it's usually ineffective to add a lot of team members quickly). What isn't viable is allowing a team to keep spinning its wheels indefinitely, hoping that a solution will be found. Set a time limit and stick to it.
I was able to help my team get back on track by a combination of these approaches. Most important was clarifying customer requirements - the previous PM hadn't done so. But the team was also without an experienced product designer or product manager, and those problems had to be addressed too. It took several months to turn things around, but it worked.
In the end, it's about getting to the end. And if you can't figure out why you're not getting closer, you won't get there.
This is not a question that anyone wants to have to answer, but it happens. The last time I ran into this, I had taken over a new product whose development team was spinning its wheels and unable to make meaningful progress. Each iteration of the product raised new problems that seemed to slow things down further. Something had to be done, quickly.
In this case, the product was in the design/prototype stage. Early-stage paralysis can be caused by several different problems:
- The team doesn't understand the customer need/problem well enough
- The functional requirements or design aren't clear enough, or
- The team lacks sufficient design experience/talent (it's usually more tactful to call it "experience")
First, make sure that the PM information is sufficient, clear, and prioritized. Go over it with the team until you're certain it's understood. Talk about the Vision too. If the team doesn't understand the customer requirements clearly, you either need to do some more homework, or communicate what you've got more effectively. Personas, scenarios, detailed workflows and use cases are usually effective in explaining customer requirements. But it's also essential to link these to specific feature sets, and to provide a clear sense of prioritization among these feature/function sets. The PM needs to make sure that the team always knows what the customer problems are, which functions are relevant to which problems, and which solutions are most important for the current release.
If it turns out that the team is simply not equipped to finish the design, get them help. The most common "missing skill" is product design expertise, though you may need help with media production, back end development, or something else. If you have the ability, you may have to personally step in and work on it, but you probably have other pressing things to attend to. If possible, borrow help temporarily from elsewhere in the company, and if you can't do that, try to bring in a consultant or contractor on an emergency basis. There are plenty of good product designers for hire as contractors, for example. The PM is often in a good position to advocate for more resources, or to support an engineering manager's request.
If you're well into development, or nearing the due date, and progress isn't happening, then consider these possible reasons:
1. The deadline was unrealistic, and Development may have signed up to it under pressure or out of false optimism.
2. The design/specs are flawed, contradictory, or unbuildable.
3. There are organizational problems in Development that are interfering with progress.
4. The design is beyond the technical capabilities of the team.
Each of these requires a very different response. And the response may depend on whether you are doing an agile or waterfall process. (One of the beauties of agile is that you aren't half way through a multi-month or multi-year project when you realize you have a problem.)
#1 is very common. Development often wants to be optimistic, and may estimate based on "best case" scenarios. No project ever achieves best case scenarios for each subproject, so this will always lead to trouble. The solution is a new project plan, perhaps with more frequent milestones. It may be possible to scale back the feature set in order to meet the schedule, and the PM will have to make some major decisions, usually involving senior management. And there may be some real pain involved.
In #2, if the problem is with the design or specs, then the problems must be identified as quickly as possible, before more time is spent building the wrong thing. One common late-surfacing problem that can bring development to a halt is usability - what if it becomes clear that the product isn't sufficiently usable, but Development has done the job it was asked to do? An agile process in designed to address this, but on a long-term development job, it may be necessary to call a time-out, run usability tests or performance benchmarks, and change the design. The later in the process that this happens, the more expensive it is. (It's never cheap, so doing the work/research to get the design right - and validating it by testing it - is really important!)
Case #3, organizational or personal problems in Development, can be very difficult and painful to resolve. It's usually the responsibility of engineering management to solve these, but it will sometimes fall to the PM to identify areas of dysfunction. Sometimes a PM, as a kind of neutral observer, can make valuable suggestions to improve the process. Pointing out inefficiencies or process gaps may be the best you can do - it's up to Development management to fix them. If that fails, you may have to escalate the issue - this is where a good relationship with management is important - they need to trust your observations. In general, the more people that agree about a problem, the more seriously it will be taken. Being constructive and proposing solutions is essential - negative criticism often makes things worse.
In #4, the case where the team is not capable of implementing the design, either you have to change the design, or the company has to change the team. Or both. Design changes may be preferable, but must often be reconciled with customer requirements, business strategy, marketing plans and sales expectations. It may be that adding to the team is preferable (keeping in mind that it's usually ineffective to add a lot of team members quickly). What isn't viable is allowing a team to keep spinning its wheels indefinitely, hoping that a solution will be found. Set a time limit and stick to it.
I was able to help my team get back on track by a combination of these approaches. Most important was clarifying customer requirements - the previous PM hadn't done so. But the team was also without an experienced product designer or product manager, and those problems had to be addressed too. It took several months to turn things around, but it worked.
In the end, it's about getting to the end. And if you can't figure out why you're not getting closer, you won't get there.