Here's an extract from "Chapter 8: Human Behavior and Complexity," Terry Cooke-Davies, in Aspects of Complexity: Managing Projects in a Complex World.
Drawing Unsupported Conclusions from Incomplete and Inconclusive Data, it is not only natural but also laudable, to seek evidence that confirms something that we hold to be true. If, for example, a project manager believes a member of his or her team is a fast and effective worker, each time that team member works fast and effectively or is told by a colleague about the work that has been done fast and effectively, the project manager will consider his or her belief to be well-founded.
If we are to hold anything to be true, it is necessary that we can cite confirmatory evidence that it is, indeed, the case. Unfortunately, on their own, isolated instances and credible anecdotes are not sufficient to support the case conclusively. At best, such evidence only suggests that our belief may be true, which is a long way short of providing proof that it is a valid belief.
This is a cautionary tale for those listening to the #NoEstimates advocates, where anecdotes of bad management are used in an attempt to replace established principles of business management.
The human behaviors are used with anecdotes like ...
"I've seen estimates abused by bad managers, so let's NOT estimate and that will fix the behavior of Bad Managers." This, of course, is a fallacy on all levels. The "bad management" is itself a symptom of untrained, inexperienced, unskilled decision making processes in the presence of uncertainty.
While the human behaviors are real and observable, conjecturing that decisions can be made in the presence of uncertainty without estimating the outcome of those decisions, there is no principle to support that conjecture. So those advocating that #NoEstimates is a credible approach to spending other peoples money in the presence of uncertainty, need to take another approach.
So what should you do, when you encounter this bad management or work where Dilbert's Boss is your boss?
The first thing to do is NOT fall for the fallacy that NOT Estimating will fix the behavior of the bad manager. That manager is still there, he or she is not going away. You've got a real problem if that manager actually doesn't understand that estimates are just that. They are not commitments in the normal sense, they are not promises that can be kept without other attributes.
Let's look at what an estimate is.
An Estimate is a value inferred for a population of values based on data collected from a sample of data from that population or generated from a model of the process being estimated. This model can be produced parametrically (Reference Class Forecasting) or through a simulation (Monte Carlo or Method of Moments is common).
- Estimates can be about the past, present, or future.
- We can estimate the number of claims in the Pleistocene era that are in the shale formations near our house.
- We can estimate the number of people sitting in Folsom Field for last night's game against Utah. The Buff's won and are now the PAC-12 South Champs.
- We can estimate the total cost, total duration, and the probability that all the Features will be delivered on the program we are working for the US Government. Or ANY software project for that matter.
Estimates have precision and accuracy.
- These precision and accuracy values have estimates as well.
- The estimated completion cost for this program is $357,000,000 with an accuracy of $200,000 and a precision of $300,000.
- Another way to speak about the estimated cost is This program will cost $357,000,000 or less with 80% confidence.
An estimate is a statistic about a whole population of possible values from a previous reference period or a model that can generate possible values given the conditions of the model.
In the project domain, an estimate is a calculated approximation of some desired measurement.
This is usually a cost, a completion date, a performance measure used in a closed loop control system to keep the project GREEN while delivering the needed Capabilities to produce the Value for the customer at the needed time for the needed cost.
Showing up late, over budget, and with missing Capabilities is not what the customer paid for.
Those advocates #NoEstimates like to say we're not estimating, we're forecasting
Let's Look at What a Forecast is
Forecasts speculate future values for a population of possible values with a level of confidence, based on the current and past values as an expectation (prediction) of what will happen:
- This is the basis of weather forecasting.
- If you listen carefully to the weather forecast it says there is a 30% chance of snow next week over the forecast area.
- We live at the mouth of a canyon at 5,095' and if there is a 30% chance of snow in Boulder (8 miles south), there is a much lower chance in our neighborhood.
- Business forecasts, weather forecasts, traffic forecasts are typical. These forecasts usually come from models of the process being forecast. NOAA and NCAR are in our town, so lots of forecasting going on. Weather as well as climate.
- Not so typical to Forecast the cost of a project or forecast the delivery date. Those are estimated values.
- For example, a financial statement presents, to the best of the responsible party's knowledge and belief, an entity's expected financial position, results of operations, and cash flows. [1]
In a forecast, the assumptions represent expectations of actual future events.
- Sales forecasts
- Revenue growth
- Weather forecasts
- Forecasts of cattle prices in the spring
A forecast is a prediction of some outcome in the future. Forecasts are based on estimating the processes that produce the forecast. The underlying statistical models (circulation, thermal models) of weather forecasting are estimates of the compressible fluid flow of gases and moisture in the atmosphere (way oversimplified).
So What Can You Do With Your Dilbert-Boss?
Like Dilbert, not much, if in fact, your boss is a cartoon character. If he or she is a human being, Cooke-Davies suggests ...
Many of these skills and competencies are concerned with relationships between either people or groups of people or different aspects of human behavior that arise from nonrational or irrational behavior that seems to be endemic to the human condition.
...
Apart from the general run of daily interpersonal relationships, projects involve certain formal power-relationships that crucially contribute to the context within which behavior is played out on projects. Perhaps the most salient of these is the relationship between the “buyer” of the output of a project and the “seller” who manages the resources necessary to deliver that output.
Many studies have shown that the behaviors where the buyer and the seller have collaborative relationships are not common. The basis of this common misbehavior comes for research by Daniel Kahneman. From the press release of the Nobel committee for Kahneman's prize
“Kahneman’s main findings concern decision-making under uncertainty, where he has demonstrated how human decisions may systematically depart from those predicted by standard economic theory. Together with Amos Tversky (deceased in 1996), he has formulated prospect theory as an alternative, that better accounts for observed behavior. Kahneman also discovered how human judgment may take heuristic shortcuts that systematically depart from basic principles of probability. His work has inspired a new generation of researchers in economics and finance to enrich economic theory using insights from cognitive psychology into intrinsic human motivation.”
The world of economics, and specifically microeconomics of decision making in the presence of uncertainty, it is clear human behavior is not always rational. Kahneman is speaking about risk-taking when we put it in the project context. The #NoEstimates advocates are suggesting that the bad management of Dilbert's Boss can be removed if we simply DO NOT Estimate. When if fact that human behavior that motivates the bad manager is not removed by NOT Estimating, it's still there, but more so, since there is no information provided for decision making.
In 2003, Kahneman stated in a Harvard Business Review article "Delusions of Success," in planning major initiatives, executives routinely exaggerate the benefits and discount the costs, setting themselves up for failure. The presence of optimism bias, attribution errors, and the illusion of control are the main sources of these biases.
So now #NoEstiimates is conjectured to solve these problems, with no evidence to support that conjecture, leaving the bad manager in a loose-loose situation.
What To Do Next?
The first step is the acknowledge that #NoEstimating will NOT fix Dilbert's Boss.
The next step is to start to understand the principles of making decisions in the presence of uncertainty with limited resources. This is the domain of Microeconomics and when applied to software development it is the microeconomics of software development. First a definition
Microeconomics is the study of how people make a decision in the resource-limited situations on a personal scale (as compared to Macroeconomics on the national scale). Microeconomics deals with decisions that individuals and organizations make on such issues as how much insurance to buy, which word processes to buy, what price to charge for a product or service, which Feature in the Product Backlog will produce the best Value for the customer. Microeconomics in the development of software deals with the types of decisions needed to successfully spend the customer's money to produce the needed value that customer is paying for.
Clearly, our projects have limited resources, never have enough time or money to produce all the features. So our projects are subject to the Microeconomics of Decision Making in the presence of uncertainty [2]
Let's start with some more resources for making estimates in the presence of uncertainty on agile projects ...
Are these resources going to fix the Dilbert Boss that misuses, abuses, estimates? Of Course Not.
What they are going to do is provide you with an understanding of the principles of making decisions in the presence of uncertanty, when spending other people's money who are paying you to produce value for them, for the cost they are expecting, on the day they are expecting - all within the probabilistic confidence levels needed to have confidence there is sufficient probability of success for their investment.
Dibert's boss should behave this way, but let's say he doesn't. Then as we say in our domain
Someone has to be the adult in the room.
Why not you?
Some Resources on this topic
[1] Assuring Credibility in Cost Estimates
[2] IEEE Transactions on Software Engineering, SXE-10, January, 1981, pp. 4-21
