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.

written by Ton Dekkers, November 14, 2011
However in chapter 6.4.2 - 3 / 4 are mentioned parametric estimation and three point estimates. Combining these options you can mitigate the risk of covering because estimates become fact based instead of judgement based. Based on historical performance a reliable estimate is produced. In conjuction with that also a probality is given. You can use the vaiance between 50% and 80% as a contingency/reserve. Witth that all is transparent. I'm still surprised why this approach is used so limited. I'm very happy that DACE (Dutch association of Cost Engineers) recognised this and started a SIG parametric estimation in collaboration with ISPA (International Society of Parametric Analyst). In the the market there are several tools that support this kind of approach, this to illustrate there are best practises.
written by Phil Armour, November 14, 2011
The 5OI identify two other types of ignorance one of which (3OI) is a process level where I don’t know I don’t know something and I don’t know a (suitable efficient) way to find out that I don’t know I don’t know something. This is a really important level in software development and is seen in things like ineffective testing, poor inspections, inappropriate use of lifecycles, etc. Heck, it’s even seen in bad estimation practices. Almost all software methods, particularly things like testing, are 3OI processes whose primary purpose is to expose our lack of knowledge.
The bottom left quadrant doesn’t really exist in a practical sense. It implies I know something, but I don’t know I know it. How did this happen? Did I forget? If so, I really don’t know it and I’m going to have to figure it out again. Do I not recognize the problem as something I really already know? If so, there are things I clearly don’t know about my problem recognition process.
“Padding” at the low level of organizations and “contingency” at the high level are both attempts to do the same thing: allow for risk. You rightly point out that the first is relatively uncontrolled since it is covert while the second should be overt and should be better controlled. However, to be truly managed we have to empirically and quantitatively determine the risk and then calculate and balance the cost of risk resourcing versus return at risk. This is an actuarial process and it’s pretty much what an insurance company does when they quote an insurance policy. T
written by Timour Khachtchevatsky, November 14, 2011
So don't try to improve Renee - improve your process.
written by T Mellor, November 14, 2011
written by Andrea Brockmeier, November 15, 2011
Yes, you can add reserve at the project, phase, or even activity level. What can be problematic is that “padding” implies that there isn’t a discussion about the risks that result in the padded estimate. Without the discussion, we miss the opportunity identify and, possibly, manage the risks that could have been illuminated with a more transparent discussion. Thanks for the comment!
written by Andrea Brockmeier, November 15, 2011
written by Andrea Brockmeier, November 15, 2011
written by Andrea Brockmeier, November 15, 2011
written by Tom, November 22, 2011
written by Phil Armour, November 27, 2011
The phrase "accurate estimate" is an oxymoron. As a few people have acknowledged, an estimate unaccompanied by a probability is simply incomplete and possibly very dangerous.
A better criterion for evaluating an estimate is its *usefulness*--does it significantly help in making a business decision *right now*? That an estimate will be "better" when we have more information is obvious. A 100% accurate estimate can only be achieved when the project is finished and there is no more uncertainty; it is accurate, but it is not useful--the need for decisions is past. An estimate that states "this project will take between one week and 15 years" is clearly accurate, but it is not useful--it does not help to make a business decision.
The same prediction problems occur in the stock market. Post hoc I can tell you exactly what companies you should have invested in; but it is not very useful. The challenge is supporting the business decision-making process *in advance*.
Employing Scrum is the equivalent of investing small amounts in a range of equities over time rather than one big sum in one stock now. Both mechanisms exist to manage risk.
written by Andrea Brockmeier, November 28, 2011
I would agree that padding is absolutely rational. If the stakeholders, including management, are satisfied with how the estimating works and their definition of success is met at the end, then it sounds like what you're doing is working great. If the missed opportunity to improve the estimates becomes more problematic, then maybe a change in approach is merited. As I say about anything in project management: If what you're doing is delivering your stakeholders' definition of success, even if it flies in the face of best practice, then keep doing it!
written by Andrea Brockmeier, November 28, 2011
I, too, tell students that the idea of an "accurate estimate" is oxymoronic, but I like your discussion to make the point. An estimate as a range implies what you're suggesting - that as you know more, the range narrows - but your comment really makes it clear. Thanks!
written by thegrumpyprojectmanager, November 29, 2011
Optimistic time O (1% chance/3 stand. devs)
Most likely time M
Pessimistic time P (1% chance/3 stand. devs)
-->Expected execution time = (O + 4xM + P) /6 , Easy!
In a smaller job with proper WBS it is possible to have thin pads. However proper change management is needed in all cases. The more vague the task, the thicker paddings (even though we may end up having no paddings if guessing wrong). And somewhere there is a limit, when we need to invoice by hour like suggested in an earlier comment.
People tend to have smaller estimates for the tasks they are interested in doing, and thick paddings for the boring ones or ones they don't favor. Especially in large business projects this gives considerable political power. But this is already kind of out of the subject.
Regards, Grumpy L:^| ]
http://thegrumpyprojectmanager.blogspot.com/

You make it seem that estimating the amount of work for a task is something that can be done accurate and that padding is added as a safety net. But in software projects I noticed that the more experienced the estimator, the more extra time is 'padded' to the estimates.
Lets say a senior dev has is making an estimation for a software integration. He thinks that he can do it in 10 days, he adds another 10 days for unforeseen complications (unknown knowns). That's actually adding reserve for risk on a task level. An I think that's better than managing those risks on a project level, isn't it? This leaves room on the risk register for more tangible risks...
I find that usually these padded estimates closer to the real executed work! I'm actually interested in finding out why junior people tend to 'underestimate' work...
I only have experience in software projects, it might be a different story in construction or any other industry...