What this helps with
The Condition vs. Pattern Mapping helps distinguish between structural inputs that shape behavior and the patterns that emerge in response over time.
It prevents misdiagnosis by separating what the system is set up to do from what people learn to do within it.

What it is not
This is not a root cause analysis.
It is not a causal proof exercise.
It is not a diagnostic scorecard.
It does not assign fault or predict outcomes.
Used incorrectly, it becomes a theory-building exercise. Used well, it becomes a discipline of observation.

Boundary reminder
This tool supports interpretation and judgment. It does not determine which conditions must change or how.
Action depends on authority, feasibility, and risk.

Condition vs. Pattern Mapping

How I’ve used it
I use this mapping when behavior is being explained primarily through intent, capability, or communication, and those explanations no longer fit.
Separating conditions from patterns often reveals that people are adapting rationally to the environment they are in, even when the resulting outcomes are undesirable.

What it captures
At a minimum, the mapping records:

• observed behavior or outcomes,

• suspected structural conditions,

• evidence those conditions exist,

• and patterns that repeat across time.

Including who adapts, what is rewarded, and what is discouraged helps make system learning visible without attributing motive.

When it tends to help
This tool is most useful when:

• similar issues recur despite different people or teams,

• behavior shifts under pressure without explicit instruction,

• explanations rely heavily on “culture” or “mindset,”

• or improvement efforts focus on people rather than structure.

It is especially helpful in complex, cross-functional, or inherited systems.

Relationship to the Project Systems Framework
The distinction between conditions and patterns sits at the core of the framework.
Conditions shape behavior, and patterns emerge as rational adaptations to those conditions. This mapping makes that relationship explicit without collapsing it into causality or prescription.

What this helps with
The Authority–Accountability Map helps make visible where responsibility for outcomes exceeds the authority required to achieve them.
It clarifies how decision rights, ownership, and expectations are distributed in practice, not just on paper.

What it is not
This is not a role clarity exercise.
It is not an org chart.
It is not a governance model.
It does not assign authority or redefine accountability.
Used incorrectly, it becomes a negotiation tactic. Used well, it becomes a boundary reference.

Boundary reminder
This tool supports interpretation and boundary clarity. It does not grant authority or compel alignment.
What happens after misalignment is identified depends on leadership intent, risk tolerance, and organizational reality.

Authority-Accountability Map

How I’ve used it
I use this map when PMs are held accountable for outcomes they cannot meaningfully influence, or when decision-making feels diffuse despite clear ownership language.
Mapping authority alongside accountability often reveals that expectations are coherent, but power is not.

What it captures
At a minimum, the map records:

• areas of accountability,

• where decision authority actually resides,

• where authority is implicit, shared, or time-bound,

• and where work proceeds despite unresolved ownership.

The goal is not precision, but visibility.

When it tends to help
This tool is most useful when:

• escalation feels frequent but ineffective,

• decisions require many approvals but no clear owner,

• accountability is enforced without corresponding authority,

• or PMs are expected to “drive” outcomes without levers.

It is especially helpful in matrixed, portfolio, or vendor-heavy environments.

Relationship to the Project Systems Framework
Authority–accountability misalignment sits at the core of system degradation.
When responsibility flows without authority, work compensates through delay, workarounds, or risk redistribution. This map makes those dynamics legible without assigning blame.

What this helps with
The Escalation Cost Inventory helps make visible the costs introduced by escalation itself, not just the issue that prompted it.
It captures how time, attention, risk, and effort are redistributed once escalation enters the system.

What it is not
This is not a critique of escalation decisions.
It is not a deterrent to raising concerns.
It is not a performance measure.
It does not assume escalation is avoidable or wrong.
Used incorrectly, it becomes a discouragement tool. Used well, it becomes a realism check.

Boundary reminder
This tool supports interpretation and judgment. It does not argue for or against escalation.
Whether escalation is appropriate depends on context, authority, and consequence.

Escalation Cost Inventory

How I’ve used it
I use this inventory when escalation is frequent, expected, or formally encouraged, yet outcomes do not improve proportionally.
Tracking escalation over time often reveals that while issues move upward, costs move outward, absorbed by teams, schedules, or relationships.

What it captures
At a minimum, the inventory records:

• what was escalated,

• what triggered escalation,

• where it went,

• what response occurred,

• and what costs were introduced as a result.

Separating direct costs from indirect or deferred costs prevents escalation from being treated as free or neutral.

When it tends to help
This tool is most useful when:

• escalation is treated as the primary problem-solving mechanism,

• issues recur despite repeated escalation,

• leaders believe escalation is resolving uncertainty,

• or teams hesitate to escalate without being able to explain why.

It is particularly useful in hierarchical, matrixed, or risk-averse environments.

Relationship to the Project Systems Framework
Escalation is a critical moment that teaches the system what happens when concerns are raised.
When escalation carries unexamined cost, systems adapt by delaying, buffering, or avoiding it. This inventory makes those dynamics visible without discouraging professional judgment.

What this helps with
The Ambiguity Classification Worksheet helps distinguish between ambiguity that enables judgment and ambiguity that quietly degrades outcomes.
It makes uncertainty explicit so it can be understood as signal, rather than treated reflexively as a problem to eliminate.

What it is not
This is not a demand for clarity.
It is not a requirements checklist.
It is not a forcing function for decisions.
It does not assume ambiguity is failure.
Used incorrectly, it becomes a premature simplification. Used well, it becomes a diagnostic lens.

Boundary reminder
This tool supports interpretation and judgment. It does not determine whether ambiguity should be resolved.
That choice depends on context, authority, timing, and consequence.

Ambiguity Classification Worksheet

How I’ve used it
I use this worksheet when work feels stalled, tense, or oddly cautious, and the stated cause is “lack of clarity.”
Classifying ambiguity often reveals that some uncertainty is doing useful work, while other forms are masking decision avoidance, power asymmetry, or misaligned incentives.

What it captures
At a minimum, the worksheet records:

• what is ambiguous,

• where that ambiguity shows up,

• why it exists,

• how the system responds to it,

• and who bears the impact.

Separating when ambiguity helps from when it harms prevents false binaries and supports more accurate judgment.

When it tends to help
This tool is most useful when:

• teams request clarity but cannot agree on what kind,

• decisions feel blocked without an obvious owner,

• exploration and delivery are conflated,

• or uncertainty persists longer than its original purpose.

It is especially helpful in discovery-heavy, cross-functional, or politically complex environments.

Relationship to the Project Systems Framework
Ambiguity interacts with every pillar of the framework.
Unexamined ambiguity can train systems toward delay or risk avoidance, while intentional ambiguity can preserve learning and local judgment. This worksheet helps tell the difference without forcing resolution.