Soft Systems Methodology explained: Checkland's 1969 method for AI briefs nobody agrees on
"Roll out an AI coding assistant across engineering." Six people nod. Everyone understands the sentence. Almost nobody means the same thing by it, and nobody finds that out until adoption stalls and the dashboard insists the tool is performing well.
That is a soft problem. Most organisations own no method for one.
A hard problem has an agreed objective and an argument about the route. Get the overnight batch to finish before the business opens. You can engineer towards that, because only the path is in dispute. A soft problem has the opposite shape. Everyone can see the mess, nobody agrees what improvement would even look like, and the objective is the thing being fought over.
Requirements gathering, proof of concept, agreed success criteria, phased rollout: every one of those takes the problem as given and optimises the route to it. Run them on a soft problem and you get a beautifully managed march to a destination half the room never agreed to.
Soft Systems Methodology is the method for the second situation. It is fifty years old, it is taught in operational research and health informatics, and almost nobody in technology delivery has heard of it. Here is the plain version.
Where it came from
Peter Checkland was at Lancaster University's Systems Department, running what became a ten-year action research programme from 1969 into why systems engineering, which worked beautifully on defined problems, fell apart the moment it was turned loose on management ones.
The first formal account is a 1972 paper, "Towards a systems-based methodology for real-world problem solving". Systems Thinking, Systems Practice followed in 1981 and Soft Systems Methodology in Action, with Jim Scholes, in 1990. Checkland wrote his own thirty-year retrospective in 2000, by which point the method had been through four successive versions, each less rigid than the last.
That last detail matters, because most of what you will find written about SSM is the original seven-stage model, which Checkland himself came to think too linear. The later version collapses it into four activities. Use that one.
The one move that makes it work
Checkland stopped treating the organisation as a system and started treating "system" as a mental construct you build in order to learn about a mess.
Read that twice, because it is the whole thing and it goes past most people at speed.
You are not drawing a model of the company. You are drawing several models of purposeful activity that different people believe the company should be, knowing full well that none of them is true, then holding each one against what is actually happening to see what the gap tells you. The models are argument tools, not blueprints. Nobody builds them. Their job is to make an unstated worldview visible enough to disagree with.
That is why SSM produces a better conversation rather than a document, and why people used to delivery methods find it slippery. It is a learning cycle, not a solution generator.
The kit
Four activities, in a loop. Find out about the situation. Build purposeful activity models. Compare the models with the situation and argue. Take action. Then go round again, because the situation has moved.
Finding out starts with a rich picture, which is an ugly hand-drawn sketch of the situation: people, work flowing, arrows, speech bubbles, conflicts drawn as conflicts. No formal notation, deliberately, because formal notation makes you leave out the awkward parts. The stick figure saying "this will be used to performance manage us" does not fit on a process map. It fits here, and it is usually the most important thing on the page.
Modelling starts with a root definition, one sentence in a fixed shape: a system to do X by means of Y in order to achieve Z. X is the transformation, Y is how, Z is why. The form is restrictive on purpose. It forces the "in order to" out of hiding, and the "in order to" is where people quietly differ.
You test each definition against CATWOE, formalised by Smyth and Checkland in 1976. Customers, the people on the receiving end. Actors, who does the work. Transformation, the change itself. Weltanschauung, the worldview that makes the transformation worth doing. Owner, whoever can stop it. Environmental constraints, what you take as given.
The W is load-bearing and almost always unstated. It is the belief that has to be true for the transformation to be worth anything, and different people hold different ones while using identical words.
Then you draw the conceptual model: the minimum set of activities that root definition logically requires. Not what the company does. What that definition, taken seriously, would oblige it to do.
Then you compare the model with reality. What is missing, what exists but connects to nothing, what happens that no model justifies. Out of that comes a list of changes, each of which has to clear two tests: systemically desirable and culturally feasible. That second test has killed more bad projects than any risk register I have ever seen.
What it does to an AI brief
Back to the coding assistant. Write it as a root definition four times, once per worldview in the room.
Finance: a system to reduce cost per feature by means of automated code generation, in order to hold headcount flat while the roadmap grows.
Engineering leadership: a system to shorten cycle time by means of removing boilerplate work, in order to ship a roadmap that is already committed.
Security: a system to control what source code leaves the building by means of one approved and logged assistant, in order to stay inside the company's data commitments.
And the fourth one, which nobody writes down, held by the people who will actually use the thing: a system to automate the enjoyable part of the job by means of generating the easy code, in order to leave a queue of review, debugging and integration, measured against the same delivery dates as before.
Those are not one project. They are four. The first needs flat headcount against rising output. The second needs the tool trusted and used daily. The third often means the bounded, logged, slower option. The fourth is not a grumble, it is a prediction, and it explains the rollout that quietly dies while the licence dashboard says usage is healthy.
You can build any of them. You cannot build all four at once. Noticing that before the purchase order is the entire return on the method.
Why this matters more in 2026 than it did in 2024
Because we have stopped building things that answer and started building things that act.
In June 2025 Gartner predicted that over 40% of agentic AI projects will be cancelled by the end of 2027, and gave three reasons: escalating costs, unclear business value, inadequate risk controls. Two of those three are purpose problems wearing a delivery costume. The same release forecast that 33% of enterprise software applications will carry agentic AI by 2028, up from under 1% in 2024. The wave has not landed yet.
Take the AI off and none of this is new. An organisation agreed on a solution without agreeing on a problem. That failure is older than the industry.
What is new is the blast radius. A chatbot with a confused purpose gives a bad answer and someone ignores it. An agent with a confused purpose takes an action, in your name, against a target that somebody else's unexamined worldview selected. The cost of an unstated W stops being a wasted budget and becomes something that happened to a customer.
Two honest qualifications
SSM will not save you from power. It surfaces disagreement, it does not resolve it. If the sponsor has already decided, no amount of CATWOE outranks them, and the standard academic objection is exactly this: the method assumes participants can debate on something like equal terms, which in most organisations is a polite fiction.
And nobody has run the study. There is no published trial showing SSM improves AI project outcomes. What exists is a well-documented failure mode and a fifty-year-old method aimed directly at it. I am arguing from the fit, not from evidence I do not have.
One thing has genuinely changed. SSM stayed niche because it was expensive: days of facilitated workshops for an output that was a conversation rather than a deliverable. Most of that cost has gone. Drafting six root definitions from six worldviews and stress-testing each against CATWOE is exactly what a language model is good at. The argument still needs the humans in the room. The paperwork that used to make the argument unaffordable does not.
Take the next AI thing on your roadmap. Write its root definition yourself, one line, in the form "a system to do X by means of Y in order to achieve Z". Then write the one the people who will actually use it would write, honestly, including the part they would never say in the steering group. Put the two sentences side by side.
If they describe different systems, you do not have a delivery problem. You have an argument, and it is cheaper to have it now than after the build.