Abuses from Estimating
I would like to start off with has anybody seen an appropriate study of estimating when it comes to doing the work? Not a study that already knows the conclusion they want, but an actual scientific study. The thoughts below are not based upon anything like that but, having seen many estimating boondoggles. I have also read portions of the works of Barry W. Boehm, and Constructive Cost Model which is a tool for estimating, many years ago.
I find myself in many discussions with the #noestimates crowd. I am not a no estimating person. The latest “exchange” was around the abuses that estimating brings. This I am in full agreement with them. I just do not go as far as they would to say, no estimates because people are abusive in this regard. My retort, people abuse antibiotics, but we do not ban these. It is interesting to note that most if not all the people I “hear” decry no estimates, are developers, albeit I say this is not via study be anecdotal evidence.
I operate on the assumption (perhaps errantly) that the no estimate response is from the abuse, that is the expectation that what you provide as estimate is law, you are accountable, there is no variance, or variation, or the other abuses cited below.
The following is from input from Ankur Saini, Peter Kretzman and Kim H Pries through Twitter exchanges. I wanted to go through the abuses first blog post. The next post will go through why the business people need to have these estimates.
Why do we estimate?
I think we should start with we perform estimates. Estimated are not really for the developers, my guess is many of these folks are not part of the capital (money and cash flow) working of the company. The developers are not likely responsible for financial decisions on which project should get priority, what expenditures (investments and operations) can be made. Projects are temporary, and if you are a for profit concern, a decision on which project to undertake is based at least in part on the potential profitability and perhaps loss (risk versus reward) calculation. The people closest to the work, are usually the most knowledgeable in this regard. Meaning, managers and executives that have not done the work recently are probably less able to make the estimates. So the best place to look for this estimate, to ascertain business viability for the project, is with the people that do the work, even if their perception is that they get nothing out of it.
Abuses
Now we get to abuses, and there are a few.
- Too much time waste / Estimating everything up front without research and sticking to those estimates
- spending exorbitant amount of time estimating rather than doing work
- You are accountable (anchor bias)
- Adding layers of padding for CYA / Forget to multiply the software fantasy by at least 3
- Letting accounting or marketing estimate
Too much time
There are some organizations, that want to detail plan the exact cost and time for the work, more than 12 months out to arrive at the estimates. This takes weeks and is a very big waste of time. We think we can predict out this far, we have no idea what we will learn in the first 90 days to be able to do any detailed predictions. That is not to say we cannot “ballpark” our estimates for the work. Everybody involved should understand that estimates are a combination of professional judgement, historical record (where possible) and guess work, and the further out in time we go, the more guess work there is. That does not mean eliminate estimating, that means make a quick estimate based upon the things you know.
Spending exorbitant amount.
We can improve our estimates through learning, and this learning requires either studying or more often doing some of the work. When we defer all work to do nothing but estimate we lose this chance to learn while doing and use this learning to help with the veracity of the estimates.
Accountability
I have seen “estimates” with a significant guess component, turn into factual discussions and this happens often. This preliminary work through of the work is taken as the actual, factual, expected end. We use this to coerce the team into meeting these guesses, through phrases like “honor your commitment” and “you are accountable” for meeting this expectation that you have set. Anchoring bias takes over and people treat these guesses as if these were infallible and based upon hard calculated infallible numbers, and revision causes some measure of consternation to the powers that be.
Adding layers of padding / Forget to multiply the software fantasy by at least 3
This abuse is likely the result of the “accountability” abuse, that is, if we are held to keep this guess as the law, we want to ensure we do not go over the estimate, so the estimate must be larger than what we think it takes to do the work. This gets complicated as multiple handling of the estimates can result in yet more padding. Consider that I add 20%, the next in the chain of the estimate – the project manager or manager – adds another 20%.
On the other hand, we should recognize, generally speaking, that people tend to think positively, probably for those famous words “hey y’all watch this.” We should consider that the first estimates are likely much lower than what is reported. To that end, when it comes to budgeting for the work, for the business case (in a later blog post), we should consider the envelop of possibilities when it comes to the project costs and time.
Letting accounting or marketing estimate
Letting accounting or marketing estimate the work, is another form of abuse. The marketing people are often not skilled in the product development or technical arts. These folks can be biased by what the customer is wiling to pay for the product and this colors their judgement also. Similarly, the accounting folks may know how much money is available for the project and use this as the cost of the project having no correlation to the actual work. It is sort of like wanting to purchase a Corvette, but my budget is an Elantra, and expecting to get my Corvette anyway. That is not how this work.
So now what.
The business personnel need to understand the costs associated with the work. If the way estimates are handled or treated in your company cause problems, then fix those underlying problems. Estimates, we have said this before, are not accurate or specific project religious doctrine. As we learn, estimates are revised (up or down). We do not need (neither will we get) a perfect estimate at the beginning, the more we do, the more we learn and know about the project, the more accurate the estimates will potentially become. This requires time doing the work. Estimates are part of the decision process for undertaking the project, answering the question “is this something we can do and feed and house our team and their family, or is this something that represents a loss, risk to the organization.” You cannot make these assessments by not considering the costs, and the costs projections are necessary to understand. Just because you do not see the need for the activity, that does not the mean the activity is not needed. Poor handling of the estimating process, does not mean we just dump that work.
I would like to thank these gentlemen again. Thank you Ankur Saini, Peter Kretzman and Kim H Pries.
The next posting will be on the business case, demonstrating the connection between the estimates, business case, and prioritization of the potential projects of the organization.
https://twitter.com/sainiankur
https://twitter.com/PeterKretzman
