On every project there are things we know and things we don’t know – Knowns and Unknowns. Organizing your thoughts around those concepts can be a constructive approach to understanding a project as shown in the matrix below:
| Knowns | Unknowns | |
| Knowns | Known Knowns Things in our plan |
Known Unknowns Things we know we don’t know |
| Unknowns | Unknown Knowns Assumptions |
Unknowns Unknowns ?? |
The Known Knowns you handle via the plan, but what about those various flavors of Unknowns? How do you normally account for those things in the project? Often it’s with padding – estimates that include unidentified amounts of time and/or money just in case.
Let’s review how padding works: You ask your tech lead, Renee, for an estimate: “Excuse me, I need an estimate for that activity you’ll be doing.” Now Renee may be thinking to herself “That will take me about 40 hours.” But Renee doesn’t tell you that. She may very likely tell you “Um, that’ll take about 60 hours.”
Why would she do this and, more importantly, so what? First, she’s doing it to cover her Unknowns. And that is absolutely understandable. Stuff happens – Unknowns! So what’s the problem?
Padding undermines sound project management practice in three ways:
1. It undermines trust. The notion that it’s a good idea to under promise and over deliver may work once or twice, but over time padding undermines the trust between the PM and the team and the rest of the stakeholders. Honest questions should inspire honest answers. That’s how you foster partnerships.
2. Have closets, will fill. If Renee says 60 hours, she may very well take 60 hours and that’s opportunity cost. She isn’t able to be allocated to other efforts.
3. Padding undermines the opportunity to learn from our experience, which in many ways is the essence of why we seek to develop good project management habits. What you want to be able to do at the end of a project is turn around and look at the journey you took to get there and be able to take something away for next time.
If you pad estimates and quite possibly end up with nonsense for baselines, what do you learn from that? Certainly not as much as you could have had you started with meaningful estimates to begin with.
Let’s say Renee is thinking 40 hours, she tells us 60, and then she comes in at 50. What do you think? Renee’s a star! But what really happened? She was 25% over! If you are measuring against meaningless numbers, you don’t get much of a chance to make the PM journey a learning experience.
Importantly, the intention here is not to highlight Renee’s failures. Rather, the purpose is to identify and understand the Unknowns that derailed the work and consider how to avert those things in the future or plan for them next time.
This is all well and good, but Renee still has her Unknowns to contend with, so what might you do to partner with her to address those?
The better project management answer to Unknowns is contingency reserves, an amount of money in the budget or time in the schedule seen and approved by management. It is documented. It is measured and therefore managed. You draw from it where and when you need to and then learn from that, as well.
The purpose of the contingency reserve is not to 100% cover everyone’s Unknowns, but rather to reduce them to a level that is acceptable to the stakeholders. So maybe it’s 10% of the project total if stakeholders aren’t too risk averse and you feel bullish about what you know and don’t know. Or maybe it’s 40% on a project with highly risk adverse stakeholders and a big box of Unknown Unknowns.
Knowns we can plan for. The Unknowns? We have two choices for how to deal with those. Under the table with padding which precludes any discussion, measurement, or management of what contributes to the Unknowns. Or Contingency Reserve in which case we talk about them, document them, measure and manage them. Only one way really enables us to learn from them.
Don't forget to leave your comments below.
Andrea Brockmeier is the Client Solutions Director for Project Management at Watermark Learning. Andrea is a PMP® as well as Certified ScrumMaster. She has 20+ years of experience in project management practice and training. She writes and teaches courses in project management, including PMP® certification, as well as influencing skills. She has long been involved with the PMI® chapter in Minnesota where she was a member of the certification team for over eight years. She has a master’s degree in cultural anthropology and is particularly interested in the impact of social media and new technologies on organizations and projects.

Comments
Those "known unknowns" do arise with some regularity.
But many scrum practitioners are on dedicated Product Teams where the backlog comes from Product Owners deciding what needs to be developed. In entrepreneurial environments, where Sales teams work with external clients to sell enhancements, Statements of Work are developed with a fee for work based upon an estimate. Over-estimating could lose opportunities. Under-estimatin g either cuts into profits or causes losses. Relative sizing only works where a particular team works consistently in the area being estimated and can base their estimate off previous experience. This is not always possible in a matrixed environment where teams are shuffled about as work is prioritized.
As for "known unknowns", you are quite right, they not only exist, but are quite common. The best example arises from a project I worked on when chief architect unilaterally decided that X technology was the way of the future and it had to be built in that technology, when no one knew if it would integrate with the existing system, and no one in the team had ever worked with it.
I remember the Rumsfeld quote, too. I really like your example of the Known Unknown, which I continue to find helpful.
Thanks so much for all your thoughtful comments today!
Andrea
Some thoughts - to keep good team between the estimator and the pm, I think the pm should always ask for 2 estimates for each task. The first estimate is the "I think it could be done in "40hrs" if everything goes well. They only need to be about 50% confident in this estimate. They should then give the "but it might take as long as 60hrs" if I run into unforeseen difficulties, they should be 90/95% confident in this estimate.
The pm then schedules the plan according to the lower estimate, and use the difference between the two in a buffer near the end of the project, this would be the "contingency reserve".
I use critical chain, and assign buffers that are half the difference of the sum of both estimates, and have found it to be very effective in leading projects to a goal end date.
It is also still possible to compare estimates and actuals, though I am not really satisfied that one's ability to "estimate accurately" means they are more senior at doing the role to which they have been assigned, and therefore I don't think it should be a strong measure of individual performance.
There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know.
Donald Rumsfeld
Read more at http://www.brainyquote.com/quotes/quotes/d/donaldrums148142.html#BxPyP5SZ0UF7kzBU.99