Scenario: a product development team at a medical device company had a testing phase that ran far longer than expected. This delay rippled throughout the project and had serious implications downstream. After the project was complete, the team leader wanted to go back and figure out why the test phase had not gone as planned. She received pushback from the team: “The past is past; let’s just move on and do better next time!”
But the team leader insisted that they team sit back down and try to figure out what happened and how future teams could avoid the mistake. By capturing that knowledge, the organization, as a whole, might benefit.
Too often we have heard – especially in Silicon Valley – that the past is meaningless and that teams just need to “move on.” We couldn’t disagree more. Post mortems and careful, after-the-fact analyses of both the successes and SNAFUs of your projects is necessary for organizational learning. Too often, we see teams making the same mistakes more than once. Or different teams within the same company repeat avoidable errors. This is costly, frustrating, and unnecessary.
The key to getting the benefit out of analyzing past difficulties is to dig deep, below the surface. Getting to the real root causes of project issues is a task that requires a little knowledge and some skills. We’ve created a four-step process that can help.
The first step is to identify the problem by creating a clear statement of it. If you cannot reach a clear and unequivocal statement of the problem, it will be impossible to solve.
Example problem statements:
- What are the root causes of our changing requirements for the XYZ project?
- What are the root causes of our Project ABC’s time-to-market delays?
- What are the root causes that led our support costs to be so high in our 2.1 release?
Next, create categories, such as people, processes, environment, management, external event, that will help you categorize a set of proposed root causes. Categorizing the various causes ensures that nothing is omitted from your analysis. For instance, what might look like a people issue, say a skill set on the team that wasn’t as strong as anticipated, may actually be a management issue, or may have management implications. To get to root rather than surface causes, it’s necessary to look at your project in a very broad context, and this step helps you to define that context. If such broad categories are not helpful, then you may categorize suspected root causes by function (marketing, design quality, etc.), or by phase (concept, design, and testing, launch) or in some other manner that best fits your team’s situation.
The third step is to then take each proposed root cause and ask “why?” within each category. For example, if the skill set on the team was inadequate, ask why this happened on the level of the individual contributor (people), on the level of management, or on the level of internal processes, if applicable. Don’t be satisfied with easy answers. Keep asking why up to five times.
Some teams use an Ishikawa diagram to capture this data. Our approach is to use a spreadsheet-based tool called a Root Cause Diagram. This tool easily captures the proposed root causes, in their categories, and level of depth.
A cross-functional team implements the Root Cause Diagram, carrying out the previous steps: defining the problem, suggesting root causes and categorizing them by type, and then asking “Why?” more than once. Hold a first, one-hour session, for these steps. The fourth and final step in the process, where the team comes to an agreement on the most likely or important root causes, may follow in a second, one-hour session.
Using a spreadsheet tool facilitates the process because it is trivial to share and archive. This process also build consensus since it is cross-functional and collaborative. It also allows those who may have had grievances about the previous issue to air them and explain their side of the story. Above all, a process such as we have described eliminates “who shot John?” time-wasting and enables evidence-based management.
Whether teams use the simple process and tool we’ve described or some other one, it’s necessary for teams to have some way to enable improvement and ensure that the same mistakes are not repeated. It is worth far more than the couple of hours required to go through the process. Teams must not let past mistakes define their future as well.
Wait! Before you go…
Choose how you want the latest innovation content delivered to you:
- Daily — RSS Feed — Email — Twitter — Facebook — Linkedin Today
- Weekly — Email Newsletter — Free Magazine — Linkedin Group
John Carter has been a widely respected adviser to technology firms over his career. John is the author of Innovate Products Faster: Graphical Tools for Accelerating Product Development. As Founder and Principal of TCGen Inc., he has advised some of the most revered technology firms in the world.