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:
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:
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:
Hmm, all very familiar. And here are some examples of words that are “good”:
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!