Category Archives: Systems and processes

Systems and symptoms

Posted by

7

I am a menshevik. Steph Gray is a bolshevik. It may not end well.

Steph wants a revolution, and he wants it by next summer. He does not believe in the false consciousness of the bourgeois revolution and is wary of alliances with objective supporters of the current regime. Despite the immaturity of the proletariat, they and only they can be the vanguard of the revolution.

October glory

1917 was a good year for the bolsheviks, of course. Little was heard of the mensheviks after that, though little groups survived in exile for a surprisingly long time. But while the bolsheviks successfully introduced the language and the superficial structures of communism,1 they made rather less progress on changing the substance. When the façade cracked, what lay behind seemed remarkably unchanged.

This is not 1917. Steph is not Felix Dzerzhinsky and shows no signs of wishing to lead the Cheka. But in calling for revolution rather than evolution, Steph is asking us to make a similar choice.

The question he raises is a good one. GDS has made very visible strides on the delivery of online information, in part through ruthless intolerance of counter-revolutionary saboteurs. But that has not been matched in the embedding of digital engagement and open policy making across government more widely, where the white armies still control much of the hinterland and where there is still too much tokenistic playing with technology, and not enough real change. He calls for an end to ‘pat on the head’ digital engagement – and that in itself has recruited Stephen Hale to join him on the barricades.

Catherine Howe, meanwhile, is perhaps the Bukharin of our story: the pragmatic but committed theorist trying to make sense of the landscape and to create policies to match.2 Having started with the question ‘are comms the blockers?’ she, and the group whose discussion she is recording, very quickly show the range of people and concerns which can make the adoption of social media slow. Solving that is not about fixing comms, it is about fixing the bigger system:

As the use of social media becomes more entrenched then I would speculate that this will become increasingly a question of organisational leadership rather than any specific practitioner groups and that it will be important to start discussing where that leadership should come from.

By coincidence I was at the Institute for Government on Friday, where Marco Steinberg was talking about the work of the Finnish Innovation Fund and the Helsinki Design Lab.

One of his strong messages was the need to identify and address the architecture of problems: it is easy to see particular aspects of an issue, particularly since organisational structures and job roles tend to reinforce a narrow view; it is harder – but essential if we want to achieve innovation – to understand how the pieces fit together and to design solutions in the context of that understanding. Policy makers need strategic designers to rethink systems fundamentally. Open policy making and engagement are central to doing that effectively – though I suspect Steinberg would be sceptical about defining the problem in terms of digital engagement, rather than engagement more generally. There is a a social dimension to engagement which online approaches can complement, but cannot be a substitute for.

In the discussion which followed, Matthew Mezey mentioned Jake Chapman’s Demos pamphlet System Failure and made the point that though it was greeted with huge acclaim when it was published ten years ago, it has had almost no long term impact. Lots of people were inspired by the approach; few if any found it possible to make the changes necessary for it to work. That resonated with me because I was one of them: I read System Failure when it first came out in 2002 and saw Chapman talk about his work – but until prompted today, I had almost completely forgotten. As ever, the real question is not about the methodology or the technology, but the organisational culture which inhibits innovation.

From that perspective, concentrating on the need to get policy teams blogging, rather than on understanding why digitally enabled policy making is still the exception itself risks being a form of head patting.

Open policy making is one of those new things which is actually not new at all. The idea that better policy making would result from wider engagement and greater participation in the policy making process – or simply from talking to more people who had direct experience and understanding – long predates digital anything. Almost twenty years ago, I remember being present at (and thanking my lucky stars that I was not on the receiving end of) a stern lecture from a cabinet minister to a group of hapless policy officials about the general uselessness of their proposals resulting from their failure to engage properly with the world beyond Whitehall. As Jo Maybin has recently observed:

This concern that civil servants are not using enough knowledge, or the right kinds of knowledge, when making policy is as old as the civil service itself. While the terminology may have changed, laments about the gap between models of evidence-informed policy-making and policy-making in practice, date back to the Haldane report of 1918 and beyond.

The fact that this a problem with a history does not, of course, make it any less of a problem. It is depressingly easy to imagine similar lectures being given today and Whitehall is still not famous for openness and transparency. And I also agree with Steph and others that digital engagement tools create possibilities which were scarcely imaginable twenty years ago and that there is real value in their wider adoption. But before jumping to prescriptions, it’s worth understanding the problem a bit better to see what might help and how.

Politics is making choices about things people disagree about. If there disagreement without a choice, it’s just an argument. If there is choice without a disagreement, you are talking about – or better still doing – implementation. Policy making as a bureaucratic process (the thing which – some – civil servants do) is a way in to making political choices, but it isn’t the only way in and certainly doesn’t solely determine the choices made.

Policy making is not always a wholly rational process, in part because politics (at the level of professional politicians) is in large part tribal:

And herein lies one of the biggest problems in politics. Because choosing between political parties should be a straightforward matter of selecting the policy platform that most closely aligns with your own. But it isn’t; it’s about group identity. And to a certain extent it has to be; because this is a representative democracy not a direct democracy, and we are picking people we trust to make decisions down the line.

So the first temptation for rationalist bureaucrats to put aside is the belief that there is some right policy waiting to be found, and that policy making is about gathering and sifting the sands of data and opinion until the nugget of truth is found. There are areas where something like that happens, but crudely speaking, the more the issue is politically salient to begin with, the less policy making will look like the rational ideal.3 So the first question is whether we are dealing with a political issue or what, for want of a better word, I will call a technical issue.

There is also a critical question about what aspects of policy making we are talking about in the first place. There can be discussions about the process (in a broad sense), identifying data, gathering opinions and perhaps identifying options. There can also be discussions about the substance of the policy in question, not just identifying options, but evaluating them and arguing for a preferred outcome. Civil servants do the first of those, and could undoubtedly do it better. But they don’t do the second in public, and the question of whether they should gets tangled up very quickly with some meaty constitutional issues. So the second question is whether the intention is to be open about the process of a particular piece of policy making or about its substance.

All that suggests that there are two important variables here, which together produce that dreaded, but occasionally useful, thing, a two by two matrix.

Two by two matix with technical v political on one axis and process v substance on the other

In the sense I am using here, a lot of policy isn’t particularly political. To take one prominent example, the rightly applauded openness of the Government Digital Service is firmly concentrated below the line. That gives them a lot of latitude because politically there is almost no controversy (there aren’t many areas of government activity where milestones are retweeted by leading opposition politicians).

GOV.UK made it's 1,000 code release in 6 months today. That's 7 releases every working day since coming out of beta last Oct. :-)// Retweeted by tom_watson

But even then, most of what they are and have been open about is in the lower left quadrant, rather than even the lower right. There have been interesting experiments in other departments, most recently at the Ministry of Justice and perhaps most bravely at BIS. The areas MoJ has announced that it is working on – booking prison visits, making civil claims, paying tribunal fees and applying for lasting powers of attorney – are firmly at the technical end of the spectrum, and the coverage of their excellent blog is, unsurprisingly, concentrated on process. Overall, they are where you might expect them to be – in the lower left quadrant.4

There is plenty of room for more of this. Four years ago, I rhetorically demanded

Where are the blogs of the policy makers, the operational managers, the chief executives, the tax inspectors, the social researchers, the whole army of people who make up public services?

The answer, now as then, is that even departments attempting systematic coverage are barely scratching the surface – some individual enthusiasts shine out, but even in the best departments there is little sense of systematic openness, still less of this being a tool for open policy making. And as I answered myself four years ago:

One obvious reason why there aren’t very many bloggers is that there aren’t very many blog readers. The blogosphere is so very large that it’s easy to overlook how very small it is. I don’t think most of the people I work with read blogs, so it’s not surprising that they don’t write them. That’s partly because I inhabit a working environment which is about as inconducive as it could be to a modern online existence but it’s partly because people have other ways of spending their lives, odd though that might seem to the people likely to be reading this.

All of which means that, while I would love to be wrong, I am pretty sure that an exhortation for all policy teams to blog, and for all ghost writing to be banned is not going to have quite the immediate transformational impact Steph (and I) would like. The absence of a multitude of blogs is not the problem, it is a symptom of much deeper organisational and cultural characteristics.

But all that still leaves the question of the top right quadrant.

Policy matrix - the radical quadrant

Of course we shouldn’t assume that the roles of civil servants are locked into the structures of past ages and are beyond improvement. It would take somebody considerably braver than I to argue that were true. But as I find myself saying a lot at the moment – and echoing Marco Steinberg – if you want to change the system, you have to change the system – you can’t just take one small part of it and assume that you can change it while everything in the wider system is unaffected.

Steph pretty clearly does want to change the system, and suggests:

An independent commission to rewrite the Civil Service Code, to rethink the roles of Ministers, senior officials, and more junior officials in terms of engaging in policy discussion and taking responsibility for decisions. Alongside it, a frank Parliamentary discussion about the responsibilities of backbenchers and Opposition in holding government to account without stifling open policymaking.

I tend to be sceptical about ideas which depend on taking politics out of  politics (not least because I tend to the slightly unfashionable view that politics is a good thing, not a bad thing).5 The idea that any opposition would – or should – avoid challenging and discussing ideas put forward from within government is not just unrealistic but wrong.6 There is in any case no prospect of such a commission, and even if there were, answers would be a long way off, so this won’t help meet Steph’s challenge to make a radical difference by summer 2014.

Even if we were to take away the question of political alignment there is still a much more universal question of organisational alignment. Organisations which allow and encourage their employees to think aloud about their employer’s business and its strategic direction are rare oases of self-confidence. Other than a few licensed mavericks (who tend to be smart enough not to bite the hand which is feeding them), that is just not how organisations work. Ending the political neutrality of civil servants wouldn’t stop the secretary of state being the boss.

So my pragmatic view is that starting towards the bottom and the left of the matrix makes good sense. Let’s encourage people to build up confidence, experience and good practice there, moving up and to the right over time. For the reasons I have outlined, the top right corner is much more difficult territory. But if we stop to solve those problems now, we risk getting completely bogged down.

Let’s also stop framing the question as being about the use of digital tools.  It is an encouraging sign of maturity when we can stop qualifying things with ‘electronic’ or ‘digital’. Digital engagement is not a digital problem, it is an engagement problem. More digital activity will be a symptom of better engagement. Better engagement won’t, on the whole, be a symptom of more digital.

The mensheviks need to be more radical about the actions they are willing to take and not just rest on theory and ideology.  But the bolsheviks need to read System Failure and decide what revolution they really want to bring about.

Proletarians of the world, unite!

Picture by Joseph Morris licensed under Creative Commons

  1. Technically socialism rather than communism, but you either already know that or really shouldn’t care. ↩
  2. If anybody is going to write the ABC of Communism of this little world, it is she. But this is probably the point where the analogy should be taken out and shot. ↩
  3. And that’s not a problem. Elected representatives have democratic legitimacy, not rational legitimacy – even though I for one like them to earn the former in part through the latter. ↩
  4. That’s not a criticism – what I choose to write about in this blog fits exactly the same pattern. There have been times when what I have written about had some fairly immediate (if not necessarily spelled out) connections with what I was doing at work, but the more my work takes me up and to the right, the less likely it is that the blog will stay closely aligned with it. ↩
  5. Which is why I see the proposal by Gus O’Donnell for retired Treasury officials to vet policy proposals before they are submitted to Parliament as a further symptom of the problem rather than as even the beginning of a solution. ↩
  6. It would also create opportunities for gaming – the temptation to get an idea floated by an official and declare it off limits to challenge might be irresistible. ↩

Law, code and architecture

Posted by

10

Law matters.

It matters at a detailed level because we all need to understand rights, duties, obligations and constraints. It matters at a social level because it is the framework for mutually accepted constraint which is part of what defines civilised society.

The purpose and foundations of law are lofty and quite abstract. The immediate practicality of law is often hugely detailed, complicated and largely incomprehensible, even to specialists. That’s not a new problem – as Edward VI put it almost 500 years ago:

I wish that the superfluous and tedious statutes were brought into one sum together, and made more plain and short.

That line is taken from – and this post prompted by – the launch of a Cabinet Office initiative on Good Law which aims to ensure that law is necessary, clear, coherent, effective and accessible. It’s hard to argue with those characteristics. But anyone who has ever needed to understand legislation will know just how far the statute book is from representing them.

This post is a reflection on that event. It puts forward an idea for making law more usable which I am fairly sure is absurd and unworkable, in the hope that at the very least it might give those whose job is to think about this problem a fresh way of framing the question – and if by some miracle there might be more to it than that, so much the better.

Update: the video of the event has now gone up at YouTube. The whole thing is two hours, including questions and discussion, but well worth watching at least the opening presentations. There is also a lively discussion among the contributors to a live chat at the Guardian public leaders network.

Some law is simple and powerful. Years ago, when I worked on benefit fraud, the Theft Act 1968 was one of the tools of our trade. Its opening words distill its essence:

A person is guilty of theft if he dishonestly appropriates property belonging to another with the intention of permanently depriving the other of it

Some law is far from simple. It is hardly possible to sustain the basic clarity of that definition of theft in creating the 4,000 further criminal offences which were apparently enacted between 1983 and 2009. The loss of simplicity may result from the detail and complexity of what it is trying to address, for example the obligation for a mariner to pay national insurance contributions may depend on whether his ship has sailed beyond the River Elbe. But all too often the complexity comes from the structure of the law itself. A power may be inserted in one act by a provision of a second act to produce regulations which may have effect in part by amending a third act or any number of other sets of regulations. It is possible to navigate along those chains, but it is not easy. The diagram below, taken from the good law report shows the web of effects of just one Act, the Companies, Audit, Investigations and Community Enterprise Act 2004. It is not a pretty sight.Diagram showing complex network of connections between different pieces of legislationSo the fact that there is a problem is clear enough. The question is what can be done about it. I will not attempt – and am not qualified to attempt – anything like a comprehensive answer to that, but I do want to reflect on one aspect of the problem.

Legislation does not spring fully formed from the heads of parliamentary counsel (and secondary legislation does not spring from there at all, but let’s keep things simple). It is the culmination of long and complex processes which express the underlying intention in different ways at different stages. The general direction is usually from the more general to the more specific – green papers go white, primary legislation generates secondary.

Legislation is far from being the only area of life where this is true. The development of any system or process will tend to go through some version of it, it just won’t have legal force at the end. One of the more obvious parallels is with software development. Commonly that’s seen in terms of law as a logical system, typified by this remote contribution to the good law launch:

I am a former computer systems analyst and now a solicitor. I believe that reducing statutes and case law to a series of nested if-then propositions is possible and would make the law far more accessible to anyone who is able to access a computer. Such computer systems used to be called expert systems. With this new initiative has their time now arrived?

There is a lot of power in this view. In principle such an approach should support a much more direct link from at least some kinds of law to implementation. There are powerful tools based based on just that perception, such as Oracle Policy Automation, which are already starting to be used in some parts of government.

But in this context I am less interested in law as code and more in law as coding. To whatever extent law is like software, is drafting law like writing code?

As John Sheridan pointed out at the launch event, the process of software development has become increasingly sophisticated, not just in the availability of tools, but also in softer techniques such as pair programming. Could similar techniques help create clearer and better structured law?

One starting point is to consider where the definitive version of any piece of software is to be found. Ultimately there is some machine level code which is the set of instructions actually followed by a computer. It is though incomprehensible to humans. Sitting above that is source code which is written by and comprehensible to humans – but only highly expert ones (and the more powerful the software the less straightforwardly comprehensible the source code will be). *A step back again, there may be documents which capture the logic of the intended system. Critically in this context, that is the first level for which the primary audience is human. Beyond that, there may be various documents capturing requirements and intentions, but those are descriptions of the intended system, not representations of it. For a system of any complexity, there will also be some kind of architecture which sets out the role of each component and how each relates to all the others.

There is no arguing with machine code: it does whatever it does, and so is undoubtedly definitive in one sense. But in a different way, there is no arguing with higher level requirements: they should be the definitive description of what is intended.

If you want to know how a system works and what it does, you are likely to be much better off starting with architecture and working down towards code than you would be by starting with some arbitrary code and trying to infer architecture.

How does any of that map to legislation? Source code is probably the closest match to legislative text. General requirements are, perhaps more loosely, analogous to policy documents. But what of more detailed specifications? And where is there any sense of architecture?

As it happens, there is a place in the legislative process where high level system logic is captured, though one I don’t think was mentioned at the good law event – instructions to counsel. These are curious documents, with no constitutional or legal status but immense practical significance. They are supposed to be the most complete, rigorous and systematic specification of what the legislation is intended to achieve and in theory (though I suspect vanishingly rarely in practice) should be all that is needed to allow parliamentary counsel to draft legislation which correctly implements ministers’ intentions. In order to do that, they need to operate at several different levels at once. They specify the system logic – the if-then statements both for the policy core and for the inevitable edge conditions. In addition, they both communicate the intention, against which more detailed parts of the solution can be tested, and also set that in context, and may illustrate what is intended in one area by analogy with what has previously been done in another.

Nobody would pretend that they are a light read, but they do have real advantages over the legislation which they generate. The first is that they are comprehensive:  the intention is in a single place, even if the legislative implementation is scattered over new and amended statutes. Secondly, they are continuous prose: they tell a story in a way which the more code-like text of legislation will never equal. Thirdly they are more easily testable: it requires less specialist knowledge and expertise for a minister or policy official to ask themselves whether what the instructions describe is the outcome they intended to achieve. And finally, they are rigorous: much of the virtue in producing instructions lies not in the finished product but in the sometimes painful process of being made to translate implicit or unspoken aspects of the policy into explicit requirements.

A good set of instructions, therefore, is a robust description of the intended legislative effect. The actual draft legislation is either a faithful representation of the instructions, in which case it can have no greater information content than the instructions did to start with, or it fails to be a faithful representation, in which case it is wrong (I am, of course, massively over-simplifying here – ignoring both how legislation changes through its parliamentary passage and the fact that there are already established – if exceptional – ways of ascribing meaning to law other than just through its own language). So we can ask again, which is the definitive version. In the world we know there is only one answer: it is always the legislative text. But perhaps there are advantages in creating a world where the answer is not so simple.

What if we were to give primacy not to the legislation but to the instructions? Put like that it sounds absurd, but what if we were to ask instead, what if we were to give primacy not to the technical coding, but to the agreed and understood system requirements.

The effect in one way would be related to purpose clauses and recitals, both of which try to make clear what the legislation is intended to do before getting into all the detail of doing it – though neither of which seemed to find much favour in the discussion. But it would be a much bigger change than that. Perhaps the most powerful feature would be that they could start at the level of architecture, embodying a version of the network diagram at the top of this post. They would map the landscape to set the reader’s bearings before diving down into the greater detail. They would shift the political debate, with the primary question always being whether the intention is clear and has been fully captured, rather than time and energy being spent on technical amendments which nobody understands.

More subtly, they offer some chance of bringing some of the narrative clarity of case-based law to the more arcane structures of statute-focused law. Richard Heaton made a powerful point that much law is taught and learned through stories, the cases which bring the law to life and set its boundaries in a way very different from the endless technical detail of administrative and other areas of law. That immediately makes it easier to engage the interest and contributions of the great majority of people who are constantly affected by laws of which they have little understanding and over which they have little influence.

So my modest proposal is this. Recognise instructions to counsel for what they are: the definitive statement of what the law should be. Let that be debated by parliament – and by all the rest of us. Treat everything we currently see as legislation as technical implementation of that architecture, still vitally important, still needing the highest quality of professional skill in its construction and application, but of no more interest to non-specialists than the source code of a browser is to those reading these words.

This may be a completely ludicrous idea. I am more than half inclined to think it is myself. But let me end with a thought experiment. If we had the freedom to start again completely, without any sense of how law should best be made and without any burden of history or tradition, what might we then invent? And would that be more like the Westminster model we are all so familiar with, or might it be closer to the approach I have sketched out here?

Source code picture by Sebastian Delmont, licensed under creative commons

Take a number

Posted by

1

We are not the customers of our own services. And even if we think we are, we are still not: we know too much, we cannot stop thinking as provider or designer.

Sometimes we are the customers of other people’s services and that holds up a mirror – sometimes a very distorting mirror – to our own. Even then, of course, the perspective of someone who is then tempted to blog about the experience is not wholly to be relied on.

A couple of days ago, I went to buy some parking permits from my local council. I am not going to give a blow by blow account of the experience. It wasn’t bad, but it wasn’t great either. There were lots of small ways in which it could have been better: here are three where service design could be improved.

The first is a point of measurement. There is a ticket based queuing system – take a ticket and wait for your number to be called. Screens show average waiting time (with the average while I was there going up by about a minute for every minute of elapsed time, but that’s another story). But there is also a queue to talk to a receptionist to get a ticket in the first place. So the queuing time being measured is a process management view, not a customer experience view.

Having got a ticket, the next thing is to wait. That turned out to be very confusing – numbers were called apparently randomly, so both giving no indication of progress up the virtual queue and making it impossible to know whether your number had been called or not. I assume that there was a process going on of assigning cases to appropriately skilled staff members, and so in practice several queues running not just one. That’s perfectly sensible, but would be a lot less confusing for customers if the queues had distinct number ranges. To make matters worse, one of the display screens showed ticket numbers in the queue – but only some of them. If the number one higher than mine has been called, and if my number doesn’t appear on the screen, should I start worrying that I have missed my turn? As it turns out, no, I didn’t need to have worried, but it was hard to be sanguine at the time.

The final point is that ineffective innovation can be a long term burden. The time came to pay for my parking permits. There was nothing so obvious and straightforward as a normal card reader. Instead, I had to be led to a payment machine, the like of which I had never seen before and which had clearly been intended to operate on a self-service basis.

In theory you put in a reference number, a postcode and, of course the card details, and got in exchange a receipt to be exchanged for whatever it was you had paid for. In practice that had clearly proved to be too difficult, so members of staff now walk the length of the building and enter everything except the card details, then stand around waiting for the payment to go through. The net effect is the worst of both worlds, with more staff time used than necessary to deliver a more disjointed service. That neatly illustrates two important points: attempted self service which fails is more complicated and expensive than not attempting the self service in the first place; and, to adapt Jakob Nielsen, users spend most of their time making other payments, so prefer your payments to work the same way as all the others they already know.

I got what I went for, I didn’t have to wait inordinately long, the service was friendly and effective. But it could – and I think should – have been just a bit better still.

There is no such thing as IT

Posted by

4

I have cracked the problem of government IT.

A few months ago, I argued that there is no such thing as the government.  Now, in a further breakthrough, I have realised that there is no such thing as IT either. Putting those two thoughts together leads unavoidably to the conclusion that the problem of government IT is not what it appears to be.

The prompt for this realisation is last month’s report from the Institute for Government, System Error, bravely subtitled, ‘Fixing the flaws in government IT’. The first thing to say about it is that it is an excellent piece of work, setting out very clearly some of the problems which beset large IT projects and how those problems would be better avoided, not by sticking ever more rigidly to formal processes which are themselves root causes of the problems, but by switching to radically different approaches to developing and delivering projects.

But the second thing to say about it is that it is deeply flawed in ways which stem from perceiving all of this to be an IT problem in the first place. Grouping issues together because there is a technology dimension is not wrong, but nor is it the only approach and, I would argue very strongly, it is not the most useful approach to addressing the problems the report is seeking to solve. The conclusion I draw from the report’s own arguments is that seeing this as being about fixing the flaws in government IT is itself one of those flaws.

I claim no originality for this thought. I came into the world of e-government just a report was being completed on making government IT projects work better, in response to a perception that too many were failing.  Although the report was called Successful IT, its very first page stated firmly that:

Our most important message is that thinking in terms of ‘IT projects’ is itself a primary source of problems. Delivering IT is only ever part of the implementation of new, more effective, ways of working. The IT has to fit closely, for example, with the demands of the public and the new working practices needed to produce the desired changes. Achieving this requires a clear vision of the context in which IT is being implemented.

A change of approach is needed. Rather than think of IT projects, the public sector needs to think in terms of projects to change the way Government works, of which new IT is an important part. Our recommendations aim to achieve this change.

I don’t for a moment suppose that the authors of System Error would disagree with any of this, but it doesn’t seem to be a central theme of their own thinking.

Instead, they focus on two basic concepts:

  • platform which is essentially about the commoditisation of as much as possible, reinforced by common standards and functions across government; and
  • agile which is about how new systems and services are developed (and so by almost necessary implication, things which are not commodities).

Their analysis of each of them is powerful and persuasive, but I think in the end takes them to some unhelpful conclusions because of a perception that the two are linked by being part of something called IT.  Slightly oddly, the report contains within it the seeds of a very different  – and to my mind much more powerful – understanding of both problems and solutions than it in fact draws from the evidence.

The body of the report opens with a strong attack on traditional waterfall approaches, particularly for the kinds of problems governments often find themselves needing to deal with:

Government is frequently tasked with tackling ‘wicked issues’, such as reducing child poverty or combating antisocial behaviour, where no one can be certain what the best solution is. For these kinds of complex problems, the best way to determine what works can often be to experiment, learn and improve as you go in an evolutionary approach. However, government IT has rarely supported this iterative and exploratory style of developing solutions. When uncertainty is high, ‘locking down’ solutions is exactly the wrong approach and virtually guarantees that a sub-optimal solution will be developed. (p28)

With equal fervour, the following chapter describes a very different approach:

Compared with traditional tools and methods, agile offers a fundamentally different approach to tackling business problems. Where the traditional approach favours complete solutions developed in a linear fashion, agile encourages a modular approach using short iterations to learn and adapt. Instead of trying to lock down requirements and minimise changes up-front, agile encourages continuous experimentation, improvement and reprioritisation. The approach to user involvement also differs fundamentally. The traditional approach favours heavy user engagement up-front to determine and lock down detailed specifications and at the end to test the final product. In contrast, agile embeds users in the process for the duration of the project, making them an integral part of the development team rather than a constituency to be consulted. (p31)

That’s an approach which certainly started off as a method for software development, but that’s not to say that’s the most helpful way to think about it in this context.  The message I get from the report is that IT is too separate from the business and needs to get closer to it.  That’s not wrong, and if it were the only available option, it would be well worth doing.  But at one level, all that’s doing is moving from the picture on the left below to the one on the right.

That’s not a bad change to make, but it doesn’t look very exciting, and it isn’t – and in both versions, both agile and platform stay firmly in the IT circles.

I am increasingly of the view that those pictures embody an unhelpful model of how organisations and services actually work – and obscure a fundamental division of labour within the IT function to boot. Neither ‘agile’ nor ‘platform’ happens in isolation in the IT organisation, or rather they do, but that’s a problem to be addressed, not a state of affairs to be emulated. Instead, those words each describes part of what, typically, happens across the organisation. Some of it is about continuing to do what the organisation does, in a repeatable and stable way, and some of it is about finding new and better ways of doing those things, or indeed of doing different things altogether. Treating agile and platform as things which end at the boundary of something called IT reinforces a compartmentalised view more likely to exacerbate problems than to solve them.

It is also true that agile and platform are less distinct than the report argues. The idea of using commodity tools, services and platforms to create agile, radical and distinctive applications is hardly novel or distinctive.  That is, after all, a way of describing the internet and the services which run across it, which is all not as new-fangled as it used to be.

A better approach is to recognise that stable things and innovative things both need to belong to the organisation as a whole – or rather to the users of the organisation’s services – rather than artificially to something called IT or something else called business. The crucial point, though, is in their relative positioning. There is a strong case for activities designed to change what is done being agile; there is no case for those projects being focused on, still less driven by, IT change. That is wholly consistent with the agile philosophy, which emphasises user stories and engagement and participation from every relevant interest, but is less consistent with some of what seems to get labelled agile practice.

So I think we need a picture much more like the one below.  IT is still there, as it should be:  it is a skilled and professional discipline with an essential contribution to make, but it is only one element of thinking about system changes.  Both what is standardised and commoditised and what is customised need to be more comprehensive in scope, though their relative balance probably should be different.

So by all means, let us have commoditised platforms and let the provision, support and reliable operation of them be an IT service to the wider organisation. Even there though, we need to be careful about the life cycle of a commodity. Email and web access are commodities, but does that doesn’t necessarily make getting stuck with a ten year old email client and IE6 an attractive place to be. Government has a web CMS platform which was intended to be a commodity, but is locked inflexibly into a world before social media. And even the most commoditised of basic internal services can suffer if their development is approached in any less agile a way than any other project, with a particular risk of being optimised for specialist rather than more general users.

But when we get beyond commodities, the picture gets very different. I don’t think the authors of the IfG report see change as being purely about IT; quite clearly they do not. But the language of the report repeatedly gets trapped in making ‘IT’ and ‘not-IT’ the key organising categories:

The principles of the agile approach can be applied to almost any IT project and could also be considered for non-IT related applications. (p47)

Though that is almost immediately followed by:

Agile may have originated as a software development tool, but many of its principles can be used much more widely. Projects should be modular, iterative, responsive to change and have users at the core. (p47)

Much of its comes from the fact that at least to start with, agile is about software development, without ever being about IT. The principles it embodies can indeed be applied much more widely, in ways which themselves have a huge impact on the nature of the project. Indeed, I would go so far as to say that the application of agile principles is inconsistent with the concept of an IT project.

So it is not possible to make change management work better in government as long as the challenge is expressed as being about fixing IT or about distinguishing IT and non-IT projects. The power – and the threat – of agile is that it undermines sequential professional silos. From what I have seen of it, it is not inherently more difficult, but it is undoubtedly very different, and like any new approach adaptation and adoption need to be taken seriously. Particularly for large and cumbersome organisations, such as are occasionally found in the public sector, there is a real risk that agile becomes a trendy label for doing waterfall in fortnightly drops.

So by all means, let’s talk about platform, agile, commodities and customisation – but let’s not squeeze them under a heading of IT where they do not fit. Once we break free of that last critical element of the waterfall mindset, we can think seriously about how to do all this better.

That still leaves, of course, the question of how best to apply agile approaches, and indeed whether they can be made to work at scale in government at all.  That’s an important debate, the subject of a flurry of recent blog posts, but it’s too big a question to come to late in a long post. So that’s a topic to return to, but one where I will be arguing that agile gives us our best hope of reconciling the challenges of large scale change in public services with efficient and effective delivery.

Customer commitments

Posted by

1

As I was getting money out of a cash machine, I saw a proud boast in the window of the bank, highlighting one of the commitments in their customer charter:

We will aim to serve the majority of customers within 5 minutes in our branches

Pause, if you will, to savour that masterpiece of wording. Their intention, which they may or not achieve, is to serve a majority of their customers, a group into which you may or may not fall, within five minutes.

At an overall level, that is testable: counting average queuing times is relatively straightforward, though on a strict (if somewhat unlikely) interpretation, almost half their customers could have been waiting for much longer than five minutes, and the target could still have been achieved. But for any individual customer, it is not: is my ten minute wait a sign that the commitment has been broken or an expected outlier?  There is no way of telling.

To their credit, the bank concerned does a pretty good job of being transparent about how they are doing, even though slightly oddly, the ‘goals’ which add up to this particular commitment don’t seem to allow them (or us) to know whether or not they are actually delivering their promise or to know what level of improvement there has been – if any – since the commitment was made. But they are willing to be at least a bit self-critical, which is usually a promising sign:

In November we measured queue times in our 300 busiest branches. 75% of customers were served within 5 minutes and the average waiting time was 4 minutes. We know, however, that there are times and places where customers have waited longer and we have much more to work on.

My point though is not to point the finger at the bank concerned.  Rather, it is to observe that it is difficult to be clear about the nature of a customer service standard, and harder still to be clear about appropriate values for any measure chosen.  That that is true in retail banking, which has not had a reputation for delivering the acme of customer service in recent years, is perhaps no great surprise. But if it is hard there, how much harder is it for public services, where the value of good service can be harder to pin down.

So there are probably lessons here in both directions.  The fact that a large bank is struggling to make sense of, still less achieve, the apparently simple ambition of having short queues in its branches should help public sector managers, often of much more complicated and variable services recognise the scale of their challenge and the difficulties inherent in meeting it. And perhaps too, it should help private sector managers appreciate that however hard it is for them to get this right, theirs is the easier task.

Cheshire cat government

Posted by

2

The best service is the one which disappears.

Alan Mather has written an interesting piece about whether government is still doing too much of its own IT. His interest is not in the possibility of further outsourcing, but in letting third parties incorporate services which also provide value to government. He is on to something important, and I think it may be even more important than he suggests.

His first example is the tax disc. As he rightly points out, the issue here is not how good the existing online service is, but why that service needs to exist at all. I have long been of the view that the most obviously efficient way of ensuring that vehicles were insured, safe, and taxed would be to require insurance companies to add the amount due to the premiums they are collecting anyway. But what makes that interesting is the glue that hold the tax disc service together in the first place: it is an unlikely, and I suspect largely unforeseen, consequence of a European Directive on motor insurance, and the database insurers set up to comply with it.

So in a sense, the issue is less that the government allowed other people to develop IT for it as that advantage can be taken of other people developing capabilities for reasons of their own. This is not a new phenomenon: companies have invoicing systems or cash registers, which as a by-product can collect and account for VAT. They have payrolls which as a by-product collect and account for income tax and national insurance contributions. In both cases this removes any requirement for those ultimately paying the taxes to transact directly with government at the point of payment, and as a result renders the process much less visible than it would otherwise be.

That may have an interesting political consequence. Paying tax is a much more overt and much more immediately painful process for people who are self-employed or run small businesses than it is for employed earners, and that may have some affect on perceptions of the value of tax and of government more generally – a useful reminder that service delivery is not a neutral and politically agnostic activity.

The idea of the vanishing service sites not need to stop there. I was involved with the online change of address notification pilots ten years ago, where we took a very deliberate decision not to create the service ourselves. Nobody moves house for government purposes in isolation, and there is clear advantage in providing a service which can cover a full range of needs in one place. So the government service was still there, but hidden behind other providers whose primary focus was elsewhere.

So the interesting question becomes whether  there are other things government can get done more effectively by disappearing. That is not, in this context about outsourcing or privatisation. There is a place for that argument, but this is not it. The answer must surely be that more things could be done more smartly by aligning them with other activities done for other purposes. A list of specific services beyond those already identified might not be very long, but the real power of this idea may lie at a different level again.  The change of address example points the way. Rather than thinking of services which can be piggy-backed on other activities, perhaps we should think of the information driving those services as the real opportunity. The information I have about myself is not information I hold, by and large, because government wants it, it is information which describes and shapes my life. Managing that information, rather than managing fragments of it scattered across government databases could be the real opportunity here – which by yet another route gets us back to volunteered personal information. And that’s interesting not just in its own right, but because it’s not where I had expected to end up when I started writing this post.

Separation of powers

Posted by

1

“Why”, asked the visiting official from Singapore, “do civil servants have to fill in tax returns?”

He was genuinely puzzled. It was 2000, and the world of e-government was still in its infancy, though more advanced in Singapore than most places. His thought was simple. The government pays its staff in the first place, why should each one of them have to report something the government already knows?

Leaving aside all the complexities of other kinds of income, the question is worth some thought. Would that be a good idea, and if not, why not?

This is an example of a broader question. Nobody likes endlessly repeating themselves. Lots of people get mildly – or even severely – spooked by seeing data supplied in one context popping up in another. The traditional way of doing things was always to ask for everything from scratch. Much of that was practical: it was the only way of getting things done in a primarily paper-based work process. Some of it was doctrinal: the thought that it was important for the customer to provide information, even if the organisation to which they were providing it already held it and could link it to the new requirement, as a way of underlining the customer’s responsibility for it to be correct.

That attitude is still very prevalent, though less absolute than the version held by some until a few years ago. I vividly remember the shock and incredulity on the faces of a line of civil servants at the merest suggestion that information they controlled might be used to make a related transaction simpler, but that was many years ago, and I don’t think their successors would have anything like the same attitude now.  Describing it as doctrinal may now be too strong but even if it is not doctrinal, it is deeply rooted habit, and that can be no less strong an influence. In much more recent conversations, I have come across an assumption that the right approach is to collect information from customers and then check it against what is known (or believed to be known), rather than using information already held, updating and correcting as necessary.

That second approach does, of course, raise interesting questions of its own. If you told me your address last year, how likely is it that it will be the same this year? What if you told me ten years ago? How do those probabilities change change according to your age? Or your postcode? At what point, if any, do I want to verify this information? When might I want to verify it again? What if there are two systems holding different addresses?

That last issue can all too readily spiral into self-propagating error. The parliamentary ombudsman has recently reported on just such a case:

We found that once an inputting error had been made, an individual’s personal data could be changed across the network of computer systems used by the bodies involved without the individual’s knowledge or consent; and the network of computer systems could not then always locate the source of any errors made. The lack of provision for users to identify retrospectively and rectify human errors which occur from time to time, as in this case, caused the Ombudsman concern.

Part of what went horribly wrong there might be usefully thought about in terms of the buffers and leeway I talked about in my last post – this case escalated out of control because nobody could or would intervene to fix it.

So there is a need to find a way of creating a buffer which prevents erroneous data circulating uncontrolled and unchecked. Volunteered personal information may well prove to be an important element of the solution, though it doesn’t in itself solve the problem that information once captured and held on a service provider’s database is likely to decay into inaccuracy.

We also need to distinguish between different types of data. I am expert in knowing where I currently live, but there are circumstances in which there are incentives to dissimulate. I am expert in how much I earn, but not necessarily in the precise amount of last year’s taxable income. So there are tensions. Things joined together can keep information aligned and up to date. But those same systems can use those same links to propagate errors. If we hold the information already, we can minimise the data collection burden for new and changed services, but we may miss an opportunity to correct and update what is thought to be known.

In a perfect world, perhaps the best government service would be no service and government could become increasingly invisible. In the present imperfect world, data needs to be checked and challenged. Perhaps there is some merit in civil servants doing tax returns after all.

Talking to the future

Posted by

0

Yesterday, in a moment of distraction, I put the wrong password into my office smartcard three times, causing it to lock up.

There are two ways of sorting that out. One is to go cap in hand to the IT support people, and wait while they do mysterious things on phone and screen, feeling mildly idiotic, despite their friendly charm.

The other is to go into a special user ID which loads a programme to reset the password. It’s very easy. All you have to do is remember the answers to three questions you gave several years ago when the thing was set up in the first place. Which, of course, is potentially not very easy at all.

Three questions. Favourite teacher. Pet’s name. Favourite singer.

This wasn’t going to work. I could argue with myself for the rest of the day what the right answer to any of them should be, and still not reach agreement.

I stared at the screen for a while. Then the penny dropped. The question wasn’t:

What is the right answer?

It wasn’t even:

What might you have thought the right answer was a few years ago?

It was actually:

How would you have answered them to give your future self the best chance of answering them?

Armed with that insight, the rest was easy. I know how my past self thinks (if less often what he thought). Three correct answers at the first attempt.

Back to work.

Service design is not the same as system design

Posted by

2

Good services depends on good systems. But good systems do not guarantee good services. The distinction is all too often overlooked, not least by designers of systems and services.

The London congestion charge is a fascinating case study of a superbly engineered system supporting a service which has some important deficiencies. I was told a couple of years ago by somebody who was on the development team that the service they built was defined by the statement:

Every car which enters central London and does not pay £5 by midnight should be charged £40.

I love the economy and precision of that statement. And there is no arguing but that the system does exactly that (albeit now with rather higher prices). But it completely misses out that the thing they built is a service. There is no customer in that statement, and so no customer relationship. The congestion charge is seen as a penalty capable of partial mitigation rather than a fee, the payment of which should first be facilitated and only then if necessary pursued. As I observed when I first ranted on the subject of the congestion charge:

HMRC has very deliberately chosen to assume that most customers want to be compliant.  It follows from that assumption that if people become non-compliant, they need encouragement and help rather than punishment.  Of course HMRC can turn nasty if it needs to, and if it puts its mind to it, it can turn very nasty indeed, but that’s not where they start from. TfL assumes from the outset that non-compliance is an attempt at evasion and its first response is to impose punishment.

There is no obvious reason why TfL could not instead send polite reminders that a payment is due and keep the penalty charges for those whose further inaction suggests an intent to avoid paying.  But something quite subtle about how they saw the problem they were trying to solve has sent them down altogether the wrong path.

What’s particularly odd about that is that in other ways, the congestion charging service was quite innovative – paying by SMS, for example, hardly rates a mention now, but was then the result of impressive creative thinking and customer insight. I find that useful, but only because the developer of a third party app has made it simple, and it speaks volumes that it should take a third party to produce the most straightforward way of completing what should be a trivially straightforward transaction.

Now, years later, there seems to have been a change of heart. From 4 January, TfL is introducing ‘Auto Pay’, with an equally admirable concise and precise description:

We’ll automatically record the number of charging days a vehicle travels within the charging zone each month and bill your debit or credit card each month.

That’s a milestone worth celebrating (and in my case at least, worth signing up for), but it’s the hook for this post rather than the point of it. Despite possible appearances to the contrary, the point is not to knock TfL or the congestion charging scheme. It is to recognise that it is easy to mark success by the achievement of technical completeness, while missing something subtle but critical about quality of service.

That is something which should concern all of us involved with the design and delivery of public services. I am trying to find a simple way to express this as a contrast between a system led approach to design and a service based approach. It’s work in progress, because it is too long and lacks the elegant pithiness of the one liners quoted above, but in its current form, it goes something like this.

The traditional approach was to start by designing the systems and processes to deliver the outputs we wanted, and only then to design the front end experience (in the broadest sense, this isn’t just about IT). That meant that the front end was compromised from the outset, but it didn’t matter because the only people who had to use it were staff who had no choice because that was their job and who could be sent on lengthy training courses.

Now we need to start by defining the user experience and outcome we want the system to support, and only then design the tools and processes needed to deliver that support. There is any number of reasons for doing that, but there are two which matter particularly. One is that we want and will increasingly need customers to be users. We can’t send them on training courses; they can walk away or, worse still, find expensive and inefficient ways of making contact if they don’t like the look of what we offer. The other is that unless we do it that way round, there is no way of knowing that the resulting service is as efficient and effective as it can be.

I would have been proud to have been part of the team which delivered the congestion charge: it’s a remarkable achievement.  But I would have been more proud to have been there and said that it wasn’t being designed to be good enough.

There is no such thing as the government

Posted by

13

In the UK, we appear to have a government. It looks like a government, often talks like a government, and sometimes behaves like a government.  But you can’t really understand the way government works until you realise that it doesn’t exist.

Bits of government exist, of course, lots of them. Sometimes we call those bits ‘departments’ and sometimes we call them other things. Sometimes they co-ordinate and collaborate. When No10 rings, they answer the phone and listen attentively and at the very least will appear to do something which can be described as a response. But government as a whole is at least as much archipelago as land mass.

It can take a while to spot that. It took me years. It took me to the Cabinet Office where, I deluded myself, I would get access to the levers of power, and would be able to make the world a better place as a result.

The levers of power (and the power brokers' kettle)

The delusion is not in thinking that there are levers of power. There most assuredly are. There are rows of them, with brass handles and the patina of age, polished daily until you can see your face in them. When you move one, there is a satisfying clunk and a little bell rings. The levers are connected together in complex ways and there are people who have made it their life’s work to understand those linkages, and to pull the levers in patterns and sequences which send clear messages in exactly the right direction.

No, the delusion is to think that those levers are necessarily connected to anything, that they directly control any machinery, that anybody hears the little bell ringing in the corner, that brass and polish are correlated with consequence.

And that matters. It matters because once you recognise that fact, you can start to do things differently.  People do, of course, recognise it at the level of caricature I have described here and nobody will admit to believing that they can get things done simply by pulling the levers of power. But inactions speak louder than words and the myth of the lever is harder to eradicate than any of us like to admit.

There are two ways forward from there. One is to connect up the levers; the other is to recognise that they are not connected and to find other ways of getting things done. I don’t particularly mind – at least for the purposes of this post – which route is chosen, nor do I think that it necessarily has to be the same route for every decision made in government. The essential thing, though, is not to imagine that anything will come from installing an additional set of unconnected levers or investing in better quality brass polish.

With that in mind, let us turn to the review of Directgov prepared by Martha Lane Fox for Francis Maude, which needs to be read in conjunction with the essential gloss provided by Tom Loosemore (and do read Steph’s post while you are there).  This is not a post about that review: it’s something I am directly involved with, so I am not going to discuss the specific content and recommendations here. Neil Williams has both his own analysis and some good links to other people’s if that is what you are after. In any case, what matters for this post is not so much what is in the report as what is outside it, the context into which it has dropped.

The idea of joining up government services by bringing them together online has been with us for years. In some ways a lot has been achieved, but pretty much nobody is satisfied with where we have got to. I have written at some length on e-government ten years on and I won’t repeat that here, but I strongly suspect that we have often looked for solutions in the wrong place. Somehow the ambition has always comfortably outstripped progress. The temptation is always to blame the digital delivery (e-government, online services gov 2.0, call it what you will), as the new thing which was supposed to achieve miracles, but has unaccountably failed to do so. That’s not completely wrong, but it is at best only half the story. The missing levers of power provide the other half. To some extent, joined up online services can cover up the essential fragmentation of government, but they cannot actually defragment it, and it is unreasonable to expect them to do so.

As a demonstration of the importance of the issue, it’s well worth reading Tom Watson’s reflections on the nature of the problem, why the last government didn’t fix it, and what would be needed to sort it out now. I recognise his diagnosis, though I don’t altogether agree with it, but it is his prescription which is relevant here. He suggests that bringing in the A team would make the critical difference:

For, as Martha rightly points out, to achieve the changes required to make engaging with HMG online a simple, pleasurable experience requires a massive change in culture and technical expertise.

And Francis is also humble enough to know that he’s going to need the flair and talent of Britain’s best web people. He needs the A-team.

If I were Francis, I would draft in Lib Dem Lord, Richard Allan, of facebook to the team. I’d steal Tom Loosemore and Matt Lock from Channel 4. And I’d throw in that well know anarchist and inventor of www.theyworkforyou.com, Stefan Magdalinski. I’d demand that the BBC lend me Tony Ageh and Bill Thompson.

And to finish off the A-team, I’d persuade David Cameron to put Martha in the House of Lords. Make her the minister for digital engagement and let her run the team. My God, they’d change Britain for the better. Good luck to them. And well done Francis.

That’s not a bad suggestion. They are all good people, and any one of them, let alone all of them, would bring energy, insight and experience. But I don’t think it solves the problem, it’s a one last heave approach. We need (as well, not necessarily instead) to recognise that providing a government web service when there isn’t a government is an intrinsically difficult thing.  The solution therefore requires a better government as well as the better web service.

I am not for a moment suggesting that there is no point in doing anything until the whole machinery of government has been restructured. That’s not going to happen, and no good will come from waiting for it. But it does mean that there are some important questions which are well worth exploring, not because they will ever have final answers, but because we need there to be better answers than we have now. Three to start us off, all closely related, might be:

  • Whose is the cutomer?
  • Who is the agent of whom?
  • Whose fault is it when it goes wrong?

There is no such thing as the government.  But there could be.

Picture by Ingy the Wingy, licensed under creative commons.