You can’t deny it: no matter how much we plan a project, something that was not previously mapped will eventually appear. That is a fact. And when these problems are not properly understood and resolved, they can generate serious consequences, such as:

• Delays in deliveries
• Delays in launching products or enhancements
• Problems with stakeholders
• Teams feeling under pressure
• Layoffs

I also recommend reading my article “How to measure the productivity of your team and how to improve it” to better understand team performance, and the article “Stakeholders – improving your power and impact” to improve the management of stakeholders involved in your project.

Returning to our topic, when we face a problem, we can use specific techniques to gain a deeper understanding of what is happening and search for solutions that address the problem at its origin. In project environments, data can also support this investigation. A platform like Saint Jude can help managers identify patterns in delays, wrong estimates, team performance, cost consumption, task quality, sprint deviations, and risks. This does not replace root cause analysis, but it gives managers better evidence to understand where the problem may be coming from.

Let’s move to our first technique:

Hypothesis formulation

To formulate good hypotheses, we first need to understand the problem, its characteristics, its context, the people involved, the relationships between them, the procedures connected to the problem, and the expected results versus the actual results.

Using tools such as a system diagram or a network diagram can be a good starting point to understand the situation, especially when we want to focus on processes, flows, and results. I will give you an example and explain it below:

System Diagram - Network Diagram

• Rectangles represent something accumulated over time, such as population
• Arrows represent flows, such as birth and death rates
• Circles represent auxiliary variables, such as population density
• Plus and minus signs represent whether the flow is increasing or decreasing

Stakeholder analysis

Stakeholder analysis helps us understand who the actors are, how they relate to each other, and, many times, the context in which they are inserted. I will mention again my article about this topic: “Stakeholders – improving your power and impact”.

Scenario analysis

This part of hypothesis formulation is used to explore alternative scenarios about how the problem may evolve and how we can resolve it. We base this analysis on assumptions, variables, and uncertainties. Then, we validate the implications and risks of each scenario to support decision-making. Here is a step-by-step process:

1. Identify the problem
2. Define what is influencing the problem
3. Establish how the problem can evolve in the future
4. Build different scenarios
5. Compare the scenarios, considering advantages, disadvantages, opportunities, risks, and implications

Example:

• Problem: My tech leader requested a salary increase
• Influence: work overload and excessive responsibility
• Possible evolution: resignation request and delays in deliveries
• Scenarios:
  • The tech leader resigns, and there is no documentation for the project
  • The tech leader starts transferring responsibilities to someone else, but without formal documentation
  • Other team members become dissatisfied because of unexpected demands
  • The tech leader resigns, and the manager does not have senior developers available

Disclaimer: Be careful when formulating hypotheses based on unclear processes or stakeholders with high impact who were not properly mapped. Lack of clarity can lead us to make serious mistakes when creating our hypotheses.

Here, Saint Jude can support the analysis by showing whether the project already has signs of overload, such as tasks concentrated in one person, delays by seniority level, recurring bugs, poor task descriptions, or an imbalance between planned allocation and actual work. These indicators can help managers create better hypotheses instead of relying only on perception.

5 Whys

In my opinion, the 5 Whys technique is one of the best and easiest ways to discover the root cause of a problem. However, it works well only when used transparently, even when we are dealing with political issues inside a company. Sometimes, people are afraid to say what is obvious to everyone. When that happens, the technique loses part of its power.

Example:

- Why don’t we have access to the production machines?

- Because the security area has not provided us with access.

- Why has the security area not provided us with access?

- Because they told us that only the security team can access production.

- Why can only the security team access production?

Everybody thinking:

- Because the CTO required it.

Even when the answer seems obvious, the exercise of continuing to ask “why” until you reach the root cause can be revealing. It helps separate assumptions from facts and makes the real issue more visible to everyone involved.

What are the advantages of the 5 Whys?

I identify advantages such as:

• Identifying process failures
• Analyzing low performance
• Investigating conflicts
• Understanding trends
• Understanding the success of a product
• Understanding the failure of a product

How to do the 5 Whys exercise?

Despite the name, it is not mandatory to stop at the fifth question or to reach exactly five questions. The number five was chosen because it is usually a good measure to find the root cause. The concept is to continue asking until you find the real reason behind the problem. In the example above, I could have continued with: “Why did the CTO require only the security team to access production?”

Another useful practice is to always start the next question using the previous answer. This creates traceability and helps us follow the logic of the problem. Example:

- Why are the tasks delayed?

- Because the developers are estimating them incorrectly.

- Why are the developers estimating them incorrectly?

In the end, when we find the root cause, we can move toward the solution. I will leave here another article I wrote: “How to find the right solutions to your project’s problems.”

In this example, Saint Jude can help support the investigation by comparing estimated versus actual task duration, identifying which types of tasks are usually delayed, which professionals or seniority levels are most affected, and whether delays are related to bugs, user stories, subtasks, features, or specific tags. This makes the 5 Whys exercise more factual and less dependent on opinion.

Ishikawa diagram

The Ishikawa diagram, often called the fishbone diagram, is a technique used to understand a problem from a systemic perspective. In other words, it helps us take a step back and see the overall scenario instead of looking only at isolated symptoms.

To use it, we can start with a model like the image below, which I will explain step by step.

Fish’s head – initial problem

Here, we put the initial problem for which we need to find the root cause. Example: All our tasks are delayed.

Fishbone and 6Ms

In the fishbone, we organize the possible causes related to our main problem, checking whether they belong to one of the 6Ms:

• Machine: all equipment, tools, and machines used
• Method: processes and instructions adopted
• Material: raw materials, components, and information
• Mission / Mother Nature: company environment, physical environment, and company purpose
• Measurement: inspection, monitoring systems, and controls
• Manpower: people involved

Let’s move to our example. We will start with our main problem: “All our tasks are delayed.” From this problem, we will place possible causes on the fishbone. Example:

• Machine: lack of DevOps automation for deployments in staging and production
• Method: refinements are not considering the developers’ experience
• Material: our components are not reusable
• Mother Nature: -
• Measurement: -
• Manpower: too many junior developers in the team and lack of a DevOps professional

Our diagram:

Notice two important points in our example:

1. Not all Ms were filled in, only those related to the main problem
2. One cause can appear in two or more Ms, such as the team’s experience, which appears in Method and Manpower, or DevOps, which appears in Machine and Manpower

Disclaimer: In my understanding, when the same cause appears in two or more places, it is a strong candidate to be the root cause. I usually prioritize it in my list of resolutions.

Disclaimer 2: The Ishikawa diagram can be used together with the 5 Whys technique. By doing this, we can identify the root cause for each M and define sub-problems that must be resolved to eliminate the main problem.

This is another place where Saint Jude can help. If the problem is “all tasks are delayed,” the platform can help break down the analysis by area, seniority, role, task type, tag, cost, allocated hours, consumed hours, and sprint performance. This helps managers see whether the problem is related to people, process, estimation, task quality, workload, or delivery flow.

Problem statement

Finally, after applying techniques to uncover the root cause, we need to define the problem statement. But what is a problem statement?

A problem statement is a clear declaration of the problem we are going to solve. It is almost like a declaration of war against the problem. In this declaration, we specify the scope, why the problem matters, and what objectives we want to achieve by solving it. We also need to include acceptance criteria and restrictions. Below, I will explain how to build this document and provide an example.

How to build a problem statement

To build it, we must:

• Define the problem clearly – describe what is happening, where, when, and why
• Identify the stakeholders – define who is impacted by the problem, their expectations, behaviors, and position regarding it
• Define criteria to evaluate the solution – here we can use acceptance criteria and objectives, such as cost reduction, time reduction, quality improvement, security improvement, and others
• Quantify the problem – if possible, quantify how much the problem is hurting the project. Example: 1 month of delay or US$ 100,000 per semester in additional costs
• Explain the root cause – here we can include the results found through the techniques explained above

Disclaimer: Remember that the problem statement must be SMART:

• Specific (S)
• Measurable (M)
• Achievable (A)
• Relevant (R)
• Time-bound (T)

Let’s go to our example:

“The delay rate in user story deliveries for Team X is around 20%, which generates approximately 1 month of delay every semester, US$ 100,000 in additional costs per semester, and dissatisfaction among the final customer, CTO, CEO, and finance area. The main causes of these delays are the team’s lack of experience and inaccurate estimations. How can we reduce these delays to 5% in 3 months?”

A strong problem statement depends on facts. Saint Jude can support this step by consolidating data about schedule, cost, task estimates, professional performance, bugs, task types, sprint deviations, and risk indicators. With this visibility, managers can write problem statements based on evidence instead of assumptions.

From this point, we can move toward the resolution. Here, I share another article about it: “How to find the right solutions to your project’s problems.”

I arrive here at the end of this article. Here, you learned four techniques to find the root cause of a problem: hypothesis formulation, scenario analysis, the 5 Whys, the Ishikawa diagram, and the problem statement.

What do you think about this article? Would you like to add any tool that you consider important?

Give a like to this article, comment on LinkedIn, or share it on your social media.

See you soon!

Erik Scaranello