Five dimensions for examining any delivery system

The five dimensions of delivery effectiveness are the domains in which system behavior is observed, understood, and improved.

How This Fits Into PPA — Dimensions give "Problem" its address

PPA, Problem, Principle, Action, is the diagnostic engine Entrowise uses to address recurring delivery problems. But "problem" on its own is imprecise. The same symptom can originate in entirely different parts of the system.

The five dimensions solve this. They are the five domains in which any delivery system behavior can be observed and categorized. You do not arrive at a dimension through a problem. You examine the system continuously across all five. What you observe in a dimension, through metrics as evidence, is the Problem in PPA terms.

Knowing which dimension an observed behavior lives in tells you which class of principles is most likely compromised. That is where diagnosis begins. Action is a change in practice that realigns behavior with those principles.

How the dimensions map to PPA: Five Dimensions → Problem in PPA (observed here) is System Behavior — effective outcomes or recurring problems, with Metrics as evidence (observe behavior, not targets) → Principle in PPA is Violated Principles — which cause-and-effect rules are compromised → Action in PPA is Change in Practice — realigns behavior with principle. In short: Problem → Principle → Action.

Metrics as evidence — not targets

Metrics in this model are not performance scores. They are evidence of what the system is producing in a given dimension. A change in Lead Time, Deployment Frequency, Decision Latency, or Escalation Rate does not tell you what action to take. It tells you where to look. The diagnostic question follows from what is observed, not from whether a number is above or below a benchmark.

The Five Dimensions — Five domains. One coherent diagnostic picture.

Each dimension is a domain for continuous examination. It contains a set of principles that govern healthy behavior in that domain, a set of practices through which those principles are expressed, and metrics that surface what the system is actually producing. Together they give any delivery problem a precise address.

01 — Flow & Delivery Dynamics

How work moves from idea to customer value. This dimension examines how work enters, moves through, and exits the delivery system. It reveals whether the system is producing flow or producing motion, and where bottlenecks, unpredictability, and hidden queues are shaping the output.

Diagnostic question — How efficiently and predictably does work move through the system?

Representative Principles: Optimize the whole system, not its parts; Limit work in progress to improve flow; Reduce batch size to surface problems earlier; Make work and wait states visible; Manage flow — don't assume it.

Representative Practices: Continuous integration, WIP limits, Visual workflow boards, Incremental planning, Dependency management, Delivery cadence reviews.

Metrics — Evidence of Behavior: Lead Time, Cycle Time, Throughput, Queue Time, Flow Efficiency, Deployment Frequency.

System behavior: Predictable delivery and stable lead times — or persistent bottlenecks, unpredictability, and motion without progress.

Explore Flow & Delivery Dynamics principles

02 — Learning, Adaptation & Decision Quality

How the organization learns, adapts, and improves. This dimension examines whether feedback reaches decisions in time to influence them, whether the organization tests assumptions before committing, and whether learning compounds or stalls.

Diagnostic question — Is the system capable of applying hard-won evidence?

Representative Principles: Frequent feedback loops inform decisions; Empiricism governs decisions under uncertainty; Embrace change as evidence of learning; Improve collaboratively, evolve experimentally; Timeboxed learning cycles protect adaptation.

Representative Practices: Retrospectives with decision intent, Customer discovery, A/B testing, Blameless postmortems, Improvement experiments, Assumption mapping.

Metrics — Evidence of Behavior: Experiment frequency, Improvement implementation rate, Customer feedback latency, Learning cycle time, Adaptation rate.

System behavior: Decisions grounded in evidence and adjusted from learning — or recurring problems that retrospectives acknowledge but cannot resolve.

Explore Learning, Adaptation & Decision Quality principles

03 — Governance, Accountability & Decision Authority

How decisions are made, owned, and aligned across the organization. This dimension examines whether the people closest to the work have the authority to act on what they know, whether accountability is real or symbolic, and whether governance enables delivery or impedes it.

Diagnostic question — Who is accountable for what — and do they actually control it?

Representative Principles: Accountability must match control; Decision authority must be explicit; Alignment over compliance; Make policies explicit; Vague guidance creates false alignment.

Representative Practices: Delegated decision-making, Lightweight governance models, Clear ownership structures, Explicit prioritization frameworks, Defined escalation policies.

Metrics — Evidence of Behavior: Decision latency, Approval wait time, Escalation frequency, Planning stability, Ownership clarity index.

System behavior: Clear ownership and fast decisions — or escalation as the default, symbolic accountability, and governance that substitutes for trust.

Explore Governance, Accountability & Decision Authority principles

04 — System Integrity & Architectural Coherence

How technology supports sustainable delivery and safe change. This dimension examines whether the technical system can absorb change without degrading, whether quality is built in or bolted on, and whether architectural decisions are accumulating coherence or accumulating debt.

Diagnostic question — Can the organization differentiate, reason about, and safely evolve the system?

Representative Principles: Build quality in — don't inspect it in later; Understand original intent before removing capabilities; New solutions create new system constraints; Every hand-off has a cost.

Representative Practices: Automated testing, Trunk-based development, Architecture reviews, Continuous refactoring, Incident retrospectives.

Metrics — Evidence of Behavior: Change Failure Rate, Mean Time to Recovery, Escaped defects, Technical debt trend, Automated test coverage.

System behavior: A system that can be changed safely and understood clearly — or fragility that makes every release a risk and every refactor a threat.

Explore System Integrity & Architectural Coherence principles

05 — Human-AI Collaboration Dynamics

How people, teams, and AI systems influence delivery together. This dimension examines how effectively humans and AI systems collaborate within the delivery pipeline — where AI amplifies capability, and where it introduces accountability gaps, oversight requirements, and judgment demands that human leaders must own.

Diagnostic question — Is AI augmenting human judgment, or replacing it?

Representative Principles: Observability before autonomy; Human accountability cannot be delegated; Decision authority must be explicit; Feedback loops must include AI behavior; Learning before scaling.

Representative Practices: AI behavior monitoring, Explicit human override paths, AI-inclusive retrospectives, Autonomy expansion reviews, Cross-functional AI ownership.

Metrics — Evidence of Behavior: AI decision review rate, Override and correction frequency, Accountability clarity index, AI outcome traceability.

System behavior: Amplified human capability with clear oversight — or accelerated execution that outpaces judgment, with accountability that dissolves when something goes wrong.

Explore Human-AI Collaboration Dynamics principles

Why Five Dimensions — Delivery systems are interconnected. Diagnosis must be too.

No single dimension tells the complete story. A metric that surfaces in Flow may have its origin in a Governance problem. An accountability gap in Human-AI Dynamics may trace back to a principle violation in the Governance dimension. The five dimensions exist because a single lens produces incomplete diagnosis.

Used together, they give leaders a structured way to examine the full delivery system, not just the part that is currently on fire.

One observed behavior can live in multiple dimensions

A team that consistently misses cross-team deadlines may have a Flow problem, a Governance problem, or both. Examining only one dimension produces an intervention that addresses half the system.

Dimensions interact — changes in one affect others

Improving deployment frequency without improving feedback loops accelerates delivery of the wrong thing. The dimensions are not independent. Understanding how they interact is part of the diagnosis.

The dimension gives the principle its context

The same principle can be violated across multiple dimensions. Knowing which dimension the observed behavior lives in narrows the diagnostic question and makes the violated principle easier to identify precisely.

Effectiveness is not the absence of problems

A high-performing delivery system is not one that never encounters problems. It is one where behavior is visible, diagnosis is fast, and the system can correct without losing coherence. These dimensions examine that capacity.

About the five dimensions — Deeper Questions

Are the dimensions a separate framework from PPA?

No. The dimensions are part of PPA. They give the "Problem" step its structure by providing five domains in which system behavior is observed and categorized. PPA is the diagnostic engine. The dimensions are how a problem gets its address before the engine runs.

How is a dimension different from a metric category?

Metrics are evidence of what a system is producing inside a dimension, not the dimension itself. Lead Time and Deployment Frequency are evidence inside Flow & Delivery Dynamics. The dimension is the domain of behavior; the metric is what surfaces from it.

Can one problem span more than one dimension?

Yes, and this is common. A symptom like "we keep building the wrong thing" can trace back to a Learning & Adaptation failure, a Governance failure, or both. Diagnosis means checking which dimension the behavior actually originates in, not assuming it belongs to the dimension where it is most visible.

Where do the Unintended System Conditions fit in?

A dimension names the domain. A principle names the specific cause-and-effect rule inside that domain. An Unintended System Condition is the stable, recurring state a system settles into after principles inside a dimension are violated long enough. Dimension, principle, and condition are three layers of the same diagnosis.

See which dimension your problem lives in

Describe a recurring delivery problem and the guided diagnostic will route it through the five dimensions to the principles being violated and the condition beneath them.

Related Resources