Week 27: Systemigram to Root Definitions – The next step

Hello fellow Systems Thinkers,

We had a good meeting yesterday.  It ended up being a session of two halves.  In the first, we discussed the Systemigram  that resulted from the previous week’s meeting.  In the second, we began to venture into creating Root Definitions for the “purpose” of the system.

Systemigram time

To kick off, I asked what the group thought of the Systemigram I’d worked up based on the Rich Picture drafting we’d done in the previous week’s session.  To remind you, here it is:

Manorwood Canteen Systemigram
Manorwood Canteen Systemigram

The feedback was positive. Apart from one initial comment that is. Namely, Jan said;

“oh, it looks quite messy and confusing.”

This is a fair comment.  It does look messy, and this is the kind of reaction I’ve received when I’ve put similar system models in front of other people.  It’s a problem we systems folk have when trying to communicate.  Diagrams and models are a great way to express the richness and complexity of a situation in a coherent and understandable way, but they can still look complex.

Complexity is scary

However, once she’d spent a moment looking around the diagram and getting her bearings Jan took to it without any worry and was very positive about it.   I think a lesson for us is to think before putting these kind of things in front of people. Some love them, but many don’t, and I think we need to pick our moment.  i.e. when they have the time and space to sit back and engage with it, not when they’re in the middle of something else.

It’s funny, many people say they really like visual material and prefer it to wordy documents.  Hence the proliferation of infographics and pie charts in reports.  But when it comes down to it, some of those same people recoil when you put a systemigram, an admittedly complex looking visual aid, in front of them.   

My feeling is that what many people actually like is something simple that hides the complexity of reality.  They prefer to not have to think too hard.  There’s something comforting about a colourful infographic or pie chart. That’s fine, but the world and problems we deal with are complex, and there is no way to avoid that if you want to make a positive difference.  So the question is what can help us to understand and deal with complexity.  I think a Rich Picture or Systemigram is a very good way to do that.  But we need the right audience, at the right time.

Iterate between Rich Picture and Systemigram

Anyway, back to our Systemigram.  We felt it does a good job of expressing what’s going on within our “System of Interest”.  It perhaps doesn’t contain the information about how well things are working, what the motivations of actors are, and where the tensions are that a Rich Picture would, but it gives a good foundation to explore those things with.  I can see how one might initially get the stakeholders around a table to create a Rich Picture, but that it would be messy and ragged, and all of the relationships not fully formed.  It would need to be redrafted and redrafted iteratively.  This Systemigram format could be a good way to do that.

We spent some time discussing things we might add, remove or change about the Systemigram based on the reality of the situation it was trying to express.  I think this is an endorsement of the format.  It prompted discussions about the “problem space” and pushed us to explore further and identify areas and things we weren’t sure of.

Into the Root Definition

In the second half of the session we moved on to begin to explore the CATWOE mnemonic for drafting a system Root Definition.  What’s a Root Definition then?  It’s essentially a description of the “Purpose” of a system.  I’ve already referred you to Stuart Burge’s excellent paper on SSM, which gives a good definition of it, so here’s another source.  It’s a set of slides put together by a couple of chaps I’ve had some communications with. They’re good slides, with some nice examples. I like them. There’s a lot of them though, so take some time and have a browse through.


We’ll be working on Root Definitions using CATWOE for a number of weeks I think, so I won’t’ go into too much detail tonight.  Yesterday, we began by thinking about and identifying the stakeholders our Systemigram had uncovered.  They will fit into the Customer, Actor, or Owner, in different combinations depending on what Transformation we are looking at within the system.  We’ll get into that all in much more detail in the coming weeks.

Where’s the W in Prison?

For now, I’ll just highlight the importance of the Weltanschauung, or Worldview as we’ll probably refer to it (although Sandra may have a view on that).  This is about the point of view from which we view the purpose of the system.  Not just who the stakeholders are, but what their motivations and beliefs are. This extracted slide from the slide set above give a nice example of different Ws for a prison:


There are lots of possible Ws at play in our canteen/meals on wheels system.  They might include the Local Authority’s desire to comply with statutory requirements on it, a belief in the social value of providing decent rest and food facilities for staff, a sense of duty to care for immobile people in the community, etc, etc, etc.  We’ll dive in further next week.

OK, that will do for now.  I wish you an excellent weekend.


Week 17 Part 2:  The relationship between Quality, Grade and Requirements….

…. and why being clear about each matters

This post is a catch up from week 17 where we had a spontaneous discussion about the relationship between quality and requirements and why improving the grade of a product or service will normally add cost, but improving quality will normally reduce cost.

The idea that increasing quality reduces costs seems counter-intuitive, but that is only because we’ve not understood what “quality” is, and importantly, how it is distinct to “grade”.  So here are some definitions of each from ISO9001, as defined by the International Standards Organisation (ISO):

Some definitions:

Requirement:  A need or expectation that is stated, generally implied or obligatory.

Quality:  The degree to which a set of inherent characteristics of an object fulfils requirements.

Grade:  The category or rank given to different requirements for an object having the same functional use.  For example, the class of airline ticket and category of hotel in a hotel brochure.

-Thanks to the International Standards Organisation (ISO) for the definitions. (https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-4:v1:en)

And for clarity, “Object” is defined as:

An object is any entity that is either conceivable or perceivable. Objects can be real or imaginary and could be material or immaterial.  Examples include products, services, systems, organisations, people, practices, procedures, processes, plans, ideas, documents, records, methods, tools, machines, technologies, techniques, and resources.”  http://www.praxiom.com/iso-definition.htm#Object

Given that we are using ISO9001 definitions, I suppose it’s only right to explain a little about what it is.

“The ISO 9001 standard provides a framework of globally recognised principles of quality management, including: customer focus, leadership, involvement of people, process approach to management, continual improvement, factual approach to decision making and mutually beneficial supplier relationships. These are also known as the eight key principals of quality management.”  – http://certificationeurope.com/what-is-iso-9001/

These definitions of Quality and Grade are applied across the world in the discipline of Quality Management.  In manufacturing, services, agriculture and pretty much anything.  Some industries have specific variants on the base standard, for example I was involved in managing an AS/EN9100 Quality Management System (QMS) when  I worked in the aerospace design and advanced engineering  sector, but that standard is essentially ISO9001 with some industry specific variations.

ISO9001 isn’t perfect, but it’s pretty good

It’s not all good news with these standards.  They can be bureaucratic to administer and whilst that’s fine  for a stable organisation in a relatively stable market, for a more dynamic organisation  in unstable markets, it can be difficult, if not impossible to maintain all company procedures appropriately documented and audited, as certification  requires.

That was certainly my experience later when playing a leading role in transforming a construction company into a primarily logistics oriented one as a result of the highly unstable market conditions that existed post the 2008 financial crash; and the need for us to develop new services for new customers to stay in business.  The idea of  maintaining a fully compliant ISO 9001 QMS in that situation  is hard to square away. Similarly, it shouldn’t be allowed to constrain any positive change or transformation in an organisation.  It is not intended to, but through  it’s (inappropriate) application, that can be problem.

So, it’s not without it’s problems, but at it’s heart it is a sound approach. For our purposes, what I think is really useful and important is how it defines Quality and Grade. To reiterate the definitions above;

  • Quality is about the degree to which requirements are fulfilled.
  • Grade is about what the requirements actually are compared to the requirements for other products in the same category.
  • Quality is independent of Grade!
Do we mean grade rather than quality then?

People often confuse the two, or simply don’t know there is a distinction.   I’ve foud this to often be the case in healthcare. In a sense, that’s fair enough.  Industries can use whatever terminology they like to mean whatever they like.  However, if “quality” means “grade”, then what word is used to refer to “quality”, or rather, services that don’t fully satisfy requirements? I’m not aware there is one.  

In practice,  I think they’ve been merged into a single concept. And maybe that’s ok. After all,  we are offering a standard service to all.  A single grade I suppose.  The difficulty,  is that it’s not entirely clear that we’ve formally defined, recorded and agreed the requirements  or purpose of our services and systems.  We found it hard to do this for a GP practice if you cast your mind back, and we weren’t aware of a Requirements Document we could refer to.  How do we know if we are fulfilling requirements if we haven’t defined and documented them?  

Leaky windows

It’s not unusual to hear people in our and  other industries say “we can’t afford to provide a higher quality service.” or similar.  This might be a problem though.  If we understand quality to be about the degree to which requirements are satisfied, rather than what the requirements are, then we can see that ultimately we can’t afford not to increase quality.  Why is this?

If the basic requirement of a car is to get the driver from A to B in comfort, and there is an aspect of it, a leaking door seal perhaps, that prevents it from  doing that, then the car will be returned to the manufacturer to be repaired.  Or the problem may be picked up by “Quality Control” before it leaves the plant and repairs are made at that point. There are costs associated to this.  The costs of identifying the problem, and then fixing it.  These costs are specifically associated to poor quality.  You have to fulfil requirements.  There are no two ways about it. You have to.  And if you don’t, you will have to pay to correct the problem.

Providing it satisfies the requirements of a typical buyer, a brand new Dacia without a leaky window is actually a higher quality car than a brand new Rolls-Royce with a leaky window.  Presuming both sets of buyers have a requirement to arrive at their destination dry.  Of course, the Rolls-Royce is a far higher “grade” of car though. It will have all sorts of additional requirements on it the Dacia doesn’t, such as speed, comfort,  the degree to which it impresses your mates, etc. Quality and Grade are independent of one another.

Increase Quality to reduce cost

In health services, there will be a myriad of requirements on any service, but for the sake of argument, let’s assume a basic and fundamental requirement on all health services is to diagnose and cure, or treat as far as is medically possible (given  NICE sanction) a presented condition. Ultimately, this has to be fulfilled, or patients will unnecessarily die, or live with  unnecessary suffering.  They and their relatives will know this, and so they will keep presenting, or be passed around different parts of the health service until the requirement is satisfied (assuming it can be).

This is all the cost of low quality.  And worse than that, if the requirement isn’t fulfilled quickly, their health can worsen, and ultimately cost more to put right.  I have personal family experience of this, and sadly, I imagine many others do too.

So, increasing quality in a health service is about identifying and treating conditions as quickly and appropriately as we can, whilst treating people as individually and kindly as possible and it is not about “gold plating”. That would be “Grade”.   When we talk about “getting things right first time”, this is what we are talking about, Quality.

A tough job in public services

I don’t underestimate how difficult this is to do in public  services though. I think one particular challenge we have is defining the requirements and in turn  the grade of the service we should offer.  We all have individual personal expectations and requirements for all things that we buy and consume.  Ideally, all products and services would be produced for us individually.  This would not be economical though.  To get around this, companies will segment their customers into groups, generalise requirements for each of those groups and produce offerings for each and importantly, charge accordingly.

If we think about laptop computers, manufacturers will produce a wide variety of models, each aimed at a different category of customer.  The medium performance, but robust build quality for the person who needs it for work, the cheap and cheerful basic machine for the home user on a budget, the high performance machine  for those who work with graphics, and the good performance in a shiny, slim package, for the trendy person who wants to impress their mates.  Each of the options described will be priced differently to reflect it’s grade.

One difficulty we have in public services is that we need to offer a standardised service for all.  We can’t “charge accordingly”. It’s not possible to do this, and satisfy everyone’s requirements, and so there is a lot of compromise and accommodation going on along  the way and effort to try to provide services that more or less satisfy most people’s requirements. A kind of service for the “average” patient.  

For health services, the core functional requirement of making people better will be the same irrespective of grade, but there will be decisions made around waiting times, length of time it takes to treat, and other service elements like comfort of facilities, and where services are provided (hospital, GP practice, or at home) etc. i.e. Non-Functional System, Non-Functional Implementation and Non-Functional Performance Requirements.

It seems to me that all of this requires debate at national and local levels between patients, taxpayers, government, commissioners, providers, suppliers, lobbyists, activists and probably others too, to come  to an accommodation over what the grade of services should be. This is no mean feet! There are a lot of stakeholders to accommodate in  public services.  It’s a much bigger job than a manufacturer has when categorising customers and  defining their requirements.  

This does beg the question how one goes about defining the concept of “Value” in health services, but let’s leave that for another day.  There’s also the  question of the role “Outcomes” play in all of this. A central one. We should also need remember what Jean Boulton had to say about the things that really matter often can’t be easily measured quantitatively. How does that fit with this approach to Requirements and Quality.  Lots of swirling questions for us to keep in mind as we continue this journey.

Does it really matter?

Why does all of this matter to we Systems Thinkers.  Well, as we’re discovering, “Requirements” are a very close relation to a system’s “Purpose”.  So quality is about the degree to which something  is “fit for purpose”.  Before we can determine whether a product of service is fit for purpose, we need to have a clear understanding of exactly what it’s “purpose” is, and that is exactly what we have been doing in this group.  You may not have realised you  were learning  about “quality” as well as problem solving and design, but you are.

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!


Is Anything Worth Maximising?

Good afternoon Systems Thinkers,

More homework

My goodness, you are lucky.  I’ve got more homework for you.

Don’t worry though, this isn’t for this week, it’s for next (18th).

Yesterday, I picked up a tweet from @kailashawati that linked to a video presentation by Joe Edelman called “Is Anything Worth Maximising?”.  I really enjoyed it.

The Heretic’s Guide to Best Practices

I’m aware of Kailash, from having read is co-authored book, The Heretic’s Guide to Best Practices.  Look here.  It’s a brilliant book and a favourite of mine.  It doesn’t talk much about “Systems Thinking” per se, but at the same time, it’s very much about systemic approaches to solving complex organisational problems.  I can strongly recommend it and believe we can all become better managers if we follow even a fraction of its advice.

Can we measure outcomes?

Anyway, back to the video, well, it’s just a talk really, but with some slides and graphics.  It’s about the way many organisations currently use metrics to drive their business that are not necessarily aligned with our, the customers’ real needs and desires, and gives some ideas about how this might be changed.

It really struck a chord for me and made me think about the work we’ve been doing in the group around “Purpose”.  The question is what is the “purpose” a customer, or patient in our case, is seeking from the system it’s accessing (YouTube, NHS, whatever…) and how do we know what “Outcomes” they are seeking from that service, and then how do we know we are fulfilling them.

For me, these are massive questions and go to the heart of what we’re trying to do with our group.  It also resonated with me after Jean Boulton’s talk last week, where she reminded us that organisations often over measure the wrong things and that often, the things that really matter simply can’t be measured.

I must admit I don’t know anything about Joe Edelman, but will find out more.  The talk is very good.

So, see what you think and what it brings up for you and our roles as health service commissioners.  I look forward to talking about it.  Here’s a link to the video:


or a transcript:


Please watch the video in advance of our session on the 18th August.  It’s about 45 mins long and covers quite a bit of ground, so do put some time aside to watch it.  Having said that, I listened to it while having breakfast with the children this morning, and seemed to manage both (although my family may disagree.  Sorry), but will need to watch/listen to it again for sure.

Enjoy the rest of the weekend,


Week 11 – Growing Trees

Written 19/07/2016

Dear STAers,

I’ve been modelling

Sorry I didn’t get this message out on Friday evening as per usual. I needed to transfer our paper based Tree Diagram we drafted in the session into an electronic form and so did that at the weekend.  I found a nice web based system called draw.io for building these kind of hierarchical diagrams.  Here is the model I built:

Allotment Purpose Tree Diagram
Allotment Purpose Tree Diagram – First Cut
To step back to last week’s session though, here’s a recap.

We met with the intention of turning the outputs of the previous week’s session where we created an Affinity Diagram into a more structured expression of the system purpose, a Tree Diagram.  If you recall, the objective of the Affinity Diagram was to generate system requirements in a semi structured way.  It was fun and very productive.

The idea of the Tree Diagram being that we wanted to structure those requirements into the overarching purpose and sub-purposes, or functions, as Stuart Burge had done with the toaster example in his “Purpose” paper (attached).  This would then give us a model to test against the actual allotment, to see whether it is fit for purpose, or indeed to design a new allotment.  It’s worth remembering this would only be from the allotment users’ perspective at the moment though.

The writing’s on the wall

We used the same paper covered wall as for creating the Affinity Diagram and set about creating post-it notes with the requirements on.  We could have saved ourselves some effort if we’d had the post it notes we’d used the previous week.  Worth remembering that.

We then began to create our tree diagram from them.  The main tasks were creating a structure of functions, and then putting the requirements below each function.  This included removing duplicated requirements.

Surprisingly difficult

Compared to the Affinity Diagram, we found this exercise to be pretty difficult.   I think these difficulties were:

It’s just quite a difficult task.

I was pushing for us to think in relatively abstract terms of functions, rather than things and differentiating between functions and requirements.  On reflection, I don’t think I understand the difference well enough, so there’s some more reading for me to do there.

Particularly when you have so many people in the room who need to agree. I think there were 9 of us last Thursday.  Perhaps first cut at building a tree diagram might work better with a smaller team of maximum of 3 people.  It can then be taken to the wider group for feedback, correction and to identify things that have been missed.  It was hard to keep everyone engaged and keep conversation focussed on a detailed task like this in a larger group.

Following from that, there were some tensions around the inclusion or not of some requirements.  One group members drew attention to her attachment to her own contributions and how she felt hurt when they were removed or disagreed with.

These are all learning points for facilitating and creating this kind of diagram, so even if the experience wasn’t as fun and free flowing as it had been the previous week for the Affinity Diagram, it’s very rich learning none the less.

There’s more to do

There is still work to do on it, and I suggest we use this week’s session continue with that.  It would be helpful if you could re-read Stuart Burge’s “Purpose” paper (here) before Thursday, just so that we can refresh ourselves a bit with the concept of purpose and sub-purpose etc.   I think that would be helpful.

I’m wondering, if once we’ve finished this diagram and are happy with it we should try to repeat the activity, but from the point of view of other stakeholders.  What do you think?

A volunteer is required

Also, I’d like a volunteer please.  It may be a few weeks before we get there, but we are going to move onto Soft Systems Methodology (SSM) and get to grips with it before trying it out on a wicked problem case study.  It’s a methodology that involves a sequence of steps, an initial one being the creation of a Rich Picture.  I think that being able to facilitate the creation of Rich Pictures is a skill all of us commissioners would find highly beneficial.  It’s a powerful approach to problem space exploration.  So, would one of you like to step forward and offer to facilitate a session where we work to create a Rich Picture of the allotment system together?  It’s still a few weeks away, and maybe even a month, so there’s plenty of time for us to gem up on it and practice a bit in advance.  So, who’d like to take this opportunity?



Week 8 – VUCA Heavy, Not VUCA Lite

Written 27/06/2016

You can’t tame Wickedness by presenting a binary choice

Thanks to Jean Boulton for the title of this message.  She has very kindly agreed to come and talk to us on the 28th July, so please do put that in your diaries.

In my last message, when I joked about being in or out of the E.U., I promised that this wasn’t a political group or communication, and it isn’t.  However, I can’t not comment on the referendum  on Thursday and the events that have unfolded since though.  From a systems perspective that is.

I’ve been particularly struck by the “wickedness” of the problems we had to grapple with in making our “in” or “out” decisions.  The problems we have been trying to solve with the simple binary choice we were given of “in” or “out” are highly wicked in nature and encompass a huge amount of Volatility, Uncertainty, Complexity and Ambiguity (VUCA).  If we remind ourselves of the defining characteristics of a “wicked problem”, I think that we can recognise all of them in the choice we were asked to make last Thursday.

  1. The problem is not understood until after the formulation of a solution.
  2. Wicked problems have no stopping rule.
  3. Solutions to wicked problems are not right or wrong.
  4. Every wicked problem is essentially novel and unique.
  5. Every solution to a wicked problem is a ‘one shot operation.’
  6. Wicked problems have no given alternative solutions.

I suppose this is why referenda are not a common feature in our decision making.  This one certainly seems to have been far too simplistic a choice to address the deeply complex social  and economic challenges we face and this binary, linear choice around a supposedly singular issue was created to address.

And now that a “right” or “wrong” decision has been made, what are we finding?  This simplistic approach to decision making has led to a situation where we have far more Volatility, Uncertainty, Complexity and Ambiguity through unintended consequences than we did before we made it.  That’s the nature of “wicked problems”.  Let’s now hope that a more systemic approach to dealing with the plethora of amplified and interlaced wicked problems we now face can be taken.

SCiO do VSM very well

So, back to normal service.  On Saturday, I went to London for a SCiO organised Viable System Model (VSM) training workshop.  It was excellent and I’m very glad I went.  I had found VSM slightly impenetrable and esoterically theoretical when I looked at it previously.  I was wrong to find it that way though.  It’s actually deeply practical and was explained in a way that made it immediately accessible and useable.  I’ll be very happy to talk to anyone about it and share my experiences if you would like.  I like my coffee black and without sugar.

Drawing a boundary is not easy

Thursday’s STA session was a productive one.  We reviewed our context diagram and discussed where we should redraw the boundary for our System of Interest.  This prompted interesting discussions and it became clear that choosing what should be in and what should be out makes a significant difference to the “purpose” of the system and how we view it.

Rabbit Hill - System of Interest

So, even though this is just an exercise and we are not trying to solve any real problem, it became apparent that when we do begin to use these approaches for designing and modifying services, we will need to pay careful attention to where we decide to draw our system boundary.  Serious thought about the implications of what we put inside and what we leave outside will be needed.  I think this is a helpful approach.

Thinking about how to think

Indeed, the interesting and powerful thing about this is that we are now thinking about how to think about problems.  We have inserted an extra step into our thought process and rather than just diving into trying to solve a problem, we are carefully thinking about what the problem is and how we should view it. That can’t be a bad thing.

As last week’s note suggested, now we have defined what our system is, we will now return to defining its purpose.  We are going to use a more thorough approach to doing so than simply using the 18 word statement as we have so far.

Affinity Diagram

We are going to use an Affinity Diagram to define the functional requirements (or sub-purposes) of the system and then use a Tree Diagram to structure them.  I’ve attached Stuart Burge’s papers on those diagrams for you.

Happily, our fellow Systems Thinker, Julian, has facilitated the building of Affinity Diagrams previously and has kindly offered to facilitate Thursday’s session.  He’s very enthusiastic about the usefulness of this diagram and it promises to be good session. We are going to follow the “in silence” version of the approach, so if you are going to be there, do please read the briefing paper in advance and also try to arrive on time as I think we will try to cover a lot of ground in the hour.

I hope to see you there.


Week 7 – Who’s In and Who’s Out…….

….Of the System of Interest (not the E.U. (this is a non-political group)).

Written on 17/06/2016

Our first model – A Context Diagram

So, this week we built our first model.  A Context Diagram.  Much of the Systems Thinking approach is about building models of various types, so this will be the first of many we build, and this particular one made for a very good starting point I think.

We created the diagram on a large piece of paper which we put in the middle of the table we were sitting around.  The conversation we had felt like a kind of structured brainstorming session and it was interesting to see the way it highlighted things that we didn’t know about our wider system and how it works.  For example, it became clear that I didn’t really know how our allotment association works and exactly who owns the land, what arrangements are, and even the legal form of the allotment association, of which I’m a shareholder and whether liabilities are limited or not.  I need to go away and find out more.

What’s our System of Interest

It also pushed us to make decisions about what our System of Interest is.  What was inside and what was outside.  This is where the “Thinking” in Systems Thinking comes in.  We are having to think not only about problems and solutions, but about how we are going to frame and view the problem/situation/thing.  I think this is an important point.  It’s the conscious and documented decisions we are making about what we are interested in and understanding how they affect the System of Interest if we leave them in or out, that is beginning to set this approach apart.

Things or Functions?

One possible trap we fell into was naming some stakeholders/things in their object, rather than functional form.  For example, we created a terminator for the Allotment Association and Committee and also for the Council.  If we we’re designing a new allotment, rather than exploring the situation as it is, it would be better to have a terminators for functions, rather than organisations, so instead have “management” and “ownership” for example, as they are functions that will need to be fulfilled, because at this stage we wouldn’t need to commit to “how” those functions are to be delivered.  But, we’re exploring the existing system as it is, so it’s OK to have done it the way we have I think, but this is something to remember for the future.

Cmap – Free and fun

Last night, I turned our drawn diagram into a computer based diagram using a program (or “App” for the younger and more trendy members of our group) called Cmap.  It’s an excellent tool and I’d urge you to have a look.  There are several similar free tools, including InsightMaker and Kumu, but I particularly like this one because it works as both an we based application and a downloadable computer based program and diagrams can be saved online in “the cloud” or on your machine.  It makes it a very versatile and practical tool.  It’s easy to pick up and use, and also to print diagrams from.  The printing of diagrams is a bit of a problem in Kumu and Insightmaker and some other tools.  They’ve been designed with collaborative working on/from a screen or projected image in mind, rather than with ability to print off diagrams.  Anyway, Cmap ticks all the right boxes for me, and is free, so have a look and play with it.  Here’s a link to the website:


And here’s  the model we built.

If you want to view a larger version, go here.

Context Diagram - Rabbit Hill

Here is another copy of the diagram.  I’ve redrawn a possible new  system boundary around what we thought was probably our System of Interest. Click on the picture to enlarge.

Revised Rabbit Hill Allotments System Boundary
Revised Rabbit Hill Allotments System Boundary

We started the exercise with the premise that the System of Interest is just the physical allotments and that everything else was outside of it and in the “context”.  It became clear as we built our Context Diagram that this boundary was probably inappropriate and we would need to include some of the key actors, including the allotment holders, association and committee and also the local Council within our System of Interest.

I think an argument could also be made that we should include services and transport infrastructure.

We’ll debate the boundary

I suggest we begin next week’s session by looking at this boundary and deciding what we want to put inside and what we want to leave out.  We’ll need to justify why we are happy to leave out the things that we do.  For example, suppliers of seeds and plants are so ubiquitous locally as physical shops and as online retailers and we don’t have any control or influence over them, it’s probably reasonable to leave them outside.  We need to consider, justify and document our decisions though. Again, we’re “Thinking”.

We can then draft a new Context Diagram with our newly defined System of Interest in the centre, and then any new stakeholders, functions, and things that become apparent.  There may not be any, or many, and this shouldn’t take long, but I think it’s worth doing to double check we’re happy with our new boundary, wherever that is.

Changing the boundary changes the purpose

Then, we can return to our other favourite subject, “Purpose”.  We will need to define the purpose of this new System of Interest.  The interesting thing here is that our decision/s about where to draw our system boundary will have an effect on the Purpose of the system.  We should take some time in the session to reflect on this.  And also, to think about why it’s important to define Purpose.  For one thing, we can never know if a systems is performing well or not, if we don’t know what it’s purpose is.

To help us define the Purpose, we can use our old friend, the “18 Word Statement”, but I’d like us to also start to get into defining the sub-purposes / functions.  Looking through Stuart Burge’s material, it looks as though the “Tree Diagram” is a nice way to do this.  He does recommend we put together an “Affinity Diagram” before doing so though, so this week’s homework is to read his papers on both.

The Affinity Diagram paper is here.

and the Tree Diagram paper is here.

I look forward to seeing you next week and picking this up again.


It was a bit VUCA, wasn’t it? – Week 6

Written 10/06/2016

Welcome to VUCA

Well, that was an interesting week.  In the spirit of her interest in the concepts of volatility, uncertainty, complexity and ambiguity (VUCA), Jean Boulton wasn’t able to get to us for our session on Thursday, so we had to respond by spontaneously improvising an alternative session.

Get your Wellies

The inspiration for what we should discuss came to me whilst I was watering the beds at my allotment on Wednesday evening.  The obvious system for us to start unpicking and understanding the allootments my plot is part of.  As we’re being anonymous here, let’s make up a name and call them Rabbit Hill Allotments.

What’s the Purpose of an Allotment?

We spent Thursday’s session returning to our favourite topic of trying to understand “purpose”.  We came up with 2 possible “18 Word Statements”.  They are:

“An allotment is a plot of land made available for individual, non-commercial gardening or growing food plants.”  (from Wikipedia).

“Community (council) owned accessible and fertile outside space for the growing of produce by those interested in doing so.”

A Path Through the Allotments

They probably need more work, and we will do that.  We’ve decided we will spend the coming weeks discussing the allotments.  Initially, we will gain an understanding of the Rabbit Hill Allotments as a system, and then move onto a case study looking at the situation that existed a few years ago in Anonymous Land when there was an acute shortage of allotment’s and waiting lists were bursting at the seams, resulting in much dissatisfaction and considerable coverage of the situation in the local press.  A wicked problem.  We’ll look at the problem and use systems approaches, probably SSM, to pull it apart and work out a solution.  Let’s see if we come up with the same solution the council did.

Welcome to Context Diagrams

Before we do that though, we’ll spend a couple of weeks further understanding the Rabbit Hill Allotments as a system and next week will draft a “Context Diagram” to understand the system boundary, stakeholders and inputs and outputs.  So, this week’s homework is to read Stuart Burge’s excellent paper on creating a Context Diagram, a copy of which is linked here.   Do have a go at drafting a diagram yourself in advance.

Something to think about is from what perspective we’re building the diagram and viewing the allotments, even in terms of the “purpose”.  I suggest we take the perspective of an allotment holder, as it’s probably closest to most of our experience, or ability to imagine.  I’ve not drawn a context diagram before, so don’t know how much it matters whether we take a certain perspective, or try to be objective in our view of the system.  I suppose it will make a difference to where we draw the boundary, but let’s find out!

Purposeful Functions

I think we may return to purpose and more specifically defining the sub purposes, or functions of the allotments the week after as I think we’ve more work to do on that.  Here are some “functions” I’ve just noted down:

Ground for growing

Water supply

Access to Site

Access to individual allotments

Car parking

Collection of rents

Allocating of allotments

Waiting list

Management of allotments

Supports social interaction

I don’t know whether they are necessarily all “functions” as some could be “means of delivering functions”, but we can discuss that and come up with a tight set of system functions.

Think back to Stuart Burge’s example of a toaster here and how he set out the functions / sub-purposes and then looked at different ways for delivering them.

It’s Raining

I wish you an excellent weekend.  Looking out of the window here, I can see it’s started to rain.  That’s very good news for me and my allotment.  I can have an evening off watering duties!  What a wonderful start to the weekend, for me at least.


Swimming in the Sea of Complexity – Week 5

Fellow Systems Thinkers,

Before I recap on this week, I just want to remind you about the INCOSE talk coming up on the evening of 13th June at the Atkins offices in Aztec West.  The flyer is attached.  Do come along, it’s free, and should be a good evening.

Embracing Complexity with Jean Boulton

Secondly, Jean Boulton is very kindly coming to talk to us at next week’s STA session, so do try to get there, and also, do try  to get there promptly so we can really get the most out of the hour.  She will be talking to us about “complexity”, so for this week’s homework, I suggest we refresh ourselves with the Wicked Problems paper and also Jean’s paper on Complexity and Volatility, Uncertainty, Complexity and Ambiguity (VUCA).

So back to this week. It was a short week, but we still managed to pack in an excellent STA session.

There were six or seven of us, which was a nice number, and the conversation flowed.  I felt we’re really beginning to get some of the concepts we’re learning about and are managing to begin to change the way we’re viewing problems and even the world.  Well, if nothing else, we’re certainly beginning to change the way we view hand dryers.

Purpose, Emergence and Outcomes

We spent the hour exploring the concepts of “Purpose”, “Emergence”, and “Outcomes”.  In particular, I was interested to explore whether they are one and the same thing.  We continued to use the example of a hand dryer to explore them with.  It was an entertaining and insightful conversation.  I don’t think we came to an agreement on whether they are one and the same thing, or quite what the nature of the relationship between them is, but we certainly deepened our appreciation of them, and of systems more broadly.

Moving the Boundary

We played around with moving the system boundary and seeing how it changed our perception of what the system is and what we needed to consider.  For example, if the hand drying device is a paper towel dispense, then the system will need to also include a bin to put the used towels in and a person to refill the dispenser and empty the bins.

Conversations have continued around the office yesterday and today, and we’ve been talking about the need to “solve, rather than serve” problems.

Should we Serve, or Solve Problems?

So, the notion of needing a hand drying device is based on our view that we need to “serve” the problem of having wet hands.  If we take the view that we need to “solve” that problem, then we start to think of ways to clean hands without getting them wet.  If we can crack that, with some kind of ultraviolet bacteria zapping device, then we also no longer need all of the space consuming basins and expensive plumbing etc.  And that means we don’t need to dedicate nearly so much space to the toilet facilities in the building and can use it for productive office space.

We Need to Challenge Ourselves and Our Assumptions

Now, this is perhaps a silly example, and you’re no doubt saying, “but that technology doesn’t exist”, and “we’d still need some wet wash facilities for when people need to wash things from their hands rather than just sanitise them”, but I think it does show that we can get new perspectives of problems and solutions by using these Systems Thinking approaches.  Even if we simply ask ourselves, “what is the system”, and “what is it’s purpose” or “what is the problem we’re trying to solve” and then challenge ourselves on the answers we jump to, we can make big shifts in our thinking, and this should pay dividends when we apply it to our real life healthcare system problems.

Finally, I’ve recently joined the INCOSE Service Systems Working Group and will be attending my first meeting on Monday.  I’ll let you know how it goes and bring the learning back to you.  Here’s a link to more info, there’s a menu halfway down the page on the right with links to sub-pages:


Enjoy the weekend,


Dry Your Hands – Week 4

Written 27/05/2016

Dear Systems Thinkers,

I hope you’ve had a good week and are set to enjoy the long weekend.

Yesterday’s session was most enjoyable.  We were allowed ourselves the luxury of spending the first half of the session having an unstructured and insightful conversation about the NHS “system”.

The Purpose of a Hand Dryer is?

We then took the example of a “hand drying device” and tried to define its purpose.  I think we did a pretty good job with the following “18 Word Statement”.  So, the purpose of a hand dryer is to be:

“An affordable over the full lifecycle device to comfortably and hygienically dry wet hands within and acceptable period of time”

Now there are some variables in there to be defined, such as “affordable”, “comfortably”, “hygienically” and “acceptable period of time”, but that’s OK I think.  We can talk to our customers and find out what is acceptable/desirable for them within each of those areas and then design accordingly.

Funtions are More Difficult

We found that it became a bit more difficult when we then tried to decompose the purpose into functions.

If you recall, in his example, Stuart Burge used a toaster and split it out into the various functions.  It relied on the fact that making toast is always going to involve applying heat to bread.  However, with the hand dryer, there are a number of methods.  Indeed, we can apply heat and evaporate the water, but we can also blow it off, or absorb it off with a fabric or paper towel, or perhaps some as yet non-commercialised method we might come up with.

So, I think some good homework for this week would be to think about breaking the purpose down into functions in the way Stuart did for the toaster for our example of the hand dryer.

I’m looking forward to seeing/hearing what you come up with.  Enjoy “Thinking”.

I’d asked previously for you to also have a think about the “purpose” of a GP practice.

Does a GP Practice have a Purpose?

Our fellow Thinker, Dr.K, came up with the following “purpose” for Primary Care (doing it for a GP Practice was a bit tricky at this stage).  I think it’s very nice.  Once we’ve covered the hand dryer in our next session I’d like us to look at this and see if we think we might improve it, and indeed what the difficulties are we experience when trying to do so.  So, here’s Kevin’s 18 Word Statement.  Thank you Dr.K.

“To cost effectively enhance the health of a population through promoting prevention, treating illnesses effectively and referring appropriately.”

Over the weekend I will have a think about the best way to move on with “purpose” and some of the methods we can use for defining it in more complex situations (such as for GP Practices).  Rich pictures and root definitions spring to mind.

Even More from Stuart

Finally, I see Stuart Burge has been busy and has uploaded a load of new downloads to his Systems Thinking Tools page.  Have a look:


So, enjoy your long weekends and I look forward to hearing what Thinking you’ve been doing when we meet next week.