The Elastic Leadership Book



        RSS Feed

Latest Entries


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 | Main | Making Impossible Decisions Without Panicking »

Reader Comments (4)

This is a visioning technique I have learned in other verticals but not yet applied to software development. It's a well-tested technique for collective dreaming as strategy planning.

And it works.

One caveat, like most visioning sessions, it is critical to create a safe space for people to give voice to their insights and equally critical to keep your mouth shut and listen to what is being said.

September 8, 2009 | Unregistered CommenterDavid Alpert

Very clever - thanks for sharing!

I can totally see how this would get people talking & thinking about the issues they're struggling with. Maybe even relieved to see that someone is actually listening to their concerns.

I wonder if you could add to it by following the responses up with a "okay, so let's pick the top 3 and figure out what steps we can take right now to turn them around so that failure doesn't happen." so the team doesn't walk out of the meeting with an impending sense of doom... ;-)

September 8, 2009 | Unregistered Commenterabby, the hacker chick blog

I think I read about this in Waltzing with Bears, which I remember for this tidbit: most people can count the cost of their project to the penny, but have no idea about its value. They can say the project cost $7,318,192.34, but when you ask them about its value, they say "Lots, we hope."

September 9, 2009 | Unregistered CommenterJ. B. Rainsberger

Very nice idea. I can't wait when I will be able to try it.

September 11, 2009 | Unregistered Commenterleszcz

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>