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.

Responses

  1. Silos. We’re still working inside Directorate silos. ‘it’s nothing to do with me, I’m a customer of IT’. No. You’re a procurer of IT but also a stakeholder. A shareholder. Act like one. Grrrr. Sorry. Major soapbox inducer.

  2. Full disclosure, I helped launch the I4G report and I find it a very good paper.

    That said, for me the issue boils to down to there are things we want/need to do and means by which we can do them.

    The challenge is to have the conversations about what we want to do and how we could do them early enough in their life for innovation, agility and joined up thinking to be embedded in those conversations.

    The notion of IT as “other” is a significant barrier to that.

  3. The point about IT is … it’s soft. Soft, as in software, endlessly programmable and reusable, always evolving. Some people, and some organisations welcome that, while others regard it as threatening.

    I see three very common mistaken assumptions in IT management. The first is the idea that software can only be useful when it’s been completely debugged and is mature and stable. The second is the idea that you have to have a strategy and agree the ‘big picture’ before any code is written. And the third mistake is that by doing the first two, you are somehow reducing risk and managing costs.

    In reality, you don’t reduce risks so much as increase the amount of usage you need to recover Value-for-Money. You will need more than one shot at solving the problem, because even if you get the answer right first time, as soon as people get their hands on the so9ftware (as opposed a requirements spec or a strategy document) they will start to think about the problem more intelligently.

    The best way to improve the effectiveness of any organization is to increase the amount of intelligence that goes into thinking about important problems. That mean – unless you believe your organization has already solved almost every problem it’s got – there’s a lot to be said for using methods like Agile and Scrum. Not because the problems and solutions are in principle uncommoditizable (they ain’t) but because they haven’t been commoditized yet because they haven’t been articulated yet.

    There was an excellent post on the Forbes blog last week about Agile and Scrum as management techniques (nothing to do with IT) with some references to credible origins (names you can drop into conversations with senior management) and this excellent list of core practices:

    1. Organize work in short cycles:
    2. The management doesn’t interrupt the team during a work cycle.
    3. The team reports to the client, not the manager:
    4. The team estimates how much time work will take:
    5. The team decides how much work it can do in an iteration:
    6. The team decides how to do the work in the iteration:
    7. The team measures its own performance:
    8. Define work goals before each cycle starts:
    9. Define work goals through user stories:
    10. Systematically remove impediments:

    I especially like No 10. None of these practices is new. or ‘techie’. but if you put them together, you have a disciplined way of getting any kind of work done, and quickly.

    Scrum Is A Major Management Discovery
    http://blogs.forbes.com/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/

  4. Hi!

    you might want to look at the work on Procuring Usable Systems. Authors such as Erik Markensten (www.antrop.se) and Henrik Artman (http://www.nada.kth.se/~artman/Publication.htm) or some of the work found here: http://www.ida.liu.se/divisions/hcs/ixs/ixs-publications.en.shtml
    Basically what it is all about is that procurement of IT should not be done primarily with a technical focus, but with a focus on what IT should be used for, and shoudl be good for.

    all the best
    Stefan Holmlid

Comments are closed.