24 October 2019
About a year ago I presented The Rumsfeld Matrix to one of my teams to talk about estimating uncertainty for a large complex software project that we were going to work on for the next 6 months, but you can apply it to any kind of project.
For those who don’t know, Donald Rumsfeld was the Secretary of Defense during the George W. Bush administration and is famous (among other things) for saying this:
“… as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don’t know we don’t know.” - Donald Rumsfeld
When we apply this matrix to project management we get the following 4 confidence levels:
These are the tasks that we can quickly assess and can accurately estimate because we have done similar things in the past. There is little need to apply a buffer on our estimates here.
The more time you spend on estimating your known knowns, the more accurate your estimate will be. Conversely, if you spend less time estimating, the more things there will be that you may have missed. The number of unknown knowns is therefore directly related to the amount of time you spend on estimating. If you are okay with having less upfront known accuracy and you just want a fast guesstimate you can add a constant buffer to your known estimate, 20-30% is typically common.
These are the tasks that you know you have to do, but haven’t done before so you can’t really accurately estimate them. Since estimates here could be hours, days or weeks off, it is typically best estimated by deconstructing the tasks into smaller tasks as much as possible and achieving team consensus on the estimate by playing games like planning poker. Realistically speaking, it’s best to play safe and double any estimates you have here.
These are the things that are almost impossible to predict that can seriously throw off your project: suddenly finding critical liabilities, team members leaving, company-wide priorities changing, sudden cut-off of funding, etc. Since these things are impossible to predict with the information we have today you might wonder what use it is to think about them at all in terms of estimation. It’s true; you can’t predict them and therefore they can’t be part of your estimation. But what you can do is prepare your team (and more importantly your stakeholders) to expect the unknown and structure your process to be able to handle any sudden changes during your project and communicate them in an intellectually honest way. This is where the strength of having an agile development process comes in where these checkpoints are built in.