--- title: "How to find hidden problems in your project before it’s too late" url: "https://www.5whys.com/articles/how-to-find-hidden-problems-in-your-project-before-its-too-l.md" canonical: "https://www.5whys.com/articles/how-to-find-hidden-problems-in-your-project-before-its-too-l.html" published: "2009-09-08T19:32:29+00:00" updated: "2009-09-13T22:07:12.663000+00:00" tags: ["Shu"] author: "Roy Osherove" description: "A pre-mortem technique for new team leads: ask the team and stakeholders to imagine the project has failed and explain why, surfacing hidden risks early." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # 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! ## Read next - [Daily Standup Meetings - Introduction and 5 useful tips](https://www.5whys.com/articles/daily-standup-meetings-introduction-and-5-useful-tips.html): How to run a daily standup meeting with the three questions, why each question matters, and five hard-learned tips for keeping it under 15 minutes. - [Step #2 – Use a big visible board with post it notes](https://www.5whys.com/articles/step-2-use-a-big-visible-board-with-post-it-notes.html): How a team lead can use a big visible whiteboard with sticky notes to track tasks, expose developers juggling several tasks, and show management the load. - [Spend at least 50% of your time with your team](https://www.5whys.com/articles/spend-at-least-50-of-your-time-with-your-team.html): Why a team lead should block 50% of each day as team time, and how to use the Five Whys and assertiveness to cut down on meetings that add no value. --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/