One of the hallmarks of a great project manager is his ability to estimate accurately. Estimating is a function of profitability. Assessing accurately and staying the course can realize the projected profit. For this reason, the one doing the work must estimate the job. Ideally, estimates are required from all angles to do the development work. Most importantly, in software, the tester’s opinions are included as part of the development team.
Far too often, estimates are “voluntold,” usually by sales and management after a signed contract is set to do a mission impossible. Expert advice is dismissed. Instead, it will be averaged out with detailed descriptions and prioritized with estimated business value when there is little to no experienced input.
WHY ESTIMATE IF YOU CAN MEASURE? —STEPHEN CHOO QUAN
To combat the unknown, we can do a SPIKE, as it is known in the agile methodology. In the simplest form, a SPIKE is a Proof Of Concept (POC) or prototype to learn so you can estimate better for tasks with higher accuracy and testing for increased business value. The SPIKE is time-boxed but not given a story point to be included in velocity calculations.
Estimates are bad because, the truth is, we are not good at them. We overestimate the event and underestimate the process. Our best estimators are humble to this fact in the face of mounting managerial pressure to reduce the timeline and cost. These estimators also know that optimism is rewarded.
A wider confidence interval (CI) is a sign of a novice or ignorance, so most pros try to keep it narrow but ignore how much luck plays a role. Therefore, even the most experienced are poor estimators but defend their variances after rationalizing unforeseen complexity, aka excuses.
There are three typical scenarios when you estimate
- You have done this exact job before and been successful
- You have successfully done a similar job.
- You have no experience with this new scenario.
The best way to estimate a project is to use statistics and not let optimism get the better of you. Do the following:
- Estimate the project. A reasonable calculation is (2N + (B+W/2) )/3, as shown in the table below.
- Find the base rate for projects of that type.
- Initiate variance from the base rate base on correlated factors and shift your estimate accordingly.
Do not get cocky and think you will have a wide variance from the base rate for similar correlated factors.
Using the Program Evaluation and Review Technique (PERT), we can estimate the time and the number of standard deviations that can happen, it is not uncommon to have two standard deviations.
| B | N | W | (2N + (B+W/2) )/3 | W-B/6 | |
| Work Breakdown Structure | (B)est | (N)ormal | (W)orst | Estimate | Sigma |
| Task1 | 2 | 4 | 8 | 4.333333333 | 1 |
| Task2 | 1 | 3 | 12 | 4.166666667 | 1.833 |
| Task3 | 5 | 6 | 9 | 6.333333333 | 0.667 |
| Task4 | 6 | 10 | 20 | 11 | 2.333 |
| TOTAL | 25.83333333 | 5.833 |
We should be re-estimating based on known average sustained velocity, but it seems like wasted energy since clients use our first estimates as gospel and law.
Sadly, we are the least knowledgeable at the beginning of a project, and that is precisely the moment when we are asked to provide estimates. The cone of uncertainty shows that our estimates become more accurate as they move down the project timeline. We also know that as the margin of input data increases, estimates will also increase in its variances, sending our initial forecast for a toss.
In closing, the way to recourse the original estimate is to estimate both content work and relationship AND win on both fronts if you are to get estimates recalculated and communicated as you go. It is best to give a range of possible dates and not give one date, which is a commitment asked to keep.
Stephen Choo Quan
Sharing is Caring. Thanks for reading and Sharing ❤
