5 Whys is a blog about technical leadership in the software world.

How to find hidden problems in your project before it’s too late

A team lead I met a couple of years ago told me of a very effective technique he used in new projects and teams where he didn’t yet know what’s really going on, the team members, or all of the things that needed to be taken care of. He told me what happened the first time he tried it:

It was 5 months before the supposed release of the project he had just gotten into. everyone looked very busy but he didn’t really know where to start. So he gathered the team in one room, including one of the stakeholders (project lead) and the QA manager, and asked them all one simple question:

“Imagine it’s the end of the project – 5 months from now. We’re standing in this same room, and the project has totally and utterly failed.

Why did it fail?”

As he said that, people around the room started talking about various things that are currently holding the project down, risks that needed to be mitigated, and quality issues that needed to be resolved. The QA manager said he didn’t yet get anything to test, and that the way things looked he will get them waay too late, which means the release will surely be late. The developers said that they have been rewriting the software three times over so far since no one seems to really know what they want. One of the developers mentioned that they are only working on the project half time since they are also working on two other projects at the same time – so he didn’t see a way this ends well.

The team lead wrote down all those risks and after 45 minutes he had a ready made list of things that really needed taking care of.

He knew what he needed to do.

What can you learn from this?

If you are a new lead on an old project, there is no hard in trying out this technique. It is a smooth and brilliant way of getting people to think of obstacles, and fleshing out problems before they arose too late to take care of.

Gather your team, and take a couple of stakeholders with you (stakeholders are the people in your company that will suffer greatly if your team fails to deliver the project). ask them the question.

You might be surprised by what you find.


Do you have your own cool technique? Share it in the comments!

Step #4 - Start doing code reviews – Seriously

Making Impossible Decisions Without Panicking