228 – Frog or bike. Does it matter?

1720 words (6 minutes reading time)                                                                Lancing Farrell

thinking frog

Colin Weatherby and Tim Whistler have made some interesting points in their contributions to the discussion about the Vanguard Method. Clearly, Colin’s colleague has had some success in using it and has been able to identify unique features of the Vanguard Method. In contrast, Tim has raised some legitimate concerns, especially from a local government perspective. I have spent some time thinking about both points of view and reading some of the material mentioned. Here are my thoughts for what they are worth.

Services are complex and the interactions between the parts, especially when people are involved, is important. Experience says that changing one part of a system does often have unintended consequences elsewhere. Even using the bicycle system as an example, changing one worn-out tyre isn’t going to improve the whole bike if the other tyre is also worn out. A blow out is still possible. Upgrading the group set to a 500g lighter (and much more expensive) set isn’t going to make much difference if the rider is 10kg over weight. Successful cyclists understand what they are doing as a ‘system’ and coordinate their effort across all aspects of their cycling.

‘Frog’ systems add another degree of difficulty. Sometimes, that difficulty can’t be seen or understood until you start to change the system. This is why ecologists intervening in natural systems often use ‘adaptive management’ approaches – e.g. trial and error – to make small changes and monitor the effect before committing to do more. They have adopted a structured and iterative process in the face of uncertainty. I know organisations are not ‘natural’ systems but human nature does apply and people don’t always behave predictably.

On the basis of this, I would support systems thinking as a way to understand an organisation and implement change. It places the emphasis on the ‘whole’ rather than the ‘parts’. Despite Tim Whistler’s concerns, risks must be taken to change a system. The trick is to manage those risks. Even when changing a bicycle system success is not guaranteed. There are many examples of organisations that have set out to implement structured, planned and documented changes that have not achieved the intended outcomes. Even having multiple change processes and coordinating them is not straightforward. It might be what we are used to doing, but that doesn’t mean we should continue if there is a better alternative.

At this point, the differences of the Vanguard Method become relevant.

Anything you do has to start somewhere. In a service, it makes sense for it to start with a person receiving the service and their purpose in using it. There doesn’t seem to be any point in giving someone a service that isn’t what they need. I am not saying they should get what they say they want, but unless they get what they need to solve their problem, they will not be satisfied. Then they must either put up with what they get or they will seek to solve their problem by re-presenting or going elsewhere. This is the source of the failure demand identified by John Seddon. It is more likely to occur if someone other than the customer has determined the purpose of the system.

This is an interesting point and raises the question of why the work is designed the way it is. If it is not to fulfil a customer purpose, whose purpose is it intended to fulfil? You might argue that it is the role of leaders to determine the purpose, but does that mean it should serve their purpose? It is a common criticism of public sector organisations that work is designed to suit the workers. Even designing the system to suit external regulators or to satisfy regulatory obligations or reduce risk is not going to work unless it also fulfils customer purpose. It is customers who create the value demands in the system.

If you study enough customers using a service, there will be common and predictable problems to be solved. This is the ‘requisite variety’ and the value demands that should form the basis for designing the system. It is not ‘standardisation’ because the system will be designed to respond effectively to what matter for customers in solving their problems. And it doesn’t mean that it won’t change over time. Once you have worked out how to deliver a service to meet value demands, you can continuously change it in response to changing demands. If that happens, the periodic service transformations we use to re-set services when they get out of step with customers won’t be required.

The worst thing that can happen is that the service design responds to unpredictable problems or exceptions. This is how additional steps get added into work flows and much of the avoidable waste (i.e. work done that doesn’t add any value for the customer) finds its way into systems. This leads to Tim’s concern that the Vanguard Method won’t deliver public value.

Mark Moore defines public value as the “collective view of the public or community about what they regard as valuable with regard to the use of public money and authority”.

Moore has placed public value on a continuum from private to public value. This is discussed in more detail in an earlier post and the fundamental concept is illustrated in this diagram.

Moore degrees of publicness

Allowing people to define the system from the viewpoint of their problem to be solved is clearly a private value situation (i.e. an individual seeking material well being). This is an unavoidable situation because people don’t like standardised services. We know that. They want choice to ensure their needs are met. My favourite example is to imagine how you would feel if doctors treated each patient according to the illnesses prevalent in their post code, rather than examining them for their specific illness. I can’t imagine anyone thinking that would be helpful or acceptable to the patient.

 Staff have regularly reported that what starts out as a typical customer transaction (i.e. I want something and I am paying you to give it to me) often ends up with the customer taking a more ‘citizen-like’ view of the situation and the council’s responsibilities, which results in the solution to their problem becoming one that is better for them and their community.

However, if, as evidenced above in the advice given by Colin Weatherby’s colleague, a discussion that starts with private value can move along the Moore’s continuum to end up with a public value outcome (i.e. both individual and collective valued states are achieved), surely it is public value. In fact, it is likely that all demands have elements of both private and public value. An example used in a previous post to illustrate the transition of value from private to public has been the planting of a street tree outside a house in a street. The resident living in the house gets value in beautifying their street, as does the broader community in reducing the heat island effect.

The issue of performance measurement is always contentious. If measures are not used to understand whether services are effective as they are delivered, how can they be improved? Relying on surveys of customer satisfaction (which seems commonplace in councils) or waiting until external comparison reporting shows you have dropped down the ‘league table’ of councils, is inadequate. I can’t imagine successful private sector service organisations waiting for that sort of feedback. In reality, there probably needs to be both sorts of measurement and reporting – leading measures that help improve systems and services, and lagging measures that reassure decision makers and the community that needs are being met and problems solved.

The link made by Tim between todays services and the services needed tomorrow is an important one. There is no point in putting improvements in place today that solve a problem and then just waiting until a new problem emerges before doing further analysis and change. We know services are dynamic and that customers and the variety they bring to the system will change over time. Why not set up a system capable of changing continuously in response to demands?

I think the main reason this doesn’t happen often is that management hasn’t worked out how to do it effectively. It also challenges the traditional ‘command-and-control’ mindset of leaders. The idea of a service catalogue is one that I have long supported (I have posted on it before). My rationale has been that no one knows with certainty what an organisation does, or does not do, unless you tell them. Write it down. Having thought more about the Vanguard Method, I can see that a rigid catalogue of services and service levels is not the solution, particularly if it is developed ‘inside-out’ by people within the organisation. The services offered need to be those required by customers or they are irrelevant.

This leads to Tim’s final point, and one that is addressed partially in Colin’s post – what happens to leaders? Leaders must change if the Vanguard Method is to be successful. It is probably the greatest threat to its success. They must change their thinking first because that will lead to a change in their behaviour. The power of what leaders do is well documented. The blog Thinkpurpose.com has a popular post about systems thinking called the ‘7 reasons you shouldn’t touch systems thinking’. The seven reasons are the frustrations that occur when workers are exposed to systems thinking but management is not committed. This seems to be a real risk.

It is a risk for leaders to adopt systems thinking and introduce a method like the Vanguard Method to change their organisation. Leaders have accountabilities that are designed around ‘command-and-control’ thinking. Many leaders have been successful in a ‘command-and-control’ environment – they are accustomed to deciding what will happen next, creating priorities and allocating resources. People rely on them to do it. However, leaders that continue with reductionist management thinking and practice will defeat the Vanguard Method or any version of systems thinking.

They have to change first.