# P-DRIVEN: Workbook

**An Operating Model for Managing Uncertainty in Incidents and Crises**

| | |
|---|---|
| **Author** | Rico Kerstan |
| **Version** | 1.0 |
| **Date** | 05.05.2025 |
| **License** | CC BY-NC-ND 4.0 |
| **Website** | [p-driven.org](https://p-driven.org) |

**Suggested citation:** Kerstan, R. (2025). *P-DRIVEN: Workbook. An Operating Model for Managing Uncertainty in Incidents and Crises.* Version 1.0. Available at: https://p-driven.org

---

## Purpose and Scope of This Workbook

This workbook serves as the codified knowledge base of P-DRIVEN.

Its purpose is to enable the correct and disciplined application of P-DRIVEN as an operating model for managing uncertainty in incidents, crises, and dynamic situations. It explains the underlying logic of the Problem-Solving P, the associated leadership and team model, and the use of supporting tools.

The workbook is intended for all potential users of P-DRIVEN. It can be used by individuals responsible for a single domain as well as by those designing, organizing, or overseeing incident and crisis management within an organization. Prior experience with P-DRIVEN is not required.

This document is an authoritative reference for the correct application of P-DRIVEN outside an acute situation. It does not replace training, certification, or licensing, but it can serve as a foundational basis for all of them.

The workbook is explicitly not designed for use during an active incident or crisis. Its purpose is learning, preparation, reflection, and organizational transfer.

## How to Use This Workbook

Its structure follows the logic of the P-DRIVEN operating model. At the core is the Problem-Solving P. The workbook therefore organizes content in three layers:

First, it establishes the foundation needed for correct use outside a live situation: purpose, scope, and the relationship to the authoritative *P-DRIVEN: Operational Guide*.

Second, it explains the Problem-Solving P itself. The steps of the Problem-Solving P are presented in the exact sequence defined by *P-DRIVEN: Operational Guide*. For each step, the workbook clarifies intent, expected outcomes, and common dilution patterns that lead to loss of effectiveness. These explanations support correct application; they do not introduce alternatives or permissible variations.

Third, it shows how the same Problem-Solving P scales across different problem sizes. The workbook distinguishes between incidents and crises not as different methods, but as different operational scales that require different depth, tempo, and coordination while preserving the same step sequence and logic. Supporting tools and documentation practices are treated as inherent enablers of disciplined execution, not as optional add-ons.

Readers may use this workbook in different ways:

* sequentially, to build a complete understanding of P-DRIVEN,
* selectively, to clarify a specific step, role, or tool,
* or as a reference for training, exercises, after-action reflection, and organizational transfer.

### Reading Guide by Role

Not every reader needs to read the entire workbook. The following guide provides a recommended reading path based on the role the reader will perform:

| Role | Recommended Reading | Focus |
|------|-------------------|-------|
| **Facilitator** | Complete workbook | Full understanding of every step, every veto situation, every board. The Facilitator must know the method better than anyone else in the team. |
| **Owner** | Parts I, II, III | Role profile, the complete Problem-Solving P (to follow it without friction), and the scaling logic. Part V is recommended for recognizing process deviations. |
| **Domain Owner** | Parts I, II, III | Same as Owner, with particular attention to the Personal Identity Principle and the CMT/DRT interface. |
| **Supporter** | Parts I, II | Role profile, the Problem-Solving P (board logic, reporting structure, scope of authority). Understanding the full cycle is necessary to operate within it. |
| **System Maintainer** | Complete workbook | Must understand the full method to maintain documentation, plan exercises, and drive continuous improvement. Implementation Roadmap (Part VI, Chapter 2) is the primary reference. |
| **Executive Leadership** | Part I, Part VI | Operating model overview, preconditions, limits, and the interface between executive leadership and the crisis structure (Part IV, Section 4). |

This workbook is not intended for real-time operational use. During active incidents and crises, *P-DRIVEN: Operational Guide* applies.

Readers who are not directly filling an activation role — such as those introducing P-DRIVEN to an organization, designing training programs, or evaluating the method — may find the following reading paths more useful:

### Reading Guide by Reader Type

| Reader Type | Recommended Reading | Focus |
|---|---|---|
| **System Implementer** (introducing P-DRIVEN to your organization) | Part VI first, then Parts I and II | Implementation Roadmap (Part VI, Chapter 2) is your primary reference. Parts I and II give you the method you are building toward. |
| **Training / L&D Planner** | Parts I, IV, VI | Role profiles and qualification requirements (Part I), exercise and training guidance (Part IV, Section 3 and Part VI, Step 5), preconditions (Part VI, Chapter 3). |
| **Academic / Method Evaluator** | Parts I, II, V, VI | Method architecture and design principles (Part I), step logic (Part II), positioning and limits (Parts V and VI). The Glossary and citation header are your primary anchors. |

## Relationship Between the Documents

P-DRIVEN is represented through two distinct but logically aligned artifacts: *P-DRIVEN: Operational Guide* and this workbook.

*P-DRIVEN: Operational Guide* is a separate, standalone document intended exclusively for use during active incidents and crises. It is deliberately concise, strictly sequential, and free of explanation or theory. Its purpose is to support disciplined execution under time pressure.

*P-DRIVEN: Operational Guide* is authoritative. It defines the authoritative sequence and logic of the Problem-Solving P. It also contains the practical artifacts needed during activation: board templates (Boards 1, 2, and 3), a Situation Briefing structure template, a Facilitator quick-reference card summarizing activities and veto triggers per step, task transmission forms, and documentation checklists. These templates and checklists are not reproduced in this workbook — they belong in the operational context, not in the explanatory context.

This workbook does not modify, extend, or reinterpret that logic. It exists to explain it. Where the workbook describes a tool, a board, or a procedure, *P-DRIVEN: Operational Guide* provides the corresponding ready-to-use template.

Explanations, context, and reflections are intentionally removed from *P-DRIVEN: Operational Guide* to preserve clarity and usability in operational environments.

Whenever differences in wording or emphasis appear between *P-DRIVEN: Operational Guide* and this workbook, the logic of *P-DRIVEN: Operational Guide* prevails.

*P-DRIVEN: Operational Guide* is available at [p-driven.org](https://p-driven.org).


## P-DRIVEN at a Glance

P-DRIVEN structures problem-solving through four phases, sixteen steps, four activation roles, three boards, and up to three team levels.

**Four Phases:**
- **Initiation** — activates the structure (Alerting, Initial Assessment)
- **Planning** — builds shared understanding and defines objectives (6 steps)
- **Implementation** — executes and monitors (6 steps)
- **Learning** — captures outcomes and prepares the next cycle (Debriefing, Structured Feedback)

**Four Activation Roles:** Owner · Facilitator · Domain Owner · Supporter

**Three Boards:**
- Board 1: Problems & Priorities
- Board 2: Solution Strategies
- Board 3: Objectives & Execution

**Three Team Levels:**
- IMT (Incident Management Team) — operational level
- DRT (Domain Response Team) — domain level under a CMT
- CMT (Crisis Management Team) — strategic level

**Five Structural Principles:**
1. The sequence is non-negotiable.
2. Every team has dual leadership: Owner and Facilitator.
3. The Facilitator holds explicit veto rights to protect process integrity.
4. Domain Owners in the CMT are identical to the Incident Owners of their DRTs (Personal Identity Principle).
5. Deviations from the defined method are deliberate deviations — not variants.


# Part I – Introduction: Applying P-DRIVEN Outside the Situation

## P-DRIVEN as an Operating Model for Managing Uncertainty

P-DRIVEN is an operating model for managing uncertainty in complex problem situations such as incidents, crises, and dynamic operational environments.

It provides a disciplined approach to problem solving under conditions where information is incomplete, time pressure is present, and consequences are significant. P-DRIVEN does not rely on predefined scenarios or best practices. Instead, it establishes a stable problem-solving logic that can be applied across different contexts, organizations, and levels of complexity.

At its core, P-DRIVEN combines three inseparable elements:

* the Problem-Solving P,
* a scalable team and leadership model aligned to that process,
* and a set of inherent tools that support disciplined execution.

These elements are designed to function together. The effectiveness of P-DRIVEN depends on their consistent alignment. Removing, rearranging, or selectively applying individual elements undermines the operating model as a whole.

P-DRIVEN is designed to be operational. It can be applied with minimal preparation and without extensive organizational prerequisites. At the same time, it remains robust enough to scale from localized problem situations to organization-wide crises without changing its internal logic.


## What P-DRIVEN Is — and What It Is Not

P-DRIVEN is a clearly defined operating model. Its scope and intent are deliberately limited.

P-DRIVEN is:

* a disciplined approach to problem solving under uncertainty,
* an operating model for incidents and crises,
* a method that integrates process, roles, and tools into a coherent whole.

P-DRIVEN is not:

* a framework that can be freely adapted or extended,
* a management system,
* a collection of best practices,
* a toolbox from which elements can be selectively combined.

There is one P-DRIVEN.

## Incidents and Crises: Scope of Application

P-DRIVEN applies to both incidents and crises. These terms describe differences in scale and organizational impact, not different methods.

A crisis is a set of problems that jeopardizes an organization’s ability to achieve its strategic objectives by exceeding the resilience of its overall processes and resources. Crises affect the organization as a whole and require centralized coordination and decision making.

An incident is a set of problems that jeopardizes the ability of a defined part of an organization (e.g., a single domain, function, or location) to achieve its operational objectives by exceeding the resilience of its processes and resources. Unlike a crisis, an incident does not threaten the organization’s strategic objectives as a whole, but it already exceeds routine operational handling within its affected scope.

From a P-DRIVEN perspective, multiple simultaneous incidents constitute a crisis. Parallel, independently steered problem-solving structures are not compatible with disciplined crisis management. Central coordination becomes mandatory once overall organizational resilience is at risk.


## Discipline, Sequence, and Non-Negotiability of P-DRIVEN

P-DRIVEN is based on disciplined execution of a defined problem-solving process. Its effectiveness does not depend on individual brilliance, experience, or seniority, but on adherence to a shared logic under conditions of uncertainty.

The sequence of the Problem-Solving P is non-negotiable. Each step builds on the outcomes of the previous one. Skipping steps, reordering them, or merging them changes the logic of the process and breaks its internal consistency. Such deviations are not neutral shortcuts. They systematically reduce the quality of decisions and the organization’s ability to adapt to a changing situation.

Methodical discipline in P-DRIVEN plays a role similar to formal rules in accounting. Accounting does not become more correct through experience or intuition. It becomes correct through compliance with a defined structure. Experience may improve speed or confidence, but it does not replace the underlying logic. The same applies to disciplined problem-solving under uncertainty.

P-DRIVEN deliberately constrains individual freedom of action in favor of collective reliability. This constraint is not a limitation but a stabilizing mechanism. In uncertain and dynamic situations, consistency of process is more valuable than flexibility of interpretation.

The non-negotiability of the Problem-Solving P does not eliminate judgment or responsibility. It provides a stable frame within which judgment can be exercised without undermining coordination, prioritization, or situational awareness. Discipline ensures that decisions remain comparable, explainable, and reversible as new information emerges.

Departures from the defined sequence create deliberate deviations from the operating model. These deviations may function in specific contexts, but their effectiveness cannot be assumed. Within P-DRIVEN, only disciplined adherence to the defined process ensures predictable performance across different situations, teams, and organizational settings.

## Roles, Leadership Structure, and Domain-Based Team Composition

### Purpose of the Team Model

The P-DRIVEN team model is designed to ensure disciplined problem solving under uncertainty while remaining scalable across different levels of impact and organizational reach.

The model separates responsibility for *content and decisions* from responsibility for *process and method*. This separation is intentional. It prevents dominance of individual experience or hierarchy over structured problem-solving and ensures that coordination, prioritization, and adaptation remain possible even as complexity increases.

Team structures in P-DRIVEN are not defined by size or hierarchy, but by scope, coupling, and impact. The same organizational form is used repeatedly and consistently across levels.


### Core Team: Owner and Facilitator

Every P-DRIVEN team is built around a core team consisting of two roles: the Owner and the Facilitator.

The Owner carries the functional responsibility for the problem space addressed by the team. Depending on scale, this role is fulfilled by an Incident Owner or a Crisis Owner. The Owner decides at defined decision points, represents the team toward the regular organization, and is accountable for the outcomes produced. The role is comparable to a project lead or product owner: decision authority is explicit, but problem-solving itself is a collective effort.

The Facilitator is responsible for the method. This role safeguards the sequence, discipline, and integrity of the Problem-Solving P, its structures, and the appropriate use of tools. The Facilitator ensures that steps are neither skipped nor reordered and that tools are used as intended. The Facilitator has no authority to alter the process and no obligation to contribute content. The Facilitator may offer generalist observations or challenge assumptions as an *advocatus diaboli* — but must never assume the role of a domain expert. Once the Facilitator begins contributing domain-specific content, process enforcement ceases and the structural separation that legitimizes the veto right is compromised.

The relationship between Owner and Facilitator follows a checks-and-balances logic. The Owner holds decision authority within the process. The Facilitator holds explicit veto rights where process integrity is at risk. Neither role can replace the other.

This dual leadership structure exists in every P-DRIVEN team, regardless of scale.


### Scaling Logic
P-DRIVEN uses a single organizational form that scales by replication, not by redesign.

At the strategic level, a Crisis Management Team (CMT) is established when problems exceed domain boundaries or when structural escalation rules apply. The CMT is led by a Crisis Owner and supported by a dedicated Crisis Facilitator. Domain Owners form the permanent supporting structure of the CMT, each representing a defined organizational domain. The Crisis Owner is not a Domain Owner. The Crisis Owner owns the crisis itself.

At the operational level, incidents or crises are handled by Incident Management Teams (IMT). An IMT addresses a defined scope such as a function, domain, site, or region. The IMT is led by an Incident Owner and supported by a dedicated Incident Facilitator.

When incidents occur within a defined domain under an existing CMT, the corresponding team is referred to as a Domain Response Team (DRT). A DRT is not a different organizational form. It is an IMT operating within domain boundaries under strategic coordination. The Domain Owner in the CMT assumes the role of Incident Owner for the DRT. Other designations such as Site Response Team or Regional Response Team follow the same logic: the name reflects scope, not structure.

Scaling follows clear structural rules. Multiple active IMTs within a single domain require formation of a DRT. Multiple active IMTs across different domains require formation of a CMT. As a general rule, parallel problem-solving structures with overlapping scope are avoided.

An exception applies when multiple IMTs operate in parallel without substantive, temporal, or resource-related coupling and without impact on strategic objectives. In such cases, establishing a CMT is not mandatory, but remains a conscious management decision rather than a default omission.

Across all levels, prioritization is not imposed hierarchically. Objectives are set at the appropriate level and brought into the respective teams, where prioritization occurs within the Problem-Solving P itself.


### Roles and Responsibilities

P-DRIVEN defines four activation roles: Owner, Facilitator, Domain Owner, and Supporter. Each role has defined responsibilities, authorities, competency requirements, and objectives. The following role profiles apply across all team levels — from a single Incident Management Team (IMT) through Domain Response Teams (DRT) and the Crisis Management Team (CMT) to Local Response Teams (LRT) and Operational Response Teams (ORT) in scaled configurations (see Part III for scaling details). Where responsibilities or authorities differ between levels, the difference is stated explicitly.

### Role Profile: Owner

The Owner carries the functional responsibility for the problem space addressed by the team. At DRT level, this is the Incident Owner; at CMT level, the Crisis Owner. The structural role is identical — the scope differs.

The Owner is the final decision authority within the team. Decisions are taken at defined points in the Problem-Solving P, not ad hoc. The Owner leads through objectives, coordination, and clear responsibility assignment. The Owner does not control execution directly and does not execute operational tasks.

The Owner represents the team toward the regular organization, toward executive leadership (at CMT level), and toward adjacent or higher-level structures. When an escalation from incident to crisis occurs, the Owner ensures that the Facilitator role within the originating team is promptly reassigned.

**Responsibilities:**

- Functional leadership of the team
- Decision-making at defined points in the problem-solving process (Situation Evaluation, Decision Taking, Objective Definition, Deactivation)
- Representation of the team toward the regular organization and, at CMT level, toward executive leadership
- Assignment and coordination of Supporters (at DRT/LRT/ORT level) or Domain Owners (at CMT level)
- Accountability for progress and results within the team's scope
- Declaration of the activation state (incident or crisis) and its termination, subject to the Facilitator's veto right
- At CMT level: resolution of decision deadlocks between domains; ensuring a single external communicative position

**Authorities:**

- Directive authority over all personnel involved in the activation within the team's scope
- Authority to assign ad-hoc tasks without prior approval chains
- Budget authority for ad-hoc expenditures up to a predefined limit (defined by the organization before activation)
- Authority to expand or reduce the team composition
- Authority to order shutdown or deactivation of infrastructure within the team's scope
- Right to escalate directly to executive leadership
- Right of access to all information relevant to the activation
- Right of access to facilities relevant to the activation

**Competency requirements:**

- Strong leadership and decision-making capability under uncertainty
- Solid knowledge of the Problem-Solving P — sufficient to follow it without resistance and to recognize when deviating from it
- Trust in the Facilitator's process authority
- Communication and coordination capability across organizational boundaries
- Resilience, assertiveness, and accountability
- Minimum exercise frequency: twice per year in the Owner role (For exercise formats and program design, see Part VI, Chapter 2, Step 5.)
- Willingness to participate in on-call arrangements

**Objectives:**

- Containment of damage and limitation of impact
- Rapid restoration of a stable operational state
- Effective and consistent situation management within the team's scope
- At CMT level: coherent, situation-appropriate, and enforceable strategic decisions


### Role Profile: Facilitator

The Facilitator carries the methodological responsibility for the team. At DRT level, this is the Incident Facilitator (or Domain Facilitator); at CMT level, the Crisis Facilitator. The structural role is identical across levels.

The Facilitator is comparable to a Scrum Master in agile project management: a method expert who moderates the process, structures collaboration, and enforces discipline. The Facilitator may offer generalist observations or challenge assumptions as an *advocatus diaboli*, but does not contribute domain expertise during the activation. The Facilitator's value lies in process enforcement, not in domain-specific content.

The Facilitator holds an explicit veto right against decisions or actions by the Owner that violate the established methodology, defined procedures, or formal authorities. The veto is not a suggestion. It is documented and binding until the Owner provides a reasoned override that is itself documented. The Facilitator also holds a specific veto right against premature deactivation.

**Veto Trigger Reference**

The Facilitator's veto right is triggered in five explicitly named situations within the Problem-Solving P:
1. **Initial Assessment** — if the Owner intends to classify the situation as neither an incident nor a crisis despite the Facilitator's reasoned objection that activation criteria are met.
2. **Situation Briefing** — if the briefing is skipped, abbreviated to the point of losing its function, or if key participants are missing.
3. **Decision Taking** — if a decision is made outside the defined process, without board-based assessment, or under hierarchical pressure that bypasses evaluation.
4. **Objective Allocation** — if objectives are assigned without board documentation or without the domain owners being present.
5. **Preparation of the Situation Briefing** — if the activation is declared closed without a completed debrief plan or against the defined deactivation criteria.

**Documentation:** When invoking the veto, the Facilitator records in writing: the time, the process step, the nature of the violation, and the Owner's response. This record becomes part of the activation documentation.

When an escalation from incident to crisis occurs, the Facilitator of the active IMT becomes the Crisis Facilitator in the newly activated CMT. The IMT must then alert and assign a new Facilitator to maintain its own process discipline. Facilitators can be deployed across domains — they are not bound to a single team.

**Responsibilities:**

- Methodological leadership and moderation of the Problem-Solving P
- Structuring the collaboration of all participants under time pressure
- Ensuring that all participants understand and apply the defined processes, tools, and decision procedures
- Active monitoring of compliance with the defined sequence and methods
- Exercising the veto right when process integrity is at risk
- Documentation of the activation: photographic board records at defined points, logging of activation and deactivation decisions (time, participants, basis of assessment), documentation of Debriefing outputs
- Maintenance of Board 3 as the authoritative execution tracking instrument — only the Facilitator moves cards on Board 3
- Preparation of each Situation Briefing cycle (finalizing Board 3, creating board records)
- Briefing and onboarding of new team members during an activation
- Ensuring clear communication within the team
- Remaining in the coordination space during the Implementation Phase

**Authorities:**

- Veto right against violations of established methodology, defined procedures, or formal authorities
- Veto right against premature deactivation
- Authority to require the use of defined methods and tools
- Access to all relevant information and documentation
- Authority to address team members on methodological requirements and to intervene when compliance is lacking
- Participation in all situation briefings, decision rounds, and documentation processes
- Access to all relevant systems and documentation platforms

**Competency requirements:**

- Strong moderation and structuring capability
- Solid knowledge of crisis and incident management methodology
- Ability to enforce a structured process under significant pressure, including against personnel who are more senior in the organizational hierarchy
- Ability to manage group dynamics in high-stress situations
- Neutral and methodological conflict resolution under time pressure
- Communication and mediation capability
- Resilience, assertiveness, and methodological consistency
- Minimum exercise frequency: twice per year in the Facilitator role (For exercise formats and program design, see Part VI, Chapter 2, Step 5.)
- Completed qualification for the Facilitator function (seminar participation and, where available, certification in incident and crisis management)
- Willingness to participate in on-call arrangements
- Willingness to be deployed across domains and team levels

**Objectives:**

- Ensuring the methodological quality and consistency of the problem-solving process
- Structured and goal-oriented problem-solving under pressure
- Complete and traceable documentation of all decisions
- Minimization of process risks and methodological errors


### Role Profile: Domain Owner

Domain Owners represent fixed functional domains within the CMT. They are the structural bridge between the CMT's strategic coordination and the operational execution within their domain. The Domain Owner is not an advisor — the role holds responsibility for coherence, feasibility, and follow-through within the domain.

Through the Personal Identity Principle (described in Part III), the Domain Owner in the CMT is the same person who serves as the Owner of the corresponding DRT. This dual function eliminates one communication interface: the person who participates in CMT planning is the same person who translates CMT objectives into domain-level execution and brings domain-level status back into the CMT.

Domain Owners are authorized to interpret CMT objectives within their domain context. If operational reality requires a different prioritization or timing than what the CMT defined, the Domain Owner adjusts — but must report the deviation back to the CMT openly. This "bottom-up interpretation" is an explicit authority, not a workaround.

Standard domains: Operations, IT and Technical Infrastructure, HR, Finance & Administration, Communications. Sales may be a separate domain or consolidated with Communications (see "Consolidation of Domains" below).

**Responsibilities:**

- Representation of domain-specific perspectives in the CMT during the Planning Phase
- Translation of CMT objectives into domain-level coordination
- Leadership of the corresponding DRT (via Personal Identity Principle)
- Bidirectional information flow between CMT and DRT
- Coordination of subordinate response structures within the domain
- Accountability for domain coherence and feasibility
- Open reporting of deviations from CMT objectives back to the CMT
- Ensuring succession of the Domain Facilitator role when escalation occurs

**Authorities:**

- Directive authority over all personnel involved in the activation within the domain
- Authority to prioritize or reschedule CMT objectives within the domain based on operational reality (with mandatory reporting of deviations)
- Budget authority for ad-hoc expenditures within the domain up to a predefined limit
- Authority to expand or reduce the DRT
- Authority to order shutdown or deactivation of infrastructure within the domain
- Right of access to all domain-relevant information
- Right to escalate directly to executive leadership on domain-specific matters

**Competency requirements:**

- Deep domain expertise and understanding of the domain's operational reality
- Strong leadership and decision-making capability
- Ability to translate between strategic and operational perspectives
- Communication and coordination capability
- Resilience and ability to manage dual-role demands (CMT member and DRT Owner)
- Minimum exercise frequency: twice per year (For exercise formats and program design, see Part VI, Chapter 2, Step 5.)
- Willingness to participate in on-call arrangements

**Objectives:**

- Ensuring the operational capability of the domain during the activation
- Containment of impact within the domain
- Rapid restoration of domain functionality
- Protection of the organization from operational overload within the domain


### Role Profile: Supporter

Supporters are situative members of a DRT, LRT, or ORT. They do not exist at the CMT level — the CMT's supporting structure consists of Domain Owners. Supporters are assigned based on the specific requirements of the situation and support the core team (Owner + Facilitator) by assuming responsibility for defined objective packages.

Supporters do not execute operational tasks themselves. Their role is to coordinate implementation within their respective area, structure information, consolidate feedback, and report progress to the team. They act as objective owners: each Supporter is responsible for a defined set of objectives on Board 3.

Through the Personal Identity Principle, a Supporter who is assigned responsibility for a sufficiently complex objective package may become the Owner of a subordinate team (ORT). This is the mechanism through which P-DRIVEN nests downward.

The number of Supporters is deliberately limited. A DRT should not include more than three Supporters (team size of five including Owner and Facilitator). This limit reflects span-of-control considerations: each additional team member increases communication overhead and reduces decision speed. The team is a leadership element — it coordinates, it does not execute.

**Responsibilities:**

- Coordination of defined objective packages within their area
- Structuring and consolidation of information relevant to their objectives
- Reporting on feasibility, progress, blockers, and side effects
- Proactive identification of emerging problems within their scope
- No direct operational execution — Supporters steer measures, they do not implement them

**Authorities:**

- No independent directive authority in the default state
- Directive authority only when explicitly delegated by the Owner for a specific objective package
- Authority to request information necessary for their assigned objectives
- Advisory function: authority to propose measures and recommend courses of action

**Competency requirements:**

- Deep expertise in their specific technical or functional area
- Ability to analyze problems quickly and structure information under pressure
- Good communication and collaboration capability with Owner and Facilitator
- Flexibility and adaptability to changing requirements
- Understanding of the board logic and the reporting structure

**Objectives:**

- Providing operational support and domain-specific input to the team
- Contributing to rapid and effective problem resolution within assigned objectives
- Collecting observations and experiences for the Learning Phase


### Qualification Summary by Role

| Role | Key Competency Requirements | Minimum Exercise Frequency | Qualification Prerequisites |
|---|---|---|---|
| **Owner** | Problem-Solving P literacy; decision-making at defined points; ability to lead through objectives | Twice per year | Completion of *P-DRIVEN: Workbook*; participation in at least one structured exercise |
| **Facilitator** | Full method mastery; process enforcement; veto authority; board facilitation; stress resilience | Twice per year (more frequent during initial deployment) | Completed qualification for the Facilitator function — seminar participation and, where available, certification |
| **Domain Owner** | Own domain expertise; understanding of CMT/DRT interface; Personal Identity Principle | Twice per year | Owner qualification for the DRT level; familiarity with the Personal Identity Principle |
| **Supporter** | Board logic; reporting structure; scope of authority within the team | No fixed minimum — determined by the organization based on activation frequency and team composition | Completion of *P-DRIVEN: Workbook*; orientation session |


### Team Structures

#### Incident Management Team (IMT) / Domain Response Team (DRT)

An IMT or DRT is a P-DRIVEN problem-solving structure for incidents within a defined scope. When operating under a CMT within domain boundaries, it is called a DRT. The organizational form is identical.

The team is designed as a leadership and coordination element. It does not execute operational tasks itself; it steers problem-solving and implementation through objectives and coordination.

![*Incident Management Team (IMT) / Domain Response Team (DRT) — Core Team with Owner, Facilitator, and Supporters*](svg/imt-drt-structure.pdf){width=90%}


#### Crisis Management Team (CMT)

The Crisis Management Team is the strategic P-DRIVEN problem-solving structure for organization-wide crises. It operates on a broader scope and longer planning horizon and coordinates multiple subordinate response structures, if implemented.

Like the IMT, the CMT is a leadership and coordination element. It does not replace operational management and does not execute measures directly.

![*Crisis Management Team (CMT) — Dual Leadership Core with Domain Owners and DRTs*](svg/cmt-structure.pdf){width=90%}


The CMT is led by a Crisis Owner and moderated by a Crisis Facilitator (see role profiles above). Domain Owners form the permanent supporting structure, each representing a defined organizational domain. The Crisis Owner is not a Domain Owner — the Crisis Owner owns the crisis.

#### Standard Domains

The following domains represent the standard CMT composition. Each domain is led by a Domain Owner whose full role profile is described above.

#### Domain Operations

The Operations domain represents the organization’s core operational and value-creating activities. Its primary perspective is the ability to continue, adapt, suspend, or restore operational processes under crisis conditions.

The domain assesses how the situation affects ongoing operations, service delivery, production, projects, and dependencies such as suppliers or partners. It brings operational feasibility and side effects into strategic decision-making and translates CMT objectives into coordinated operational responses.

The Operations domain ensures that information from affected operational units is consolidated and fed back into the CMT and that decisions are communicated clearly into subordinate response structures.

#### Domain IT and Technical Infrastructure

The IT domain represents information technology, operational technology, and technical infrastructure required to maintain the organization’s ability to operate and communicate.

Its perspective includes availability, integrity, and recoverability of systems, data, and technical services. The domain coordinates IT-related response measures, assesses technical risks and constraints, and ensures that technical dependencies are considered in strategic planning.

In close coordination with the Communications domain, IT ensures the technical capability for internal and external communication throughout the crisis.


#### Domain HR

The HR domain represents all personnel-related aspects affecting the organization’s workforce.

Its focus is on workforce availability, duty of care, legal and contractual constraints, and the impact of the situation on working conditions and personnel deployment. The domain evaluates how crisis-related measures affect employees and supports the development of viable personnel-related responses.

HR ensures alignment with labor law, collective agreements, and co-determination requirements and coordinates implementation within the organization’s personnel structures.


#### Domain Finance and Administration

The Finance and Administration domain represents financial, administrative, legal, and facility-related perspectives not explicitly assigned to other domains.

Its focus is on financial viability, legal feasibility, procurement, contractual obligations, and the availability and protection of physical assets and facilities. The domain assesses constraints arising from budgetary, legal, or administrative requirements and coordinates enabling measures such as procurement, contracting, or access control.

Finance and Administration provides the cross-functional backbone that enables other domains to act within permissible and sustainable boundaries.


#### Domain Communications

The Communications domain represents internal and external communication effects and requirements.

Its perspective focuses on credibility, consistency, timing, and audience-specific communication. The domain coordinates messaging across internal stakeholders, customers, partners, authorities, and, where applicable, the public and media.

Sales-facing communication is treated as part of this domain when customer interaction becomes critical. Where required, this perspective may be organizationally separated while remaining functionally aligned with Communications.

The domain ensures that communication is aligned with situational awareness, decision-making, and available information, and that communication capability is maintained throughout the crisis.

#### Domain Sales

The Sales domain represents customer-facing commercial relationships and revenue-critical interactions.

Its perspective focuses on the impact of the crisis on customers, contracts, service commitments, and revenue streams. The domain assesses risks related to customer retention, contractual obligations, penalties, and escalation dynamics in key accounts.

Sales ensures that customer-specific implications are systematically reflected in strategic problem-solving and that commercial considerations are aligned with operational feasibility and communication strategy. The domain coordinates customer-facing actions within the boundaries set by the CMT and ensures consistency across accounts and regions.


#### Consolidation of Domains

P-DRIVEN defines a standard set of domains to ensure that all relevant perspectives are represented during crisis-level problem-solving. These domains reflect functional needs, not organizational charts.

In organizations with lower complexity, limited personnel, or in situations where the scope of the crisis does not require full differentiation, domains may be consolidated. Consolidation is a structural decision intended to preserve problem-solving capability under constrained conditions.

Domain consolidation does not change the underlying logic of P-DRIVEN. All perspectives covered by the standard domains remain required and must be explicitly considered, even when represented by fewer roles.

Typical and permissible consolidations include:

* Communications with Sales  
* Finance and Administration with HR  
* Operations with IT and Technical Infrastructure

Consolidation must not result in the omission of perspectives. If a domain is merged, its responsibilities remain fully in scope and must be actively represented in decision-making.

As complexity, scale, or communication intensity increases, consolidated domains should be separated again to prevent overload, loss of situational awareness, or delayed coordination.

![*CMT with Consolidated Domains — Domain Owner Structure in Crisis Configuration*](svg/cmt-consolidated.pdf){width=90%}


## From Learning to Application: Preparing for Use in Real Situations

Understanding P-DRIVEN conceptually does not automatically create operational capability.

This workbook explains the logic of the operating model, the structure of roles, and the disciplined sequence of the problem-solving process. The ability to apply P-DRIVEN in real situations depends on whether these elements are translated into organizational practice.

Preparation begins with structural clarity. Roles must be formally defined, authorities assigned, and domain boundaries explicitly determined. The dual leadership structure must be established before a situation occurs. In particular, Facilitators require prior qualification, as methodical integrity cannot be improvised under pressure.

P-DRIVEN is designed to function with minimal preparation. It does not require complex simulations or extensive scenario libraries to become usable. However, structured training and exercises significantly improve quality of application. Teams that have practiced the disciplined sequence of the problem-solving process tend to generate more differentiated options, recognize interdependencies earlier, and avoid premature convergence on single solutions.

Exercises should focus on process discipline rather than scenario realism. The objective is not to rehearse specific events, but to internalize the sequence, decision points, and coordination logic of the P-DRIVEN model.

Preparation also includes ensuring that the operating model is embedded in the organization. Interfaces to executive leadership, communication channels, and documentation practices must be clarified in advance. The transition from routine operations to a formal IMT or CMT should be defined structurally. P-DRIVEN provides the umbrella for all of this.

For a step-by-step implementation roadmap — from the initial mandate through role assignment, equipment, and first exercises — see Part VI, Chapter 2.

# Part II – The Problem-Solving P

## Logic and Purpose of the Problem-Solving P
At the core of P-DRIVEN lies a structured problem-solving process referred to as the "Problem-Solving P".

The visual and conceptual idea of the Problem-Solving P is inspired by the “Planning P” used in the Incident Command System (ICS) (see FEMA, *Incident Command System Resource Center*, https://training.fema.gov/emiweb/is/icsresource/). The Planning P illustrates a disciplined sequence of briefing, planning, decision-making, and operational execution in emergency management. P-DRIVEN adopts this structural clarity but applies it to a broader organizational context and extends it into a general operating model for managing uncertainty in both incidents and crises.

![*The Problem-Solving P — 16-step process with initiation, planning, implementation, and learning phases*](svg/problem-solving-p.pdf){width=90%}


The Problem-Solving P represents a defined sequence of steps that structure collective thinking and coordinated action. It ensures that teams move from situational understanding to decision-making and coordinated implementation in a disciplined and transparent manner.

The structure of the Problem-Solving P is organized into four phases:

**1) Initiation Phase**  
The Initiation Phase establishes control over the situation. It clarifies whether a formal problem-solving structure is required, defines scope and responsibility, and creates the initial shared understanding necessary to proceed. The objective is not completeness, but stability and orientation.

**2) Planning Phase**  
The Planning Phase structures analysis and strategy development. The team clarifies the problem, defines objectives, develops alternative courses of action, and evaluates their consequences. This phase deliberately separates thinking from execution to prevent premature solution bias. A core objective of this phase is to broaden the decision-corridor.

**3) Implementation Phase**  
The Implementation Phase translates decisions into coordinated action. Objectives are delegated, progress is monitored, and adjustments are made where necessary. Execution remains connected to the defined objectives and assumptions established during planning.

**4) Learning Phase**  
The Learning Phase consolidates insights gained during execution. Assumptions, decisions, and outcomes are reviewed in order to strengthen organizational resilience and improve future performance. Learning is not an optional add-on but an integral component of disciplined problem-solving.

The sequence of the Problem-Solving P is not arbitrary. Each phase produces defined outputs that serve as the foundation for the next. Skipping or reordering phases breaks this logic and weakens the reliability of decisions.

The Problem-Solving P is scalable. The same structure applies within an Incident Management Team, a Domain Response Team, or a Crisis Management Team. Differences lie in scope, depth, and time horizon—not in the logic of the process.

The Problem-Solving P is not a creativity technique and not a linear checklist. It is a coordination mechanism that stabilizes decision-making under uncertainty. In P-DRIVEN, leadership, team composition, and the use of tools are aligned to this structure. The Problem-Solving P therefore forms the structural backbone of the entire operating model.


### Time Reference for One Iteration Cycle

The following table provides indicative time ranges for each step of the Problem-Solving P. These are reference values, not rigid prescriptions. Actual durations depend on the complexity of the situation, the size of the team, the team level, and the maturity of the organization. ORTs and DRTs with concrete, domain-specific problems tend toward the lower end of each range. CMT-level cycles, which address strategic and cross-domain issues, tend toward the upper end. With practice, teams become significantly faster.

| Phase | Step | Duration |
|-------|------|----------|
| **Initiation** | Alerting | Variable (depends on alerting system and availability) |
| | Initial Assessment | 5–15 min |
| **Planning** | Situation Briefing | 5–10 min |
| | Situation Assessment (Board 1) | 5–15 min |
| | Situation Evaluation (Board 1) | 5–10 min |
| | Decision Taking (Board 2) | 15–60 min |
| | Objective Definition (Board 3) | 5–15 min |
| | Objective Allocation (Board 3) | 5–10 min |
| **Planning Phase total** | | **~45–120 min** |
| **Implementation** | Situation Freeze | 5 min |
| | Transmission of Tasks | 5–10 min |
| | Processing of Tasks | IMT/DRT: 2–8 hours; CMT: 4–72 hours |
| | Task Follow-Up | Continuous during execution |
| | Situation Update (Board 3) | Continuous during execution |
| | Preparation of Situation Briefing | 5 min |
| **Learning** | Debriefing | 15–30 min (immediately after deactivation) |
| | Structured Feedback | 2–4 hours (within days after deactivation) |

The Implementation Phase should not be set too short. At IMT and DRT level, it should usually last between two and eight hours. At CMT level, a meaningful window is four to 72 hours because the planning horizon is broader and subordinate teams need time to complete their own cycles before reporting back.

Especially in the first iteration, feedback will often not yet consist of completed results. Typical early feedback concerns activation progress, constraints, first effects, and newly identified problems. The Facilitator is responsible for setting the iteration timing at each level accordingly.

The Initiation Phase (Alerting and Initial Assessment) occurs only once per activation, not per iteration. The Learning Phase occurs only once, after deactivation.


## Initiation Phase  
### Step 1: Alerting
#### Purpose of the Step

Alerting enables the organization to respond without delay once defined escalation criteria are met.

The purpose of this step is the rapid and structured activation of the designated P-DRIVEN roles. Alerting ensures that a formal problem-solving structure — either an Incident Management Team or a Crisis Management Team — is established before informal coordination or uncontrolled escalation occurs.

Alerting is triggered through a defined triage point once a predefined activation criterion is met. The objective is not to assess the situation in depth, but to initiate disciplined structure.

#### Intended Outcome
The step is complete when:

- A defined problem-solving structure (IMTs and/or CMT) is formally activated.
- The required roles are alerted and at least one qualified individual per role has assumed responsibility.
- A defined meeting location (physical or virtual) is activated.
- The organization has shifted from informal reaction to structured problem-solving.

For each team level, alerting processes must be predefined. This includes:

- Clear activation criteria  
- Defined role lists per team  
- A maintained alerting system  
- Redundancy sufficient to ensure timely takeover of each role  

Alerting must always reach both the functional lead (Incident Owner or Crisis Owner) and the corresponding Facilitator. The dual leadership structure must be activated from the outset.

The number of persons per role should ensure a high probability of timely assumption. Where no formal duty system exists, multiple qualified individuals per role must be designated in advance.

#### Typical Misunderstandings and Early Deviations

**Telephone chains and single points of failure**

Alerting mechanisms based on sequential telephone chains create structural fragility. If activation depends on one person reaching the next, the entire process becomes vulnerable to delay or failure.  

Time calculations illustrate the risk: alerting five roles sequentially with ten call attempts at 30 seconds each already consumes several minutes before confirmation, not including successful calls, callbacks, and coordination. Under time pressure, such delays are operationally significant.

Alerting must be parallelized and system-supported. Redundancy is a design requirement, not a contingency.

**Insufficient role redundancy**

Limiting role assignments to a small group of senior executives creates artificial bottlenecks. P-DRIVEN roles are functional roles, not status roles.  

The ability to perform as Incident Owner or Crisis Facilitator depends on qualification and process discipline—not on hierarchical position. Organizations that bind these roles exclusively to top leadership risk delayed activation and structural overload.

**Fear of Pushing the Alarm Button**

A common deviation is delayed activation due to hesitation, uncertainty, or concern about reputational impact. This “Fear of Pushing the Alarm Button” leads to informal coordination attempts before formal structures are established.

P-DRIVEN tolerates early or even unnecessary activation. The subsequent assessment step provides a structured mechanism to scale down or deactivate if required. Delayed activation, by contrast, reduces stabilization capacity and increases uncontrolled escalation.

**Over-personalization of alerting**

Alerting tied to specific individuals rather than defined roles creates confusion when availability changes. Roles must be structurally defined and backed by multiple qualified individuals. Alerting always targets roles, not persons.

**Activation without structural readiness**

Triggering alerting without predefined meeting points, communication channels, or clear role definitions results in immediate loss of momentum. Alerting is not merely a notification—it is the transition from routine operation to structured problem-solving.

**Escalation without formal declaration**

Teams sometimes begin coordinating across domains without formally declaring activation of an IMT or CMT. This creates parallel decision paths, unclear authority, and inconsistent communication. Structural activation must precede cross-domain coordination.

#### Facilitator Activities in This Step

- Confirm availability through the alerting system.
- Proceed to the coordination space immediately. If the Facilitator arrives before the Owner, begin preparing the room: set up the three boards, lay out moderation cards and markers, ensure communication equipment is functional.
- Verify that the alerting system has reached all required roles. If critical roles remain unconfirmed, coordinate with the Owner on escalation to backup personnel.
- Prepare the structure for the Initial Assessment: have the orientation questions ready, prepare a clock for time-boxing.


### Step 2: Initial Assessment
#### Purpose of the Step

The Initial Assessment establishes a first structured understanding of the situation immediately after alerting.

Its purpose is to create a shared situational picture within the activated team, determine whether a formal incident or crisis is present, and define immediate stabilization measures. The objective is orientation and structural clarity. The step does not focus on completeness.

The team convenes without delay, physically or virtually. The Initial Assessment marks the transition from activation to disciplined problem-solving.

#### Intended Outcome

The step is complete when:

- A shared preliminary situational picture has been established.
- The scope and potential impact of the disturbance have been outlined.
- Immediate stabilization measures have been identified and, if necessary, initiated.
- A formal decision has been made whether the situation constitutes an incident or a crisis.
- The next coordination point (e.g., first structured situation briefing) has been scheduled.
- Communication channels and stakeholder notifications have been clarified.

The Initial Assessment focuses on essential orientation questions, such as:

- Which processes, organizational units, systems, or services are affected or potentially affected?
- What duration of disruption is currently anticipated?
- Which interdependencies or cascading effects are plausible?
- What impact on core operations or strategic objectives is foreseeable?
- What level of public or stakeholder visibility is likely?

The decision whether a formal incident or crisis is present is taken by the responsible Owner (Incident Owner or Crisis Owner) within the team setting. The Facilitator documents the decision, including time, participants, and basis of assessment.

The Initial Assessment should be completed rapidly. As a guiding principle, the phase is designed to conclude within a short, predefined time window. The result is a structured starting point for the Planning Phase.

If the situation is expected to exceed the initial operational time horizon, the activation of follow-up shifts is initiated as part of the Initial Assessment.

The objective is to ensure continuity of problem-solving without loss of structure or decision quality. Sustained operations require early preparation of replacement personnel before fatigue, cognitive overload, or coordination breakdown occur.

Shift preparation is triggered when:
- extended duration is expected,
- predefined time thresholds are reached,
- or continuity cannot be ensured with the current team.

Follow-up personnel are alerted in advance and remain on standby until handover.

Shift transitions are structured and sequenced. Responsibility is transferred stepwise, not simultaneously. The transition typically begins with the Owner, followed by the Facilitator, and then supporting roles. At no point should multiple critical roles be handed over at the same time.

The handover is complete only when the incoming role confirms full situational understanding and operational readiness. The transition point is explicitly documented.

Shift preparation and handover are not administrative activities. They are part of maintaining operational capability.


#### Typical Misunderstandings and Early Deviations

**Confusing initial assessment with full analysis**

Teams often attempt to achieve completeness during this step. This delays structured planning and consumes time without improving stability. The Initial Assessment defines orientation and structure; detailed analysis belongs to the Planning Phase.

**Avoiding formal classification**

Hesitation to formally declare an incident or crisis leads to ambiguity in authority and communication. Structural clarity requires an explicit decision. Over-classification can be corrected later; under-classification undermines coordination.

**Immediate solution bias**

Under pressure, teams may jump directly to technical or operational countermeasures without clarifying scope and interdependencies. Ad-hoc measures are permissible when necessary for stabilization until further steps can be taken, but must not replace structured assessment.

**Uncontrolled communication**

Allowing external inquiries, internal escalation requests, or media questions to interrupt the Initial Assessment destabilizes the team. Once activated, the IMT or CMT must protect its working capacity and communicate at defined intervals or upon validated information.

**Parallel side coordination**

Initiating informal cross-domain coordination outside the formal team structure during Initial Assessment creates inconsistent information flows and unclear authority. All structural decisions must be made within the activated team.

**Overreliance on predefined criteria**

Formal criteria for declaring incidents or crises support decision-making but are not exhaustive. Mechanical application without situational judgment can lead to misclassification. The criteria guide the decision; they do not replace responsibility.

**Delayed preparation of follow-up shifts**

Teams often postpone shift planning until fatigue or overload becomes visible. This leads to degraded decision quality, loss of structure, and chaotic transitions. Shift preparation must start early, not when performance already declines.

**Simultaneous or unstructured handovers**

Replacing multiple roles at the same time or without sequencing creates loss of context and coordination gaps. Handover must be staged and controlled, with clear responsibility at every point in time.

**Handover without confirmation of readiness**

Transferring responsibility without ensuring that the incoming role has understood the situation leads to hidden discontinuities. Operational responsibility only transfers after explicit confirmation of readiness.

#### Facilitator Activities in This Step

- Moderate the Initial Assessment: guide the team through the orientation questions, enforce the time box (5–15 minutes), prevent premature solution discussion.
- Document the formal activation decision: record the time, participants present, the basis of assessment, and whether the situation is classified as incident or crisis.
- Set up the three boards for the first Planning Phase cycle.
- Agree with the Owner on the time for the first Situation Briefing.
- If shift preparation is triggered: ensure the alerting of follow-up personnel is initiated and documented.
- **Veto situation**: If the Owner intends to classify the situation as neither an incident nor a crisis despite the Facilitator's reasoned objection that activation criteria are met, the Facilitator intervenes: "The activation criteria are met. We classify the situation as an incident or crisis and continue the process." If the Owner insists, the Facilitator exercises the veto right and documents it.
- During shift handover, the outgoing Facilitator transfers: the current state of all three boards, the iteration rhythm, the documentation status (photos taken, decisions recorded), and any open issues. The incoming Facilitator confirms readiness before assuming the role.


## Planning Phase

The Planning Phase transforms an initial understanding of the situation into structured, goal-oriented problem-solving. It marks the transition from reacting to an event toward actively shaping its resolution.

In many organizations, this phase is dominated by unstructured discussions, premature decision-making, or direct jumps into action. As a result, teams often mix facts with assumptions, solutions with problems, and actions with intentions. This leads to inefficiencies, misalignment, and avoidable errors.

P-DRIVEN addresses this by enforcing a strict methodological separation between:
- understanding the situation,
- identifying and prioritizing problems,
- developing solution options, and
- preparing execution.

To achieve this, the Planning Phase follows the **Three-Board Method**, which structures the entire process into three distinct and sequential visualizations.


### The Three-Board Method

The Three-Board Method divides the Planning Phase into three clearly separated workspaces:

- **Board 1 – Problems & Priorities**  
  Focuses on understanding the situation, identifying problems, and defining priorities.

- **Board 2 – Solution Strategies**  
  Structures the generation and evaluation of possible solution strategies.

- **Board 3 – Objectives & Execution**  
  Translates selected solutions into concrete, actionable steps with responsibilities and timelines.

This separation is not optional. It is the core mechanism that ensures clarity, discipline, and effectiveness in the problem-solving process.

Each board answers a fundamentally different question:

- **Board 1:** What are our problems?  
- **Board 2:** What can we do about them?  
- **Board 3:** How do we implement it?

By separating these questions, the method prevents typical failure patterns such as:
- jumping to solutions before understanding the problem,
- mixing operational tasks with strategic decisions,
- or losing track of priorities.

The Facilitator is responsible for guiding the team through the boards, ensuring that:
- each step is completed before moving to the next,
- results are clearly documented,
- and no phase is skipped or merged.


### Visual Representation of the Three-Board Method

![*The Three-Board Method — Sequential Logic from Problem Identification to Execution*](svg/three-board-method.pdf){width=90%}


### Step 1: Situation Briefing

#### Purpose of the Step

The Situation Briefing establishes a shared and structured understanding of the current situation as the starting point for the Planning Phase.

It serves as the controlled input into Board 1 (Problem Analysis). The objective is not to report everything that is known, but to provide only the information necessary to identify and formulate relevant problems.

The briefing is delivered by the Owner and follows a predefined structure to ensure completeness, consistency, and comparability across iterations.

The use of a fixed briefing structure is mandatory. It enforces discipline, reduces ambiguity, and prevents the omission of critical information. The specific structure may vary by organization, but it must cover at minimum: the current situation, cause, and consequences; the strategic intent of superior leadership; the analysis of likely developments and risks; open objectives and constraints; and the Owner's own intent for the next iteration. A ready-to-use briefing structure template is provided in *P-DRIVEN: Operational Guide*.

The Situation Briefing is conducted at the beginning of each planning cycle and after relevant changes in the situation.

---

#### Intended Outcome

At the end of the Situation Briefing, all participants share a common and aligned understanding of:

- what has happened and why,
- the consequences observed so far and the consequences that may emerge next,
- the resulting risks,
- open objectives, constraints, and measures already underway,
- the strategic intent of superior leadership, and
- the Owner's own intent for the next iteration.

The output is not the briefing itself, but a **structured basis for problem identification on Board 1**.

The team is prepared to:
- translate information into clearly defined problems,
- avoid redundant discussions about facts,
- and move directly into structured analysis.

The briefing is concise and time-boxed (typically 5–10 minutes). Questions are clarified immediately after the briefing in a controlled manner by the Facilitator.

No decisions are made during the Situation Briefing. Decision-making begins only after problems have been explicitly defined and prioritized.


#### Typical Misunderstandings and Early Deviations

**Using the briefing as a reporting ritual**

Teams often treat the Situation Briefing as a status update or reporting exercise. This leads to excessive detail, loss of focus, and reduced attention. The briefing is not about completeness, but about relevance for problem-solving.

Outputs from previous iterations—especially content already visible on the three boards (in particular Board 3) — do not need to be repeated in detail. Completed objectives should only be addressed if they create new problems, dependencies, or require clarification. Redundant reporting reduces efficiency without improving decision quality.

**Unstructured or inconsistent delivery**

Without a fixed structure, briefings become inconsistent, incomplete, and difficult to compare across iterations. Critical information may be omitted, while irrelevant details consume time.

**Mixing information with interpretation**

Facts, assumptions, and interpretations are often presented without distinction. This creates confusion and leads to flawed problem definitions. The briefing must clearly separate verified information from assumptions.

**Premature discussion and decision-making**

Participants frequently interrupt the briefing with questions, suggestions, or decisions. This disrupts flow and leads to fragmented understanding. Discussion must be deferred until after the briefing.

**Overloading the briefing**

Including too much detail or too many aspects leads to cognitive overload. The briefing must remain concise and focused on what is necessary for the next step.

**Skipping the briefing in follow-up cycles**

Teams sometimes omit the Situation Briefing in later iterations, assuming shared understanding. This results in divergence, hidden assumptions, and coordination issues. Each cycle requires a renewed alignment.

**Treating the briefing as an end in itself**

The most critical mistake is failing to translate the briefing into problems. Information that is not converted into problem statements has no operational value within P-DRIVEN.

#### Facilitator Activities in This Step

- Open the Situation Briefing by stating the time and confirming who is present.
- Enforce the time box (5–10 minutes). Signal the Owner when time is running out.
- Ensure the Owner follows the predefined briefing structure. If the Owner deviates or omits a required category, prompt completion.
- Prevent interruptions during the briefing. Questions, comments, and suggestions are collected afterward.
- After the briefing, moderate a controlled question round. Limit questions to factual clarification — redirect any solution proposals or evaluative statements to the appropriate later step.
- **Veto situation**: If the Owner or a team member attempts to skip the Situation Assessment and move directly to solutions ("We already know what we need to do"), the Facilitator intervenes: "The Situation Assessment has not been completed. We proceed to Board 1." If the Owner insists, the Facilitator exercises the veto right, documents it, and continues with the defined sequence.


### Step 2: Situation Assessment

#### Purpose of the Step

The purpose of the Situation Assessment is to translate the shared situational understanding into a structured set of explicit problems.

This step marks the transition from information to analysis. It ensures that the team does not operate on vague impressions, but on clearly articulated problem statements.

Situation Assessment takes place on **Board 1** and is conducted as a focused and time-boxed activity. It combines individual perspectives into a collective problem space.

The objective is not completeness, but relevance. Only problems that are actionable or have potential operational impact are considered.



#### Intended Outcome

At the end of this step, the team has produced:

- a consolidated set of clearly formulated problems,
- clustered into meaningful groups,
- without redundancy or ambiguity.

The output reflects both:
- currently observable issues, and
- anticipated problems likely to arise in the near future.

This structured problem set forms the basis for prioritization in the next step.

Problem statements should be concise, specific, and free of implicit solutions. To ensure clarity and comparability, problems should be formulated using simple guiding questions. A well-defined problem typically answers:

- **What** is the issue?
- **Where** does it occur (system, process, unit)?
- **When** does or could it occur?
- **Who** or what is affected?
- **What is the impact** (current or expected)?

The process follows a strict sequence:

1. **Individual Brainstorming (time-boxed, ~3 minutes)**: Each participant identifies relevant problems independently.

2. **Collection of Problems** : All inputs are made visible on Board 1 (e.g. cards or digital equivalent).

3. **Clustering and Consolidation**: The Facilitator groups similar problems, removes duplicates, and abstracts where appropriate.

The result is a shared and reduced representation of the problem landscape.


#### Typical Misunderstandings and Early Deviations

**Describing situations instead of problems**

Teams often restate facts from the briefing instead of formulating problems. A situation only becomes actionable when it is expressed as a problem. Descriptions without problem framing do not support decision-making.

**Jumping to solutions during brainstorming**

Participants frequently suggest actions instead of identifying problems. This disrupts the logic of the method and leads to premature convergence. Solutions are strictly handled in Board 2.

**Lack of time discipline**

If brainstorming is not strictly time-boxed, discussions emerge and dominant voices take over. This reduces diversity of input and delays the process. Speed is essential to capture intuitive assessments.

**No anticipation of future problems**

Teams tend to focus only on current issues and neglect foreseeable developments. This leads to reactive behavior. Anticipation is a required element of effective problem identification.

**Over-fragmentation or excessive detail**

Problems are sometimes defined too narrowly, leading to an unmanageable number of items. The Facilitator must ensure appropriate abstraction and clustering.

**Unclear or vague problem statements**

Poorly formulated problems (e.g. “system unstable”) create ambiguity and hinder prioritization. Problems should be specific enough to allow comparison and decision-making.

**Dominance of individual perspectives**

Without structured facilitation, strong personalities may shape the problem set disproportionately. The method relies on capturing distributed knowledge, not hierarchy-driven input.

#### Facilitator Activities in This Step

- Initiate the individual brainstorming: distribute moderation cards, set the time box (~3 minutes), ensure silence during individual writing.
- Collect all cards after the time box ends.
- Cluster the cards visibly on Board 1: group similar problems, remove exact duplicates, abstract where appropriate. Read each card aloud while placing it.
- When a card contains a solution rather than a problem, separate it visibly and note it for Board 2: "This is a solution proposal. It will be considered during Decision Taking. For now, we need the problem it addresses."
- When a card is too vague, ask the author to reformulate: "Can you express this as a specific problem?"
- After clustering, invite the team to review the board and add any problems that were missed.
- Confirm closure of the Situation Assessment before moving to Situation Evaluation.


### Step 3: Situation Evaluation

#### Purpose of the Step

The purpose of Situation Evaluation is to assess and prioritize the identified problem clusters in a structured and transparent way.

This step ensures that the team does not attempt to solve all problems simultaneously, but instead focuses on those with the highest operational relevance.

It translates a broad and unstructured problem landscape into a clearly prioritized set of issues, creating a decision-ready foundation for solution development.

Situation Evaluation is conducted on **Board 1** and represents the final step before moving from analysis to solution design.


#### Intended Outcome

At the end of this step, the team has identified a limited number of **top-priority problems (typically five)** that will be addressed in the subsequent steps.

The evaluation follows a structured two-dimensional approach:

- **Urgency** (time sensitivity)
- **Importance** (impact on operations)

Each participant contributes to the evaluation by assigning a fixed number of votes per dimension (e.g. five for urgency and five for importance). Votes can be distributed across multiple problems or concentrated on a few.

The results are then transferred into the **Eisenhower Matrix**, which structures the problems along the two dimensions:
- urgent vs. not urgent
- important vs. not important


|                     | **Urgent**                          | **not Urgent**              |
|---------------------|-------------------------------------|-----------------------------|
| **Important**       | Priority 1                    | Priority 3              |
| **not Important**   | Priority 2                      | Priority 4             |


The final prioritization is determined by:
1. the position of the problem within the matrix (priority of quadrant), and  
2. the number of votes received.

Based on this, the **Top 5 problems** are selected for further processing.

If ranking is ambiguous (e.g. tie between positions), the Owner makes the final decision.

The outcome is a shared, transparent, and methodologically grounded prioritization that directs all subsequent planning activities.


#### Typical Misunderstandings and Early Deviations

**Avoiding reduction**

Teams often hesitate to reduce the number of problems, attempting to address too many issues at once. This leads to loss of focus and ineffective execution. Prioritization requires deliberate exclusion.

**Confusing urgency with importance**

Immediate pressure is frequently overvalued, while structurally critical problems are underestimated. The method explicitly separates these dimensions to counteract this bias.

**Dominance of hierarchy over structured evaluation**

Without disciplined voting, seniority may influence prioritization disproportionately. The voting mechanism is designed to aggregate distributed expertise, not reinforce hierarchy.

**Premature discussion during evaluation**

Participants often begin debating individual problems during voting. This slows down the process and biases results. Evaluation should be fast and largely intuitive.

**Overengineering the prioritization**

Adding additional criteria or complex scoring systems reduces clarity and speed. The Eisenhower logic is intentionally simple and sufficient under time pressure.

**Ignoring the prioritization outcome**

Teams sometimes continue working on non-prioritized problems. This undermines the method and leads to resource fragmentation. Only selected top problems should move forward.

#### Facilitator Activities in This Step

- Explain the voting procedure before it begins: each participant receives five votes for urgency and five for importance. Votes are cast silently and simultaneously — no discussion before or during voting.
- Distribute voting materials (sticky dots or markers).
- Enforce silence during voting. If participants begin discussing, intervene: "Voting is individual. Discussion follows after the result."
- Count votes, transfer problems into the Eisenhower matrix on Board 1, and read the resulting prioritization aloud.
- In case of ties, present the tied problems to the Owner for a final decision.
- Confirm the Top 5 with the team. Mark them visibly on Board 1.
- Declare the Situation Evaluation complete before moving to Decision Taking.


### Step 4: Decision Taking

#### Purpose of the Step

The purpose of Decision Taking is to develop and select viable solution strategies for each prioritized problem.

This step marks the transition from analysis to decision-making. It ensures that actions are not derived intuitively or prematurely, but based on a structured exploration of alternatives.

Decision Taking takes place on **Board 2**. It enforces deliberate thinking by requiring multiple solution paths before committing to action.

The objective is not to find the perfect solution, but to select a viable and timely course of action under uncertainty.


#### Intended Outcome

At the end of this step, the team has defined **at least one selected solution strategy for each prioritized problem**.

The process follows a strict sequence:

1. **Generation of Solution Strategies**  
   For each prioritized problem, the team defines **three distinct solution strategies**.  
   This requirement is mandatory and ensures sufficient diversity of thought.

   Strategies should differ in approach (e.g. containment vs. workaround vs. root cause resolution) and may include unconventional options.

2. **Structured Evaluation of Options**  
   All strategies are briefly evaluated against key criteria:
   - feasibility (can it be implemented under current conditions),
   - effectiveness (does it solve the problem),
   - risks and side effects (what new issues may arise),
   - synergies (does it address multiple problems),
   - dependencies (does it rely on other actions).

3. **Selection of Strategy**  
   The team selects the most suitable strategy per problem through consensus or majority decision.

   In some cases, **multiple strategies may be selected in parallel** if they expand future options or address different aspects of the problem.

Selected strategies are clearly marked on **Board 2** and form the direct input for execution planning.

The step is time-boxed (typically ~15 minutes, extended in complex situations if required).


#### Typical Misunderstandings and Early Deviations

**Defining too few solution options**

Teams often move directly to a preferred solution without exploring alternatives. This reduces solution quality and increases the risk of blind spots. The requirement of three strategies is intended to counteract this bias.

**Superficial variation of strategies**

Providing three variations of the same idea (instead of fundamentally different approaches) undermines the purpose of the step. True alternatives must differ in logic or approach.

**Falling back to standard procedures without reflection**

Teams may default to known playbooks without considering whether they fit the specific situation. Established procedures are valid options, but must still be evaluated alongside alternatives.

**Over-analysis and loss of tempo**

Excessive discussion or detailed evaluation delays decision-making. The goal is not exhaustive analysis, but sufficient confidence to act.

**Avoiding clear decisions**

Teams sometimes hesitate to commit to a strategy and keep multiple options open without prioritization. This leads to ambiguity and weak execution.

**Ignoring interdependencies**

Solutions are often treated in isolation, although they may influence or depend on each other. Failure to recognize dependencies can lead to conflicts or inefficiencies during execution.

**Premature convergence driven by hierarchy**

Senior participants may push for a preferred solution early in the process. This suppresses alternative perspectives and reduces the quality of decision-making. Structured evaluation must precede commitment.

#### Facilitator Activities in This Step

- Transition the team from Board 1 to Board 2. Announce the step and its time box (~15 minutes).
- For each prioritized problem, prompt the team to develop three distinct solution strategies. Enforce the three-strategy requirement: "We need a third approach that is fundamentally different, not a variation."
- Write the strategies on Board 2 as they are proposed, visibly linked to the corresponding problem.
- Moderate the brief evaluation of each strategy (feasibility, effectiveness, risks, synergies, dependencies). Prevent extended debate — the evaluation must be sufficient to decide, not exhaustive.
- When the team converges prematurely on one strategy without genuinely considering alternatives, intervene: "We have not yet evaluated the other options. Let's hear them before deciding."
- Call the time box. If more time is needed for complex situations, the Facilitator extends explicitly and states the new limit.
- Confirm the selected strategies on Board 2 with the team before moving to Objective Definition.
- **Veto situation**: If the Owner attempts to skip strategy development and move directly to assigning tasks ("We don't need alternatives, just do X"), the Facilitator intervenes: "Decision Taking requires at least three strategies per problem. We have not completed this step." If overridden, the veto is documented.


### Step 5: Objective Definition
#### Purpose of the Step

The purpose of Objective Definition is to translate selected solution strategies into concrete objectives that can be assigned, executed, and monitored.

This step marks the transition from deciding *what should be done* to defining *what exactly must be achieved*. It operationalizes strategy without collapsing into unstructured task lists.

Objective Definition takes place on **Board 3**. It creates the basis for coordinated execution and later follow-up.

The objective is not activity, but clearly defined outcomes.

#### Intended Outcome

At the end of this step, the team has defined one or more **SMART objectives** for each selected solution strategy.

Objectives must be formulated in a way that enables execution and control. Each objective should be:

- **Specific** –  describing the intended outcome  
- **Measurable** – allowing verification of progress or completion  
- **Achievable** – realistic under given conditions  
- **Relevant** – directly contributing to resolving the underlying problem  
- **Time-bound** – defined with a clear deadline or time frame  

A well-defined objective answers:

- What must be achieved?  
- How do we recognize success?  
- By when must it be achieved?  
- What resources or constraints are relevant? 

Objectives must be short and concise. They should be formulated in a way that they can fit on a single card or visual element without losing clarity. Overly long or complex formulations reduce usability and hinder quick understanding during execution.

Multiple objectives may be required for a single strategy if implementation requires several coordinated actions.

All objectives are transferred to **Board 3**, which serves as the execution and tracking layer. This ensures that strategies are not only decided, but translated into actionable and controllable outcomes.

#### Typical Misunderstandings and Early Deviations

**Using strategies as objectives**

One of the most common mistakes is directly transferring solution strategies onto Board 3 as if they were objectives. Strategies are inherently broad and conceptual, while objectives must be concrete and operational.

Without proper translation, execution becomes unclear, progress cannot be measured, and accountability is weakened.

**Turning strategies directly into tasks**

Teams often move from strategy selection straight into task assignment. This skips the necessary abstraction layer of objectives and leads to fragmented execution. Objectives must define intended outcomes before work is assigned.

**Defining activities instead of objectives**

Statements such as “call supplier” or “check system status” describe actions, not objectives. Objectives must express what is to be achieved, not merely what someone should do.

**Vague or immeasurable wording**

Poorly defined objectives make follow-up impossible. If success cannot be recognized, the team cannot reliably monitor progress or adapt execution.

**Omitting deadlines**

Objectives without a time frame lose operational relevance. Time-bound definition is essential for prioritization, coordination, and accountability.

**Overloading objectives**

Trying to combine multiple outcomes into one objective creates ambiguity and weakens ownership. Objectives should remain clear and manageable.

**Ignoring resources and constraints**

Objectives are sometimes defined without considering available personnel, authority, or material means. This produces unrealistic planning and undermines execution from the outset.

**Confusing Board 3 with a task board**

Board 3 is not a list of miscellaneous activities. It is the structured translation of selected strategies into monitored objectives.

#### Facilitator Activities in This Step

- Transition the team from Board 2 to Board 3. For each selected strategy, prompt the team: "What are the concrete objectives that implement this strategy?"
- Write each objective on a card and place it on Board 3 in the "open" column.
- Quality-check each objective against the SMART criteria. If an objective is too vague, push back: "How will we know this objective is achieved? What is the deadline?" Reformulate with the team until the objective is specific and time-bound.
- Ensure that objectives are formulated as outcomes, not activities. If someone proposes "call supplier," ask: "What must be achieved by that call? What is the objective?"
- Verify that each objective is realistic given the team's current resources and the planning horizon.


### Step 6: Objective Allocation

#### Purpose of the Step

The purpose of Objective Allocation is to assign defined objectives to responsible roles and required resources, and to make execution transparent and manageable.

This step translates objectives into coordinated action by linking them to ownership, capacity, and execution status.

Objective Allocation takes place on **Board 3**, which functions as a structured execution board. It ensures that all activities are visible, traceable, and controllable across the team.

The objective is not only to assign work, but to establish a shared operational picture of who is doing what, with which resources, and in what status.

---

#### Intended Outcome

At the end of this step, all objectives are:

- assigned to a clearly defined responsible role,
- linked to the required resources,
- and placed within a defined execution status (e.g. open, in progress, blocked, completed).

Each objective is represented as a visual element (e.g. card) on **Board 3**, enabling a shared and continuously updated overview of all activities.

The structure of Board 3 follows two dimensions:

- **Responsibility (rows)** – e.g. Owner, Facilitator, Domains
- **Status (columns)** – e.g. open, in progress, blocked, completed  

| **Responsible**        | **Open / New** | **In Progress** | **Blocked** | **Completed** |
|-----------------------|----------------|------------------|-------------|---------------|
| Owner                 | Objective / _Resource A_      |                  |             |               |
| Facilitator           |                | Objective / _Resource B_        |             |               |
| Domain Operations      | Objective / _Resource C + D_     | Objective / _Resource F_ Objective / _Resource G_       |             |               |
| Domain IT             | Objective / _Resource H_     |                  | Objective   |               |
| Domain HR             |                | Objective  / _Resource  I_     |             |               |
| Domain Finance        | Objective / _Resource J_      |                  |             | Objective     |


A printable Board 3 template is provided in *P-DRIVEN: Operational Guide*.

Resources are managed explicitly:
- Only resources that are available and integrated into the situation may be assigned.
- Each resource can only be allocated once at a time.
- If required resources are not available, a separate objective must be created to obtain or activate them.

The board must be maintained in a way that enables **handover readiness at any time**. Any incoming role must be able to understand the current state of execution without additional explanation.

For traceability, objectives should be clearly linked to their iteration (e.g. by color-coding or timestamping).



#### Typical Misunderstandings and Early Deviations

**Unclear or missing ownership**

Objectives without a clearly assigned responsible role lead to diffusion of responsibility and delayed execution. Every objective must have exactly one accountable owner.

**Assigning multiple owners**

Shared responsibility often results in no effective responsibility. Ownership must be explicit and singular, even if multiple people contribute.

**Ignoring resource constraints**

Teams frequently assign objectives without checking resource availability. This leads to overload, conflicts, and unrealistic planning. Resource allocation must be explicit and constrained.

**Double allocation of resources**

Assigning the same resource to multiple objectives at the same time creates hidden bottlenecks and delays. Resource usage must be transparent and exclusive.

**Not managing unavailable resources**

Teams often assume resources will become available without planning for it. If a resource is missing, this must be treated as a problem (for the next iteration) or as an objective.

**Treating the board as documentation instead of control tool**

Board 3 is not a passive record. If it is not actively used to steer execution, it quickly becomes outdated and irrelevant.

**Inconsistent or outdated status tracking**

If the status of objectives is not updated continuously, the board loses its function as a coordination tool. Status must reflect reality at all times.

**Lack of handover readiness**

Boards that can only be understood by the current team create major risks during shift changes. The structure must allow any incoming team to immediately grasp the situation.

**Overcomplicating the board**

Adding too many statuses, categories, or visual elements reduces clarity. The board must remain simple, structured, and quickly readable under pressure.

#### Facilitator Activities in This Step

- For each objective on Board 3, ensure that a single responsible person is assigned. If ownership is unclear, prompt the Owner: "Who is responsible for this objective?"
- Check for resource conflicts: no person or resource should be assigned to multiple objectives simultaneously without explicit acknowledgment. Flag double allocations.
- Verify that deadlines are set for all objectives and that they fall within the current planning horizon.
- Set the time for the next Situation Briefing. This defines the iteration cycle length. Communicate it clearly to the entire team.
- Confirm that Board 3 is complete: every objective has an owner, a deadline, and a status ("open"). Read the board aloud as final confirmation before the team transitions to the Implementation Phase.
- **Veto situation**: If the Owner attempts to move to execution without completing the allocation ("We'll sort out the details later"), the Facilitator intervenes: "Objectives without clear ownership and deadlines cannot be tracked. We complete the allocation before execution begins."


## Implementation Phase
### Step 1: Situation Freeze

#### Purpose of the Step

The purpose of the Situation Freeze is to formally conclude the Planning Phase and create a stable reference point for execution.

It marks the transition from structured decision-making to decentralized implementation. By freezing the current state of all three boards, the team ensures that execution is based on a clearly defined, shared, and documented plan.

The Situation Freeze prevents continuous re-discussion and protects the integrity of the planning results during execution.


#### Intended Outcome

At the end of this step:

- all three boards (Board 1–3) are **finalized and documented**,
- a **clear execution baseline** is established,
- and the **start of the next planning cycle** is defined.

The documentation is typically created through a complete visual capture (e.g. photo) of all boards. This serves as the formal record of the team’s work and decision-making process.

The documentation must allow reconstruction of:
- the situation and problem structure,
- the selected strategies,
- and the defined objectives with responsibilities and resources.

A specific **time for the next Situation Briefing** is set. This ensures that execution is time-boxed and followed by a new structured planning cycle.

After the freeze:

- execution begins immediately,
- team members move into their respective operational roles,
- and work is carried out based on the defined objectives.

The Facilitator remains responsible for maintaining the documented situation and preparing the next iteration.


#### Typical Misunderstandings and Early Deviations

**Continuing planning during execution**

Teams often continue to modify plans informally after execution has started. This leads to inconsistencies, loss of alignment, and unclear priorities. Once frozen, changes must be deferred to the next planning cycle.

**Skipping documentation**

Failing to document the boards removes traceability and makes it impossible to reconstruct decisions. Documentation is not optional—it is the only reliable record of structured decision-making.

**No defined next planning cycle**

Without setting a clear time for the next briefing, execution becomes open-ended and unstructured. Regular iteration is essential to maintain control.

**Treating the freeze as administrative overhead**

The Situation Freeze is sometimes perceived as unnecessary bureaucracy. In reality, it is a critical control mechanism that stabilizes execution and enables coordination across teams.

**Incomplete or inconsistent board state**

If boards are not fully updated before freezing, execution starts on an unclear or outdated basis. The freeze requires a clean, consistent, and complete state.

**Lack of separation between planning and execution spaces**

If teams remain in the same setting and continue discussions, the distinction between planning and execution blurs. Physical or logical separation reinforces role clarity and focus.

**Facilitator leaving the coordination space**

If the Facilitator joins execution activities, documentation and coordination deteriorate. The Facilitator must remain focused on maintaining structure and preparing the next cycle.

#### Facilitator Activities in This Step

- Create a photographic record of all three boards. This is the first documentation point of the cycle.
- Confirm that the time for the next Situation Briefing is set and communicated.
- Remain in the coordination space. The Facilitator does not leave during the Implementation Phase.
- As team members depart for execution, ensure each person confirms their assigned objectives and the reporting schedule.

#### The Facilitator During the Implementation Phase

After the Situation Freeze, the coordination space empties. Team members leave to work on their objectives. The Facilitator stays. This is the longest continuous stretch of the iteration cycle, and it can feel deceptively quiet — but it is not idle time. The Facilitator's work during the Implementation Phase follows a consistent rhythm:

**First 15 minutes after Situation Freeze:** Complete board photography. Verify that task transmissions are underway (written, not just verbal). Confirm the reporting schedule with each team member before they leave. Note the agreed time for the next Situation Briefing visibly in the coordination space.

**Ongoing during execution:** Monitor incoming status reports. Each report triggers a Board 3 update — move cards from "open" to "in progress," from "in progress" to "completed," or from "in progress" to "blocked." Note the reason for any blocked objective directly on the board. Track which team members have reported and which have not. If a scheduled status update is overdue, request it proactively — but do not chase. One reminder is sufficient; repeated absence of reporting is itself a finding for the next Situation Assessment.

**Between reports:** Review the current board state. Identify patterns: Are multiple objectives blocked by the same cause? Are deadlines realistic given what has been reported? Are there dependencies between objectives that were not visible during planning? Note observations for the Debriefing. Prepare mentally for the next Planning Phase: What problems are likely to emerge? Which strategies from Board 2 were not selected but may become relevant?

**Five minutes before the next Situation Briefing:** Initiate the Preparation of the Situation Briefing. No new information is accepted from this point. Finalize Board 3. Take the second photo of the cycle. Confirm that the Owner is ready to brief. Reconvene the team.

The Facilitator does not solve problems during the Implementation Phase. The Facilitator does not coordinate execution. The Facilitator maintains the boards, receives information, preserves traceability, and prepares the next cycle. The discipline of staying in the coordination space — resisting the urge to help, to check, to intervene operationally — is one of the hardest aspects of the role and one of the most important.


### Step 2: Transmission of Tasks

#### Purpose of the Step

The purpose of Task Transmission is to translate defined objectives into executable instructions and formally assign them to the responsible resources.

This step ensures that objectives do not remain abstract, but are operationalized into clearly understood and actionable tasks within the respective areas of responsibility.

It creates clarity at the interface between the coordination team (CMT / IMT) and the executing units.

---

#### Intended Outcome

At the end of this step, all objectives are translated into **clearly defined tasks** that have been formally communicated to the responsible resources.

Each task must be documented in a structured and unambiguous way. A complete task description includes:

- **Objective** – What is to be achieved? (expected outcome, not just activity)  
- **Responsibility** – Who is accountable for execution? (exactly one responsible person)  
- **Resources** – Which means are available and approved for execution?  
- **Deadline** – By when must the objective be achieved, and when are updates expected?  
- **Communication** – How and when is progress reported?  

Tasks are typically transmitted in written form (e.g. email or task management systems) to ensure traceability and consistency. Verbal communication may complement, but not replace, written transmission. A task transmission form template is provided in *P-DRIVEN: Operational Guide*.

The result is a set of clearly assigned and understood tasks that enable decentralized execution without continuous coordination.

---

#### Typical Misunderstandings and Early Deviations

**Unclear or incomplete task descriptions**

Tasks that lack clarity regarding outcome, responsibility, or deadlines lead to delays, misunderstandings, and rework. Each task must be self-contained and understandable without additional explanation.

**Assigning multiple responsible persons**

Shared responsibility creates ambiguity and reduces accountability. Each task must have exactly one accountable owner, even if multiple resources are involved.

**Focusing on activities instead of outcomes**

Tasks are often formulated as actions (“check”, “analyze”, “call”) instead of results. This disconnects execution from the original objective and makes evaluation difficult.

**Missing communication expectations**

If reporting intervals and channels are not defined, feedback becomes inconsistent or delayed. This reduces the ability to steer execution.

**Overloading tasks**

Combining multiple objectives into a single task reduces clarity and makes progress difficult to track. Tasks should remain focused and aligned with a single objective.

**Purely verbal task assignment**

Relying only on verbal instructions leads to loss of information and lack of traceability. Written transmission is required for reliable coordination.

**Assuming implicit understanding**

Teams often assume that recipients interpret tasks as intended. Without explicit formulation, different interpretations emerge, leading to inconsistent execution.

**Reassigning tasks without updating the board**

Changes in responsibility or scope are sometimes communicated informally but not reflected on Board 3. This creates discrepancies between planning and execution.

#### Facilitator Activities in This Step

- Review each task description before transmission for completeness: objective, responsibility, resources, deadline, and communication expectations.
- Ensure that each task on Board 3 has exactly one accountable person assigned.
- Verify that task formulations describe outcomes, not activities. Challenge vague formulations ("check the system") and redirect toward result-oriented descriptions ("confirm that system X is operational and report status by [time]").
- Confirm that written transmission has occurred for every task. Verbal briefings are acceptable as supplements, not substitutes.
- Update Board 3 to reflect all assigned tasks as "open" with the responsible person noted.


### Step 3: Processing of Tasks

#### Purpose of the Step

The purpose of Processing of Tasks is the execution of assigned objectives by the responsible resources within their respective areas of responsibility.

After the Transmission of Tasks, execution moves outside the coordinating team. The assigned resources — whether internal staff, external service providers, or other designated parties — work on their objectives independently, within the scope and parameters defined during the Planning Phase.

During this step, team members should physically or logically separate to work on their respective tasks without mutual interference. Direct exchange between team members is generally not necessary during execution. The Planning Phase has produced clearly defined objectives, and each responsible person pursues them individually. The Facilitator remains in the coordination space to maintain the boards, receive status updates, and ensure traceability.

This separation is deliberate. When all team members remain in a single space, distractions, unstructured discussions, and the temptation to deviate from the method increase. Under stress, simultaneous phone calls and side conversations raise noise levels and erode concentration.

The coordinating team does not manage execution in detail. It maintains awareness, receives structured feedback, and prepares the next planning cycle.

#### Intended Outcome

At the end of the execution interval:

- All assigned objectives have been actively worked on within the respective areas of responsibility.
- Resources report progress at agreed intervals and through defined channels to their responsible team member.
- Team members are responsible for ensuring that status updates — including delays or blockers — are communicated in a timely manner.
- Team members should limit inquiries to the agreed reporting intervals. The persons operationally resolving the incident or crisis need time and space for execution.
- New developments that arise during execution are not acted upon ad hoc. They are noted and addressed in the next Planning Phase iteration. Unless a development requires immediate stabilization, the response is: "We will address this in the next planning cycle."

#### Typical Misunderstandings and Early Deviations

**Reacting to every incoming update immediately**

Under pressure, teams tend to respond to every new piece of information as it arrives. This disrupts the disciplined cycle of plan–execute–review and leads to fragmented, uncoordinated action. New information is by definition already in the past. If the team learns about it, it has already happened — or the team itself cannot act on it directly. Structured iteration, not constant reaction, maintains coordination quality.

**Team members remaining in the same space**

Keeping all team members in one room during execution leads to informal discussions, mutual distraction, and spontaneous re-planning outside the defined process. Physical or logical separation protects execution focus and method discipline.

**Expanding scope beyond assigned objectives**

Resources sometimes extend the scope of their work without reporting back. This creates coordination gaps and may conflict with parallel activities or with objectives assigned to others. Any significant deviation from the defined objective must be communicated to the responsible team member and, if substantial, raised with the Owner.

**Withholding blockers until the next planning cycle**

While routine status updates follow agreed intervals, blockers and critical developments must be escalated to the Facilitator without delay. The Facilitator moves the corresponding card on Board 3 from "in progress" to "blocked." This information is then fed into the next Planning Phase iteration to adjust the approach and plan new measures.

**Informal coordination bypassing the team structure**

Direct coordination between resources outside the defined structure produces fragmentation. Communication paths established during planning must be respected during execution.

#### Facilitator Activities in This Step

- Remain in the coordination space. The Facilitator does not participate in task execution.
- Monitor incoming status updates and update Board 3 accordingly as reports arrive.
- Track reporting intervals. If a team member's scheduled update is overdue, proactively request a status report.
- When a blocker is reported, immediately move the corresponding card on Board 3 to "blocked" and note the reason.
- Do not initiate new coordination or change task scope. The Facilitator maintains the boards and receives information — execution decisions remain with the Owner.
- Use the execution interval to prepare for the next planning cycle: review board states, identify patterns, and note process observations for the Debriefing.


### Step 4: Task Follow-Up

#### Purpose of the Step

The purpose of Task Follow-Up is to continuously monitor the progress of assigned objectives during the execution interval.

Each team member monitors the progress of the objectives assigned to them. The responsible resources provide regular status updates, which are documented. These updates provide a clear overview of the current state of tasks and help to maintain transparency and traceability.

Task Follow-Up is not a separate meeting or event. It is an ongoing activity during the Implementation Phase. It ensures that the coordinating team maintains situational awareness and can identify emerging issues before they escalate.

#### Intended Outcome

At the end of the execution interval:

- Each team member has a current understanding of the status of their assigned objectives.
- Status information has been communicated and documented.
- The Facilitator has received sufficient information to update Board 3 accurately.
- Emerging blockers or deviations have been identified and flagged.

Depending on the complexity of the incident or crisis, team members may need to maintain additional tracking mechanisms (e.g., subordinate Kanban boards) for more detailed management of their assigned objectives. These must not be confused with or mixed into Board 3, which remains the authoritative tracking instrument for the coordinating team.

#### Typical Misunderstandings and Early Deviations

**Confusing Task Follow-Up with active management of execution**

The coordinating team monitors and tracks — it does not micro-manage. The resources executing the tasks are responsible for their own work. Follow-up ensures visibility, not control.

**Waiting for the next planning cycle to report blockers**

Critical status changes — particularly blocked objectives or significant scope deviations — must be communicated to the Facilitator immediately, not held until the next Situation Briefing. Delayed reporting reduces the team's ability to respond.

**Failing to document status updates**

Verbal updates that are not captured reduce traceability and create information gaps during shift changes or when preparing the next planning cycle. Status updates must be recorded.

**Over-reporting and creating noise**

Frequent, unstructured status updates overwhelm the Facilitator and obscure relevant developments. Reporting must follow the defined intervals unless a critical change occurs.

#### Facilitator Activities in This Step

- Consolidate incoming status updates and ensure they are reflected on Board 3.
- Distinguish between routine progress reports and escalation-worthy blockers. Routine updates are noted; blockers trigger immediate board updates and are flagged for the next planning cycle.
- If team members report verbally, ensure documentation occurs — either by requesting written confirmation or by capturing the update directly on the board.
- Maintain awareness of which objectives have not yet reported status. Flag gaps before the next Preparation of the Situation Briefing.
- Do not interpret or evaluate task progress beyond what is reported. The Facilitator tracks status; the Owner evaluates results.


### Step 5: Situation Update

#### Purpose of the Step

The purpose of the Situation Update is to keep Board 3 current throughout the Implementation Phase by reflecting all status changes as they occur.

Board 3 functions as the authoritative execution tracking instrument. It must accurately represent the current state of all objectives at all times. The Situation Update is not a scheduled event but an ongoing, event-driven activity: whenever the status of an objective changes, Board 3 is updated accordingly.

Status changes that trigger an update include:

- an objective moving from "open" to "in progress,"
- an objective moving from "in progress" to "completed,"
- an objective moving from "in progress" to "blocked,"
- or any other transition that changes the execution state of an assigned objective.

Cards on Board 3 may only be moved by the Facilitator. This ensures that the information on the board remains consistent and reliable.

#### Intended Outcome

At any given point during execution:

- Board 3 accurately reflects the current status of all objectives.
- The Facilitator has updated all reported changes.
- Any incoming team member — including shift replacements — can read Board 3 and understand the execution state without additional briefing.
- Blocked objectives are visibly marked and prepared for input into the next Planning Phase iteration.

The Situation Update also serves as the basis for the Preparation of the Situation Briefing. When the Facilitator prepares for the next planning cycle, the state of Board 3 must already be current.

#### Typical Misunderstandings and Early Deviations

**Treating the board as a periodic documentation task**

Board 3 is not updated at intervals. It is updated on every status change. Treating it as a periodic report reduces its value as a real-time coordination instrument.

**Multiple people updating the board**

Allowing team members other than the Facilitator to move cards creates inconsistencies and competing versions of execution status. The Facilitator is the sole authority for Board 3.

**Not flagging blocked objectives visibly**

Blocked objectives that are not clearly marked on Board 3 will not be addressed in the next planning cycle. Blockers must be visually distinct and unmistakable.

**Overcomplicating the board during updates**

Adding excessive detail, annotations, or status categories reduces readability under pressure. The board must remain simple, structured, and quickly readable.

#### Facilitator Activities in This Step

- Move cards on Board 3 immediately when a status change is reported. Cards may only be moved by the Facilitator.
- Ensure blocked objectives are visually distinct on the board (e.g., marked with a clear indicator or moved to a designated "blocked" column).
- Reject attempts by team members to move cards themselves. Reinforce that Board 3 is the Facilitator's responsibility.
- Keep the board readable: avoid excessive annotations. Each card should show objective, responsible person, and current status — nothing more.
- Maintain Board 3 as a real-time instrument, not a periodic report. Any delay between a reported change and its reflection on the board degrades coordination quality.


### Step 6: Preparation of the Situation Briefing

#### Purpose of the Step

The purpose of the Preparation of the Situation Briefing is to ensure that at the time of the next Situation Briefing, all relevant information is structured and ready. This step marks the transition from the Implementation Phase back into the Planning Phase.

The Preparation begins at a defined time before the scheduled Situation Briefing — typically five minutes. During this window, the Facilitator finalizes Board 3 by incorporating any last status changes. No new information is introduced during this step. No new emails are received, no calls are taken. This ensures that the captured data remains consistent and provides a stable basis for the briefing.

Once the final update of Board 3 is complete, the Facilitator creates a photographic or digital record of the board state.

Concurrently, the Owner prepares the Situation Briefing. All team members use this time to collect problems they have observed during execution for input into the next Situation Assessment.

#### Intended Outcome

At the end of this step:

- Board 3 has been finalized and documented (photo or digital capture).
- The Owner is prepared to deliver the Situation Briefing.
- All team members have collected observations and problems for the next Situation Assessment.
- The team is reconvened and ready to enter the next Planning Phase.

The Preparation of the Situation Briefing also includes a critical assessment by the Owner: whether the incident or crisis is still ongoing. The Owner evaluates the current situation and determines whether the activation criteria are still met. An incident or crisis can be declared ended when:

- The affected processes, systems, or services have been stabilized.
- The original activation criteria are no longer met.
- No acute need for further coordinated measures exists.
- Regular operations can resume without significant impairment.

Before the Owner declares the end of an activation, the Facilitator holds an explicit veto right. This veto enables the Facilitator to challenge the decision and require a renewed evaluation if the preconditions for closure are not yet fully met. The veto is documented.

If the activation is declared ended, it is announced during the Situation Briefing, and the process transitions into the Learning Phase. All open objectives and remaining problems must be explicitly handed over to the regular organization.

If the activation continues, a new Planning Phase begins with the Situation Briefing. During the subsequent Situation Assessment, problems from the previous iteration are reviewed for continued relevance before new brainstorming begins. Existing problems that are still current require new cards to enable fresh assessment and prioritization without anchoring bias.

#### Typical Misunderstandings and Early Deviations

**Skipping the preparation window**

Moving directly from execution into the Situation Briefing without a defined preparation step produces incomplete board states, unprepared briefings, and missing problem observations. The five-minute window is not optional.

**Introducing new information during preparation**

Accepting new calls or reading new messages during the preparation step disrupts the consistency of the documented board state. The preparation window is a controlled cutoff to ensure a stable baseline for the next cycle.

**Not assessing whether the activation should continue**

Teams sometimes enter the next planning cycle without explicitly checking whether the incident or crisis still meets the activation criteria. This leads to unnecessary iterations or, conversely, premature deactivation without formal assessment.

**Not collecting problems during execution**

If team members arrive at the next Situation Assessment without having noted problems and observations during execution, the brainstorming phase loses quality. Problem collection is a continuous activity during the Implementation Phase.

**Reusing problem cards from the previous iteration**

Carrying over problem cards from the previous iteration without re-creating them introduces anchoring bias. Problems that remain relevant must be captured on fresh cards and evaluated anew.

#### Facilitator Activities in This Step

- Five minutes before the scheduled Situation Briefing, initiate the preparation window. Announce to the team that no new information is to be received or processed from this point.
- Finalize Board 3 by incorporating any last status changes. After finalization, create a photographic or digital record of the board state.
- Confirm that the Owner is prepared to deliver the Situation Briefing.
- Ensure all team members are reconvening and have collected their observations and problems for the next Situation Assessment.

> **Veto situation — Premature deactivation:** Before the Owner declares the end of an activation, the Facilitator explicitly assesses whether the preconditions for closure are met. If the Facilitator determines that the situation has not been sufficiently stabilized, that activation criteria are still met, or that open objectives have not been adequately handed over, the Facilitator exercises the veto right. The veto is documented. The activation continues with the next Planning Phase.


## Learning Phase

The Learning Phase is the structured conclusion of each P-DRIVEN activation. It serves two distinct purposes: immediate feedback collection after deactivation and subsequent structured analysis to derive organizational improvements.

The Learning Phase is not optional. It is an integral part of the Problem-Solving P. Omitting it removes the mechanism through which the organization preserves and applies the experience gained during the activation.

The Learning Phase is triggered when the Owner declares the end of the incident or crisis during a Situation Briefing. The team remains assembled to begin the first step immediately.


### Step 1: Debriefing

#### Purpose of the Step

The Debriefing serves the immediate collection of observations, impressions, and initial findings directly after the conclusion of the activation. It takes place while the team is still assembled — before members leave the coordination space.

The purpose is to capture what is fresh: immediate reactions, observations about what worked and what did not, and initial ideas for improvement. The Debriefing is not an analysis. It is a structured collection of raw feedback while recall is at its highest.

The Debriefing is facilitated by the Facilitator.

#### Intended Outcome

At the end of this step:

- All core team members have contributed their immediate observations.
- Key impressions about what worked well and what did not are documented.
- Initial improvement suggestions have been collected without detailed analysis.
- The documented output is available as input for the subsequent Structured Feedback.

The Debriefing is kept short and focused. It should not exceed 15–30 minutes. The guiding questions are:

- What worked well during the activation?
- What did not work well or caused difficulties?
- What should be done differently next time?
- Were there situations where the method was not followed? What happened as a result?

The documentation is captured by the Facilitator in written form. It does not need to be elaborate — structured notes are sufficient.

#### Typical Misunderstandings and Early Deviations

**Skipping the Debriefing due to fatigue**

After a prolonged activation, teams are often exhausted and eager to leave. This is precisely when the most valuable observations are at risk of being lost. The Debriefing must happen immediately, while the experience is current.

**Conducting the Debriefing as a blame exercise**

If participants feel that the Debriefing is an evaluation of individual performance, they will not engage honestly. The Facilitator must frame it explicitly as a structural and methodological review — not a personal assessment.

**Turning the Debriefing into a full analysis**

The Debriefing collects observations; it does not analyze them. Extended discussion, root cause analysis, or detailed improvement planning belongs in the Structured Feedback. The Debriefing must remain short.

**Not documenting the results**

Verbal feedback that is not written down has no lasting value. The Facilitator must capture findings in writing, however briefly.

#### Facilitator Activities in This Step

- Facilitate the Debriefing session. Set the frame explicitly: this is a structural and methodological review, not a personal performance assessment.
- Guide the team through the four guiding questions in sequence. Ensure each team member contributes.
- Capture all observations in written form. Structured notes are sufficient — no elaborate report is required at this stage.
- Manage time. The Debriefing should not exceed 15–30 minutes. Redirect discussions that shift into detailed analysis — that belongs in the Structured Feedback.
- Ensure the documented output is preserved and available as input for the subsequent Structured Feedback.


### Step 2: Structured Feedback

#### Purpose of the Step

The Structured Feedback is the systematic, detailed review of the activation conducted after the immediate Debriefing — typically within days, not weeks. Its purpose is to analyze the activation systematically, derive specific lessons, and define concrete improvement measures.

Unlike the Debriefing, which captures immediate impressions, the Structured Feedback is a moderated, thorough examination of the entire activation. It reviews each phase of the Problem-Solving P, the effectiveness of roles and team structures, the quality of decisions, and the accuracy of assumptions.

The Structured Feedback is facilitated by the Facilitator or, where available, by a qualified external moderator.

#### Intended Outcome

At the end of this step, the team has produced a documented record that addresses:

- **Review of the activation phases**: The team walks through the activation from Initiation through Implementation, examining each phase for adherence to the Problem-Solving P, quality of execution, and observed deviations.
- **Quality of decisions**: Which key decisions were made, on what basis, and with what outcome? Were assumptions validated? Which assumptions proved incorrect?
- **Process adherence**: Where was the Problem-Solving P followed with discipline? Where did deviations occur, and what were their effects?
- **Team and roles**: How did the leadership structure perform? Were the Owner and Facilitator roles effective? Were domain perspectives sufficiently represented?
- **Tools and infrastructure**: Did the boards, alerting systems, communication channels, and documentation processes function as intended?
- **Preparation**: What organizational readiness factors supported or constrained effective response?
- **Concrete improvement measures**: What specific actions, structural changes, procedural adjustments, or training requirements are identified based on this activation?

Improvement measures must be formulated as concrete, actionable items — not vague observations. Each measure should specify what needs to change, who is responsible for implementing the change, and by when.

The Structured Feedback output is documented and communicated to organizational leadership and the person responsible for maintaining the incident and crisis management system. Findings that require organizational response must be tracked and followed up — not archived.

#### Typical Misunderstandings and Early Deviations

**Postponing the Structured Feedback indefinitely**

Scheduling the review for "later" often means it does not happen. The Structured Feedback should take place within a few days of deactivation — close enough for detailed recall, but with enough distance for reflection.

**Restricting participation to leadership roles**

Excluding operational participants loses the most granular observations. Those who executed objectives often have the clearest view of where the process worked and where it failed. Where relevant, external resources or subordinate team members should be included.

**Producing a report instead of learning**

A written report that is archived without generating concrete action has no organizational value. The Structured Feedback must result in tracked improvement measures, not documentation for its own sake.

**Conducting the review without structure**

An unstructured discussion about "what happened" produces inconsistent coverage and tends to focus on dramatic events rather than systematic patterns. The review should follow the phases of the Problem-Solving P to ensure completeness.

**Revisiting only failures**

Analyzing only what went wrong misses the opportunity to identify and reinforce effective practices. The Structured Feedback must address both strengths and weaknesses.

**Failing to track improvement measures**

Recommendations without ownership, deadlines, and follow-up change nothing. The Structured Feedback is only as valuable as the implementation of its findings.

#### Facilitator Activities in This Step

- Facilitate or co-facilitate the Structured Feedback session. If an external moderator leads, the Facilitator contributes process observations and board documentation from the activation.
- Structure the review along the phases of the Problem-Solving P to ensure systematic coverage. Prevent the discussion from gravitating only toward dramatic events.
- Ensure that both strengths and weaknesses are addressed. Redirect conversations that focus exclusively on failures.
- Challenge vague improvement suggestions. Each measure must specify what changes, who is responsible, and by when.
- Ensure the documented output — including concrete improvement measures — is communicated to organizational leadership and the System Maintainer (the person responsible for maintaining the incident and crisis management system).
- Verify that improvement measures are assigned to responsible persons and entered into a tracking mechanism. Findings that are archived without follow-up have no organizational value.


---

# Part III — Applying the Problem-Solving P: Incidents and Crises

Part II described the Problem-Solving P as a sequence of steps. This part addresses how the same process applies to different scales of activation — from a single-domain incident to a multi-location crisis — and what changes (and what does not) as the situation grows in scope and complexity.

The central claim of this part is: **P-DRIVEN scales by nesting, not by modification.** The sequence of steps, the role structure, and the method discipline remain identical at every level. What changes is the depth of planning, the number of teams running the Problem-Solving P in parallel, and the coordination overhead between them.


## Applying P-DRIVEN to Incidents

An incident is a situation that threatens the objectives of a single organizational unit but can be managed with the resources, processes, and authority available within that unit. No cross-organizational coordination or special authority is required.

### Team Structure

The responding team is a single **Incident Management Team (IMT)**, also referred to as a Domain Response Team (DRT) in the context of a specific domain. Its minimum composition is:

- **Incident Owner** (functional lead): makes decisions, delivers the Situation Briefing, bears responsibility for outcomes.
- **Incident Facilitator** (methodological lead): moderates the Problem-Solving P, maintains the boards, enforces method discipline, holds veto rights on process violations.

Depending on the situation, the Owner may bring in **Supporters** — individuals with specific domain expertise who take responsibility for defined objectives during the Implementation Phase. Supporters are not permanent team members. They are activated on demand and released when their objectives are completed.

### How the Problem-Solving P Runs

The full Problem-Solving P runs exactly as described in Part II. No step is shortened, skipped, or combined. The difference to a crisis activation lies in:

- **Planning horizon**: hours to days, not days to weeks.
- **Iteration speed**: cycles are short. A complete Planning–Implementation–Planning cycle typically takes two to four hours.
- **Board complexity**: fewer problems, fewer objectives, fewer resources to track. The boards are leaner, but their structure is identical.
- **Team size**: typically two to four people. Coordination overhead is low.

### Activation and Deactivation

The activation of an IMT follows the Initial Assessment. The Owner determines — based on predefined criteria — whether the situation qualifies as an incident within the team's scope. If so, the IMT is formally activated and the first Situation Briefing is prepared.

Deactivation follows the same logic described in Part II under Preparation of the Situation Briefing: the Owner assesses whether the activation criteria are still met. If the situation has been stabilized, the original activation criteria no longer apply, and no further coordinated measures are required, the Owner declares the incident ended. The Facilitator holds veto rights on this decision. After deactivation, the Learning Phase (Debriefing and Structured Feedback) follows immediately.

### Escalation

If the situation exceeds the capacity of the IMT — because it affects multiple domains, overwhelms available resources, or requires authority beyond the team's scope — it escalates to crisis level. The escalation follows a defined handover sequence:

1. The Facilitator of the active IMT becomes the Crisis Facilitator in the newly activated CMT. Before leaving the IMT, the Facilitator hands over to the incoming IMT Facilitator: the current state of all three boards, the iteration rhythm, all documentation (photos, decisions recorded), and any open issues. The incoming Facilitator confirms readiness before the outgoing Facilitator assumes the Crisis Facilitator role.
2. The Owner of the active IMT initiates alerting for a replacement Facilitator for the IMT. The IMT pauses its current iteration if necessary until the new Facilitator is in place. An IMT without a Facilitator must not continue to run the Problem-Solving P.
3. If no IMT was active at the time the crisis is declared, the Crisis Facilitator role is filled by the first qualified person reached through the alerting system.

The transition from incident to crisis is not a break in the process. It is an expansion of the coordination structure while the Problem-Solving P continues to run.


## Applying P-DRIVEN to Crises

A crisis exists when the situation threatens the organization as a whole, or when a single organizational unit is overwhelmed beyond its own capacity to respond. Multiple problems without standard solutions exist simultaneously. The organization cannot maintain full operational capability.

### Team Structure

The responding structure consists of two levels:

- A **Crisis Management Team (CMT)** that coordinates across domains.
- One or more **Domain Response Teams (DRTs)** that execute within their respective domains.

The CMT is organized as a dual leadership structure:

- **Crisis Owner**: overall decision authority, liaison to executive leadership.
- **Crisis Facilitator**: methodological authority, process moderation, veto rights.

The CMT is complemented by **Domain Owners** — one per domain. Each Domain Owner is the **same person** who serves as the Owner of the corresponding DRT. This personal identity across levels is a structural design principle, not a convenience. It eliminates a communication interface that would otherwise require explicit management.

The CMT may include temporary **consultants** for specific expertise (legal, psychological, technical). These contribute to situation assessment and decision quality but do not hold standing roles.

![*CMT with Consolidated Domains — Domain Owner Structure in Crisis Configuration*](svg/cmt-consolidated.pdf){width=90%}

### How the Problem-Solving P Runs

Both the CMT and each active DRT run their own Problem-Solving P. These cycles are **nested and interlocked**:

- The CMT runs a Problem-Solving P cycle at the strategic coordination level. Its Board 3 contains objectives allocated to domains — not the internal tasks of those domains.
- Each DRT runs a Problem-Solving P cycle at the domain-specific execution level. Its Board 3 contains the internal objectives derived from the CMT's allocation.
- The Domain Owner carries objectives from the CMT into the DRT and carries status feedback from the DRT back into the CMT — within the same person.

The CMT does not see or manage the internal boards of the DRTs. It allocates objectives, receives status, and iterates its own plan. The DRTs do not decide independently on matters that affect other domains or the organization as a whole. They execute within their scope and escalate through their Domain Owner when scope is exceeded.

![*Interlocked Problem-Solving P cycles — CMT and DRT cycles in hierarchical coordination*](svg/interlocked-ps.pdf){width=90%}

### Planning Horizon and Iteration

The CMT typically operates on a planning horizon of days to weeks. Its iteration cycles are longer than those of the DRTs. A CMT planning cycle may span several DRT cycles.

The DRTs operate on a shorter horizon — hours to days — and iterate faster. They may complete multiple Problem-Solving P cycles while the CMT is still within a single Implementation Phase.

This difference in cycle speed is expected and by design. It does not require synchronization of cycles. The synchronization point is the Domain Owner, who updates the CMT at each CMT planning cycle with the current state of the DRT.

### Activation of DRTs

DRTs are not activated automatically with every crisis. Their activation is demand-driven. The Domain Owner in the CMT assesses — based on the objectives allocated to their domain — whether additional personnel, organizational, or specialist support is required. If so, the Domain Owner independently establishes a DRT.

If a DRT was already active before the CMT was established (e.g., from an escalated incident), the Domain Owner decides after CMT activation whether the DRT remains necessary or whether its tasks should be transferred to other structures.

### Deactivation

The Crisis Owner declares the end of the crisis during a Situation Briefing, subject to the Facilitator's veto right. All open objectives and remaining problems are explicitly handed over to the regular organization. The Learning Phase follows immediately.

DRTs may be deactivated before the CMT if their domain-specific objectives are resolved. The decision lies with the respective Domain Owner.


## Scaling the Same Logic: Differences in Depth, Not in Sequence

The transition from incident to crisis changes the coordination structure, the team size, the planning horizon, and the number of parallel Problem-Solving P cycles. It does not change the sequence, the roles, the boards, or the method.

| Dimension | CMT (Crisis) | IMT (Incident) | DRT (Domain within Crisis) | ORT (Operational Response Team) |
|---|---|---|---|---|
| Sequence of the Problem-Solving P | Identical | Identical | Identical | Identical |
| Role structure | Crisis Owner + Crisis Facilitator + Domain Owners | Owner + Facilitator | Owner + Facilitator | Owner + Facilitator |
| Board structure | Board 1, 2, 3 | Board 1, 2, 3 | Board 1, 2, 3 | Board 1, 2, 3 |
| Planning horizon | Days to weeks | Hours to days | Hours to days | Hours |
| Iteration speed | Hours to a day | Hours | Hours | Hours |
| Parallel Problem-Solving P cycles | One | One | One per DRT | One per ORT |
| Link to level above | — | — | Domain Owner in CMT | Supporter in DRT becomes ORT Owner |
| Coordination overhead | Minimal | Managed through Domain Owner | Managed through personal identity chain | Managed through personal identity chain |

The table shows three levels, but the pattern does not stop at three. Each level can establish ORTs below it, following the same structural logic. An ORT under a DRT may itself activate a further ORT — for example, when a location-level team needs to split execution across multiple facilities or work streams. At every additional level, the same principles apply: the same Problem-Solving P sequence, the same role structure, the same board logic, and the same personal identity mechanism linking it to the level above.

### The Personal Identity Principle

The structural mechanism that enables scaling without information loss is **personal identity across levels** (*Personenidentität*).

This means: the person who represents a domain in the CMT is the same person who leads the DRT for that domain. And in turn: a Supporter within a DRT can become the Owner of an Operational Response Team (ORT) established below the DRT level.

Each instance of personal identity **eliminates one communication interface**. Where two different people would need to hand off the same piece of information — with all the associated risks of delay, distortion, and loss — one person carries it within themselves from one level to the next. No handoff protocol, no translation, no lag.

This is not a convenience. It is a load-bearing structural principle. When personal identity is broken — when the Domain Owner in the CMT is not the Owner of the corresponding DRT — an explicit communication interface is created that must be actively managed, documented, and monitored. Every such interface adds overhead and risk.

The continuation of this principle follows a consistent pattern:

1. The **Domain Owner** in the CMT **is** the **Owner** of the domain's DRT.
2. A **Supporter** in the DRT can **become** the **Owner** of an ORT below the DRT.
3. At each additional level of nesting, the same pattern applies.

This is how P-DRIVEN scales structurally: not by adding coordination protocols, but by extending chains of personal identity across levels. The fewer interfaces, the less information is lost. The more levels that rely on personal identity, the more robust the coordination.

### Nested and interlocked Problem-Solving P cycles

When a CMT and one or more DRTs are active simultaneously, **multiple Problem-Solving P cycles run in parallel**. Each team runs its own complete Problem-Solving P cycle on its own boards.

The interlocking works through the Domain Owner:

- In the CMT's Planning Phase, objectives are defined and allocated to domains via Board 3.
- The Domain Owner carries these objectives into the DRT, where they become input for the DRT's own Planning Phase.
- The DRT runs its own P: Situation Briefing, Situation Assessment, Decision Taking, Objective Definition, Objective Allocation, Situation Freeze, Transmission, Processing, Follow-Up, Situation Update, Preparation — and loops back.
- Status, completions, and blockers flow back from the DRT to the CMT through the Domain Owner, who reports during the next CMT planning cycle.

The Problem-Solving P cycles at different levels do not need to be synchronized in time. The CMT may be in its Implementation Phase while a DRT is already in its next Planning Phase. The synchronization point is the Domain Owner's report at each CMT planning cycle — not a shared clock.

DRTs are authorized to re-prioritize or reschedule CMT-assigned objectives if operational conditions at the domain level require it. This authority exists because DRTs hold detail knowledge and situational awareness that the CMT does not have in real time. However, any deviation from CMT-assigned objectives is **mandatory to report** back to the CMT through the Domain Owner. The CMT must be informed of deviations, their reasons, and their anticipated effects. Silent deviation is a process violation.

### Depth of Nesting: The Pattern Continues Downward

The nesting pattern does not stop at two levels. A DRT that faces sufficient complexity within its domain may establish one or more **Operational Response Teams (ORTs)** below it. Each ORT runs its own Problem-Solving P with its own boards, its own Owner and Facilitator, and its own iteration cycle.

The mechanism is identical to the CMT–DRT relationship:

1. A **Supporter** in the DRT is assigned responsibility for a subset of objectives (e.g., a specific location, a specific technical work stream, or a specific sub-domain).
2. That Supporter **becomes the Owner** of an ORT established to handle that subset.
3. The ORT runs its own P. Its Owner reports status back to the DRT — as a Supporter in the DRT's context and as the Owner in the ORT's context.
4. If the ORT itself faces sufficient complexity, a Supporter within it can establish a further ORT — and the pattern repeats.

There is no theoretical limit to the depth of nesting. In practice, each additional level adds coordination overhead. Organizations should add levels only when the complexity at a given level exceeds what its team can coordinate with Supporters alone. The decision to establish an ORT follows the same logic as DRT activation: it is demand-driven, decided by the responsible Owner, and communicated to the level above.

#### Planning Horizons Across Levels

As the nesting deepens, the planning horizon at each level becomes shorter and the iteration cycle becomes faster. This is a structural consequence: each lower level deals with more concrete, more immediate problems and has a narrower scope of authority.

| Level | Typical Planning Horizon | Typical Iteration Cycle | Scope |
|---|---|---|---|
| **CMT** | Days to weeks | Hours to a day | Organization-wide, strategic |
| **DRT** | Hours to days | Hours | Domain-specific, tactical |
| **ORT** | Hours | Hours | Task-specific, operational |
| **Further levels** | Progressively shorter | Adapted to the level above | Progressively narrower |

The planning horizon of each level must fit within the iteration cycle of the level above. If a DRT's planning horizon extends beyond the CMT's iteration cycle, the CMT will plan its next cycle without current DRT status — which defeats the purpose of nesting. The Facilitator at each level is responsible for setting iteration timing that allows the level below to complete at least one cycle and report back before the next planning cycle begins above.

This creates a natural rhythm: the CMT sets a pace, each DRT iterates faster within that pace, and each ORT iterates faster still. The personal identity links between levels ensure that status flows upward at each synchronization point without requiring separate reporting protocols.

### Scaling Across Locations

When a crisis affects multiple geographic locations, the coordination structure must extend horizontally. This introduces a new structural element: the **Location Response Team (LRT)**.

An LRT is structurally equivalent to a DRT — it runs its own Problem-Solving P with the same role structure (Owner + Facilitator) and the same board logic. The difference is that its scope is defined geographically rather than functionally.

#### Two Approaches to Geographic Scaling

There are two structural options for establishing LRTs. Organizations must decide which approach to use based on available personnel and the nature of the situation.

**Option 1: Domain-Specific LRTs (Recommended)**

Each affected domain establishes its own LRT at each affected location. The IT domain, for example, would have a dedicated IT-LRT at Location A and another at Location B.

This approach preserves the personal identity chain:

- The Domain Owner IT in the CMT **is** the Owner of the IT-DRT.
- A Supporter in the IT-DRT **becomes** the Owner of the IT-LRT at Location A.
- The IT-LRT at Location A reports through its Owner back to the IT-DRT, which reports through the Domain Owner IT back to the CMT.

Each communication link is carried by personal identity. No translation, no intermediary.

**Advantages:**

- Clean domain accountability at every level.
- No information loss through cross-domain translation.
- Consistent with the existing DRT nesting logic — no new structural element required.
- Domain Owners in the CMT receive direct functional reporting from every location.

**Disadvantage:**

- Requires more personnel. Each domain at each location needs at minimum an Owner and a Facilitator.

**Option 2: Cross-Domain LRTs (Resource-Constrained Deviation)**

A single LRT per location handles all domain activities at that location. The LRT Owner represents the entire location in the coordination structure.

This approach breaks the personal identity chain between Domain Owners and location-level execution. The LRT Owner is a geographic coordinator, not a domain specialist. Information must be translated between functional and geographic perspectives.

To compensate, **Domain Owners must be explicitly allocated to locations** for structured reporting. Each Domain Owner receives status reports from the LRTs for their functional area, but through the intermediary of the LRT Owner rather than through a direct personal identity link.

**Advantages:**

- Lower personnel requirement. One LRT per location, regardless of the number of affected domains.
- Single interface per location for the coordination structure.

**Disadvantages:**

- Breaks the personal identity principle. Each LRT-to-Domain-Owner link becomes an explicit communication interface that must be managed.
- Information loss and translation distortion are structural risks.
- The LRT Owner must be cross-functionally competent — a significantly higher qualification requirement.
- Domain Owners bear a dual burden: CMT function plus location reporting.

**Assessment:**

Option 1 is the approach consistent with P-DRIVEN's structural logic. It scales the existing nesting pattern without introducing new elements or interfaces. Organizations that can staff domain-specific LRTs should do so.

Option 2 is a resource-driven compromise. It is not a variant of P-DRIVEN but a **deliberate deviation** from the structural logic that accepts specific risks in exchange for lower personnel requirements. Organizations choosing Option 2 must explicitly manage the interfaces that the personal identity principle would otherwise eliminate. The burden of proof for the effectiveness of this deviation lies with the organization that adopts it.


## Common Pressure Points When Scaling Up

Scaling from an incident to a crisis — or from a single-location to a multi-location crisis — introduces coordination challenges that do not exist at the IMT level. These are not failures of the method but consequences of increased complexity. Recognizing them early prevents structural erosion.

### The CMT Takes Over Operational Decisions

When the CMT begins making decisions that belong to the DRTs — specifying how objectives should be achieved rather than what objectives to pursue — the domain teams lose their operational autonomy. The CMT's planning cycle is too slow for operational detail. Decisions that require domain-level situational awareness must remain at the domain level.

The indicator is clear: if the CMT's Board 3 contains tasks rather than objectives, it has crossed the boundary. The CMT defines *what* needs to be achieved and *by when*. The DRT decides *how*.

### DRTs Stop Reporting or Report Around the Domain Owner

When DRT members communicate directly with the CMT — bypassing their Owner, who is the Domain Owner — the structured information flow breaks down. The CMT receives unfiltered, unstructured input that it cannot process within its own planning cycle. Simultaneously, the Domain Owner loses situational awareness of their own domain.

All reporting from a DRT to the CMT passes through the Domain Owner. This is not bureaucracy. It is the mechanism that keeps information consistent across levels.

### Domain Owners Leave the CMT During the Planning Phase

Domain Owners are simultaneously the Owners of their DRTs. During the CMT's Planning Phase, they must be present in the CMT. During the CMT's Implementation Phase, they shift to managing their DRTs.

When Domain Owners leave the CMT during its Planning Phase to handle domain-level issues, the CMT loses the perspective it needs for informed decision-making. The Facilitator must enforce presence discipline: during CMT planning, Domain Owners are in the CMT. Period.

### P Cycles Are Not Aligned Between Levels

The CMT and its DRTs do not need to run synchronized cycles. However, the CMT must schedule its own planning cycles with awareness of DRT cycle timing. If the CMT begins a new Planning Phase before DRTs have had time to process and report on their current objectives, the CMT will plan on outdated information.

The Facilitator manages this by setting Situation Briefing times that allow Domain Owners to bring current DRT status into the CMT.

### Boards Are Mixed Between Levels

When DRT-internal tasks appear on the CMT's Board 3, or when CMT-level objectives appear on a DRT's Board 1, the separation of coordination levels collapses. Each team maintains its own boards. The CMT's Board 3 tracks objectives allocated to domains. The DRT's Board 3 tracks objectives allocated to resources within the domain. These are different levels of abstraction and must not be combined.

### Uncontrolled Activation of DRTs or LRTs

If DRTs or LRTs are established without clear activation decisions — because "it seems like we need one" — the CMT loses track of its own coordination structure. Every team activation is a deliberate decision by the responsible Domain Owner, documented and communicated to the CMT. Teams are activated when needed and deactivated when their objectives are complete.

### Geographic Scaling Without Structural Clarity

In multi-location crises, the most common failure is ambiguity about which structural option is in use. If some locations have domain-specific LRTs while others have cross-domain LRTs, and the CMT has not explicitly defined the reporting structure, information will be incomplete, inconsistent, and late.

Before establishing LRTs, the CMT must decide: domain-specific or cross-domain? The decision applies to all locations. Mixed structures create coordination gaps that are difficult to detect and impossible to manage under pressure.

### Personal Identity Chain Is Broken Without Compensation

When the person in the CMT is not the person leading the corresponding DRT — due to personnel constraints, shift changes, or organizational decisions — a communication interface is created. If this interface is not explicitly managed (defined reporting intervals, documented handoffs, clear escalation paths), information will degrade at every level transition.

Every break in the personal identity chain must be identified, acknowledged, and compensated with explicit coordination mechanisms. Silent breaks — where two different people assume the other is handling the interface — are among the most common causes of coordination failure in scaled activations.


---

# Part IV — Supporting Elements and Working Aids

P-DRIVEN is designed to function with minimal infrastructure. The method itself — the Problem-Solving P, the Three-Board Method, the role structure — requires no specialized software, no proprietary tools, and no elaborate documentation systems. This is deliberate. In an incident or crisis, the systems an organization normally relies on may be impaired, compromised, or unavailable. Any method that depends on specific technology to function is fragile precisely when it is needed most.

The guiding principle is: **method before technology**. The structured process and the competence of the people executing it are the primary assets. Tools support the method — they do not constitute it.

This part describes the minimal working aids that support effective application of P-DRIVEN, how documentation is handled without creating additional overhead, how method discipline is maintained under stress, and how P-DRIVEN interfaces with existing organizational structures.


## Minimal Working Aids and Their Purpose

Working aids in P-DRIVEN serve three functions: information capture, information visualization, and communication. They do not introduce new processes. They support the processes already defined by the Problem-Solving P and the Three-Board Method.

The working aids described in this section are scoped toward the needs of organizations managing IT-related incidents and organizational crises. Organizations operating in non-IT contexts (e.g., logistics, facility management, public administration) should treat items beyond the three boards and basic communication equipment as context-dependent rather than mandatory. The core requirement in any context is: shared visual workspace (the three boards), reliable independent communication, and a dedicated coordination space.

### The Three Boards

The Three-Board Method is the primary working aid. It requires:

- Three writable surfaces (whiteboards, flipcharts, or equivalent) — one for each board.
- Moderation cards (index cards, sticky notes, or magnetic cards) in sufficient quantity.
- Markers in multiple colors.
- Magnets or adhesive materials to attach cards to surfaces.

The boards must be large enough for the team to read from a normal working distance. They must be located in the coordination space where the team conducts its Planning Phase.

Digital equivalents (shared screens, collaboration tools) may be used if and only if they meet the same requirements: visible to the entire team simultaneously, editable in real time, and operable without dependence on the organization's primary IT infrastructure. If the organization's network is part of the problem, digital boards are not available. Physical boards have no dependencies.

### Communication Equipment

P-DRIVEN teams must be able to communicate with each other, with resources executing objectives, and with the regular organization. Communication equipment must be **independent of the infrastructure that may be affected by the incident or crisis**.

This typically includes:

- **Dedicated mobile phones** with separate numbers and SIM cards (prepaid), not the team members' personal or corporate devices. Corporate devices continue to receive routine calls, emails, and notifications that consume attention and create cognitive load. Dedicated devices ensure that only crisis-relevant communication reaches the team.
- **Dedicated email accounts** at a provider independent of the organization's primary email system. If the organization's email is compromised or unavailable, crisis communication must continue.
- **A mobile internet connection** (e.g., LTE/5G router with prepaid SIM) independent of the organization's network infrastructure.
- **An alerting system** capable of multi-channel notification (app, SMS, voice call), availability confirmation, automated conference calls, and escalation logic. The alerting system must function independently of the organization's internal communication infrastructure.

Optional but recommended:

- **PMR radios** (walkie-talkies) for local communication when mobile networks are unavailable or overloaded.
- **A standby website** hosted with a separate provider, prepared in maintenance mode, activatable on short notice for external communication when the organization's primary web presence is unavailable.

### The Coordination Space

The coordination space is the physical (or virtual) room where the team conducts its Planning Phase. Requirements:

- Space for the full team (typically up to seven people).
- The three boards, visible and accessible.
- A table for working and briefing.
- Sufficient power supply, preferably with an uninterruptible power supply (UPS) or a portable power station.

During the Implementation Phase, team members leave the coordination space to work on their objectives separately. The Facilitator remains. This means the organization needs at minimum one additional workspace where the Owner can work undisturbed.

The coordination space must be protected from interruption. External visitors, routine inquiries, and uninvolved staff must be kept out during an activation. Clear signage ("Do Not Enter — Activation in Progress") is a simple but effective measure.

### Documentation Equipment

- A **camera** (smartphone is sufficient) for photographic documentation of the boards at defined points in the process (Situation Freeze, Preparation of the Situation Briefing).
- **Notebooks and pens** — fresh ones for each activation. If notes must later be surrendered to authorities, insurers, or legal counsel, using a dedicated notebook prevents loss of everyday records.
- A **printer** for producing and distributing written instructions, if needed.

### Laptops

Dedicated laptops, independent of the organization's domain infrastructure (e.g., Active Directory), ensure that the team remains capable of working even if the organization's IT systems are compromised. These do not need to be high-end devices. Refurbished hardware is sufficient. They must be configured with:

- An operating system that boots independently.
- Basic office software.
- Access to the dedicated email accounts.
- A password manager containing administrative credentials, SSH keys, certificates, and other access data required for incident response. The password database must be stored encrypted and accessible independently of the organization's systems (e.g., on an encrypted USB drive or a separately hosted cloud storage).

### Administrative Access

The team must have immediate access to administrative accounts for critical systems. This includes domain administrator credentials, SSH keys, certificates, and any access data needed to execute recovery measures. These must be stored securely but accessibly — in an encrypted password manager on a medium the team can reach without depending on the systems that may be affected.

### What Is Not Needed

P-DRIVEN does not require:

- Specialized crisis management software. Software can support, but must not constitute the method. Dependence on specialized tools creates fragility and training overhead for a process that is activated infrequently.
- Elaborate documentation templates. The boards and photographic documentation provide the record.
- A dedicated permanent crisis room. Any meeting room that meets the spatial requirements can serve as the coordination space.

The total cost of equipping a P-DRIVEN team with the necessary working aids is modest — typically a few thousand euros for physical equipment, communication devices, and basic IT hardware. This is not an investment in technology. It is an investment in independence from technology that may fail.


## Documentation Without Bureaucracy

One of the most common objections to structured processes is the perceived documentation burden. P-DRIVEN addresses this through **integrated documentation**: the method itself produces the documentation as a byproduct of its execution. No separate documentation role is required.

### How Documentation Is Produced

The documentation of a P-DRIVEN activation consists of:

1. **Photographic records of the boards** taken at two defined points in each cycle:
   - At the **Situation Freeze**, when the Planning Phase is complete and the boards represent the current plan.
   - At the **Preparation of the Situation Briefing**, when Board 3 reflects the current execution state before the next planning cycle begins.

2. **The alerting system log**, which records activation times, availability confirmations, and initial communication.

3. **Written task transmissions** (email or equivalent), which document what was assigned to whom, with what scope, and by when.

4. **The Debriefing notes** and **Structured Feedback report**, which capture observations and improvement measures after deactivation.

This set of records — board photos, alerting logs, task transmissions, and learning phase documentation — provides a complete, reconstructable account of the activation without requiring anyone to sit and take minutes.

### The Facilitator's Role in Documentation

The Facilitator is responsible for:

- Ensuring that photographic documentation happens at the defined points.
- Maintaining Board 3 as the authoritative execution tracking instrument.
- Documenting the Debriefing output.
- Ensuring that the formal activation and deactivation decisions are recorded (time, participants, basis).

This is not a secretarial function. It is part of the Facilitator's process responsibility. The documentation is a consequence of method discipline, not an additional task.

### What Not to Document

Avoid:

- Verbatim minutes of discussions. The boards capture decisions, not deliberations.
- Detailed logs of every phone call or status update. The board state at defined points captures the aggregate.
- Retrospective report writing during the activation. The documentation is produced in real time through the method. Post-hoc narratives are produced, if at all, during the Structured Feedback.

The goal is a documentation trail that is **sufficient for reconstruction, accountability, and learning** — not a comprehensive archive of everything that happened. Every hour spent on documentation during an activation is an hour not spent on problem-solving.


## Maintaining Method Discipline Under Stress

The Problem-Solving P is designed for situations where cognitive load is high, information is incomplete, and time pressure is real. The method works precisely because it constrains behavior in ways that prevent common stress-induced errors. But the same stress that makes the method necessary also makes it harder to follow.

### Why Discipline Erodes

Under stress, experienced practitioners tend to revert to intuition-based decision-making. This manifests as:

- **Skipping the Situation Assessment** ("We already know what the problems are").
- **Jumping to solutions** before problems are assessed and prioritized ("Let's just do X, we've seen this before").
- **Abandoning the boards** ("We don't have time for this, let's just talk it through").
- **Collapsing the dual leadership** ("The Facilitator can handle the boards, I'll make the decisions and communicate them directly").
- **Extending the Planning Phase** indefinitely because the team wants more information before committing to objectives.

Each of these shortcuts feels efficient in the moment. Each degrades coordination quality, decision traceability, and team alignment. The Facilitator's role, veto rights, and process enforcement responsibilities — as described in Part I and throughout Part II — exist precisely to counter these tendencies. Under stress, the Facilitator's process authority is not diminished. It becomes more important.

### The 80-Percent Principle

A recurring challenge in crisis management is the pursuit of complete information before acting. In practice, complete information is never available. Decisions in incidents and crises are always made under uncertainty.

P-DRIVEN embeds this reality structurally: the iterative cycle means that every decision is revisited in the next planning cycle. An 80-percent solution now is better than a 100-percent solution that arrives too late. The team acts on the best available information, observes the results, and adjusts in the next iteration.

This does not mean acting recklessly. It means accepting that imperfect action within a structured process produces better outcomes than delayed action based on the hope of perfect information.

### Training and Qualification

Method discipline under stress cannot be achieved through reading alone. It requires practice.

- **Facilitators** require the most intensive qualification. They must be able to enforce the process under pressure, manage group dynamics, moderate structured problem-solving, and exercise their veto right against senior personnel. This is a distinct skill set that must be trained through exercises.
- **Owners** must understand the Problem-Solving P well enough to follow it without resistance and to recognize when they are deviating from it. They must trust the Facilitator's process authority.
- **Supporters** must understand the board logic, the reporting structure, and their own scope of authority.

Regular exercises — at minimum twice per year for each role — are essential. (For exercise formats and program design, see Part VI, Chapter 2, Step 5.) Exercises are not optional enrichment. They are the mechanism through which the method becomes executable under real conditions.

*P-DRIVEN: Workbook* provides understanding. Exercises provide competence. Both are necessary; neither is sufficient alone.

A dedicated P-DRIVEN training and exercise program — covering qualification curricula, exercise formats, scenario design, and competency assessment — is available separately. It is not part of this workbook. For details, see [p-driven.org](https://p-driven.org).


## Interfaces to Existing Organizational Structures

P-DRIVEN does not replace an organization's existing management structures. It activates alongside them when a situation exceeds routine capacity. This creates interfaces that must be managed explicitly.

### Relationship to Executive Leadership

The executive leadership (board, C-level, managing directors) retains overall responsibility for the organization, including during an incident or crisis. The P-DRIVEN team structure operates as a **special organizational structure** under the authority of executive leadership.

The Crisis Owner acts as the executive leadership's delegate for the operational management of the crisis. The Crisis Owner:

- Acts on behalf of executive leadership.
- Represents their strategic interests in the operational process.
- Ensures that decisions are coherent, situation-appropriate, and enforceable.

Executive leadership is not embedded in the P-DRIVEN team structure. During a crisis, executive leadership handles non-delegable tasks: representation toward regulators, boards, political stakeholders; strategic communication; and protection of the organization's overall interests. This separation prevents executive leadership from becoming operationally overloaded and protects the operational process from strategic interference.

The interface is structured: the Crisis Owner provides decision proposals to executive leadership and receives strategic guidance. Executive leadership does not participate in the Planning Phase or intervene in operational board decisions.

### Relationship to the Regular Organization

During an activation, the P-DRIVEN team structure and the regular organization operate in parallel. The regular organization continues to function in all areas not affected by the incident or crisis. The interfaces are:

- **Domain Owners** link the P-DRIVEN structure to the regular organization's functional areas. They carry information in both directions: situation status from the P-DRIVEN structure to the regular organization, and operational reality from the regular organization into the P-DRIVEN structure.
- **Supporters** are drawn from the regular organization. Their temporary assignment to the P-DRIVEN team must be communicated to and accepted by their regular line management. This requires organizational policies that explicitly authorize the release of personnel for incident or crisis duty.
- **Handover at deactivation**: when the activation ends, all open objectives and remaining problems must be explicitly handed back to the regular organization. This handover is the Owner's responsibility and must be documented. Open items that are not handed over will not be addressed.

### Relationship to Existing Plans and Procedures

Organizations typically maintain various plans: business continuity plans, disaster recovery plans, scenario-specific playbooks, communication plans. P-DRIVEN does not replace these. It provides the **decision-making and coordination framework** within which these plans are activated, adjusted, or abandoned.

A playbook describes what to do in a specific scenario. P-DRIVEN describes how to decide what to do when the scenario is unclear, when multiple scenarios overlap, or when the playbook does not cover the situation. The two are complementary:

- During the Situation Assessment, known playbooks may inform the problem identification.
- During Decision Taking, established procedures may be one of the evaluated solution strategies.
- During Objective Definition, playbook-defined actions may become objectives on Board 3.

But the Problem-Solving P governs. If the playbook conflicts with the team's assessment of the situation, the team's assessment takes precedence. Playbooks are aids, not mandates.

### Organizational Preconditions

For P-DRIVEN to function effectively, certain organizational preconditions must be in place:

- **Authority framework**: the special organizational structure must have defined authorities — including budget authority for ad-hoc expenditures, directive authority over personnel involved in the activation, and the authority to make decisions without the usual approval chains.
- **Personnel release policy**: exercises and activations require personnel to be released from regular duties. This must be organizationally sanctioned, not negotiated case by case.
- **Exercises have equal standing with real activations**: organizational policy must treat exercise participation as a core duty, not as an interruption of "real work."
- **Culture of early activation**: alerting the team must not be treated as an accusation or a sign of failure. Organizations must actively encourage early activation and treat every alert as an expression of responsibility.
- **Annual review**: the system — roles, plans, equipment, contact data — must be reviewed at least annually. Event-driven reviews follow every real activation, every exercise, and every significant structural change in the organization.

These preconditions are not part of P-DRIVEN itself. They are the organizational soil in which P-DRIVEN can take root. Without them, the method exists on paper but cannot be executed when it matters.


---

# Part V — Typical Errors, Dilution Patterns, and Misuse

P-DRIVEN is not a self-executing system. Its value depends on the fidelity with which it is applied. In practice, certain failure patterns recur across organizations and activations. Understanding them is not optional enrichment — it is part of operational preparation. A team that can name these patterns is more likely to catch them in real time.

This part describes the most common ways P-DRIVEN fails in practice: through sequence violations, method mixing, planning pathologies, and structural role confusion. Where Part II describes step-specific misunderstandings at the point of occurrence, this part addresses systemic patterns that span multiple steps or affect the operating model as a whole.


## Breaking the Sequence

The Problem-Solving P is a sequential process. Its phases and steps follow a defined order for structural reasons: each step produces outputs that the next step requires. Situation Assessment produces the problem list that Situation Evaluation prioritizes. Prioritization produces the inputs that Decision Taking works on. Decision Taking produces the solution strategy that Objective Definition translates into concrete assignments. Skipping or rearranging steps does not save time — it invalidates the outputs downstream.

### Jumping to Solutions

The most common sequence break is jumping from Situation Briefing directly to solution discussion. The team hears the current situation and immediately begins discussing what to do. The Situation Assessment and Situation Evaluation are skipped. As a result:

- Not all problems are visible. The team works on the problems that were mentioned first or most loudly — not necessarily the most important ones.
- No prioritization has occurred. The team treats all mentioned problems as equally urgent.
- No structural evaluation of solution strategies has been performed. The "obvious" solution is pursued without considering alternatives.

The shortcut feels efficient. Under stress, the first solution that comes to mind has a powerful pull — especially when that solution has worked in a similar situation before. This is precisely the cognitive trap the structured sequence is designed to prevent. Experienced practitioners who have "seen this before" are at higher risk of this error, not lower.

### Skipping the Situation Assessment Entirely

A related pattern is declaring the Situation Assessment unnecessary because "we already know what the problems are." This typically occurs in recurring incidents or situations where a single dominant problem is obvious. The error is that collateral problems — the ones that will complicate execution — are not surfaced. The dominant problem absorbs all attention; the secondary problems compound undetected until they escalate.

### Abandoning the Boards Mid-Activation

Teams under sustained pressure sometimes abandon the boards partway through an activation. The first few cycles use the boards; as fatigue and time pressure build, the team reverts to verbal coordination. When this happens, the shared documented state disappears. Each person retains their own mental model of the situation. Coordination gaps open silently. The next iteration — if it happens at all — lacks the documented basis it requires.

Once the boards are abandoned, there is no clean path back without a deliberate reset. The Facilitator must call this explicitly, re-establish the board state from available information, and restart the formal process.

### Condensing Multiple Steps Into One

Under pressure, teams sometimes attempt to run Situation Assessment, Evaluation, and Decision Taking simultaneously — presenting the problem, evaluating it, and deciding the solution in a single discussion. This collapses three structurally distinct steps, each requiring different cognitive modes, into one undifferentiated conversation. The result is that the outputs of each step are not reliably produced. Problems are not fully collected because discussion moves immediately to evaluation. Evaluations are not independent because decision preferences already influence them.

The sequence is not bureaucracy. It is the mechanism by which the process produces reliable outputs under cognitive load.


## Mixing P-DRIVEN with Other Methods

Organizations often operate under multiple frameworks simultaneously — governance frameworks, agile practices, ITSM processes, or ad-hoc crisis protocols they have used in the past. When a P-DRIVEN activation begins, these frameworks do not disappear. Practitioners bring their habitual patterns with them. The result is method mixing.

### Running Parallel Processes

A common pattern is activating P-DRIVEN while simultaneously running a separate war room or a parallel escalation process — typically because the P-DRIVEN activation is not yet trusted by senior stakeholders. Two structures produce two decision tracks. The P-DRIVEN team coordinates one set of measures; the parallel structure decides another. When these conflict or overlap, execution suffers.

P-DRIVEN cannot coexist with a parallel decision authority over the same scope. Either P-DRIVEN is the decision structure for the activation, or it is not. A hybrid where "the CMT runs P-DRIVEN but the executive team also makes decisions directly" is not a variant. It is a structural conflict.

### Importing Agile Rituals

Teams familiar with agile methods sometimes attempt to integrate standups, sprint reviews, or retrospectives into P-DRIVEN. These patterns are not compatible. Standups are designed for stable, ongoing work; P-DRIVEN is designed for unstable, urgent situations. The two operate on different assumptions about information flow, time horizons, and decision authority. Mixing them produces neither the flexibility of agile nor the structure of P-DRIVEN.

If an organization uses agile methods in its regular operations, P-DRIVEN replaces them during an activation. After the activation ends and the organization returns to routine, agile methods resume.

### Grafting Checklists Onto the Process

Pre-existing checklists and playbooks are useful inputs to the Problem-Solving P. They become a problem when they are treated as the process. A team that works through a checklist during the Situation Assessment is not conducting a Situation Assessment — it is checking boxes. The Situation Assessment requires active brainstorming and open problem collection. A checklist anchors attention to what was anticipated. The unanticipated problems — often the most consequential — are not on the checklist.

Use checklists and playbooks as reference material during the Planning Phase. Do not let them substitute for structured problem collection and evaluation.


## Over-Planning and Premature Solution Design

Iterative planning under uncertainty requires acting before complete information is available. This principle is a recurring source of resistance. The fear of acting on incomplete information leads to two failure patterns that, while opposite in appearance, both delay effective response.

### Extending the Planning Phase Indefinitely

The Planning Phase has a defined scope: collect problems, evaluate and prioritize, decide on a strategy, define and assign objectives. It ends when objectives have been assigned and transmitted. A common failure is extending the Planning Phase because the team wants more information before committing to a plan. Additional briefings are requested. The Situation Assessment is reopened. Decision Taking is deferred because "the situation is still developing."

In incidents and crises, the situation is always developing. The Planning Phase is not designed to produce certainty — it is designed to produce a coordinated response to the current best understanding. The iteration cycle exists precisely because the first plan will be revised. The objective is a good-enough plan now, not a perfect plan later.

The Facilitator must enforce the time boundaries of the Planning Phase. When the team has completed the defined steps and produced defined objectives, the Planning Phase ends.

### Designing Solutions During Problem Assessment

The inverse failure is premature solution design: the team begins designing solutions during the Situation Assessment, before problems have been fully collected and evaluated. This is the "let's just do X" pattern — a solution is proposed early, and the rest of the process reshapes itself around evaluating and defending that solution rather than genuinely assessing the situation.

Premature solution design is reinforced by confirmation bias: once a solution has been proposed, subsequent information tends to be interpreted as supporting it. Problems that don't fit the proposed solution are minimized. Alternatives are not genuinely explored.

The Situation Assessment must close before solution discussion begins. Any solution proposal during the Situation Assessment is out of sequence and must be parked — noted for consideration in Decision Taking, not evaluated in the moment.

### Planning to a Higher Resolution Than Required

Objectives on Board 3 must be clear and assignable. They do not need to be fully specified. A common error is defining objectives so granularly that the Planning Phase produces a project plan rather than a set of objectives. This consumes Planning Phase time, reduces the team's flexibility to adjust, and implies a degree of execution certainty that does not exist.

Objectives are assigned to people with scope and timeline. The person executing the objective is responsible for working out the details. The team plans to the level of what must be achieved and by when — not to the level of how every step is executed.


## Role Confusion and Leadership Drift

The dual leadership structure — Owner and Facilitator — is the most consistently misunderstood element of P-DRIVEN in practice. The separation of decision authority (Owner) from process authority (Facilitator) runs counter to how most organizations operate. Resistance to it manifests in predictable patterns.

### The Owner Doubles as Facilitator

The most common structural collapse is the Owner attempting to run both roles simultaneously. This typically happens when a qualified Facilitator is unavailable, or when an Owner judges that the Facilitator is too slow or too methodically rigid. The Owner begins running the boards, moderating the discussion, and making decisions at the same time.

This fails for structural reasons. Facilitation requires full attention on the process. Decision-making requires full attention on the content. Running both simultaneously degrades both. The boards are not maintained with the care they require. Decisions are made without the structured input the process is designed to produce. The veto mechanism disappears entirely.

An Owner without a qualified Facilitator should either stop the activation and obtain one, or explicitly acknowledge the deviation, document it, and understand that the quality guarantees of P-DRIVEN are compromised.

### The Facilitator Becomes a Domain Expert

The complementary failure is a Facilitator who begins contributing domain expertise during the problem-solving phases. This is particularly common when the Facilitator has deep technical knowledge of the incident domain. The Facilitator offers opinions on which problems are most critical, proposes solutions during Decision Taking, or argues for specific objectives.

When the Facilitator enters the content, process enforcement ceases. The boards receive less attention. Time discipline erodes. The structural separation that gives the Facilitator veto authority loses its legitimacy — a Facilitator with a content preference cannot objectively enforce the process.

The Facilitator may offer generalist challenges — questioning assumptions, pointing out gaps, or playing the *advocatus diaboli*. This is a legitimate and valuable contribution. But domain-specific expertise, however deep, must not become the Facilitator's primary contribution. Once the Facilitator argues for a specific technical or operational solution, role separation breaks down. If the Facilitator has domain-relevant observations, they may be offered as input through the normal process — noted on a card during the Situation Assessment like any other problem. The role itself must remain process-focused.

### Domain Owners Leaving the CMT

In a scaled activation, Domain Owners form the support structure of the CMT. They hold the connection between the CMT's strategic planning and the DRT's operational execution. When Domain Owners physically leave the CMT during the CMT's Planning Phase to manage domain-level issues directly, the CMT's situation picture becomes outdated and incomplete.

Domain Owners in the CMT are there to inform CMT decision-making and take CMT objectives back to their DRTs. They do not execute at the domain level while the CMT is in its Planning Phase. Domain-level execution happens through the DRT — via the personal identity link, the DRT Owner is the same person as the Domain Owner in the CMT only outside of the CMT's Planning Phase.

### Hierarchical Override of the Process

Organizations where rank and authority are culturally dominant sometimes experience hierarchical override: a senior person enters the coordination space, bypasses the structured process, issues direct instructions, and leaves. This happens because the Problem-Solving P is visible and deliberate — it can look slow to someone who is accustomed to directing immediate action.

The damage is structural: the boards no longer represent the authoritative picture. Objectives have been assigned outside the documented structure. The Facilitator has been bypassed. The team continues the formal process, but a parallel set of actions is now in execution outside of it.

The Crisis Owner is responsible for shielding the team from hierarchical override. The relationship to executive leadership — described in Part IV — exists precisely to provide this protection. Executive leadership acts through the Crisis Owner, not around the team structure. Any deviation from this interface should be treated as a structural incident, not absorbed silently.

---

# Part VI — Transfer and Limits of P-DRIVEN

P-DRIVEN was developed for organizations that need a reliable, scalable structure for managing incidents and crises — primarily in organizational and IT contexts. This part addresses how the method transfers to different organizational settings, what preconditions make it effective, where its boundaries lie, and when it should not be used.


## Transferring P-DRIVEN into Different Organizational Contexts

P-DRIVEN is not sector-specific. Its core — the Problem-Solving P, the Three-Board Method, the dual leadership structure, and the personal identity principle — applies wherever teams must make coordinated decisions under uncertainty with high stakes. The method has been applied in IT incident response, organizational crisis management, and multi-site operational disruptions. The underlying cognitive and structural problems are consistent across these contexts.

Transfer, however, requires deliberate adaptation. Not adaptation of the method — P-DRIVEN's principles are not negotiable — but adaptation of implementation: scale, nomenclature, interfaces, and activation thresholds.

### Scale

A large organization with multiple business units, geographic footprints, and thousands of employees requires a CMT–DRT–ORT structure with careful attention to personal identity chains and inter-level synchronization. A medium-sized company may activate only a single DRT for most incidents and only rarely need a CMT. A small organization may operate with a single team of four to six people using the Problem-Solving P without a formal multi-level structure.

The method scales down as well as up. A two-person team using a single board to work through a structured problem-solving cycle is applying P-DRIVEN. The structure is minimal but the core logic — assess situation, evaluate and prioritize, decide and define objectives, implement, learn — is preserved.

Specifically, what scales down and what does not:

- **Scales down:** The number of boards can be reduced. A small team addressing a single problem may work with one board that combines problem identification, strategy selection, and objective tracking. The number of domains can be reduced to one. The formality of the Situation Briefing can be simplified to a brief verbal summary. The iteration cycle can be shortened.
- **Does not scale down:** The dual leadership (Owner + Facilitator) is the structural minimum. A single person cannot be Owner and Facilitator simultaneously without structural compromise. The sequence of the Problem-Solving P is not negotiable regardless of team size — steps may be faster but not skipped. The veto right remains.
- **Explicitly acknowledged as degraded:** If an organization operates P-DRIVEN without a separate Facilitator, this is a deliberate deviation. The veto mechanism and process enforcement are structurally compromised. This may be an acceptable trade-off for very small teams, but it must be documented as a conscious decision, not an accidental omission.

The domain consolidation rules described in Part I (Section 5) provide additional guidance for small organizations that cannot staff all domains separately.

### Nomenclature

P-DRIVEN specifies role names and team designations based on its internal logic. Organizations with established terminology — "Incident Commander," "Gold Team," "Crisis Cell," "Core Team" — may map their terminology to P-DRIVEN's structure rather than abandoning their existing language. The mapping must be explicit and documented: which existing role corresponds to the Owner, which to the Facilitator, which to Domain Owners or Supporters.

What organizations must avoid is mapping terminology onto P-DRIVEN in ways that misrepresent the structural logic. Calling a senior executive "the Owner" when that person has no intention of following the Problem-Solving P introduces confusion without benefit. The names matter less than the structure.

### Regulatory and Compliance Contexts

Some organizations operate under regulatory requirements that prescribe specific incident management structures (e.g., ITIL-based major incident management, NIS2 obligations, sector-specific requirements). P-DRIVEN is compatible with these requirements but does not replace the formal reporting and documentation obligations they create. The activation of P-DRIVEN produces — as a byproduct of its process — documentation that supports regulatory compliance: board records, alerting logs, task transmissions, learning phase outputs.

Where regulatory frameworks prescribe specific escalation thresholds or reporting timelines, these become activation criteria and external interface requirements for the P-DRIVEN structure, not replacements for it.

### External Support and Coaching

Organizations implementing P-DRIVEN for the first time should not expect to be fully operational from the first exercise. The method requires practiced competence, particularly in the Facilitator role. Reading *P-DRIVEN: Workbook* produces understanding. Exercises under realistic conditions produce competence.

Where qualified internal Facilitators are not yet available, engaging an external methodological coach for initial exercises and the first real activations is strongly recommended. An external Facilitator can run the process while internal staff observe and develop their own competence. This is a transitional measure, not a permanent delegation. The goal is organizational self-sufficiency in the method.


## Implementation Roadmap

Introducing P-DRIVEN is a project. It requires a mandate, defined responsibilities, resources, and a structured sequence of steps. The following roadmap describes the typical path from the decision to implement to operational readiness. It is derived from practical implementation experience and follows the principle that an organization should be able to respond to incidents from the day it begins structuring its incident and crisis management — not only after months of preparation.

The roadmap is not a rigid plan. Organizations differ in size, maturity, and risk profile. But the sequence matters: each step builds on the outputs of the previous one. Skipping steps creates gaps that surface during the first real activation.


### Step 1: Mandate and Project Initiation

Implementation begins with an explicit mandate from executive leadership. Without this mandate, the project lacks the authority to define roles, assign personnel, allocate budget, and establish the special organizational structure that P-DRIVEN requires.

The mandate must cover:

- **Objective**: establish a functioning incident and crisis management capability based on P-DRIVEN.
- **Resources**: financial budget (equipment, training, external coaching), personnel (time allocation for project lead, future role holders, and exercise participants), and a realistic timeline.
- **Project lead**: a named person responsible for driving the implementation. This person does not need to come from IT or operations — the role requires organizational competence, access to executive leadership, and the ability to coordinate across domains. In many organizations, this person will later assume the System Maintainer role (see below).
- **Authority**: the project lead must have the authority to request input from all domains and to propose structural decisions (role assignments, authority frameworks, domain boundaries) to executive leadership.

The mandate is not a formality. It is the organizational commitment that separates a documented intention from an executable project. Without it, implementation stalls at the first resource conflict.

**Output of this step:** Written project mandate with objective, resources, project lead, and timeline.


### Step 2: Define Structures and Assign Roles

The first operational step is to establish the team structure and assign roles. This means:

1. **Define team levels**: Determine which team levels the organization requires. Most organizations start with a single DRT for their most critical domain (typically IT). A CMT is added when the organization's risk profile includes scenarios that affect multiple domains simultaneously. ORTs and LRTs are added only when complexity demands it.

2. **Define domains**: Map the organization's functional structure to the standard domains (Operations, IT, HR, Finance & Administration, Communications, optionally Sales). Consolidate where personnel constraints require it, following the rules described in Part I.

3. **Assign roles**: For each team level, assign the Owner and Facilitator roles. Identify at least two persons per role to ensure availability through redundancy. Assign Domain Owners for the CMT. Identify potential Supporters for each DRT.

4. **Document role profiles**: Create role profiles (based on the profiles in Part I of *P-DRIVEN: Workbook*) that include responsibilities, authorities, competency requirements, and contact data. These profiles must exist in written form — accessible during an activation without depending on the organization's primary IT systems.

5. **Define the authority framework**: Establish the authorities for the special organizational structure: budget limits for ad-hoc expenditures, directive authority over personnel, decision autonomy, and the interface to executive leadership. These authorities must be formally approved by executive leadership before the first exercise.

6. **Define activation criteria**: Establish clear, predefined criteria that trigger an alert. Activation criteria must be unambiguous enough that the person receiving the initial report can decide whether to alert — without needing to consult a manager first.

**Output of this step:** Documented team structure, assigned roles with role profiles, approved authority framework, defined activation criteria.


### Step 3: Establish the Problem-Solving P

With structures in place, the team learns and practices the Problem-Solving P:

1. **Familiarization**: All role holders read *P-DRIVEN: Workbook*. The Facilitator reads it completely; Owners focus on Parts I, II, and III; Supporters focus on Parts I and II.

2. **First tabletop exercise**: A low-pressure walkthrough of the complete Problem-Solving P using a simple scenario. The objective is not scenario realism but process familiarity: Can the team execute the sequence? Do participants understand their roles? Does the Facilitator maintain the boards? This exercise reveals the most basic gaps and misunderstandings.

3. **External coaching** (recommended): For the first exercises, engage a qualified external Facilitator who runs the process while internal Facilitators observe. This accelerates competence development and prevents the team from developing incorrect habits that are difficult to correct later.

4. **Iteration**: Repeat exercises at increasing complexity. Each exercise is followed by a Debriefing and Structured Feedback session that feeds improvements back into the process and the role understanding.

*P-DRIVEN: Workbook* provides understanding. Exercises provide competence. Both are necessary; neither is sufficient alone. An organization that reads *P-DRIVEN: Workbook* but never exercises will fail at the first real activation — not because the method is wrong, but because untrained execution under stress reverts to intuition.

**Output of this step:** Team has completed at least one tabletop exercise. Facilitators have practiced moderating the full Planning Phase. Basic process gaps have been identified and addressed.


### Step 4: Equipment and Documentation

With the process established, the organization equips itself for activation:

1. **Coordination space**: Identify and prepare the room (or rooms) where the team will conduct its Planning Phase. Requirements are described in Part IV.

2. **Boards**: Procure and install the three writable surfaces. Physical boards (whiteboards, flipcharts) are the default. Digital equivalents may supplement but must not replace them.

3. **Communication equipment**: Procure dedicated mobile phones, dedicated email accounts, a mobile internet connection, and an alerting system — all independent of the organization's primary infrastructure. Requirements are described in Part IV.

4. **IT equipment**: Procure dedicated laptops independent of the organization's domain infrastructure. Configure them with basic office software, access to the dedicated email accounts, and an encrypted password manager containing administrative credentials and access data.

5. **Documentation**: Create the two core documents:
   - *P-DRIVEN: Operational Guide* (compact reference for use during activation: process steps, role summaries, board templates, briefing structure template, Facilitator quick-reference card, task transmission forms, documentation checklists, alerting procedures, contact lists). A reference version is available at [p-driven.org](https://p-driven.org) and can be adapted to the organization's specific context.
   - An **Organizational Handbook** for incident and crisis management (structural document: authority framework, role profiles, domain definitions, activation criteria, interfaces to executive leadership and the regular organization, maintenance schedule).

6. **Playbooks**: Where the organization has identified recurring scenarios, create playbooks that describe the known response actions. Playbooks are inputs to the Problem-Solving P, not replacements for it. They are used during the Situation Assessment and Decision Taking steps as reference material. A playbook does not need to be exhaustive — a one-page summary of known actions for a specific scenario is more useful than a hundred-page document that no one reads under pressure.

**Output of this step:** Equipped coordination space, communication and IT equipment in place, *P-DRIVEN: Operational Guide* and Organizational Handbook created, initial playbooks where applicable.


### Step 5: Exercises and Continuous Improvement

The system is now structurally complete. It becomes operational through sustained exercise and maintenance:

1. **Exercise program**: Establish a regular exercise schedule. Minimum: twice per year per role. Recommended starting format:
   - **Monthly tabletop exercises** (1–2 hours): One role holder prepares a scenario; the team walks through the Problem-Solving P on paper. Low overhead, high learning value.
   - **Quarterly functional exercises** (half-day) with external coaching: Realistic scenario with time pressure, role rotation, and structured feedback. These exercises test the process under conditions closer to a real activation.

2. **Post-exercise improvement cycle**: Every exercise produces Debriefing and Structured Feedback outputs. These must be tracked and followed up — not filed. Improvements flow back into role profiles, *P-DRIVEN: Operational Guide*, playbooks, and equipment.

3. **Annual system review**: Once per year, review all components: roles and assignments, contact data, equipment functionality, activation criteria, authority framework, playbooks, and *P-DRIVEN: Operational Guide*. This review is triggered by the calendar, not by an event. Event-driven reviews follow every real activation, every exercise, and every significant organizational change.

4. **Transition to self-sufficiency**: If external coaching was used in Steps 3–5, the organization should aim for self-sufficiency within the first year. The indicator is that internal Facilitators can run a full exercise without external support and that the Debriefing produces actionable findings without external moderation.

**Output of this step:** Running exercise program, improvement cycle established, annual review scheduled.


### The System Maintainer

Implementing P-DRIVEN is a project. Maintaining P-DRIVEN is a permanent responsibility. Organizations need a named person who owns the system between activations. This role is referred to as the System Maintainer.

The System Maintainer is not an activation role. The System Maintainer does not appear in the team structure during an incident or crisis (though the person may hold an activation role in addition). The System Maintainer is the peacetime custodian of the entire incident and crisis management system.

**Responsibilities:**

- Administrative maintenance and continuous development of the incident and crisis management system
- Maintenance and updating of all documentation (*P-DRIVEN: Operational Guide*, Organizational Handbook, role profiles, playbooks, contact lists)
- Planning, execution, and follow-up of exercises
- Organization of training and qualification measures
- Regular reporting to executive leadership on the state of the system
- Advisory support to domains on incident and crisis management requirements
- Coordination of annual and event-driven system reviews
- Tracking and follow-up of improvement measures from exercises and real activations

**Authorities:**

- Access to all information and documents relevant to the incident and crisis management system
- Authority to request input and contributions from all domains
- Authority to initiate exercises and reviews based on a schedule approved by executive leadership
- Right to participate in CMT or DRT sessions during activations (as observer or in a defined activation role)
- Right to propose adjustments and improvements to executive leadership

**Competency requirements:**

- Solid knowledge of incident and crisis management, including relevant standards (e.g., ISO 22301, BSI-Standard 200-4)
- Qualification as a Facilitator (the System Maintainer should be able to fill the Facilitator role during activations)
- Systematic documentation and process maintenance capability
- Organizational and communication competence
- Ability to moderate and support exercises
- Integrity, discretion, and persistence

**Objectives:**

- Ensuring that the incident and crisis management system is current, effective, and transparent
- Fostering organizational resilience through practiced and documented processes
- Establishing a continuous improvement culture
- Contributing to risk minimization and organizational readiness

The System Maintainer is frequently the person who initiated the implementation project (Step 1). The role does not require a dedicated full-time position in most organizations — but it requires explicit assignment, protected time, and organizational backing. A System Maintainer without time and authority produces documentation, not readiness.


## Preconditions for Effective Use

P-DRIVEN cannot be effective without certain organizational and personal foundations. These are not supplementary requirements — they are structural preconditions. An organization that installs P-DRIVEN without them has a documented system, not an operational one.

### Qualified Personnel

All activation roles require qualification through exercises, not only through reading. The qualification depth differs by role — Facilitators require the most intensive preparation, Owners must internalize the process, Supporters must understand the board logic and their scope of authority. Detailed qualification requirements are described in the role profiles (Part I) and in Part IV, Section 3. Minimum exercise frequency: twice per year per role. This is not optional.

### Organizational Authorization

P-DRIVEN operates as a special organizational structure with authorities that differ from the regular organization. These authorities must be formally defined before an activation. An organization that has not pre-authorized the crisis team's budget authority, directive authority over personnel, and decision autonomy will find that every significant decision during an activation requires escalation to leadership outside the team — which negates the purpose of having a structured team.

The special organizational structure needs defined authorities, not just defined roles.

### Open Error Culture

P-DRIVEN's learning loop — Debriefing and Structured Feedback — produces improvement only if participants can report observations without fear of personal consequence. In organizations where identifying errors is treated as blame, the Learning Phase produces sanitized outputs that protect individuals but do not improve the system.

An open error culture is not a cultural luxury. It is the precondition for the learning loop to function. Without it, each activation improves nothing, and the same errors recur.

### System Maintenance

The P-DRIVEN system must be maintained between activations. Role assignments change as people leave and join the organization. Contact data becomes stale. Equipment must be tested and updated. Playbooks must be reviewed against current operational reality.

Minimum maintenance: an annual review of all roles, contact data, equipment, and plans. Event-driven reviews follow every real activation, every exercise, and every significant structural change in the organization. Maintenance that is not formally scheduled will not happen.


## Explicit Limits of P-DRIVEN

### P-DRIVEN Does Not Provide Solutions

P-DRIVEN is a decision-making and coordination framework. It provides structure for how a team processes a situation, makes decisions, and tracks execution. It does not tell the team what to do. The quality of decisions made within the Problem-Solving P depends entirely on the domain knowledge, technical competence, and situational awareness of the people using it.

An organization whose technical staff cannot solve an IT infrastructure failure will not solve it faster by using P-DRIVEN. The method improves coordination and reduces decision errors under stress — it does not supply expertise that is not present.

### P-DRIVEN Requires Sufficient Activation Time

The Problem-Solving P requires time to execute. The first iteration of the Planning Phase — including Situation Briefing, Situation Assessment, Evaluation, Decision Taking, Objective Definition, and Allocation — typically requires between 30 and 60 minutes. This is not a weakness; it is the investment that produces coordinated, traceable execution rather than fragmented, uncoordinated action. But it means that P-DRIVEN is not suitable for situations where response must be immediate and reflexive.

For immediate, time-critical first actions — initial containment measures, emergency shutdowns, first responder decisions — P-DRIVEN activates after those measures are taken, not instead of them. The method governs sustained response, not the first seconds.

### P-DRIVEN Does Not Manage the Situation for You

The boards, the structure, the iteration cycle — none of these produce an outcome without human judgment. The Situation Assessment produces a problem list only if participants think carefully and speak honestly. The Situation Evaluation produces a priority order only if the team genuinely assesses impact and urgency rather than defending their own domain's interests. Objective Definition produces actionable objectives only if the team has the clarity to define what must be achieved.

P-DRIVEN provides structure. It does not remove the requirement for clear thinking. Teams that apply the structure mechanically — going through the motions without genuine engagement — will produce the appearance of a structured process without its substance.

### Information Problems Are Not Solved by the Process

Crises are characterized by a double information problem: simultaneously too little reliable information and too much unreliable information. P-DRIVEN's iterative structure addresses this better than most alternatives — the short iteration cycles mean that decisions are regularly updated as new information arrives. But it does not resolve information scarcity. A team that cannot obtain reliable input about its situation cannot produce reliable situation assessments, however disciplined its process.

Organizations that operate in environments with poor information infrastructure — where systems do not produce usable telemetry, where key personnel are unavailable, where external dependencies cannot be quickly contacted — face this problem acutely. P-DRIVEN manages the uncertainty; it does not eliminate it.


### Empirical Basis

P-DRIVEN is based on practitioner experience and structured design reasoning, not on controlled empirical studies. Its design decisions draw on established concepts from emergency management (ICS Planning P), organizational design (dual leadership, checks and balances), and decision science (structured problem-solving under uncertainty). The method has been developed and refined through real-world application in incident and crisis management across multiple organizations.

This workbook documents the method as designed. Empirical observations, case studies, and practical implementation experience are published at [p-driven.org](https://p-driven.org).


## When Not to Use P-DRIVEN

### Situations Requiring Immediate Reflex Action

Some situations require immediate execution of pre-defined response procedures: a fire alarm triggers evacuation, a system detection alert triggers an automated containment script, a medical emergency triggers a first aid protocol. These are not situations for P-DRIVEN. They are situations for trained reflexes and pre-authorized procedures.

P-DRIVEN activates after the initial reflex action has been taken and the organization needs to assess, coordinate, and sustain a response. The distinction is important: the first 60 seconds of a datacenter fire belong to the fire response protocol. The next 12 hours belong to the incident management structure.

### Situations Fully Covered by Existing Procedures

If a situation is fully covered by an existing procedure — the playbook precisely describes the condition, the response actions are unambiguous, the responsible personnel are clearly defined, and no coordination across domain boundaries is required — then activating P-DRIVEN adds overhead without benefit. Apply the procedure.

P-DRIVEN is for situations where the applicable procedure is unclear, where multiple scenarios overlap, where cross-domain coordination is required, where the playbook doesn't fit, or where the situation exceeds the capacity of routine response. When routine capacity is sufficient, use it.

### Situations Where the Dual Leadership Cannot Be Staffed

P-DRIVEN without a qualified Facilitator is structurally degraded. If no qualified Facilitator is available and an external coach cannot be obtained, the organization faces a genuine capability gap. Proceeding with P-DRIVEN under these conditions is possible, but the veto mechanism, process enforcement, and documentation quality will all be compromised.

In this situation, the honest choice is to acknowledge the gap explicitly rather than to proceed while pretending the method is intact. Running an informal coordination structure while documenting it as P-DRIVEN produces false assurance — the documentation suggests methodological rigor that does not exist. It is better to acknowledge the compromise and work to close the capability gap through qualification.

### Routine Coordination and Regular Project Management

P-DRIVEN is designed for situations that exceed routine management capacity: elevated stakes, high uncertainty, cross-functional coordination, time pressure, and incomplete information. It is not a general-purpose coordination or project management method.

Organizations that activate P-DRIVEN for routine operational coordination, minor incidents that fall within normal response capacity, or project management tasks are misallocating attention and building poor habits. The method must remain associated with the conditions it is designed for. Overuse dilutes the signal that activation carries — if P-DRIVEN is activated constantly, the activation itself no longer communicates urgency.

Reserve P-DRIVEN for situations that genuinely require it. Keep the activation threshold meaningful.


---

# Glossary

| Term | Meaning |
|---|---|
| **Activation** | The formal declaration that an incident or crisis management structure is operational. Activation creates explicit authority, role assignments, and process discipline. It is triggered by the Initial Assessment and ends with the Owner's deactivation decision (subject to Facilitator veto). |
| **Advocatus Diaboli** | A role the Facilitator may adopt within the Problem-Solving P: deliberately challenging assumptions, questioning conclusions, and introducing alternative interpretations of the situation — without contributing domain-specific content. The intent is to stress-test the team's reasoning without compromising the Facilitator's methodological neutrality. The *advocatus diaboli* function is bounded: it ends when the challenge has been registered and does not extend to advocating for a specific course of action. |
| **Board 1 (Problem Board)** | The visual instrument used during the Situation Assessment and Situation Evaluation. It captures all identified problems as individual cards, clusters them, and prioritizes them using an Eisenhower matrix (urgency × importance). |
| **Board 2 (Strategy Board)** | The visual instrument used during Decision Taking. For each prioritized problem from Board 1, at least three distinct solution strategies are developed, evaluated, and selected. |
| **Board 3 (Execution Board)** | The visual instrument used during the Implementation Phase. It tracks all objectives with their responsible persons and statuses (open, in progress, blocked, completed). Only the Facilitator moves cards on Board 3. |
| **CMT (Crisis Management Team)** | The strategic coordination team activated when a situation exceeds the capacity of a single domain. The CMT coordinates across domains and sets strategic direction. It consists of the Crisis Owner, the Crisis Facilitator, and Domain Owners. |
| **Coordination Space** | The designated physical or virtual location where the team convenes during an activation. Equipped with boards, communication equipment, and documentation tools. The Facilitator remains in the coordination space throughout the Implementation Phase. |
| **Deactivation** | The formal declaration that the incident or crisis is ended and the activation structure is dissolved. Decided by the Owner, subject to Facilitator veto. Triggers the Learning Phase. |
| **Domain Owner** | A team member responsible for a specific functional area (e.g., IT, Operations, Communications) within the CMT. Through the Personal Identity Principle, the Domain Owner simultaneously serves as the Owner of the corresponding DRT. |
| **DRT (Domain Response Team)** | A tactical team operating within a specific domain under the coordination of the CMT. Led by a Domain Owner (who is also the DRT Owner) and a Domain Facilitator. DRTs run the Problem-Solving P independently within their domain scope. |
| **Escalation** | In P-DRIVEN, escalation refers specifically to the formal, structural transition from incident-level to crisis-level management: an IMT is escalated to a CMT when the problem scope exceeds domain boundaries or when strategic objectives are at risk. Escalation in this sense is a defined organizational event with a specific handover sequence (boards, objectives, iteration rhythm, documentation), not a general term for increasing urgency or severity. |
| **Facilitator** | The person responsible for methodological leadership. Moderates the Problem-Solving P, maintains the boards, enforces method discipline, and holds the veto right. Does not hold decision authority over content. May contribute as a generalist or *advocatus diaboli* but must not assume the role of a domain expert. |
| **Deliberate Deviation** | A deliberate departure from P-DRIVEN's defined structures, sequence, or principles. It is not a variant but an explicitly acknowledged deviation. The burden of proof for its effectiveness lies with the organization that adopts it. |
| **IMT (Incident Management Team)** | The team activated for an incident within a single domain. When no CMT exists (incident-only scenario), the IMT operates independently. Structurally identical to a DRT, but without CMT coordination above it. |
| **Iteration Cycle** | One complete pass through Planning Phase → Implementation Phase → Planning Phase. The cycle length is set during Objective Allocation and defines the rhythm of the activation. Typical duration: 2–4 hours at DRT level. |
| **LRT (Local Response Team)** | A team responsible for coordinating crisis response at a specific geographic location in multi-location crises. LRTs are subordinate to the CMT and run the Problem-Solving P independently within their geographic scope. |
| ***P-DRIVEN: Operational Guide*** | The compact, authoritative reference document for use during active incidents and crises. Contains process steps, board templates, briefing structure templates, role summaries, and checklists. Deliberately free of explanation. Available at [p-driven.org](https://p-driven.org). |
| **ORT (Operational Response Team)** | A sub-team of a DRT formed when the scope of a single domain exceeds what one team can manage. ORTs handle specific operational sub-areas and report to the DRT. |
| **Owner** | The person responsible for functional leadership. Makes decisions at defined decision points, delivers the Situation Briefing, and is accountable for outcomes. At DRT level: Incident Owner. At CMT level: Crisis Owner. |
| **Personal Identity Principle** | The structural principle that the same person serves as Domain Owner in the CMT and as Owner of the corresponding DRT. This ensures that strategic decisions and tactical execution remain connected through a single accountable person. |
| **Problem-Solving P** | The structured process at the core of P-DRIVEN. Consists of four phases: Initiation (Alerting, Initial Assessment), Planning (Situation Briefing through Objective Allocation), Implementation (Situation Freeze through Preparation of Situation Briefing), and Learning (Debriefing, Structured Feedback). Named after the P-shaped visual representation of its iterative flow. |
| **Supporter** | A person with specific domain expertise who is temporarily integrated into a DRT, LRT, or ORT to work on defined objectives. Supporters do not exist at CMT level. They have no independent directive authority unless explicitly delegated by the Owner. |
| **System Maintainer** | The peacetime role responsible for maintaining the incident and crisis management system: documentation, equipment, exercises, role assignments, and continuous improvement. Not an activation role. |
| **Three-Board Method** | The visual planning and tracking system used within the Problem-Solving P. Consists of Board 1 (problems), Board 2 (strategies), and Board 3 (objectives/execution). The three boards form a traceable chain from problem identification through strategy selection to objective tracking. |
| **Veto Right** | The Facilitator's explicit authority to block decisions or actions by the Owner that violate the established methodology, defined procedures, or formal authorities. The veto is documented and binding until the Owner provides a reasoned override that is itself documented. Specific veto situations include: skipping the Situation Assessment, skipping strategy development in Decision Taking, incomplete Objective Allocation, and premature deactivation. |