Chapter 3: Read Context, Complexity, and the Whole System

The plan is technically sound

The BlueLine steering committee is looking at a green technical picture. Lena Voss, the project director, has just finished the monthly summary: the bus rapid-transit corridor is in month 8 of 24, physical works are running 9 percent ahead of baseline, and the transport model validates the design. When the corridor opens, it is expected to carry 180,000 passenger trips a day. Construction, as engineered, is on track.

Aisha Bello, the community liaison, has been quiet. When Lena invites her update, Aisha puts two sheets of paper on the table. The first is the model’s assumption about displaced traffic: 30 percent of trips re-route to local streets, 70 percent shift to other modes. The second is her field count from the last three weeks: the split is closer to 55 percent diversion, 45 percent mode shift. Two residential streets are carrying nearly three times their design flow. A crossing that used to take 12 minutes now takes more than 30. Three traders have closed; a petition with 2,300 signatures reaches the mayor’s office today.

Councillor Diana Kamau speaks. “The engineering is fine. That was never in doubt. What is not fine is that the model does not contain my constituents. The corridor is a system, and you have been managing a construction site inside it.”

Lena starts to explain that the model is validated and that a design change now would cost two months and 4 percent of the budget. She stops. Aisha is not disputing the model’s mathematics. She is disputing its boundary. Everything the model measured sat inside the construction boundary. Everything the field counts measured sat outside it, where the effects actually land.

That gap is the subject of this chapter.

The boundary is a decision

A plan is a model of intended work. A project is a temporary organization embedded in a larger system: the technical solution, the people who run it, the organization that funds and governs it, the community and market around it, regulators, the environment, and time. Change in any part propagates through the others, with delay and amplification, and some of it comes back and pushes you.

Every model and every project has a boundary, a line that says what counts. The construction boundary included walls, tracks, and stations; it excluded the streets where traffic landed, the markets where income fell, and the trust the petition measured. A boundary is not wrong in itself; all models have them. It becomes wrong when it is inherited without examination, because it decides which risks you will see, which effects you will answer for, and which stakeholders feel the project without ever being in the room. Choosing the boundary, and arguing about it openly, is a judgment call the leader owns.

Local optimization is managing one part of the system as if it were the whole: the contract is protected, the model is defended, the budget line is honored, while the system the project exists to serve quietly degrades. None of this looks like incompetence at the time. It looks like a sound plan meeting unexpected events. What the project leader does first is not scheduling, budgeting, or method selection. It is reading: naming what kind of situation this is, where the boundaries sit, which chains of cause and effect will amplify the project’s own actions, and which parts of the plan rest on untested belief.

Four kinds of situation

The most important classification in project work is not big versus small, technical versus human, or public versus private. It is the nature of cause and effect in the situation you face.

In a clear situation, cause and effect are obvious to anyone who looks, and a documented procedure produces the expected result. Follow the runbook, standardize, and monitor for exceptions. In a complicated situation, cause and effect must be found through analysis: experts can determine what is going on, several good answers are possible, and the outcome is then largely predictable. Bring in experts, analyze, and decide. In a complex situation, cause and effect are visible only in retrospect, and the system responds to your interventions: the same action can land differently in two apparently identical situations. Run small, safe-to-fail probes, watch what the system does, and adapt. In a chaotic situation, no useful cause-and-effect relationship is perceivable right now. Act to stabilize: protect people, information, and basic function, then sense what the situation has become.

This way of sorting situations comes from the Cynefin sense-making framework, described by Cynthia Kurtz and Dave Snowden in a widely cited 2003 paper. The domain names have evolved since then, but the content is unchanged: using one domain’s playbook in another is the error. Complex work run as complicated produces big plans with manufactured certainty. Complicated work run as complex produces endless experiments where analysis would have answered. Clear work run as complex produces ceremony where a checklist would do.

And a project is not one domain. It is a bundle of situations, each of which can sit in a different domain, and the classification can change as the work proceeds. Classify the workstream or the decision, not the project. The corridor is clear where the runbook governs, complicated where the engineering is analyzed, complex where traffic and community behavior respond to the project, and at moments of failure, chaotic.

Loops, delays, and the quiet killers

Three system properties explain most project surprises that are not random bad luck.

Feedback loops. An effect that comes back to influence its own cause. A reinforcing loop amplifies: congestion diverts traffic, diversion provokes complaints, complaints reach politicians, politics changes the design, the change extends closures, and more closures mean more congestion. A balancing loop regulates toward a goal: congestion rises, drivers shift to other modes, and congestion eases. The project’s actions participate in such loops whether or not anyone names them.

Delays. The gap between an action and the evidence of its consequence. Delays are the quiet killers: they make a system look stable when it is not, and they let teams keep steering in a direction that stopped being right months ago. At BlueLine, field counts took two weeks to reach the transport model, so the plan always reacted to traffic that no longer existed.

Nonlinearity. Outputs that are not proportional to inputs. A street at 30 percent capacity absorbs a 20 percent traffic increase with ease; the same street at 95 percent capacity turns that increase into gridlock. Systems near a limit swing hard from small pushes, which is why a small model error can produce a large real-world consequence.

The practical consequence: the most important events often occur at the system’s edge, after the delay, outside the boundary, and they do not appear in the status report. And when the situation is unclear, the wrong reflex is to reach for a method or a tool. The better first move is sensemaking: what kind of situation is this, where are the boundaries, which loops will run us, and what do we actually believe? Sensemaking before solutioning prevents the two most expensive errors: applying a complicated-domain method to complex work, and applying a complex-domain method to clear work. Method misuse is almost always a context error, not a skill error.

Reading the system at BlueLine

The next week, Lena convenes a three-hour framing session with the councillor, Aisha, the transit operator, a market trader, the modeler Miguel Alvarez, and a liaison from the environmental regulator. The room builds four artifacts together, and the artifacts are the point, because each one forces a different kind of honesty.

The context canvas describes the situation. One page, six cells: organizational, technical, social, regulatory, market, environmental, each holding the two to five forces that matter, their direction, and whether the project can influence them. The organizational cell deserves its own care: culture, incentives, power, and history shape projects more than most external factors. The funder pays progress on physical works, so the contract is rewarded for walls, not outcomes; the operator wants ridership but holds no seat at the steering table. A prior cancellation taught residents to disbelieve commitments. These are as real as a geotechnical report, and the canvas makes them visible. The rest of the room fills in: the BRT design is proven in other cities; the corridor passes three markets and a school, and 1,400 shops depend on it; two jurisdictions have separate approval cycles and an environmental review is already six months late; rents are rising as traders fear displacement; the eastern segment sits on a flood plain with drainage approval outstanding. Each cell gets a watcher, and the two weakest cells get marked.

The causal-loop sketch explains how the situation behaves. One sheet of paper, five to ten nodes, arrows showing influence, every loop labeled R (reinforcing) or B (balancing), every delay marked. The room’s sketch names three loops.

Figure 3.1: The corridor as a system. Solid arrows are primary
flows; dashed arrows are feedback. R = reinforcing, B = balancing.

  primary flow:  lane closures -> congestion -> diversion
                 -> side streets -> resident and trader pressure

  R1 (failure story):  pressure -> political pressure -> design
                 change -> longer closures -> more congestion

  B1 (model story):    congestion -> mode shift -> fewer cars
                 -> less congestion

  B2 (the lever):      engagement -> mitigation -> fewer complaints
                 -> less pressure

  delay: two weeks from field count to traffic model

R1 is the loop running the project unseen. B1 is the model’s honest story: congestion pushes drivers to other modes. B2 is the loop the project could feed deliberately: engagement leads to mitigation, mitigation lowers complaints. The two-week model delay sits between the field and the plan, invisible until the room draws it. The decisive question is asked for each loop: who owns it, and what would we see first if it started running?

Then the arithmetic that changes the meeting. The corridor carries about 50,000 vehicle-trips a day, and construction displaces an estimated 15,000. The model assumed 70 percent shift to other modes and 30 percent diversion to local streets: 10,500 and 4,500 trips. Field counts show a different split: 6,750 mode shift, 8,250 diverted. The extra 3,750 trips a day land on two streets, pushing them from a combined design flow of about 4,000 trips to roughly 12,250, three times what they were built for, and crossing time rises from 12 minutes to about 36. For the 1,400 shops at two deliveries each, that is 2,800 delivery trips at 24 extra minutes, roughly 1,120 vehicle-hours a day, about 392,000 hours over the closure’s 350 working days. At 15 local-currency units per vehicle-hour, about 5.9 million units of delivery delay, nominal, falls on traders and residents; halve both the extra time and the shop count and it is still on the order of 1.5 million. None of it appears in the cost baseline, because it all lands outside the construction boundary. This is illustrative arithmetic, not an audit; the point is magnitude. The model error costs the system a sum that dwarfs the mitigation line item that now has no owner.

The complexity profile is the domain logic on one page: which playbook fits which kind of cause and effect, and the error each domain invites.

Figure 3.2: The complexity profile, a simplified summary of the Cynefin domains (Kurtz and Snowden, 2003)

The domains also set the governance. Clear and complicated work can run on slower gates, expert review, and baseline control; complex work needs short feedback loops, small probes, and decision rights at the point of feedback; chaotic work needs minimal governance until it stabilizes, then a deliberate move toward order. The corridor is the lesson in one line: construction runs predictive, engagement and mitigation run adaptive, and the seam between them is synchronized at a standing system review where the construction lead and the community liaison trade evidence before either commits. Match governance cadence to feedback speed: the more complex the domain, the shorter the distance between an action and the evidence of its consequence. One governance model for the whole project is usually a category error.

The assumption inventory says what is still guesswork. A table of assumption, owner, evidence strength, consequence if wrong, and review date, where evidence strength takes four levels: observed, heard from a credible source, analogy, or guess. The room gets honest fast. The 70/30 mode-split assumption is observed to be wrong, so every downstream number is suspect. The speed-recovery figure is an analogy from another city. The claim that the community will accept 24 months of disruption was never stated or tested. The environmental approval timeline is a guess. Each entry gets an owner, a review date, and a cheap test: a count, a pilot, a document read, a conversation. The inventory converts “we assumed” from an excuse into a working list, and the highest-scoring assumptions are the project’s real risk register, whether or not they appear there yet.

The session’s outcome is not a new construction plan. It is a re-baselined way of seeing: a four-week window to test mitigations (a temporary signal plan, delivery windows, a shuttle service), a standing system review with the councillor and the operator, a model that now carries a diversion variable, and two named loop owners, R1 on Lena, B2 on Aisha. The corridor is still in month 8 of 24. What changed is that the loops that will decide the outcome now have names, owners, and leading indicators.

A language model can draft a first-pass context canvas from project documents, propose candidate feedback loops from meeting notes, and assemble a raw assumption list in minutes. Use it to widen the field of hypotheses, never as a substitute for observation: redact sensitive data, treat every proposed entry as a hypothesis to verify with people inside the system, and send someone into the field for the counts and the quiet signals no document contains. The context canvas is an observation instrument; fluency is not evidence.

The model was right

Competent teams do this every quarter: a validated model says the plan is sound, field data disagrees, and the field data is treated as a measurement problem rather than a finding. “The count must be off.” “The instruments need recalibrating.” The model is refined with the same variables, and the new variable, the one the situation is trying to communicate, never enters. The failure is not the mathematics; it is the boundary, adopted without argument and defended as territory.

The tell: every iteration adds refinement to existing variables, and none adds a variable. The mirror failure is the complexity excuse: label everything complex, then use the label to avoid dates, budgets, and decisions. Its tell: the word “complex” appears more often than any named probe, any owned decision, any re-baseline. The second failure is harder to fix, because it wears the costume of sophistication. Complexity is a reason to sense faster, not to decide less.

Practice

1. A quick classification. Classify each situation into its dominant domain (clear, complicated, complex, or chaotic), or name the system element if none of the four fits: “The warehouse flood response is being improvised minute to minute; nobody can yet say what happens next.” “A structural engineer must analyze the corroded beam before anyone can say what the repair should be.” “The runbook for this release was executed successfully twice, and today’s steps are identical.” “Every time we change the pricing, competitors respond within days and the market behaves differently.” “Field counts take two weeks to reach the model, so the plan reacts to traffic that no longer exists.”

The first is chaotic: act to stabilize first, then sense. The second is complicated: expert analysis produces the answer. The third is clear: follow the procedure and monitor for exceptions. The fourth is complex: run probes and watch the response; the same intervention can land differently each time. The fifth is not a domain at all; it is a delay, a system structure problem whose fix is a shorter feedback path, not a different playbook. The common error is classifying by emotional weight: urgent situations are not automatically chaotic.

2. Read your own system. Choose a project you know from work, community, or study. Build a minimum viable context canvas (six cells, two to five forces each) and a causal-loop sketch (five to ten nodes, every loop labeled R or B, every delay marked). List the five assumptions your plan depends on most, score their evidence, and mark the one that, if wrong, would most change the plan.

The exercise succeeds when the canvas has specific entries rather than generic ones, when every loop has an R or B label, and when every assumption has an owner and an evidence score. The organizational cell is the one most people skip: include who is rewarded for what, who holds power, and what history taught stakeholders to expect. The assumption that would most change the plan usually sits in the cell with the weakest knowledge; test that cell first with the cheapest evidence that would move it, a count, a pilot, a conversation, or a document read.

3. A decision room. Three weeks later, Councillor Kamau proposes moving two stations to spare the main market. Engineering estimates 2 months of delay and 4 percent of budget; the petition now has 3,100 signatures. The trade-off is real: relocation protects livelihoods and trust; the status quo protects the date, and every extra month of construction extends the disruption. Decide: accept the relocation, reject it, or accept it conditionally, and defend the trade-off in terms of the system map.

The system map frames the decision: the station location is a leverage point that feeds trader income, ridership, trust, and the R1 loop that has already cost the project time. A defensible answer accepts in principle with conditions: a joint design review weighing ridership with relocation against the extended disruption, a hard decision window of four weeks, and a re-baseline that funds the extra two months explicitly. Rejection is defensible only with evidence that relocation destroys more value than it preserves, gathered from traders and the model together, not either alone. The unsafe answers: accepting silently with no re-baseline, or rejecting while promising engagement that never materializes. Good answers name the evidence that would change the position: a trader census, a ridership model with relocated stations.

4. The mastery drill. Four situations, four first responses. For each: name the dominant domain, then choose the first response from a short list, follow a documented procedure, commission expert analysis, run a small safe-to-fail probe, or stabilize the basics first. First, a hospital is migrating medical records to a new vendor platform; the identical runbook succeeded twice before. Second, a bridge needs rehabilitation, and the load calculations require specialist analysis before any design is defensible. Third, a new payment feature depends on merchant behavior and competitor moves; two prior launches with similar designs produced opposite results. Fourth, a flood has cut the main road, the warehouse has lost power, and staff are unaccounted for. Then answer one more question: what is the trap if the leader of the third situation adopts the playbook of the second?

The first is clear; follow the runbook and monitor for exceptions. The second is complicated; commission the expert analysis, then decide. The third is complex; run safe-to-fail probes, watch the response, and adapt, because prior launches are data, not guarantees. The fourth is chaotic; stabilize people, information, and basic function first, then move deliberately toward order as understanding returns. The trap: a complex domain run on the complicated playbook produces a big, confident plan whose certainty is manufactured; it feels rigorous and fails systematically, because the system was never knowable in advance. Strong answers note that classifications can change: the flood response moves from chaotic to complex as information arrives, and the migration could shift from clear to complicated if a new data type appears.

5. Transfer question. In the project you lead or work on right now, which part of the system is most likely to surprise you, and what delay would hide the surprise until it was expensive? Name the loop you have never drawn, then draw it.

Reading the situation is the first act of judgment; the second is deciding what to do about what you have read. The same skill that shows you the loops and the boundaries reveals that choices remain: what to notice, what to say out loud, how much of the plan to trust, and how to tailor the approach without breaking the obligations that hold. That is the subject of the next chapter, “Exercise Ethical Judgment and Tailor Deliberately.”

Notes

• BlueLine Urban Mobility Program is a composite case created for this book; no real city, corridor, or company is depicted. It is introduced here and developed in later chapters. All characters are composite, and the corridor numbers are author-created illustrative figures.
• The four Cynefin domains and the sense-act sequence are simplified summaries of the framework introduced by Cynthia F. Kurtz and David J. Snowden, “The New Dynamics of Strategy: Sense-making in a Complex and Complicated World,” IBM Systems Journal 42, no. 3 (2003): 462-483. The domain names have evolved in later publications (the simplest domain is now usually called clear, and the ambiguous center, called disorder in 2003, is now usually called confused); this chapter follows the 2003 source for the domain logic. Readers should consult the framework’s current publications for the official diagrams and vocabulary.
• The systems vocabulary of feedback loops, delays, and nonlinear consequences follows Donella H. Meadows, Thinking in Systems: A Primer (Chelsea Green, 2008), and the causal-loop discipline follows John D. Sterman, Business Dynamics: Systems Thinking and Modeling for a Complex World (Irwin/McGraw-Hill, 2000).
• ISO 21502:2020 and the PMBOK Guide, Eighth Edition (Project Management Institute, November 2025) both address project context and complexity; readers should consult the official publishers for the current text, as this book is independent of those organizations.