Problems as Treasures: A Problem Taxonomy for Your Project.

"Another mess to clean up." Project management involves an enormous amount of attention devoted to problems. In agile we call them impediments and dependencies; sometimes we also include risks. In ITIL we distinguish between incidents and problems.

The effect of problem management on projects is an almost endless chain of decisions that, at times, drives the business, the technical team, and the management profile that arranges and monitors them as a servant leader to distraction. To handle disagreements and bring some order, we usually turn to a prioritization matrix if we're in a sensible, coordinated context. If we're in a different context, we fall back on experience by similarity, and if not, on impulsive decisions based on perceptions, urgencies, or fears.

The problem isn't that problems exist. The problem is treating them all the same. Problems aren't challenges, but they can be challenging. Poorly conceptualized challenges (true need, sponsorship, expected outcome, deviations) turn into problems.

Cynefin: understanding the context first

Almost three decades ago, Dave Snowden taught us about Cynefin and the 5 context domains where problems live:

• Clear/Simple: a stable, obvious, and known cause-effect relationship. Standards exist and no experts are needed.
• Complicated: the cause-effect relationship exists but isn't obvious; you need to analyze it or bring in specialists to find it. More than one correct solution exists once diagnosis is done.
• Complex: the cause-effect relationship can only be understood in hindsight, because the system has many interacting variables that are hard to visualize, with emergent and unpredictable results. Since no established best practices exist, challenges are approached experimentally.
• Chaotic: no cause-effect relationship can be discerned, either before or after, since the environment is in crisis and/or changing too fast. The approach is to first stabilize, then observe, and then try to establish some order toward standardization.
• Disorder: a state in which it isn't clear which domain you're in; there's confusion, and each actor interprets the situation according to their own bias. The goal is to diagnose and classify the situation, moving the problem into one of the four domains above so it can be acted on appropriately.

It's an abstract taxonomy that lets us pinpoint the nature of the challenge. Before solving, it's worth understanding what type of context we're operating in. There are also frameworks and methodologies that define problem typologies more closely tied to a specific area of work.

ITIL: incidents and problems are not the same thing

In ITSM, there's the classic ITIL approach to problems/incidents from a proactive or reactive standpoint, assessing them with the simple and effective impact and urgency matrix.

ITIL reminds us of something basic: putting out the fire and understanding why it started are not the same activity.

Aware that both coexist within a continuous improvement approach, ITIL establishes a framework to reduce the probability of impact and places emphasis on avoiding recurrence by learning from experience. To do this, it distinguishes between incidents and problems:

Incident management

• Objective: restore the service quickly, "put out the fire," even by rolling back changes or using workarounds.
• Horizon: short term, focused on operational continuity and user experience.

Problem management

• Objective: understand why incidents occur and how to prevent them from recurring, through structured root cause analysis.
• Horizon: medium to long term, focused on service stability, reliability, and continuous improvement.

In practice, a serious or recurring incident usually triggers the opening of a problem to investigate its causes. And the findings from problem management usually give rise to change requests to permanently fix the service.

A matrix for executive problems

If what we need is an order of magnitude and logic for executive-level problems, one that isn't purely tied to technology nor as abstract as Cynefin, I'd like to propose a matrix combining two well-known typologies that you might find inspiring.

I base it on combining Peter Drucker's typology with Art Smalley's:

Peter Drucker's generic typology

Peter Drucker distinguished four types of problems that appear in organizations based on how they arise and persist:

1. Truly generic: cases that are symptoms of a recurring pattern within the organization — today we would call them "systemic." Drucker explains that most problems are of this nature, and that although symptoms may vary in how they manifest, they are just adaptations of the original. This clears the path considerably if we're able to find the root cause.
2. Unique: your organization experiences them only once, but the situation is common in other organizations. They aren't anomalous or rare, and you can seek support by looking at similar situations faced by competitors or partners.
3. Truly exceptional, truly unique: singular situations that can't be treated as textbook cases; they usually have complex, multifactorial causes that rarely converge again.
4. Early manifestations of a new generic problem (Earlys): weak signals of a trend that will become recurring if not addressed. Extremely interesting and profitable to tackle before they contaminate the ecosystem.

From my experience in Lean, this classification forces you to decide whether to act with improvement responses (Kaizen), design new policies (Kaikaku), or engage in deeper strategic reflection (Kakushin).

Art Smalley's typology

Art Smalley also proposes four types of problems, but from the angle of how they're approached:

1. Troubleshooting: a reactive response to "stop the bleeding" and return the situation to the known standard as quickly as possible.
2. Gap from standard: using structured problem-solving to eliminate root causes preventing the standard from being met. The measures remain reactive but systematic and planned.
3. Target state: a proactive, continuous-improvement approach aimed at reaching a performance level better than the current one, defining a new standard.
4. Open-ended: proactive, creative exploration of radical solutions or new models that go well beyond current levels of value.

Each type calls for different methods, management cadences, and mindsets. All of them share, as their guiding axis, their relationship to the standard as an ideal.

Crossing the nature of the problem with its method of resolution

What I apply in projects is a combined matrix. Its power lies in crossing the nature of the event (Drucker) with the resolution methodology (Smalley). This avoids the classic mistake of applying "engineering solutions" to "management problems", or vice versa.

Drucker helps you understand the nature and recurrence of the problem within the system, while Smalley points you toward the practical resolution approach from Lean.

How to use this matrix in projects

This matrix lets you categorize any deviation in a project and select the appropriate resolution "style." You can start from the row (Drucker): is this problem generic, unique, exceptional, or an early signal of something that will recur? Then you choose the column (Smalley): should we contain it, tackle a deviation from standard, pursue a target state, or open up a space for innovation?

Consciously using this double classification helps avoid two very common mistakes: treating strategic crises as simple operational incidents, or, the other way around, using "innovation" when in reality it would be enough to standardize and fix a recurring deviation in the project. Both inappropriate actions are forms of Muda: management waste that should be identified and eliminated.

Problem management is a cross-functional effort: it requires participation from development, operations, security, business, and other teams to investigate causes and design effective solutions.
Once the process for approaching problems is established and understood, problems become the cornerstone of growth and adaptation: true treasures of the organization, levers of competitiveness and learning.

At Rev by Paradigma, thanks to our experience in agility, lean, and digital product design, we build simple processes for approaching problems in situational or systemic circumstances, which can be surgical or sustained depending on our clients' needs.

Classifying a problem well doesn't automatically solve it, but it keeps you from starting in the wrong place. And in complex projects, that alone is a huge advantage.

References

• Cynefin Framework
• Snowden & Boone - A Leader's Framework for Decision Making, Harvard Business Review
• Peter Drucker - The Effective Executive
• Art Smalley - Four Types of Problems