[This post was originally published on 13 March 2013 on the Public Sector Innovation Toolkit and has been copied to the DesignGov site to capture the full history of DesignGov in the one place. If you would like to comment or see the comments made by others on this post, please visit the original article.]
Despite the tongue-in-cheek nature of this post’s title1, it is about a serious aspect of the innovation process. Innovation is hard work. It means that you are changing the status quo, and the status quo can be quite firmly attached where it is, thank you very much. It means that you are asking (or requiring) people to change what they do or how they think, and not always for an obvious reason or benefit (or the benefit may not be for them, just the cost).
In the public sector, where there are usually multiple areas and organisations with a legitimate interest in any particular issue or process, it also means that innovation is hard not just for those ‘doing’ or leading it, but also for those around them. And the bigger the innovation, the bigger the radius of ‘hard’.
DesignGov is not a ‘huge’ innovation, but we in the team believe it is pretty significant. And due to its unusual and experimental nature, with some unusual organisational and logistical aspects, the establishment process has not always fit well with standard processes and procedures. So that has resulted in us sharing some of the hard with our colleagues in the agencies who are working with us, particularly those playing a role in supporting our establishment (e.g. logistical matters).
In some ways that is part of the point of the pilot DesignGov – to explore how the Australian Public Service can do things differently. And we think we’re collecting a lot of ideas about how a whole range of things might be better done in the future and where there might be unnecessary hurdles or frameworks in need of a refreshed perspective.
In other ways, it can feel like a continual process of asking people to do, or help with, things that don’t fit with their standard work.
Reactions to such requests can range from:
- Why are we doing it this way? Why don’t we do it one of several other ways?
- We don’t have time to do this, as we have all of our business-as-usual processes that are more important
- But what are you trying to achieve? How will you measure it?
- Okay, we’ll investigate how that might work or what we might have to do to allow that
- Yes we can help you with that
- This isn’t going to work
- How about we try this?
(Actually it is common for reactions to include all of these over different times!)
This is not unusual or unexpected – there are some fantastic books, articles and blog posts written about these sorts of issues and the underlying reasons why (personally, I highly recommend How Stella Saved the Farm: A Tale About Making Innovation Happen by Vijay Govindarajan and Chris Trimble or their more comprehensive work The Other Side of the Innovation Challenge: Solving the Execution Challenge for an exploration of some of these issues).
But it does reflect that there can be a big difference between knowing something and knowing something. So much of the innovation process is a journey of discovery that, despite best efforts or intentions, can be so hard to convey to people who have yet to experience it.
As well, because innovations are introduced into wider systems, it can be difficult to predict what the combination of different reactions and responses from other parts of the system will mean. For instance, a project plan may identify all sorts of possible things that will go wrong – but they are usually all drawn from experiences of previous projects (those of the team or more broadly). With an innovation, the things that might go off course are likely to be different – and maybe in part because you put in place controls or measures for the things that you thought might go awry.
In this respect, design and innovation are very similar – the learning comes just as much from the doing as it does from the underlying conceptual frameworks and associated guidance. Until you actually get the innovation underway, it will always be a question of ‘what if?’ or ‘what about?’. That does not mean we should not try to predict what will go wrong or plan for contingencies. But it does mean that it is just as important to be flexible and to be able to respond and readjust those plans.
One of the key planks of our strategy at DesignGov is to make sure that everything we do can contribute value in multiple ways2. An experiment is something that might not work. DesignGov is very much an experiment – and so it might not work. But our approach ensures that while any one element of the experiment may not work, there will still be value out of the whole of the experiment.
In keeping with this strategy, we hope to share our experiences as what is effectively a ‘start-up’ in government so that future projects can learn from what has gone before – so consider this part one. We aim to post about other aspects of the experience of being a start-up, in addition to our posts about what we are doing, soon.
- For those familiar with the relevant episode, the second part of the title should be sung repeatedly in the spirit of The Simpsons chant “You don’t win friends with salad” ↩
- A big thanks goes to Dan Hill and his book Trojan Horses and Dark Matter: A Strategic Design Vocabulary for helping us to crystallise this thinking ↩