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.
And here is the poster itself:
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.
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.