Donald Rumsfeld made it into the Oxford Dictionary with:
"There are known knowns; things we know we know. There are known unknowns; that is to say we know there are things we do not know. But there are also unknown unknowns – the ones we don't know we don't know.”
With this spectacular sentence Rumsfeld nailed three of the four possible combinations of the known and the unknowns. However, he got me thinking. When it comes to knowledge (particularly in a project context), are there such things as known unknowns and if so what we should we be doing about them?
I believe there are and I would define them as follows:
“An unknown known is something that is known to some members of the team and not to all, or something that is known to the team but its significance is not appreciated.”
Let me give you some examples of unknown knowns. I’ll start with far away and long ago before moving to the sort of issues we encounter on a day to day basis.
Example one. When a piece of foam insulation broke off the Space Shuttle Columbia's external fuel tanks and struck the wing NASA limited its investigation, even though some engineers on the team suspected that the damage was serious. We all know what happened next.
Example two. The British knew about the Enigma encryption machine before the war, as the German designers filed plans at the UK’s patent office in 1926. However it wasn’t until 1939, when they met their Polish equivalents that the British discovered that it was wired alphabetically, with rotor A wired to the first contact, B to the second contact and so on. This was the same set up as in the diagram in the patent application. This was known to the British boffins but was so obvious they never even considered it as a possibility.
Example three and a little closer to home. Years ago I worked on a project which involved helping a company change its hardware maintenance supplier. The change was made for strategic reasons and meant that my client would have one maintenance provider worldwide. It was a big project. Sixteen countries, 16,000 devices. The project took six months. Three days after we made the cut-over it was announced that the new provider was pulling out of hardware maintenance. This had been known at group – but no-one in the UK was told or thought to check.
Finally – example four. Our client had scheduled a cut-over to take place over a weekend. Various team members told the project manager they didn’t want to work over the weekend. He disregarded their concerns and insisted they carry on. What they knew and he didn’t was that at weekends the air con was turned off and that the temperature in the project room got seriously toasty. It turned out (of course) to be the hottest day of the year…
All these examples fit my definition of an unknown knowns. So if we accept they exist how do we guard against them?
Notwithstanding my first example – it’s not rocket science. Dealing with unknown knowns is all about two things:
Firstly it’s about effective communication. Having an open culture where discussion is encouraged and having mechanisms in place that allow for concerns to be raised and investigated will draw out a lot of known unknowns.
Secondly it’s about questioning assumptions. We could push the live date back four weeks but have we checked that all key resources are still available?
Getting into the habit of talking (really talking) to people and questioning (really questioning) one’s assumptions are things that a good project manager should always be doing. Which begs the question – where would the world be today if Donald Rumsfeld had focussed in on the unknown knows…