Walking the line between Skunkworks and Business as Usual

Home / Design / Walking the line between Skunkworks and Business as Usual
Walking the line between Skunkworks and Business as Usual

Several times recently I’ve heard the word ‘skunkworks‘ mentioned. Most recently it was in a Guardian interview with Mark O’neill, the ‘leader of the government’s IT ‘skunkworks’ team – as well as CIO of two prominent UK Government departments.

I have to admit to being fascinated by the idea of a skunkworks capability in Government. Ideally, a skunkworks team is untethered from organisational rules and structures, and allowed the freedom and flexibility to focus on solving problems and pursuing real innovation – which often means failing a good number of times before (potentially) achieving a measure of success.

I’ve made the argument in the past that innovation could be as simple as taking the practice of one sector and applying it to another, bringing about change and introducing a new way of achieving something. This often requires people who work across sectors and have the ability to spot latent needs in one sector that can be met by standard or best practice from another. This is briefly alluded to in the afore mentioned article when Mr. O’neill speaks about what Government could learn from its engagement with London 2012.

Skunkworks have historically been used to come up with solutions where normal business practice has failed or where significant leaps in technology are required, the success and output of which may later be put into production using Business as Usual (BAU) methods of production.

All of which leads me to ponder what kind of leap is Government trying to make?

It strikes me, from my brief sojourn into Government a couple of years back, having worked for commercial organisations across multiple sectors for more than twenty years, that Government departments could do with more exposure to how businesses plan and manage their IT, develop their digital services, and have an imperative to find a balance between the needs of the organisation and the desires and goals of their customers. Indeed, even the Government itself has gone down this route by engaging people like Sir Alan Sugar and Martha Lane Fox.

On the other hand, if the idea of the skunkworks team is to be a rapid prototype development unit – that doesn’t get too bogged down in coding, and spends more time achieving some of the balance I’ve referred to – then they could possibly introduce more rigour into the process of developing their IT and digital services, introduce the people who design these services in departments to their users, and look to build ‘just enough’ to accomplish a specific set of tasks, then possibly there is some educational value.

However, with a large proliferation of open source technologies on the market, and project management and user-centred design methodologies that many in Government fail to understand or embrace, I worry that what many will think of as innovation, is already so imbedded as BAU elsewhere that BAU will get mistaken for innovation (I recognise a degree of my own hypocrisy here).

One other thing the article mentioned was the use of Agile development. I’ve had the distinct ‘pleasure’ of working with agile in projects that range from quite small (new builds and enhancements) up through major software development programmes. The one thing I’ve learned is that it’s rarely applied the same way twice, and that people rarely follow its basic values (see link above for source):

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Skunkworks teams, by their very nature, should be agile. However, how the work that comes out of a skunkworks effort is then rolled into the organisation can be another matter altogether. As you can imagine, a skunkworks team can roll out some small live applications, websites and enhancements, but when it comes to large-scale services development, the best it can hope to achieve is to do some proof of concept work, prototype, and inform the larger project that will follow. And that is where the many varied applications of the Agile process will show varied results.

Still, though I’m quite baffled by what a Government skunkworks team hopes to achieve – and from the looks of it in quite a public way (keeping in mind that most skunkworks projects are secret with some percentage of the ones that succeed becoming a product we might one day see, and the rest buried deep in a basement vault never to be heard from again) I fully intend to watch this space and see what comes out of it.

I also wonder what roles the Parliament skunkworks team, Directgov | innovate, dotgovlabs, and the shadowy Alphagov team might play in the short to medium term in working with Mr. O’neill’s skunkworks team in the digital space.

I think it promises to be an interesting next twelve months for UK Government digital.

Leave a Reply

Your email address will not be published.