ASEC 2016

Hello Systems Thinkers,

A special guest….

The session yesterday was excellent.  We had a surprise special guest.  Well, a surprise in so much as it was arranged at the last minute.  The guest, was Matt, of the Royal Navy and MoD.  I’ve been talking to Matt about various opportunities and him attending a session for a little while, so when he got in touch yesterday morning to say he was available at the last minute, I of course jumped at the chance.

….and a trip to ASEC

I’ll write up a proper review of the session, including reflections from group members in the next week or so.  In the meantime, I thought I’d say a little bit about my trip to ASEC this week.  What on earth is ASEC I hear you say.  Well, it is the Annual Systems Engineering Conference which is organised by INCOSE UK.  It took place on Tuesday and Wednesday at the University of Warwick, and it was brilliant.

I’ve wanted to go to ASEC for a couple of years now, but haven’t been able to.  This year I got very lucky and was able to attend as a poster I submitted to the Academic Research Showcase was accepted.  I’ve become involved through STA in a pan European research project looking at different methods of innovation and how to both manage and teach them. The project is called the TACIT Knowledge Alliance.  Here is a photo of me standing next to the poster submitted.

TACIT poster
TACIT poster

And here is the poster itself:

TACIT poster
TACIT poster
So much good stuff

The event involved lots of talks and tutorials.  With several going on at any one time, choosing what to go to was not easy.  There were of course lots of opportunities to catch up with people I knew and also meet new people, including several good folk who are subscribed to this blog.  This was brilliant.  Spending 48 hours in the company of around 150 other people who were similarly into all things systems, was fantastic.  Really stimulating.

So, what were the highlights?  For me, I genuinely enjoyed every talk I heard, but I think the two standout sessions were the Service Systems Engineering Working Group session and also the Easy Approach to Requirements Syntax (EARS) tutorial.

The services working group

I was briefly a member of the Services Working Group earlier this year, but have had to step back from full involvement because of a lack of time.  It’s a shame, as it’s a fascinating and pertinent area, but it was great to catch up with where the group is at.  The group are looking at determining to what degree the regular INCOSE Systems Engineering (SE) approach (if there is such a thing) can be applied in the services domain.  We spent this session discussing the key differences between products and services and whether these matter when trying to use SE methods.  We worked on categorising services into various types based on different characteristics.

We only had an hour and a half, but the conversation and perspectives were fascinating.  In my view, services are all about the organisation that’s behind delivering them.  I think functional focussed approaches can be applied to the design of services, but I’m less sure about their applicability for the ongoing evolutionary development of them.  As we’re finding, our service design problems are often complex and wicked in nature.  I think Capability Engineering, and the approaches we’re learning about, which are better suited to dealing with socially complex situations are where we will also need to look. We’ll see.


Easy Approach to Requirements Syntax is a very neat way to write requirements.  It was created by Alistair Mavin. Who also ran the tutorial.  Alistair did a sterling job of teaching us this concise and robust way of writing requirements.  The word “easy”, refers to the difficulty of learning the method and language, rather than the actual job of defining requirements, which is never easy.

If you want to know more about EARS, here is a paper by Alistair I found on ResearchGate.  There are loads there, so have a look.

Easy Approach to Requirements Syntax

For me, a key insight I will take away from this session was something that Alistair said.  It was along the lines of:

“Customers don’t have requirements.  They have goals.  Systems have requirements.”

The example Alistair gave was of a car.for a fast car, a requirement might be that it can travel from 0 to 60 mph in under 6 seconds.  This would be a requirement of the car, a system.  It’s unlikely it would be a requirement of the customer though.  A customer goal might be to have a fast car that give a real thrill of speed when driven and impresses his/her mates.

The job of the Requirements Engineer is to take those poorly defined goals and turn them into technical requirements.  And if it turns out that producing a car that accelerates to 60mph in 5.8 seconds requires a larger and more expensive engine than a car that get to 60mph in 6.2 seconds, that requirement will need to be looked at and possible traded off to see if the customer goals can be achieved in a different way. Perhaps by adding some flashy chrome to the body work and tightening up the suspension.

What does this mean for us?

What does this mean for us in health services.  I’m not quite sure, so suggest we reflect on it and discuss.  It takes us back to the subject of patient outcomes.  How we determine what they are and then design systems that deliver them.  How do we determine outcomes, and then translate them into specific requirements for our systems?  This is a big question for us.

Back to normal

So, next week it’s back to normal. No ASEC, and no special guests.  We’ll get back down to Rich Pictures.  Please have a go at producing a new Rich Picture for the staff canteen.  Pick a stakeholder, or a perspective and have a go from that point of view.

In the meantime, enjoy the 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. (

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.”

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.”  –

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 17 Part 1: What is it about plans?

Dear STA Procrastinators,

Oh dear, I don’t know if it’s me, or if it’s us, but we just don’t seem to be able to stick to a plan.  The intention had been to run through our allotment purpose tree diagram and take the “requirements” listed on it and run them through the Holistic Requirements Model.  The expectation being that we will have omitted requirements, miss-named functions, i.e. not used verb-nouns, and won’t have defined all of the performance and implementation requirements.  Perhaps we’ve been procrastinating in not doing that job, we were supposed to do it last week after all, but the conversations we’ve had instead have, nonetheless been rich and worthwhile.

So, to get to the point, we didn’t have the allotment requirements discussion yesterday.  There were only a few of us able to get to the session, including a new group member, Mike, who asked a few pertinent questions, which led me to give a bit of an overview of the topics we’ve covered so far.  He also pulled me up on something that I’d said to him quite some time ago along the lines of “increasing quality will reduce costs”.  As we have been discussing “requirements”, it seemed a good opportunity to explore this a bit further and in particular the relationship between requirements, quality and cost.  There is quite a bit to say about this and we had a very good conversation, so I think I’ll write it up in a separate post.  For now, I just want to get this post out in time for your Saturday morning newsletter, so you can at least see the homework for this week and start thinking about next week’s session.

With a bit of help from our friend Julian Johnson

Next week’s session is to get on with the exercise of correctly terming and categorising our allotment requirements.  They are set out on the tree diagram.  A kind man called Julian Johnson has been posting some very helpful comments below our blog posts from the past weeks giving us some guidance on how to correctly handle requirements.  See his comments below the blog posts here, and here.

He has also suggested we read this paper by Stuart Burge on writing and categorising requirements.  It’s very good and gives straightforward and clear guidance on how we can better develop our allotment requirements.  In a way, it’s no bad thing we didn’t attempt the exercise this week and will read this paper before doing it.


Julian’s Functional Requirements

Well, they’re the allotment’s actually, but Julian has provided them for us.  He has put together from our tree diagram.  I suppose it’s a bit of a cheat to give these to you in advance of the session on Thursday, but i think there is still a job to do in deciding if this is a complete set of functions and then working out what the associated non-functional requirements are.

Allotment Functional Requirements

manage the allotment

       manage social aspects

                   manage tenants

                   define rules

                   resolve conflicts

                   establish / maintain collective sense of ownership

       manage the site

                   manage space

                               manage utilities (water, power, waste disposal)

                               mark / maintain plot boundaries

                               define rents

                               collect rents

                               pay rents

                               manage costs v income

                               protect people

       manage physical environment

                   access the site

                               manage pedestrian access

                               manage car parking

                               manage cycle parking

                               manage / maintain road access

                               maintain bus stop

                               park a car

                               park a bicycle

                   access within site

                               access the plot (ingress, egress)

                               maintain secure storage

                               access the secure storage

                   maintain the growing climate

                               maintain fertile soil

                               maintain conducive topography

                               protect the crops

                   maintain wellbeing

                               establish / maintain contemplative space

                               establish / maintain peaceful environment

                               establish / maintain plot sense of ownership

This list of functions is not necessarily complete though.  Please do think about whether it is.  I think that will partly decide who’s perspective we view the allotment purpose from, i.e. what it’s Operational Requirement is.

Enjoy this long weekend fellow STA friends,


Week 16: Déjà vu with the Holistic Requirements Model

Dear STA gang,

It’s a winding road (back from holiday)

By now, I’m sure you’ve realised I’m no slave to a plan and am inclined to make up our path as we travel along it.  This week was no exception.  We had intended to get back to our allotment example and use the Holistic Requirements Model (HRM) to categorise the requirements we’d previously defined and tried using to put together a tree diagram.   We are now going to do that next week, which means the “Is Anything Worth Maximising?” session has been pushed further into the future.  

As a number of people had been away on holiday last week, but had now returned, and some of those who had come last week couldn’t come this week, I thought it worth repeating the HRM session again.  So that is what we did.

There were 8 of us in the session yesterday, which I was really pleased with.  We’ve now been going for approaching 4 months, so to have so many people attend in the middle of holiday season and to still be enjoying themselves is simply fantastic.  I want to say thanks to the group for sticking with it and putting in the effort to keep up with the reading and turning up week in and week out.

All credit to the learners

In this time of cut, or non-existent training budgets, I think it’s credit to all of you that you’re taking your personal development into your own hands and putting in your own time in the form of lunch breaks and evenings to plug away at learning something new.  I’m sure you will enjoy the fruits of your labours.  I’m positive you, our organisations and ultimately, our patients will and that makes me very pleased.  That, and getting the word out about the goodness of systems approaches and how their use could benefit health care commissioning is the reason I began this journey with you, so I’m thrilled we’re sticking with it and making tangible progress.  Thank you, and keep up the good work.

There’s nothing more to say

I wrote such a comprehensive report on our HRM session last week, that I don’t think there’s much more to report from yesterday’s session.  We basically covered the same ground again.  I found it really useful to do so actually and felt it helped me get a firmer grasp on the various types of requirements and how they work together.  Now we’ll have to put that to the test with the allotment example.

Apart from checking our tree

To remind you, here is the Tree Diagram we’d put together. Click it t expand it. Well, it’s actually one of two we produced, but it’s the more developed one.   Thanks to Matt for putting it together in electronic format. There’s still more work to do on it, and it will be interesting to pick that back up again, once we’ve fully defined out requirements with the HRM.  We had a helpful comment on an older post pointing out we’d not defined functions as verb nouns, so we’ll take that on board and be careful to remodel the requirements correctly.  Thanks for the comment julian Johnson.  It’s appreciated.

Allotment System Tree Diagram

What are Requirements anyway?

One thing I’m not sure we have covered here in the blog, is an actual definition of what Requirements are.  So here is one from the Systems Engineering Book of Knowledge (SEBoK):

Statement that identifies a product* or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability.

*includes product, service, or enterprise.

It looks as though they have taken this definition from the ISO/IEC 42010:2007 Standard.  You may, or may not choose to look that up. 

The homework

The homework for next week is to individually think about how we might turn the definitions of categories of requirements into language that is more understandable and accessible to our colleagues.  Terms such as “Non-Functional Implementation Requirements” are going to leave people wondering what on earth we are talking about.  Whilst it might make us sound ever so clever, it would likely make people think we’re weird and talking unhelpful gibberish.  The challenge will be to find terminology that will be meaningful to people, but also manage to retain the specificity of the original.  Let’s see what we can come up with.

Enjoy your weekend,


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!


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:

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.



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 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?