It’s your first day on the job. The boss introduces you to the obviously demoralized team, and tells you you’ll be taking over the failing project, which is outside your core area of expertise. The documentation is incomplete and messy, there haven’t been any stories written (much less prioritized and estimated), the business sponsor has gone permanently missing, and the UX designer tells you that he’s had to design the screens for the feature with no budget for user testing, and no idea who the target customer is.
Do you turn around and run out the door? No. You’re a PM and you can handle it, and besides, these people need your help. Here’s how I was able to turn my own nightmare project around (and still ship on time!) when faced with exactly this scenario:
1. Listen and learn. There is a reason why the project is failing. Usually the team members (especially the engineers) are not oblivious as to why the project is failing. Take them each aside, one by one, and ask for their candid assessment of what the current status is, and why the project went so wrong in the first place. Ask as many follow-up questions as you need, but in this initial conversation you really shouldn’t be talking more than 10% of the time. You’ll learn a lot more by listening than you will by talking or trying to problem-solve at this point.
As you listen to the story told by each team member you should begin to notice some patterns emerging. Lack of team cohesion, unclear requirements, inadequate commitment or supervision from stakeholders, poor planning, and role confusion are common problems that cause projects to fail. Your project may have several issues, or even all of them as mine did. When several team members bring up one particular issue, make sure it goes on your personal roadmap of problems to address.
2. Understand the team dynamic and begin to build relationships. Your #1 goal (after assessing the situation) is to begin rebuilding trust within the team. It’s important that the team trust you (as they will, in time, after you have proved that you are competent, empathetic, and that you keep your promises), but it’s also important that they trust each other.
Perhaps the majority of team members are new to the company and don’t understand where this project fits into the company strategy. Maybe they are feeling isolated or cut off from other teams. Lack of clear leadership and purpose could be causing squabbles amongst team members. Take stock of what has caused the team failure and begin addressing those issues immediately. You can do this in 1:1s, smaller group meetings, or with the whole team as required.
3. Assess the project’s importance to the company and to the user. Why was this project started in the first place? If the project has a business sponsor, sit down with that sponsor to understand the business pain this project was meant to solve. Learn everything you can about the business case, the target market, and the requirements. Why does the company want to offer this feature? Why would users want to use it? What is the target audience?
If the requirements have changed, make sure to document and prioritize the new requirements and communicate to the sponsor that because the requirements have changed, so must the timeline. The stakeholders probably won’t be happy about this, but it’s better to base your relationship with these stakeholders in reality.
4. Get Agile. Now that you have assessed the reasons for the project’s failure, begun repairing the relationships in your team, and gathered the new requirements, it’s time to gin up the project again. Now would be a good time to do some pretotyping or prototyping. (Do the business sponsor’s requirements match the user’s needs? You don’t know unless you test.) When you’re reasonably confident you’re going the right way, begin story writing/documentation for the highest-priority requirements, get design started on revisions based on your learnings from the prototype, and do your first sprint planning with the team.
You’ll need to understand how the team likes its documentation/stories written, and how they prefer to work with designers. For the first couple of sprints your velocity will be uneven and your estimations will be totally wrong, and so it’s too early to forecast a completion date, but remember to keep the sponsor engaged in your early successes in order to build momentum within the organization. You should see the spirits of your team begin to lift as the ship gets back on its proper course.
These four steps are simple, but they’re oftentimes not easy. Depending on how long the project has been in failure mode, the team’s relationships may be very badly or even irreparably damaged. So might the credibility of the team within the organization. If you treat the project’s current issues as the result of a failure in communication, rather than some kind of moral failure caused by incompetence, you’re more likely to succeed in turning the project around. Good luck!