Life is messy. Those of us who work as business analysts see it in the myriad of ways in which people create, store and retrieve information in order to do their work. Called upon to help improve a situation, we often reach for help in the form of a methodology. The trouble with most system design methodologies is that they are made for giving structure to the process of building a solution, not for helping people living in a messy situation decide what would actually make things better. It is all too easy, particularly with larger projects, to get to design without fully understanding the context in which people will use the solution. What’s missing is an explicit way of capturing the culture and politics of the situation in order to bring key stakeholders to a common vision of what to change.
Soft Systems Methodology (SSM) is a lesser known approach to business analysis that enriches the tool set for exploring the cultural and political context of improvement projets. Based in system theory, SSM is an inquiry process that takes the term “system” beyond technology, taking into account the people involved and what aspects of the situation matter to them. It isn’t new; since Peter Checkland published his original work more than 30 years ago SSM has drawn a following among practitioners and researchers (mostly in the UK) who were looking for more effective ways to tackle complex problems.
According to SSM, understanding how to improve a situation requires both a logical and a social view. The former takes us down the familiar path of examining activities and information flows, perhaps building a Context Diagram and identifying gaps between actual practice and a potential future state. The social inquiry addresses how people working in the situation perceive it and how their respective world-views influence what changes would be acceptable. This leads to a series of possible future state models, each of which could deliver some improvement, combined with insight into the chances of success, given differences about what matters to different stakeholders.
Models are a core components of SSM, serving both as a medium to structure the inquiry – giving a first-level representation of the situation – and as a source of questions to ask of different stakeholders. Conventional modelling techniques (e.g., Context Diagram, UML activity diagrams, BPMN models, Value Stream Maps) can help, but the emphasis that SSM puts on people and perception invites other approaches.
Rich Pictures provide a way to visualize a complex situation in terms of the main business processes, their data requirements, relationships among the main actors and their perception of the issues and opportunities for improvement. Unlike formal modelling languages, Rich Pictures do not have rules. Well, maybe one: tell a story. Use images, pictures, keywords and descriptive labels to help the reader take in who is processing what data for what purpose, what data is coming in, what information is going out, and what matters to key people in the situation. Frequently hand-drawn, even cartoon-like, the aim is to convey a complex story more effectively in picture than in than prose.
Root Definitions: CATWOE
The informality of a Rich Picture does not mean that it is any less rigorous than other models; rather, the picture is the result of a structured analysis that seeks to derive clarity from complexity. The analysis starts by identifying one or more candidate system relevant to the situation, expressed in the form of a one-sentence root definition:
A system to do X by Y, in order to Z.
Taking a simple example, suppose the system to be improved was a document management system in an organization that does proprietary Research and Development work. The existing practice is to use file shares. A possible root definition could be:
A system for storing and retrieving documents in order to enable knowledge sharing among researchers.
The next step is to view the system from the perspective of a key stakeholder (or group) using the mnemonic CATWOE in order to identify key elements, starting with what input the system converts to output (the Transformation, T) from that perspective. The rest of the analysis builds out detail, identifying:
- Who (or what) benefits from this transformation?
- What problems are they experiencing?
- How would they react to one change versus another?
- Who does the work in order to produce output?
- What happens to them if some aspect of the system changes?
- How would they react to one change versus another?
- From “start” to “finish”, what are the steps, the inputs and outputs?
- What do key stakeholders care about the most?
- What are the points of agreement (and conflict) between stakeholders about what is important?
- To whom is the “system” answerable (who has the authority to take action to change it)?
- How much help do you need from them in order to make a change?
- What would cause them to help / hinder a change?
- What external factors interact with the system in a way that constrains what is possible?
- Are there technical, regulatory or other factors that will govern the approach to change?
In this example, CATWOE taken from the perspective of the VP, Research and Development, might look like this:
Customers: Researchers, Project Teams
Actors: Researchers, Project Teams (Don’t see value in learning a new technology.)
Transformation: Organize, store and retrieve project documents, research reports and reference material.
Weltanschauung (world-view): Access to information aids team productivity.
Owner: VP, Research and Development
- Must use existing technology infrastructure
- Corporate investment in SharePoint
- Non-disclosure agreements, patent applications
The analysis gives us a snapshot of the system from a single perspective, one that puts a high value on improved information access, while still acknowledging other stakeholders. Senior management concerns about protection of intellectual property and the IT department’s view of ownership become environmental constraints that limit how the system can operate. Shifting the perspective to one of those stakeholders might emphasize different aspects as their interests take centre stage. Neither perspective is wholly right or wrong; pursuing the cycles of discussion that come out of the analysis leads to discovery about which changes are desirable and feasible.
Why SSM Matters
SSM provides an inquiry process that helps everyone involved gain understanding of each other’s concerns and the relative merits of different approaches to change. On some levels that’s nothing new; any experienced business analyst probably has some structured stakeholder analysis in their repertoire already. The extra pieces that SSM brings to the table are the deliberate effort to view the situation from different perspectives and the early timing in the project life cycle. The cyclic process of discussion and learning helps build mutual understanding and trust among stakeholders, strengthening the collective will to embrace the changes that lie ahead.
Based on my own experience of using (at least parts of) SSM for more than a decade, here are some things to like about it:
- CATWOE is easy to remember as an outline of what to ask, especially in the early stages of getting to know stakeholders.
- By encapsulating a rich snapshot of what’s going on in a situation and how it is perceived from a variety of perspectives, CATWOE can lead quickly to a way of structuring a discussion about which changes could be effective.
- Just as User Stories provide a kind of shorthand for Use Cases, Root Definitions can encapsulate the big picture of an entire system in a single sentence.
- Rich Pictures help depict a problematic situation in a way that can draw attention to what needs to change, where there are conflicts and whose support may be needed in order to succeed.
- The emphasis on understanding the system from different perspectives helps to build attitudes of trust and collaboration between stakeholders and those charged with making improvements.
- SSM is scalable. It can be equally effective for drawing insights about a single system within a single organization, for developing system strategy across a whole organization or even for tackling complex situations (e.g., regional health care delivery) that involve multiple systems, organizations and stakeholder groups.