Reworking the SSM Root Definition & Final Conceptual Models

Hello Systems Thinkers,

This is a fairly short post, just to wrap up on the SSM work.  We finished with it quite a while back and have been busy exploring a variety of systems ideas and concepts, and in particular, have been dipping our toe into cybernetics and the Viable System Model. It’s good stuff.

For the moment though, I just wanted to write a note to complete the work on our SSM models.  If you recall, the last post I wrote on SSM was a summary of the conceptual model building we’d been doing.  Here’s the post:

http://systemsthinkersanonymous.com/ssm-conceptual-models/

Building the models was very much a learning process.  We learned about building models, but also about the thing we were studying and thinking about, the canteen.  The process helped us to  reframe our thinking and understanding and we gained a number of insights into functions that would be required to run the canteen along the way.  This was helped, by us showing the work we had done to the canteen management team, who pointed out areas where our thinking was incomplete.  They also found the experience helpful and highlighted several areas to them they had not considered.

All new and improved Root Definition

Because our understanding of the situation changed, we decided to revisit our original Root Definition to see if was still appropriate.  It wasn’t , and so we modified it to reflect our new understanding.

First of all though, here is our previous Root Definition:

A facility and service owned and operated by the Local Authority through their employees, to provide an environment that supports relaxation and social interaction and provides nutritional food at lunchtimes that satisfies the need for affordable hot and cold food and drinks and facilities to heat and eat home prepared food, which recognises appropriate legal requirements within the existing canteen space within the building, in the belief that doing so will have a positive effect on wellbeing and motivation of the workers in the building and also enhance revenues coming to the Local Authority by making a profit from selling food and drink and also by making the building a more attractive place for prospective rent paying tenants to locate their operations.”

And here is our updated version:

“A facility and service owned and operated by the Local Authority through their employees, to provide an environment that supports relaxation and social interaction and provides nutritional food that satisfies the need for affordable hot and cold food and drinks during regular office hours and facilities to heat and eat home prepared food available 24/7, as well as providing opportunities for local charities to supply and showcase produce and providing training opportunities for people with learning difficulties which recognises appropriate legal requirements within the existing canteen space within the building, in the belief that doing so will have a positive effect on wellbeing and motivation of the workers in the building and also enhance revenues by making the building a more attractive place for prospective rent paying tenants to locate their operations, whilst the canteen facility’s direct revenue impact must be cost neutral.”

You can see we’ve added elements about the community focus of the canteen, using local charities as suppliers, and offering training and employment opportunities to people with learning difficulties, as well as defining the financial performance expectation it operates in.

Again, what stood out about SSM process is how iterative it is.  We came back to iterate the Root Definition, and in doing that, realised our Conceptual Models were not complete.  We hadn’t considered the need for the canteen to market its offering.  It was helpful that this process of iteration and development drew this out.

Our new and final models

So, we returned to our top level Conceptual Model and incorporated a “marketing” node.  Here is the revised top level model:

Revised top level Conceptual Model

You can see the new marketing node, number 6, in the middle of the model.  And here is the Conceptual Model for the marketing function:

Conceptual Model of Node 6 – Marketing

 

The end of the SSM road……..for now.

This brings our SSM story to a close for now. The next steps in the process would have been to compare the models to the reality to identify  gaps in the organisation and things that could be changed or improved. We did have some conversations with the canteen management about this and discussed areas for improvement with them, but given this was a case study and not a piece of work they commissioned from us, we were only able to go so far.

You can’t beat an occasional CATWOE

We certainly learned a lot on this journey and will be using SSM again.  Indeed, I have been using it frequently in my own work.  In particular, I find the CATWOE mnemonic very helpful when starting on a new project and trying to state what the purpose is.  That’s part of the beauty of SSM I think.  It is a 7 step process, but you can actually take most of those steps on their own and use them independently and get helpful results.  It’s like a bag of several tools you can pick and choose from, rather than a single approach. Although, of course, you can run all of the way through the process if the situation allows, and warrants it.

Week 18 Part 2: Where in the world of Systems Thinking are we?

Let’s pause and think about thinking

We’ve charged head first into learning various tools and methods, but haven’t had much discussion about what Systems Thinking is and where the approaches we’re learning sit within the wider discipline.   We’re now on the verge of heading into learning about Soft Systems Methodology (SSM) and I thought it worth us taking an opportunity to catch our breath and talk about Systems Thinking more generally.

You’d think it’s all about System Dynamics

When you google “Systems Thinking”, the overwhelming majority of the top listings relate to the approach of System Dynamics and its proponents such as Peter Senge, Donella Meadows, the Waters Foundation and others.  System Dynamics is a valuable approach and is especially good for understanding relationships, causal effects and feedback loops between system elements.  

Another approach sitting high on the google rankings is John Seddon’s “Vanguard Systems Thinking”.  This is a kind of overhauled version of “Lean” specifically for service provision and has gained a lot of traction in the Public Sector here in the UK.  There is debate about whether it is genuinely a form of Systems Thinking or not.  Personally, I don’t intend to add to that debate, so will leave it there.  It is a good and useful approach in the right context, and the core concept of “failure demand” is particularly insightful.  Why not look it up.  Whether they are genuinely Systems Thinking approaches or not, these approaches have valuable uses and much can be gained from employing them.  

But there’s a problem.

Whilst they may dominate, these approaches only account for a very small part of what’s on offer in the world of Systems Thinking.  The problem comes when you tell people you’re into Systems Thinking, as they tend to think this is what you mean.  Well, it’s largely not what we mean.  Not to say there’s anything deficient about these approaches, it’s just that given our particular context, I don’t think they are the most useful for us right now.  

I hope we are going to be relatively agnostic in our approach and embrace the diversity of what is out there and become “mixed methods” practitioners.  There’s such a wealth of amazing stuff out there, with each approach having its strengths and weaknesses for any given context.  Here is an amazing map showing some of the incredible diversity and range of theories and approaches available to us:

http://www.scimaps.org/maps/map/map_of_complexity_sc_154/detail

Hard and Soft Approaches

System Dynamics, is from the “hard” school of approaches and is the dominant approach on the other side of the Atlantic.  Here in the UK, we use “hard” approaches extensively, where they are the more appropriate, but there has also been significant development in “soft” approaches. The term “soft system” is one coined by Peter Checkland when he created Soft Systems Methodology (SSM), but it has been extended to encompass the range of approaches created to help understand and intervene in complex situations involving humans, or “Human Activity Systems”, where “purposeful Activity” is being undertaken.

Are systems real?

One way “soft” approaches differ from their “hard” relatives is they don’t view systems as things that have their own objective existence. In this view, systems are not real things.  The operative word in Soft Systems Thinking is “thinking”.  It’s about using the various conceptual qualities of systems, such as boundary, purpose, structure and interrelationships to better understand messy real life situations.  There is a difference between thinking about systems and thinking in terms of systems.  Here is a quote from the Systems Engineering Book of Knowledge (SEBoK) describing this:

“The identification of a system and its boundary is ultimately the choice of the observer. This may be through observation and classification of sets of elements as systems, through an abstract conceptualisation of one or more possible boundaries and relationships in a given situation, or a mixture of both concrete and conceptual thinking. This underlines the fact that any particular identification of a system is a human construct used to help make better sense of a set of things and to share that understanding with others if needed.”
http://sebokwiki.org/wiki/What_is_a_System%3F

The System of Systems Methodologies

I am proposing we learn about SSM next.  I think it an appropriate method to support us in commissioning health services.  To give some perspective of where it sits in relation to other approaches, here is a very nice table called the System of Systems Methodologies (SoSM) created by Robert L. Flood and Michael C. Jackson.  It’s described and explored in their excellent book, Creative Problem Solving: Total Systems Intervention (I just checked and there are some second hand versions of this available for just £0.01 plus postage.  Why not treat yourself).  It also gives a good description of what Systems Thinking is and is not, as well as describing a variety of approaches and in what contexts it is most appropriate to use each.  I must admit I’ve copied this version of the table (to save me re-drafting it) from this rather good blog post about Critical Systems Thinking, another approach:
http://wulrich.com/bimonthly_november2012.htmlSystem of Systems Methodologies

For now, we’re in the Pluralist/Complex Zone

As commissioners, when we come to design new services, or intervene in existing ones, I think we’re very much in the pluralist/complex zone. Pluralist, because not all parties involved are directly under our control and will have different views, interests and motivations.  It is likely those interests are compatible though and an accommodation can be found, so ours in not a “coercive” environment.   It’s “Complex”, because as we’ve discussed previously, the problems we face in commissioning and intervening in services are “Wicked” in nature.

Having said that, if we find ourselves redesigning parts of our own or other organisations, we will likely shift to the left, a “Unitary” environment.  In that case, we would find a Cybernetic approach like the Viable Systems Model useful.  And if we find ourselves doing Lean, or Quality Improvement work within a single organisation we would drop into a less complex, simple/unitary environment and find an approach like System Dynamics useful.

The value is in matching approaches to contexts, not in the approaches themselves

To finish, I just want to make it clear that this System of Systems Methodologies is in no way a hierarchy.  I’ve observed some practitioners who tend to specialise in one approach, come to view their favoured approach as the “right” or “best” way to do Systems Thinking. I’ve also observed a kind of perception that there is more kudos and prestige in being involved in problems and approaches that are sited in the “Complex” domain.  I suppose it’s not helped by terminology such as “Simple”.  Perhaps we imagine that the less capable people deal with the “simple” problems, whilst we more impressive folk deal with the “complex” problems.  I think this is an unhelpful and wrong view.  As the SoSM shows, it’s about horses for courses, and selecting the most appropriate method for the problem you’re facing.  In our working lives, we’re likely to face organisational problems in all six of the zones.  Let’s just hope there aren’t too many in the Complex/Coercive space.

I’ve said we’re going to look at SSM next.  It seems to be the most appropriate approach for us, given our context, but I don’t want us to become attached to it, or personally identify ourselves with it.  I want us to be open to all approaches and to even get to the point where we are able to mix them.  We have to start somewhere though, and the best place for us to do that, seems to me to be with SSM.  Let’s see where it takes us.

Week 15: The Holistic Requirements Model…

Hello STA fellows,

…is more fun than it sounds…..

As you know, the path we’re following through the world of Systems Thinking is a winding one with all sorts of interesting diversions along it.  In the spirit of VUCA, It’s never linear or predictable. With that in mind, I’m going to confess immediately that we’re changing the plan for next week’s session.  We’d intended to talk about the Joe Edelman talk I sent out a link for last Saturday, but we’re going to delay talking about that until the session on Thursday 25th August.

…So much so, we’ll do more next week

Instead, those of us who could make it to the group yesterday decided it would be best to use next Thursday to continue our discussions on the Holistic Requirements Model (HRM).  There’s more to do in classifying the requirements for our allotment.  Actually, we barely began the task yesterday.

What did we do then, those of you who couldn’t make it will be asking.  Well, we actually had a very productive and enjoyable session.  It was a relief, as I’d been expecting it to be quite difficult, as I’d found the reading difficult to fully absorb and apply.  This is a more detailed, technical and conceptual approach than any others we’ve tried so far I think.  To remind you, here’s the HRM:

Holistic Requirements Model

Our dear friend, the toaster

We spent the session discussing the model, the different types of requirements and then running through the example Stuart Burge uses in his paper, our dear friend, the toaster.  This was a lot of fun.  A bit like doing a quiz and we got into a bit of a flow with it.  Here’s the toaster table we ran through including the correct classifications and reasons:

Toaster Functional & Non-Functional Requirements

Submitting to thoughts of functions

It was a useful exercise and we began to see ways we can use this model to gain a deeper understanding of the “purpose” of services we commission and the functions that make up those purposes.  It pushes us to think in terms of functions and constraints around those functions.  This is a very different way of thinking for us.  The advantage, we thought is it allows us to let go of thinking about solutions we’re predisposed to and makes us think about what functions are necessary to address the problem, or to use the ligo, Operational Requirement.  

It also challenges us to be more thorough in our assessment of what functions are needed, what our expectations are around performance and what the constraints are.  I suppose this kind of gets done in Project Management approaches, but not as thoroughly or in as structured a way I think.  The beauty of the structure, is it also highlights where you’ve missed something. It’s deeply logical.  We like this approach.

Watch your verbs

Language is very important in defining requirements.  Functional Requirements need to be constructed from a verb and a noun.  We looked at the different types of verbs Stuart says are “useful” for defining Functional Requirements and those he says are not and can lead to the creation of “pseudo functions”.  We had to laugh, as those in the “pseudo” category actually look a lot more familiar to us in the language we use than those that are “useful”.  Here’s a list of the types of words we’re not supposed to use:

Achieve Allow Appoint Conform Cope Enhance
Exceed Facilitate Improve Meet Provide Promote

Hmm, all very familiar.  And here are some examples of words that are “good”:

Absorb Accelerate Access Act Activate Actuate
Add Agitate Adjust Advise Alert Align
What’s the truth?

Sam pointed out that in our defence, the “good” verbs are “hard” and specific and can be difficult to apply in our human world of health services, where things are rarely clear cut.  We thought this might well be right and actually the not so “good” verbs might be more appropriate in our field, than they are in the design of products perhaps.

Now, are we just making excuses for ourselves, or is it much harder to use these harder, tighter verbs when talking about human centric services. Desirable outcomes are subjective and and it may or may not be possible to diagnose and treat?  I don’t know.  This is something for us to explore.  Now, if anyone reads this and thinks they know the answer, or simply have a view, please write something in the comments section.  We’re open to having a discussion here.

This talk of “hard” words makes me think about the distinction between “hard” and “soft” systems approaches.  The type of requirements classification we’ve been doing here seems to be found more in the area of Systems Engineering than Systems Thinking.  That is to say, it appears to be more often and more readily applied to “hard” rather than “soft” problems.  We haven’t really spent much time discussing the differences between hard and soft systems approaches, but we did touch on it in this session.

A glimpse of SSM on the horizon

We’ll explore this in much more detail in time and we will learn and use Soft Systems approaches, including Soft Systems Methodology (SSM), as they’re the approaches best suited for the world of wicked problems.  So far, we’ve been warming up for that and learning the basics of systems concepts to prepare us.  If you want to get ahead of the curve though, why not watch this 15min video of Peter Checkland, the originator of the SSM approach, talking about it’s origins.  It’s worth watching:

One thing I’ve been wondering about, and want to look into further, is how we integrate this approach to requirements modelling with a soft systems approach to defining system requirements and functions.  How do you accommodate the multiple perspectives and interests at play in a wicked problem situation and use this kind of structured method.  We’ll see.  It’s not the way it tends to be done, but I do like the HRM, so want to see how far it can used.

Back to the trees and the allotment

Back to yesterday’s session.  We began to look at our allotment Tree Diagrams towards the end of the hour and began to classify the functions and other requirements on them into the HRM format. We didn’t get far though because we ran out of time.  It became clear it wouldn’t be an easy task.  It’s hard to get your head into this fairly abstract world of functions when you’re so used to inhabiting the world of things, and when you already have a physical solution in mind.  I’m looking forward to picking it back up again on Thursday.  In the meantime, please reread the the HRM paper, and have a think about the functions of the allotment and how we should structure them.

I’ve realised I’ve not covered another important area of the model we discussed, that being its recursive nature and how you use it as you go down the layers of functionality within a system. It’s late though, and we can go into that again next week.

OK, enjoy your weekend!

Tim

After a break, it’s time to tend the allotment

Good evening Systems Thinkers,

Big thank you to Gary Smith

Yesterday, we were extremely fortunate and privileged to have Gary Smith come to speak with us.

Gary is a seriously bright guy.  I already knew that, but what I hadn’t quite appreciated is just how deep a systems thinker he actually is and in particular, his incredible appreciation of systemic human interconnectedness.  Thank you Gary, I feel like I was missing something important that you’ve helped reconnect now. 

The session has given me a jolt and left me asking some questions about the direction we’re taking.  Perhaps we need to mix in more systems theory and philosophy and investigate the emotional and sensory apsects of being a good systems thinker, as well as plugging away with the practical tool kit we’ve been learning.  You thoughts are welcome.

I’ll write up a full reflection on the session and get it posted.  If you were there, and would like to add your own thoughts, please do note them down and let me have them.

Harmonised Requirements

Now, I know you’ve really missed having homework the past couple of weeks, so here is some for next week’s session.  I propose we revert back to our plan of do a show and tell of the two purpose Tree Diagrams we built.  To help us in our discussions about them, it would be good to improve our understanding of defining different types of Requirements.

I  realised my understanding of how to define and classify requirements isn’t up to scratch and that left us floundering a little when trying to do it, so if we can all read the linked document below and learn together, that will be great.  So, here’s the reading, the Harmonised Requirements Model:

http://www.burgehugheswalsh.co.uk/Uploaded/1/Documents/HRM-Tool-Box-V1.0.pdf

The Harmonised Requirements Model is quite a technical approach and there’s quite a bit of detail to digest and understand in this paper, so please do try to read it a couple of times, and not at the last moment.

Hard or Soft

This is an approach from the “hard” side of systems approaches and more commonly used in Systems Engineering of physical systems, rather than the “soft” approaches we are focussing on for use in systems involving human interaction, or Human Activity Systems as they’re known.

I think that is OK though.  It’s certainly OK to use this approach when you’re designing a stand alone service I think and the problem is relatively tame. That may or may not be the case with our allotment example. We can discuss that.

I also think this is a very helpful approach to help us gain a deeper understanding of requirements that relate to function, operation, performance etc.  It will give us a better understanding of how to describe systems and their purposes, before we get into the more comprehensive “soft” approaches.  This is should give us a good grounding.

So, enjoy your weekend and i look forward to seeing you next week.

Tim