Let's assume we can get over the confusion as to why estimating can and does add value in many project management situations. The next step in our maturity - this is maturation in the sense of CMMI IPPD SE/SW maturity - is to understand that the estimates are probabilistic in nature.
But first - in my experience here in aerospace - is to understand the difference between probability and statistics. In most AP High school and introductory college texts, probability and statistics are taught in the same course. This is where the confusion starts.
Here's a useful example that can distinguish between the two:
- We have a bucket, a collection of colored marbles and a hand (human hand)
- Statistics = we're holding in our hand a collection of colored marbles. Statistics asks the question:
- Given the information in our hand, how many of what color and quality of marbles are in the bucket?
- Probability = we've looked into the bucket and seen the color and quantity of marbles. Probability asks the question:
- Given the observation of the contents of the bucket (color and quantity) what color and quantity of marbles would we have in our "closed" hand if we draw a sample from the bucket?
What estimating does - if we have the right underlying information - is ask and answer the question:
From the information of the past - cost and schedule performance - what is the probability we will be able to perform to some forecast cost and schedule?
Notice there are two elements here:
- The forecast value - cost and or schedule of a future outcome.
- The confidence that we can come in at or below the forecast value.
There are several issues not addressed in the suggested approach that says "let the managers do this work, and let the developers focus on analysis..."
- The estimates for the durations have no underlying probability distributions in the absence of data or models for producing the data (calibrated COCOMO for example). Numbers generated in this way can not be placed in a confidence interval. Even if the probability density function is derived by curve fitting - usually a 4th order polynomial - this has little integrity in practice
- Understanding that estimates are random numbers (but not random) drawn from underlying probability distributions removes nearly all the complaints about poor estimating.
- Once this recognition takes place, true probabilistic process can be put in place to deal with the need to answer - how long and how much?
- Assigning this estimating work to a staff that is not performing the actual work or has performed it in thepast is simply a "bone headed" idea. Here in aerospace, estimates are done by IPT Leads and Discipline Leads. These are the people responsible for delivering the spacecraft subsystems.
- The suggestion that estimating is muda and should be done by others leads directly to bad estimates
- Either do estimating right or admit that the estimating process is really guessing
In the end estimating is a critical success factor for any project management style - agile or not. Getting good estimates requires understanding the differences between probability and statistics. In means gathering historical data to calibrate the estimating process. And most importantly it means developing estimating skills at the engineer and implementer level not the management level.
