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.

Systemic-Textual-Analysis-Tool-v1

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,

Tim

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,

Tim

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?

Tim