Computer Weekly have posted an interview with Mike Bracken: a fairly chatty (and somewhat predictable) getting-to-know-you piece, but with a few interesting snippets.
He reflects on the problems with the e-petitions relaunch:
For example, with e-petitions, no-one could predict just how fast that demand would go up. Consequently we learnt a lot about scaling and applications within the government estate. We reacted literally within an hour to sort out [the site crashing]. If someone else is doing that for you, you don’t learn. Managing a contract is a distinct skill but actually managing the service is different.
Was it really so unpredictable? Ah well, never mind. There’s also some detail about the structure of the nascent Government Digital Service:
The five areas of GDS will include DirectGov, which will be the most prominent constituent; identity assurance, which will identify people consuming government services; BetaGov, headed up by Tom Loosemore and formerly known as the AlphaGov team building a prototype for a single government website; digital engagement; and the innovation team.
Total headcount within the GDS will be ‘up to 200’, but the budget across those five areas has ‘yet to be finalised’. (Incidentally: it was confirmed in a PQ issued today that the GDS budget for 2011-12 would be £22.3 million.)
Mike also makes a point about the need to set precedents, a point I’ve made here numerous times in the past:
Launching successful products and pointing at them as examples of what can be done will be key. One can do lots of formal learning, but the simple way to build that culture of expertise is take people on a journey with you, which also means failing and learning on the way.
I’ve learned from my own experience that this is really the only way to take organisations with you. Find a modestly-sized but reasonably high-profile project, whose manager buys into the need for change. Make a success of that one, whatever it takes; then sell everything else you’re planning on the back of it.
The argument of ‘well, it was good enough for X’ is pretty primitive; but it works better than anything else I’ve ever tried. I’ve found few teams who really cared about ‘the journey’: most are only really interested in knowing the (approximate) destination, and seeing some evidence that you know the route.