Prerequisite Tree (PRT)
Pattern: A named solution to a recurring problem.
A necessity-logic map that turns a tested injection or ambitious target into the intermediate objectives required to overcome the obstacles blocking implementation.
Also known as: PRT; prerequisite map; close relative of the intermediate objectives map.
Reasoning mode: necessity-based logic — arrows read in order to A, we must have B; multi-in-edge defaults to AND.
The Prerequisite Tree starts after a proposed solution has passed its first logic test. The Future Reality Tree may show that an injection should produce the desired effects. That still doesn’t mean the organization can implement it. The PRT asks a different question: what real obstacles prevent this future from existing, and what intermediate objectives must be achieved to remove or work around those obstacles?
Understand This First
• Future Reality Tree — the solution test whose injections usually become PRT targets.
• Necessary Cause — the logic type the PRT uses for intermediate objectives.
• Categories of Legitimate Reservations — the scrutiny discipline for PRT entities and obstacle claims.
Context
The PRT belongs in the implementation half of the Thinking Processes. The Current Reality Tree answers what to change? The Evaporating Cloud and FRT answer to what to change? The PRT starts the third change question: how to cause the change? It shows which intermediate objectives have to exist before the injection or ambitious target can be achieved.
The tool uses necessity logic. Its arrows read in order to achieve A, we must first have B. That puts the PRT on the same logic side as the Cloud and on the opposite side from the sufficiency-based CRT, FRT, and Transition Tree. The distinction matters because the PRT doesn’t claim that an intermediate objective by itself will cause the final objective. It claims the final objective cannot be reached without that intermediate objective.
In TOCICO Dictionary terms, the building block is the prerequisite-obstacle link: identify an obstacle that blocks the desired state, then identify the intermediate objective that overcomes it. Scheinkopf’s Handbook chapter makes the same point through the Cloud analogy. In a Cloud, the hidden current-reality entity under a necessity arrow is an assumption. In a PRT, the current-reality entity is an obstacle.
Problem
A team can know the right direction of solution and still fail because it skips the implementation logic. The injection is stated, the future state looks desirable, and the organization treats the remaining work as project planning. The project plan then fills with tasks: hold meetings, buy software, train staff, update measures, communicate the change. Some tasks matter, some are noise, and the plan doesn’t show which current obstacle each task is meant to remove.
The missing object is the implementation path. A serious change has obstacles: missing authority, absent data, incompatible policies, untrained people, measurement systems that punish the new behavior, dependencies between departments, or fears that aren’t yet public. If those obstacles are not named as entities in current reality, the action plan becomes a wish list. The PRT forces the team to state the path in necessity terms: in order to implement the injection, these intermediate objectives must exist, and these obstacles explain why they do not exist yet.
Forces
• The injection is easier to admire than to implement. Once the FRT has made the solution look coherent, the team wants to move directly to action. The PRT slows that move long enough to find what can block it.
• Obstacles are current-reality entities, not generic risks. “People may resist” is too broad to plan against. “Sales managers are paid on booked revenue, not delivered throughput” is an obstacle the team can test and address.
• Intermediate objectives are conditions, not tasks. “A competitive pay package is in place” is an IO. “Meet with HR” is an action that may help create it. Mixing the two turns the tree into a task list.
• Sequence matters only where necessity requires it. Some IOs can be achieved in parallel. Others must precede their parent because the parent cannot exist until they do. The PRT has to show that distinction without pretending every activity is sequential.
• The plan has to survive people who were not in the room. A PRT that only captures the builder’s intuition won’t hold. Each obstacle and each IO has to be stated clearly enough for affected managers to challenge.
Solution
Build the PRT from the desired injection or ambitious target backward through the obstacles that prevent it. For each obstacle, state the intermediate objective that would overcome it. Then map the IOs in the order required by necessity logic until the bottom of the tree reaches objectives the team can start achieving with known actions.
The construction discipline has four moves.
First, state the target as a condition, not as an activity. “Personnel develops a competitive pay package” is close to an action. “A competitive pay package for workers is in place” is a condition the tree can reason about. The same discipline applies to IOs: they are states that must exist, not meetings to schedule.
Second, list the real obstacles blocking the target. Each obstacle should be an entity in current reality. Scheinkopf’s bank example uses obstacles such as the bank not knowing local wage-rate structures, not knowing what comparable banks pay experienced staff, and lacking a clear definition of what “competitive” means. Those are not vague concerns. They are checkable facts.
Third, pair each obstacle with an IO. If the obstacle is that the bank doesn’t know local wage rates, the IO may be that the bank has current salary-survey data from the Chamber of Commerce. If management lacks a definition of competitive pay, the IO may be that management has set the entry package against comparable work and pay. The IO either eliminates the obstacle or makes the obstacle no longer block the target.
Fourth, sequence the IOs by necessity. If one IO must exist before another can be achieved, draw the dependency. If two IOs can be pursued independently, leave them parallel. The PRT is not trying to create a detailed action plan. It is trying to show the necessary conditions that must be created before the injection can be implemented.
A small PRT has this shape. The convergence at IO3 reads as the necessity default — both IO1 and IO2 are required for IO3 — without an explicit junctor:
flowchart BT
IO1["Current local wage data is available"] --> IO3["Management has defined competitive entry pay"]
IO2["Comparable bank pay levels are known"] --> IO3
IO3 --> Target["A competitive pay package for workers is in place"]
O1["Obstacle: local wage structure is unknown"] -. "overcome by" .- IO1
O2["Obstacle: peer-bank pay is unknown"] -. "overcome by" .- IO2
O3["Obstacle: competitive pay is undefined"] -. "overcome by" .- IO3
The dashed obstacle links are not actions. They explain why the IOs are needed. The solid arrows are necessity links: in order to have the target, management must first define competitive pay; in order to define competitive pay, it must first know the local and peer-bank data. The data-gathering actions belong in the Transition Tree or project plan, not in the PRT itself.
The PRT’s rare override case is the OR-junctor, used when two alternative intermediate objectives could each satisfy a single parent IO and the diagram models them as substitutes rather than jointly required. A small companion PRT shows the construct in isolation: two alternative IOs converge through an OR-junctor onto the parent IO they could each satisfy.
flowchart BT
AltIO1["Alternative IO: comparable-bank pay data is purchased from a wage-survey vendor"] --> OrParent(("OR"))
AltIO2["Alternative IO: comparable-bank pay data is gathered through a banking-association working group"] --> OrParent
OrParent --> ParentIO["Parent IO: comparable bank pay levels are known"]
classDef orjunctor fill:#A6894B,stroke:#3a2f1a,color:#fff,stroke-width:1.5px;
class OrParent orjunctor;
The first diagram is the PRT in its standard form: IO3’s default-AND reading says both upstream IOs are required, with no junctor needed. The second diagram isolates the OR-junctor for the case where two alternative IOs could each satisfy the same parent. Together, they model the convention: bare arrows where the necessity default says every named IO is required, and an explicit OR-junctor where the modeler intends any one of the named IOs is enough on its own. The OR-junctor is rare in PRTs because most implementation paths have IOs that are jointly required. It appears when implementation can take alternative routes to satisfy the same prerequisite.
How It Plays Out
Scheinkopf’s bank case shows the PRT immediately after the CRT, Cloud, and FRT have done their work. The CRT had converged on a pay-structure problem behind teller turnover, poor service, customer complaints, and customer attrition. The Cloud had resolved the budget conflict by moving money from hiring and initial training into entry pay. The FRT had tested why the pay-package injection should produce lower turnover and better service. The PRT then asked what could block implementation.
The bank’s obstacle list was practical. It did not know the local wage-rate structure. It did not know what other banks were paying experienced help. Management lacked a clear definition of competitive pay. Management lacked clear guidelines for removing average-to-marginal employees. Each obstacle received an IO: get local salary surveys, check banking-association pay levels, define competitive pay, establish performance guidelines. The resulting PRT did not tell the bank every phone call to make. It told the bank which conditions had to exist before the pay-package injection could be real.
The same pattern appears in a DBR or S-DBR implementation. Suppose an FRT has tested the injection “materials are released according to buffer status and due-date logic, not local work-center availability.” The obstacle list may include an ERP system that releases jobs by work-order date, supervisors measured on local utilization, missing buffer-status visibility, and expediters who are rewarded for heroic intervention. The IOs are not “train supervisors” or “configure ERP.” They are conditions: buffer-status data is visible at release, release authority is tied to the buffer rule, supervisor measures no longer reward local loading, and expediting exceptions are reviewed against constraint protection. Once those IOs are clear, the TT or CCPM plan can name the actions.
The PRT also explains why some TOC implementations stall after an elegant Cloud or FRT. The solution logic may be sound, but one layer of resistance remains: people agree with the solution but see obstacles to implementing it. Goldratt’s six layers of resistance place that concern at Layer 5. The PRT is the tool for that layer. It doesn’t persuade people that the solution is desirable. It makes the implementation obstacles explicit enough that they can be worked.
Warning: Do not use a PRT as a generic risk register. A risk register can list anything that might go wrong. A PRT lists obstacles that currently block a necessary condition on the path to the target. If the obstacle isn’t a current-reality entity, or if the IO doesn’t overcome it, the tree is padding.
Consequences
Benefits. The PRT gives implementation planning a logical spine. It turns “we need to implement the injection” into a visible chain of intermediate objectives, each tied to a real obstacle. That makes the plan easier to challenge, easier to defend, and easier to hand off to the people who will build the detailed work plan. It also keeps the team from confusing negative branches with implementation obstacles: the FRT handles side effects caused by the injection; the PRT handles obstacles that block the injection.
The tree also protects the handoff to Critical Chain Project Management. CCPM can schedule and buffer work only after the work is known. A PRT supplies the IOs and the obstacle logic; the Transition Tree and project network then supply actions, dependencies, resources, and buffers. Without the PRT, CCPM often inherits a task list whose connection to the desired future is more assumed than shown.
Liabilities. A PRT can feel abstract to managers who want an action list. That is partly the point: an IO is a condition to achieve, not the action that achieves it. The abstraction becomes a liability only when the tree stops before the bottom-level IOs are concrete enough for the team to know what action comes next. Scheinkopf’s rule is useful here: if no one can think of the first action, go back to the PRT and break the obstacle into smaller IOs.
A second liability is false obstacle logic. Teams often write obstacles that are fears, opinions, or polite names for conflict rather than current-reality entities. The test is whether the obstacle can be validated. If it doesn’t exist, no IO is needed. If it exists but does not block the target, the IO is irrelevant. If the IO does not overcome the obstacle, the tree offers motion without implementation power.
A third liability is overusing the PRT where an S&T Tree would be clearer. For a single injection or bounded implementation path, the PRT is the right tool. For an organization-wide change with multiple levels of strategy, tactics, assumptions, and communication needs, the Strategy and Tactics Tree may absorb the PRT function. The PRT still supplies the obstacle discipline; it just may not be the final communication artifact.
Related Articles
Complements: Critical Chain — The PRT determines the intermediate objectives in the change path, while Critical Chain Project Management schedules and protects the project work that will achieve them.
Depends on: Future Reality Tree (FRT) — The FRT verifies the injection and desired future the PRT then turns into an obstacle-and-intermediate-objective path.
Depends on: Necessary Cause (Necessity Logic) — The PRT is a necessity-logic tool: every intermediate objective is stated as a condition required before a higher objective or injection can exist.
Downstream of: Current Reality Tree (CRT) — The CRT names what must change; the PRT appears later when the chosen injection has to be implemented despite real obstacles.
Downstream of: Evaporating Cloud (Conflict Resolution Diagram) — A Cloud often supplies the injection whose implementation obstacles the PRT maps after the FRT has tested its effects.
Informs: Strategy and Tactics Tree (S&T Tree) — The S&T Tree can absorb PRT obstacles and intermediate objectives when implementation has to be coordinated across management levels.
Precedes: Transition Tree (TT) — The PRT identifies the intermediate objectives and obstacles; the Transition Tree turns selected IOs into detailed action-level cause-and-effect steps.
Tested by: Categories of Legitimate Reservations (CLR) — The CLR's clarity and entity-existence checks apply directly to PRT entities, while obstacle and IO causality are checked against the necessity claim each arrow makes.
Sources
• Cox, TOCICO Dictionary of Theory of Constraints Terms (2nd ed., 2012), entries “prerequisite tree,” “intermediate objective,” “obstacle,” “prerequisite-obstacle link,” “intermediate objectives map,” “necessity-based logic,” and “transition tree.” The certification-grade definitions for the PRT’s purpose, building blocks, IO-map derivative, and relationship to the TT. Distributed through TOCICO membership; no Open Library record.
• Cox and Schleier, Theory of Constraints Handbook (2010), Ch. 23 (Mabin and Davies, “The TOC Thinking Processes: Their Nature and Use”). The chapter places the PRT inside the change-question sequence, classifies it as a necessity-based Thinking Process tool, and distinguishes its obstacle-mapping role from the FRT’s solution-testing role and the TT’s action-sequencing role.
• Cox and Schleier, Theory of Constraints Handbook (2010), Ch. 25 (Scheinkopf, “Thinking Processes Including S&T Trees”). The working construction source for this entry: the bank PRT example, the obstacle-to-IO pairing discipline, the instruction to write IOs as entities rather than actions, and the validation checks for obstacle existence, obstacle causality, and IO causality.
• Dettmer, Goldratt’s Theory of Constraints: A Systems Approach to Continuous Improvement (1997). The practitioner exposition that treats the PRT as part of the Logical Thinking Process and gives the verbalization discipline for necessity logic carried into PRT work.
• Scheinkopf, Thinking for a Change: Putting the TOC Thinking Processes to Use (1999). The book-length Thinking Processes curriculum behind the Handbook chapter; useful for the distinction between necessity logic, obstacle mapping, and the action-level detail that belongs downstream.
• Goldratt, It’s Not Luck (1994). The narrative source for the CRT-to-Cloud-to-FRT-to-PRT-to-TT implementation sequence as practiced by Alex Rogo and the UniCo division teams.