🎯 Theme: Why Most Data Projects Solve the Wrong Thing

This page provides a framework for constructing and deconstructing complex problems using PDIA methodology, 5 Why’s technique, and fishbone diagrams to identify root causes rather than symptoms before developing solutions.

Constructing the problem

This section draws on the Problem Driven Iterative Adaptation (PDIA) approach developed by Harvard’s Building State Capability programme. It encourages a deeper construction of the problem to ensure that the work addresses root causes, not just symptoms, and mobilises local ownership and momentum for change.

The purpose of this section is not to jump to solutions, but to construct a shared understanding of the problem—why it matters, who it affects, and what the implications are for inaction. A well-constructed problem creates urgency, aligns stakeholders, and creates space for locally grounded, adaptive responses.

Problem Construction Framework (PDIA-inspired):

• What is the problem?

Clearly articulate the specific data issue or challenge. Avoid framing the problem as the absence of a solution (e.g., “we don’t have a dashboard”). Instead, focus on what isn’t working (e.g., “Service delivery complaints reported via community engagements are not consistently tracked, analysed, or followed up on, resulting in limited accountability.”)

• Why does this problem matter?

Go deeper into the consequences of the issue. This might relate to inefficiency, broken feedback loops, equity concerns, or reputational risks. Use data or examples where possible. Ask “why does this matter?” multiple times to unpack the significance and reach the root cause.

• To whom does the problem matter?

Identify the stakeholders who are most affected (e.g. community members, ward councillors, service departments) and those who need to care more (e.g. executive leadership, monitoring and evaluation units). This is crucial for framing the problem in a way that can build broad-based ownership.

• How do we bring attention to the problem?

Describe the evidence, narratives, or indicators that can be used to make the problem visible and urgent (e.g. stories of unresolved complaints, maps of issue hotspots, lack of progress across repeated reports).

• What will the problem look like when it is solved?

Outline a vision of success that stakeholders can align around. This may be: “Community-raised issues are tracked in real-time, linked to responsible departments, and resolved transparently, with feedback loops in place.” While this might not be achievable in one iteration, this shared vision provides direction.

Example:

The current problem is that service delivery issues raised by communities during mayoral visits are stored in Word documents and manually shared with departments. These issues are often long-standing and politically sensitive, yet there is no central way to track progress or ensure accountability. This matters because it undermines the responsiveness of local government, risks reputational damage, and creates inefficiencies in responding to the public. While some systems exist (e.g. CRM platforms), they are disconnected from this process. This affects both the community, who lack visibility, and municipal staff, who struggle to coordinate and report effectively. By showcasing how this data can be structured and visualised, the project aims to trigger momentum for better practices and improved service delivery.

Deconstructing the problem

Once a problem has been constructed and agreed upon, it is critical to deconstruct it. Deconstructing a problem allows us to understand its complexity, avoid premature solutions, and break it down into manageable parts that can be addressed in a sequenced, locally appropriate way.

Often, what appears as a single issue is the result of multiple, layered causes. Without understanding these, we risk designing interventions that treat the symptoms rather than addressing the root drivers. The purpose of this section is to go beyond surface-level observations and unpack the system of causes that lead to the issue at hand. This creates a stronger foundation for action and allows for more precise entry points.

This section should be completed collaboratively with key stakeholders, as they will each bring perspectives that can help reveal operational, institutional, and behavioural dimensions of the problem. The process is guided by two complementary tools: the 5 Why’s technique and the Ishikawa (Fishbone) Diagram.

The “5 Why’s” Technique

The 5 Why’s method is a structured conversation tool that helps explore why a problem exists by repeatedly asking “why does this happen?”—typically five times or more. Each answer leads to the next layer of cause.

Example (framing the problem as a question):

Problem: Why is it difficult to track service delivery complaints raised during community visits?

1. Because the issues are stored in unstructured Word documents.
2. Because there is no agreed system or process for capturing the data centrally.
3. Because community engagement is seen as separate from operational systems like CRM.
4. Because data governance structures across departments are fragmented.
5. Because responsibility for system integration has not been clearly assigned or resourced.

The 5 Why’s help to surface both technical and political causes, and begin to differentiate between symptoms, underlying conditions, and systemic barriers.

Ishikawa (Fishbone) Diagram

The second tool is the Ishikawa Diagram, also known as a fishbone diagram. This helps to categorise and visualise the root causes identified in the 5 Why’s under different “bones” or categories. These categories can be adapted to the context of the issue—for example:

• Processes (e.g. data capture procedures, review workflows)
• People (e.g. responsibility, skills, communication gaps)
• Systems/Tools (e.g. CRM platforms, dashboards, access to Power BI)
• Governance/Policy (e.g. decision-making authority, accountability)
• Culture and Norms (e.g. fear of reputational damage, siloed mindsets)

Each branch of the diagram should be populated with sub-causes, drawn from the 5 Why’s analysis. The completed fishbone provides a shared visual of the systemic complexity of the issue.

Example Fishbone Categories for a Data Governance Problem:

Output of this Section

The completed analysis should result in:

• A clear articulation of root causes, not just symptoms.
• A shared understanding of the different dimensions of the problem.
• A starting point for sequencing and prioritising interventions (to be detailed in the next section).
• A diagnostic visual (fishbone diagram) that can be revisited and updated throughout the project.