William Heath has written a characteristically thoughtful piece about VRM. Equally characteristically, he sent round an email (starting ‘Dear enlightened public-sector loving friends…’ – who could possibly resist?) seeking comments and responses. I feel a bit apologetic, therefore, that this is not such a response. Although perhaps it will turn out that it is.
Enough obscurantism. Let’s start at the beginning. VRM is hardly a term in common use (and William kindly points us to to Wikipedia’s explanation). It stands for Vendor Relationship Management, conceived of as an opposite, the reciprocal of Customer Relationship Management. CRM is what big organisations do to us; VRM turns the tables and allows us to manage our relationships with them. So instead of them having lots of detailed (but potentially outdated and inaccurate) data about us, we hold our own data and choose to supply it where and when and to the extent that it creates value for us. Apart from much else, that, arguably, puts some of incentives in the right place to work effectively: if I control my name record, it will always be spelled right; if they do, repeated experience is that that they will often spell it consistently and relentlessly inaccurately. Not only is that a better world for me, it is arguably a better world for them: large organisations will be liberated from the need for large and cumbersome databases, which cost a great deal of money to build and maintain without ever quite working as well as one might hope.
That’s not a small matter. William says that ‘VRM will allow a transformation that is living, human, and compassionate’. It will cut costs, improve the quality of public services, de-tox the database state, and be the basis for co-creation (moving us from being customers to being participants). That’s great – and the fact that I am rushing over all of this isn’t because I don’t see the force and attraction of VRM: given a choice between a VRM world and a CRM world, VRM has a lot going for it. But particularly because William is interested in the public sector, there are two critical questions to address, not just one. And what this post is really about is those two questions, using VRM as an interesting and thought provoking example, rather than focusing on the substance of VRM as such.
The first question is the obvious one: where do we want to go? That is a critically important question and it can look like a hard question, sometimes an impossibly hard question, which is not the same thing. But it is often a great deal easier than the second question: how do we get there from here?
The reason why the second question is hard usually doesn’t have much to do with whatever is being proposed in isolation, it has to do with dealing with the installed base and with the consequence of decisions made in the past, sometimes a long time in the past. To take a very different example, the reason why it is impossible to fit air conditioning on London’s deep tube lines is that all the design decisions were made a hundred years ago on the basis of the technology then available, the requirements then understood and, critically, the absence of anything to learn from as they were the first of their kind anywhere in the world. The result is that there simply isn’t room in the tunnels for anything more than the current trains, the cross sections of which are necessarily pretty much identical to those of a century ago.
So the VRM challenge is not just that vendors/service providers/government departments hold information in big databases and that many things might work better if instead the data were distributed, held and managed by individuals, or even that there would need to be some means of getting data from one set of places to another. It is that every bit of process – human, clerical, IT system, legal framework, behavioural expectations – is currently designed, or rather has grown up over the years without very much overall design, on the assumption that data is to be found in databases. That is an enormous challenge, dwarfing any kind of transformation programme I am aware of anywhere in government (or anywhere else for that matter).
That’s where the lobster pots come in. They are easy enough to get into, but hellish difficult to reverse back out of, as any number of unhappy lobsters could testify. They account for an awful lot of things: electoral systems tend to be like that – they evolve in a particular direction, but having done so can be very hard to change if the direction stops being the most useful one. That’s not the fault of the people wanting the new direction – their entire aim in life is to provide us with a better way forward which avoid the problems of the past. But although it’s not in any way their fault, they are still stuck with the challenge, because if they don’t have an account of what the trap door looks like in their particular lobster pot which would allow us to swim away, their concern risks seeming very abstract. Or in other words, what you have to say about how to get there from here is one of things which can add to the weight of what you have to say about where we should be going.
None of that is intended as a recipe of despair. Just because change is hard, it doesn’t mean that we shouldn’t keep trying to do it. But it is an argument that if we don’t think as carefully about the change process as about the desired change outcome, there is little point in worrying too much about the outcome because we aren’t going to get there.
So I suggest there are two things which the advocates of VRM need to do. The first is to recognise that data and the control of data are components of much larger and more complex systems and to start to think aloud about the implications of one for the other. The second – as a matter of some urgency – is to find a better name. VRM is a very smart formulation, but it’s not one that will ever easily go mainstream. It is a negative definition in being coined as the opposite of CRM, which makes a neat point but will never catch on with people who don’t have any idea what CRM is in the first place; it is a definition which points in the wrong direction – the whole point is that the focus is not on the vendor; it is a definition which is too narrow – you can describe government services in many ways, but vendor is not generally one of them; and it’s a TLA in a world already considerably over-populated with such things. It’s also a tiny example of the lobster pot challenge: it will be much easier to change the name now than in the future once it has become part of the installed base of language. And if it feels hard to change the name now, how much harder will it be to change the substance of our approach to managing data for the future?