I recently came across a (Dutch) book called the ‘Institute of brilliant failures’. It is written by the former innovation manager of ABN Amro called Paul Iske. He has always been interested in failures because he believes that we can learn from failures. However, we have an environment where we are afraid of failures. We rather focus on our successes and keep really quiet about all of the failures we had. In this blog I will discuss some highlights of this book. And of course, I cannot write a blog about brilliant failures without describing one of mine.
Paul started collecting what he later called brilliant failures because he was interested in why people exactly fail. In general, there are many reasons why people fail, it could be that they don’t have the right skills, they never really intended the project to be a success or a number of other reasons.
But Paul identified a group of failures that did have the right vision: people were inspired to do the project, did the due diligence with regards to risks, had the right approach and lastly learned from that what went wrong. Everything looked to be ok and yet they failed. What happened?
He created an acronym called VIRAL (Vision, Intent, Risk, Approach and Learning) which has the letters of the elements in order to create a score to what extent the project is actually a brilliant failure. If you, for instance, totally ignore risk, it can not be a brilliant failure.
What Paul found out is that the reason why projects go wrong can be traced back to a number of archetypes, situations that can occur in almost every organization. These archetypes are from the perspective of an innovation perspective but I believe they are also applicable to project in the ICT area.
He identified in total 16 archetypes that all resulted in a brilliant failure. I will not go into detail for all of the 16 archetypes but I’ll pick out three that are the most striking to me.
The first one is the Canyon. A canyon is basically created by erosion like the Grand Canyon in United States. The Canyon archetype describes the processes that are so becoming part of the organization’s way of doing things that it is very hard to change them. They are stuck in their ways of doing business. They will do things the way they always did things. This can be an issue if your project or innovation is aimed at making changes.
However, these processes also have a good side it will give the organization guidance as to the approach to common situations. But, as an organization you should be able to let go of these established principles and have an open mind, especially when you’re doing innovation or projects. Don’t underestimate the power of established procedures and the reluctance of people to give up on them.
The beautiful farmer’s daughter
The second archetype has to do with serendipity. It is described by Paul as looking for a needle in the haystack but not finding it. You rather find the beautiful farmer’s daughter. I think the best-known example is 3M’s Post It. Looking for a very strong glue they ended up with the product that really didn’t stick that well. The innovation stayed on the shelve for a number of yours until another 3M engineer was looking for something that you can affix to something and remove it a number of times without the sticky layer deteriorating too much. In this case they were looking for a sort of superglue (the needle) and found something that didn’t stick at all that well (the farmer’s daughter).
In the end, of course, it became a big success with Post-It’s becoming not only a brand from 3M but also a category name (very much like Sony’s Walkman). So you look for one thing and you find another thing. Well, I can live with that.
Divers of Acapulco
The third archetype is called the divers of Acapulco. It is all to do about timing since these divers dives from 30 to 40 meters into the water that rises and sets with the waves. This archetype can describe the brilliant failure that had everything going for it apart from the timing.
It was either too early or it was too late. Too early could be that the market really isn’t ready for it, people don’t see the problem. Too late could be that you are actually developing something and someone else introduces a product to the market before you’re ready. This does not mean that it is a failure, but you do need to see what your strategy needs to be.
My brilliant failure
Of course, I should mention a brilliant failure as well. As I’ve made many let me pick a simple one. We were doing a research project together with partners to automate the interpretation of EEGs (Electroencephalography, recorded brainwaves) for the diagnosis of, in this case, epilepsy. We had the right partners on board, a specialist hospital, AI specialists to develop the interpretation and so on. What we did not factor in was the fact that our new solution did not fit with the established model of reimbursement of healthcare cost. In simple terms, our work could not be billed to a health insurer since it was not an established and accepted treatment (from a commercial perspective). The archetype in this case was mostly the canyon. We simply thought that it would be accepted.
What are my takeaways from reading this book? Well, basically that failures are inevitable. Things can and will go wrong, so you need to be prepared for that. That preparation can be how to remedy the situation, learn from the situation, or even prevent the situation. To start with the latter one of the ways to prevent a situation is to imagine that it has already gone wrong and track back from that situation. This is called the pre-mortem. Here you look at the root causes that a project goes pear-shaped. It will force you and your team to think of situations that might’ve caused the failure.
IT projects are of course different from innovation projects. Let’s say you already started with your digital transformation (with the help perhaps of our white paper) and want to start with a project on digital imagination. With this I mean a project that will give the organization new capabilities using (digital) technology. You can use the archetypes from the book to learn and for instance a pre-mortem approach to prevent failure as much as possible.
From an IT perspective, an example: it could of course be that the performance of the system wasn’t as good as you hoped it would be. This could then be turned into measure that will make sure that this doesn’t happen.
Apart from the book, there is also a website and a database with brilliant failures for all of us to learn from and share our failures.
Failure is not only an option, it is also part of learning and growing our businesses.