How To Fix a Project

Struggling or failing projects have enormous costs. They are both costly and demotivating at the same time. This is especially sad because there are a lot of fun ways to be wasteful, and a lot of cheap ways to be demotivating.

On failing projects, people come to work, they go to meetings, they do stuff, time goes by, and nothing ever comes of it. Lots of work is in progress. Lots of things are said to be nearing completion. Yet nothing meaningful is actually done. Weeks turn into months. Months turn into years sometimes. And there is nothing.

Failing projects tend to develop inertia that is difficult for many people escape. It’s a project rip tide that sucks down everyone who comes near it. We need to fix it by approaching it thoughtfully.

I want to explore how I recognize a struggling or failing project and how to rescue them.

Recognizing a Failing Project

By definition, a failing project will have missed expected deadlines, even just internal deadlines, and probably multiple deadlines. Whether because of missed completion or missed quality gates.

There a variety of symptoms that would have caused this. They may vary per project.

In failing projects there may not be much product in a working state. There is nothing for anyone to test or demo. People will be sick on demo day. Or they’ll demo source code that could work if several other things worked.

In failing projects, there is no formal release plan - no sequence of gates leading up to the release date. No plan is written down. Maybe because nothing is planned at all. It was all just going to work magically but we’re past magic now. The “last 10%” of the project takes 500% of the time.

In a failing project, you are unlikely to find reference architectures. At least not ones that people on the project reference. Everyone has it in their heads, or so they want everyone else to believe.

Failing projects tend not to have a defined singular leader. No one person is taking accountability for the end result every day. There are people responsible for parts of it, but not the whole of it. There may be someone who appears to own it, but they only drop in occasionally. There is no single person who has their head around the entire project. This is very bad.

There may be a project manager on the project. And senior people. A lead tester. A scrum leader. An Ops person. And usually several others. None of these people have their head around the entire project though. So none of them alone are able to see project-wide risk, or execute significant tasks without tons of communications. This is very bad.

Tasking may be without context of the larger project. There are no priorities — the team is spending time on things that may not even need to be done to reach the goal. But they do seem busy and busy is comforting. Busy creates the illusion that the team is working toward a finish — which serves to delude the actual people doing the work. Working is great. If it counts. Otherwise, working is wasteful and we should not do it (unless it’s academic).

Just because you are finishing tasks doesn’t mean you’ll finish the project.

Finishing the project is the only thing that matters. It’s a results driven world. Let’s fix it.

How to fix a failing project

Now that you’ve observed the problem, let’s enter project rescue mode. Here’s how I would do it, specifically:

1. Draw the big picture — literally. Draw a picture of the entire universe of the project at a high level. However big it is — every site, every service, every database, every component. Now, you and everyone can see everything with context. For example, if there are ten tasks about a database replication, you need to see the context within which this need exists, what systems it impacts, and even which teams those systems belong to.
2. Draw the big picture of the personnel on the project, and their basic roles. Now you know who knows what. Also map out other groups and people that this team depends on. They might also be slowing things down. Communication lines may be undefined entirely or incorrectly presumed.
3. Define broad acceptance criteria for the project itself. Acceptance criteria at the project level makes it clear for all to see the end goals, both functional and non-functional. There may be many criteria to meet. For example, the site is available in 2 regions and failover is automated and tested. Or the services scale to handle 10K requests/second.
4. Remove spectators — people who show up for the calls but don’t contribute anything. They may be low performers or just people who used to be relevant to the work but no longer are. Spectators are not neutral actors. They are net negative actors because they give others license to also be spectators. Spectating is a virus. You can’t even let one of them in the room. I was once on a project with 37 people invited to the daily call — at a point well before that, everyone assumes that everyone else is a spectator. That’s taking it to the extreme, but normally I want fewer than ten people in the room.
5. Clear other significant priorities for everyone on the team. If this project matters, then everyone has to focus on it. There is no room for people with other projects. Other projects serve as excuses for low results on this project. Build accountability and empowerment by removing excuses.
6. Become the singular leader or define who that person is, if there is someone fully capable. To the extent you can, stop working on other things because this project needs max focus. As the singular leader, you have to understand the big picture so you can stop wasteful work and focus only work that impacts the results. You must now understand everything going on in the project — every task. It’s also important to clarify that whoever was supposedly the leader, no longer is.
7. Define the next increment. Set the one next meaningful goal, which should be reachable within 2–3 weeks. This has to be something which is able to be demonstrated. Change the momentum by getting a small win. Small wins build team spirit.
8. Once daily team meetings are required and you have to run, or at least attend, them. Cancel every other meeting related to the project unless you know for a fact that it’s necessary. Cover every blocker and every past due item — you do know what is past due? This may require some initial triage to get there.
9. Do not add new people to the project until you know for a fact that they are needed.
10. Take a broad risk assessment. Look ahead as much as possible to understand what big risks could derail the project long term. Don’t try to find small risks — it’s too soon. Make sure the big risks are addressed. For example, did anyone acquire budget for the infrastructure required?

Focus, simplify, and continuously demonstrate results.

Reduce the project and reduce the people on it to only what is necessary to gain some small wins, then execute relentlessly.

From here, small problems will continue to surface but they should be immediately obvious given the new plan. The worst case scenario is that the team doesn’t have the skills required to deliver the work. This is actually uncommon in my experience. If it is the case though, then we require additional personnel — but at least you can see it clearly now. And when the help arrives, there will be a coherent project for them to enter. They are not just thrown into the vortex.

Good luck.