Innovation Lessons from the Past

When public sector innovation is talked about it can often seem like a new focus, or something that governments have only recently paid attention to. Yet on a recent holiday I had a reminder that governments have been innovating for a long time, and that many of the issues that we face today when innovating are not new. In this case the reminder was a Swedish naval vessel built early in the 17th Century.

The setting of the reminder was a visit to the Vasa Museum in Stockholm, which focuses on the Vasa warship, a Swedish ship that quickly capsized and sank on its maiden voyage in 1628, and which was salvaged and restored in the mid-1900s.

The visit was interesting for a number of reasons, not least that it was very interesting to see the old ship. However my first question, after the obligatory “wow” at the sight of the restored ship, was why did this large vessel sink so quickly on a relatively calm day in a safe harbour? What went so wrong that such an event could occur in a country that was then regularly building ships?

The answer to this came in bits and pieces. I thought the museum was very well curated, and as you proceed around the exhibits you learn more about the facts of what happened, including that there was no immediately obvious error or contributing factor (such as the crew being drunk or the cannons being unsecured and causing an imbalance as they moved around). Rather, the central mistake was structural, in that the ship had too high a centre of gravity, and it would have required a much wider and heavier base in order to sail safely.

Still, I thought it was odd that this could happen with such a large undertaking. A large ship such as this must have been a relatively significant investment for the country. Surely there was a point at which someone knew that the vessel was not actually going to be seaworthy? That something had gone wrong?

Yet the mistakes, while obvious in hindsight (once helpfully explained by the museum, anyway), were not as easily or as readily apparent at the time. Or, rather, there was limited ability to act on the warning signs for those that did see them or realise that something was amiss. This is something that I think is a common risk for innovation projects, where the lack of previous experience means that it can be difficult to identify what is different (something that naturally comes with innovation), what is problematic, and what needs to be acted upon.

For me, then, the story of the Vasa was actually one of innovation, of trying to do something different, and the terrible consequences that can sometimes come from a poorly managed innovation process.

To help explain why, the below list includes some of the things that identify the Vasa as a failed innovation project, as well as my thoughts on how these points reflect common issues in innovation projects:

• Innovative project: The ship was an innovation in that it was of a relatively new design, incorporating two gun decks, something that was still novel, and involving significant extra weight for the ship. Nowadays, a procurement exercise involving new designs or capabilities is a common warning sign for innovative projects, indicating that additional care will be needed in order to make sure the project proceeds carefully. In this case, the end result was that the ship set sail despite not being seaworthy.
• Keen interest from the project sponsor: The King was apparently particularly interested in the project, wanting it to be one of the most powerful warships in the region. The King was involved in the specifications and requirements, and cared about the appearance (decoration/ornamentation) of the ship. Innovation projects certainly require strong support from the leadership, however this can be problematic when the sponsor takes a close interest that is not matched by experience or an in-depth understanding of the practicalities. In this instance the King set out not only the vision, but also some of the precise project parameters, which perhaps should have been left to more experienced or knowledgeable people. A sponsor of an innovation project definitely needs to know or appreciate the limitations of their team, but they also need to understand their own limitations and place trust in others where appropriate, something that can be hard for those used to being in charge (whether they are the King, or more modestly, someone in charge of a public sector organisation or team). Another parallel with innovation projects is that there can sometimes be close attention to the less material matters (e.g. the ornamentation and the look of the ship) rather than the things that really matter (whether it actually floats). Care needs to be taken that the “showy” side of the project does not involve compromises to the fundamentals of whether it will actually deliver and have the impact needed.
• Change in project scope: There were apparently additional requirements outlined during the project, to do with the number of weapons that the ship could carry. As many of us know from experience with procurement processes, a change in scope during the project can be a big problem and a warning sign. While there should be the ability to revisit and reassess things during the project as new things are learnt, the unilateral declaration of new requirements is rarely a good development.
• Change of key personnel: The original shipwright commissioned to build the ship became ill and died during the construction process, and another person took over. While the new shipwright could well have been as good (or better) than the previous one, any change of key personnel during an innovation project involving specific expertise can be risky. During the time of the construction of the Vasa, ship plans were not drawn but relied heavily on tacit knowledge and experience. This reliance on tacit knowledge is often the case with innovation projects which involve personal judgement and emergent practice, and a change of personnel can risk losing that tacit knowledge or in there being a mismatch in assumptions about what is possible or desirable. Who knows whether the original designer overseeing the whole of the project would have been sufficient to make a difference? It may not have, but the original shipwright may, if nothing else, have been better placed to respond to any warning signs and declare that there was a problem. This might have been something the replacement shipbuilder may not have had the position or authority to do.
• Warning signs and unsure delegations: Close to the launch of the ship, the captain overseeing construction was worried and provided a demonstration for the Vice Admiral with 30 men running back and forth across the deck while the ship was moored. During the test the vessel rolled alarmingly. The Vice Admiral stopped the demonstration and allegedly remarked that he wished the King were at home (in Stockholm, rather than travelling abroad) – presumably because the King would have seen the evidence for himself and realised that something was wrong. It seems however that nothing was done about this alarming result. Soon after, the ship was ordered to set sail, where it sank and multiple casualties resulted amongst the crew. Again, there are many parallels with other innovation projects. There may be individual warning signs about what is happening, but no one might feel in a position to say “Stop!” or to flag that there is a major problem. Innovation projects also often involve unclear delegations – who was ultimately responsible? Who could see the big picture of the project? The replacement shipwright? The overseeing captain? The Vice Admiral? Or the King? And with the King not readily available, but being known to be eager to have the ship launched, who was in a position to say “We cannot launch this ship” in the face of that expectation? Who was going to be prepared to contradict their King? And more generally, how often is someone going to be willing and prepared to contradict their senior management, knowing the likely consequences? Sometimes, as we might presume about the Vice Admiral, it may seem safer and easier to go along with things knowing that if it goes wrong, the fault will lie elsewhere. This option may seem attractive if the alternative is to be the one who identifies a problem and bears the potential wrath from on high.
• Evaluation and scapegoating: After the sinking of the ship, an inquest was held to find out what went wrong. After it was established that the ship was well built and that it was not incompetence or carelessness on the part of the crew, the evidence pointed to a wrong design/insufficient hull to balance out the heavy upper gun decks. In the end, the perfect scapegoat was found to be the original shipwright who was by then deceased. This verdict meant that any uncomfortable questions about the role of the King in the ship’s design could be avoided. This is similar to where evaluations of innovation projects regarded as less than successful can sometimes focus on apportioning blame rather than learning about what went wrong, and how such mistakes could be systematically avoided in the future.

So what have we learnt in the nearly 400 intervening years about innovation projects? Some quick points that I think are important, and which can help avoid such mistakes, include the following:

• Innovative project: Recognise upfront that the project is innovative, and do not treat it in the same way as regular projects. Ensure that learning is emphasised, and that there are many ways that unexpected issues can be flagged and dealt with.
• Keen interest from the project sponsor: Ensure that the input and views of the sponsor is included, and that they feel that they are a part of the project, but have a means for their input to be considered within the context of that of others (e.g. have advice from experts that the sponsor recognises and values, and whose advice they will listen to). Don’t seek to contradict or embarrass the sponsor by showing what they have got wrong, but look at how they can be included in the learning process and/or how they can gain confidence that they are being listened to and that the project is being run responsibly.
• Change in project scope: Ensure that new requirements are explicitly identified and that there is a prioritisation process, so that there is a clear understanding of which requirements are most important. Allow processes for newly added requirements to be better understood, including probing the underlying motivation/desires that have given rise to the requirements and whether they might be met in some other way if needed.
• Change of key personnel: Support innovators in sharing their tacit knowledge, their experience and their assumptions about the project. Bring in others who can appreciate the issues or complexities involved. Where that may not be possible, revisit the project fundamentals when there is a change of key personnel, and ensure that everyone is on the same page as to what might be possible or where there might be questions or needed changes.
• Warning signs and unsure delegations: Have someone who has oversight of the entire project, who can see the big picture and link any individual warning signs together to get a sense of the health of the overall project. Ensure that someone is in a position to say stop/go for the project, but that they do not have an incentive to just defer to the safest position, and continually stop the project when there is any possible problem. At the same time this person should also not feel afraid to raise concerns, and should have the reassurance that to do so is part of their role.
• Evaluation and scapegoating: Ensure that the failure of any innovation project results in some clear and explicit recommendations as to how such future mistakes can be avoided. Try not to apportion individual blame except in the case of actual negligence or incompetence (and even then, consider the context and whether the people involved were equipped with what they needed to do the job).

Yet how often are such strategies really put in place in the public sector? How often do we still see projects encounter similar issues as to those faced by the Vasa project (even if the results of the other projects are unlikely to still be talked about 400 years from now)?

I would suggest that such attention is now often clearly apparent in areas where there are life and death matters – for instance in medicine with experimental procedures and drugs; in the aviation industry with plane incidents and crashes; and in the military. In cases where there are significant consequences, there is a strong incentive to ensure that such learning is built into systems. But it can be difficult in less critical situations for people to challenge the existing processes even while they are involved in an innovative project.

I think the challenge, and the reason why these lessons from the past are still pertinent, is that getting innovation right is really hard. Despite all that has been learnt since 1628, innovation is still challenging. Even where we might know in theory how to avoid these mistakes, getting the actual implementation of the necessary supporting systems and processes right can still be really difficult.

Yet this challenge is one we need to continually strive to meet. Public sector innovation is something that has very real consequences. While those consequences are quite often good ones (and often unremarked), sometimes they are bad enough to feature in a museum hundreds of years later, as a monument to folly. Thus we all have a role to play in ensuring that we avoid or minimise as much of the folly as we can, and that we collectively deliver better outcomes for citizens. We all have a role to play in ensuring that we get innovation right – whether it be being prepared to tell the King that “this ship is going to sink and people are going to drown”, or, more likely, to say during a project “something doesn’t seem right here; can we revisit what it is we’re trying to achieve, and check whether this is the best way that we can do that?”

So this idle holiday excursion to a museum reminded me why we at the Observatory have to continue our work to learn more about the innovation process, and why we need to work with others to help them learn about and apply innovation processes that work in their individual contexts. It’s because there are no simple answers when it comes to innovation and that some lessons continue to be important no matter how long ago they were first learnt. It’s because it can be all too easy to not ask the right questions, to not challenge those in charge when things might not be going in the right direction, to let things go ahead even though there are signs that things are going wrong because it’s not our responsibility.

Are there other historical innovative public sector projects that you think still have lessons for us now? If so, let us know in our LinkedIn group or send us an email.

(You can read more about the Vasa and its history at the museum’s website.)