Complicated vs Complex: A Delivery Diagnostic

Dave Snowden's favorite illustration of the difference between complicated and complex work is an aircraft. An aircraft is a complicated system: thousands of components, each knowable and definable, every relationship between them catalogable, and cause and effect separable so that understanding the linkages lets you control outcomes. Walk up to an aircraft with a box of tools and nothing changes. Now consider what happens in an organization when a rumor of reorganization surfaces: the complex human system starts to mutate in unknowable ways, new patterns form in anticipation of the event ¹. Same word, two different problems. Consulting teams that cannot tell them apart default to the only playbook they know, and the numbers show the cost: large IT projects run 45 percent over budget and 7 percent over time while delivering 56 percent less value than predicted ².

The distinction, made operational

The Cynefin framework, which Snowden developed in 1999 while at IBM, sorts problems into four named domains plus a confused center. Clear work has obvious cause and effect: drive on the left in the UK, on the right in the US, sense, categorize, respond. Complicated work has cause and effect that is knowable, but only through analysis and expertise: an engine that will not start, sense, analyze, respond. Complex work has unknown unknowns where acting in the space changes the space and cause and effect can only be deduced in retrospect: probe, sense, respond ³. Chaotic work demands acting first to establish order. The center of the framework, once called disorder, is now labeled confused or aporetic: the state of not knowing which domain you are in, where most troubled projects live ⁴.

The operational consequences are sharper than the vocabulary suggests. Jon Smart, author of Sooner Safer Happier, maps the domains to delivery approaches: the complicated domain, where activity is ordered, repetitive and knowable, is the sweet spot for lean; the complex domain, where product development is emergent and filled with unknown-unknowns, is the sweet spot for agile. Frameworks are domain-specific tools, not religions ³.

Academic work pushes the same point further. Andreas Nachbagauer's extension of Cynefin for project management combines complexity with repeatability into a typology: expertise is useful in simple and complicated projects only, while complex and novel projects demand experience, authority and trust, and the recognition of abstract patterns, because learning from past projects only transfers when the situations are similar ⁵. That explains a recurring consulting failure: a firm staffs a complex transformation with experts who delivered a similar-sounding project elsewhere, and the pattern recognition that worked before fails because the situation was never actually the same.

The failure mode: a category error, not a process error

When a project goes sideways, the instinct is to blame execution, scope, or stakeholders. More often the root cause is that the delivery model was designed for the wrong domain. The classic pattern is a complex project run as if it were complicated: a fixed specification, detailed milestone plan, and stage-gate governance. Lynn Crawford's PMI analysis describes what happens: complicated projects have hard, clear boundaries defined by contracts, while complex projects have soft, permeable boundaries that shift with the people involved. Intangible products, information systems, organizational and cultural change, cannot be modeled or prototyped the way buildings and machinery can, so clarity and agreement about the end product are far harder to achieve ¹. PMI's Navigating Complexity practice guide codifies the definition: complexity is a characteristic of a project or its environment that is difficult to manage due to human behavior, system behavior, and ambiguity ⁶. Ambiguity, note, not size.

The opposite failure is just as common: a genuinely complicated project treated as complex, wrapped in agile ceremony it does not need. The 17th State of Agile report found 71 percent of organizations use agile in their development lifecycle and Scrum remains the most popular team-level methodology at 63 percent, yet more than a third of respondents say leadership does not understand agile and puts up roadblocks ⁷. When the framework is adopted as a label rather than a response to complexity, teams get ceremony without empiricism, and ceremony is where the time goes.

The five-question diagnostic

At kickoff, before a single plan is written, run the engagement through five questions.

Can someone specify the outcome in advance? If the deliverable is tangible, a building, an integration, a data migration with a known schema, the outcome can be specified. If it is intangible, a culture change, an operating model, the plan must be built around learning.

Have we done this exact thing in this exact context before? Repeatability matters as much as complexity. A well-trodden integration for a similar client is complicated even if large. The same integration into a new organizational context with new politics is complex.

Is cause and effect discoverable by analysis? The aircraft test. Can a competent expert decompose the problem, understand the linkages, and predict outcomes? If yes, complicated. If the system changes in response to being studied, complex.

Are the boundaries contractual and stable? If scope is defined by contract and exchange with the environment is controlled, you are in complicated territory. If the boundaries are permeable and the project cannot be isolated from its environment, expect emergence ¹.

Does acting in the space change the space? The rumor test. If people react to the project, pre-empt it, resist it, or reorganize around it, you are in a complex adaptive system, and the plan must be a set of hypotheses, not a schedule.

What actually changes in delivery

Once the domain is named, the changes are concrete and cross-cutting. Estimation is where the category error hurts first. According to a secondary analysis of the 2025 State of Agile data, fewer than a third of teams say their estimates accurately predict delivery, yet 86 percent still spend at least an hour every sprint estimating, and 87 percent still use story points ⁸. This is not a story-point problem, it is a domain problem: point-based estimation assumes a complicated world where effort correlates with size. In complex work, the uncertainty lives in the requirements and the integration, not the implementation, so relative sizing against a stable baseline stops meaning anything. Teams that do complex work well shift from estimating items to forecasting flow: instrumenting cycle time and throughput, slicing work into small consistent increments, and running Monte Carlo simulations against historical throughput to produce probability distributions instead of point estimates ⁹. Scrum.org's Daniel Vacanti is the standard reference, and tools like ActionableAgile and Baseliner.ai make it practical without spreadsheet gymnastics ⁹.

Governance changes the same way. The Scrum Guide is explicit that Scrum is designed for complex work, founded on empiricism, knowledge comes from experience and making decisions based on what is observed, through the pillars of transparency, inspection, and adaptation ¹⁰. A stage-gate model is a prediction instrument: it assumes you can know the end state well enough to approve passage. An inspect-and-adapt cadence is a sensing instrument: it assumes the end state will move and structures the team to adjust as it learns. For complex engagements, replace approval gates with review cadences that update the plan from what was observed.

Stakeholder management is the third shift. In complicated work, stakeholders are a fixed list with defined interests, managed through a communication plan. In complex work, stakeholders are the system: complex projects are highly subject to the influence of people with different agendas, values, and responses, and need leadership that is self-aware, collaborative, comfortable with ambiguity, and able to think systemically ¹. The practical move is to stop treating stakeholder engagement as a milestone, the kickoff deck, the steering committee, and instead run it as continuous sensemaking: regular structured conversations whose purpose is to surface the shifting agendas that would otherwise derail the project.

Why 2026 makes this urgent: AI broke velocity

There is a 2026-specific reason this diagnostic matters now: AI coding tools have invalidated the estimation baselines that complicated-world planning relied on. The 2025 DORA report, based on nearly 5,000 technology professionals, found AI adoption is near-universal, 90 percent of respondents use AI at work, and AI has a positive relationship with throughput but a negative relationship with delivery stability: acceleration exposes weaknesses downstream without robust control systems ¹¹. For delivery teams this is the velocity problem made concrete. A five-point story in 2024 might genuinely be a two-point story in 2026 because AI compresses implementation time, so any team forecasting on pre-AI velocity is underestimating capacity; and the work that remains, specification, review, integration, is exactly the work where complexity lives ⁸. The implementation layer got faster and the uncertainty layer did not: the work got more complex, and complex work demands empirical forecasting ⁹.

Put it into practice

A consulting team that wants to operationalize this does four things. First, run the five-question diagnostic at kickoff and write the conclusion into the engagement: name the domain explicitly in the kickoff deck and the weekly status format, forcing client and team to agree on what kind of project this is. Second, match the contracting model to the domain: fixed-bid makes sense for complicated work where the outcome is specifiable and the risk is execution; complex work should be structured as staged or time-and-materials engagements with explicit learning checkpoints, because a fixed-bid on an emergent problem converts uncertainty into scope fights. Third, build the empirical loop into the operating rhythm: small batches, visible progress, and a retrospective cadence that changes the plan. This is the discipline we run inside our own content pipeline at Adroit: every article passes a mechanical verification script checking word count, citations, and formatting before it ships, and every publishing run ends in a written retro that feeds the next one. The artifacts differ, the loop is identical: transparency, inspection, adaptation, every cycle ¹⁰. Fourth, re-run the diagnostic quarterly, because work moves between domains. Smart's example is a new car model: it starts complex, focus groups, prototypes and wind tunnel testing, moves to complicated when 100,000 units a year are built on a lean line, dips into chaos with a recall, then returns to complicated ³. The domain is a property of the work at a moment, not a permanent label. The first move is admitting which problem you are actually solving. An aircraft is complicated and rewards expertise. A rumor of reorganization is complex and rewards humility, pattern recognition, and the willingness to probe, sense, adapt. The diagnostic costs an hour at kickoff and saves the 45 percent over budget the category error costs everyone else.