In any development methodology, we throw around the word “estimate” freely not really understanding how it’s interpreted by many. In many cases, an estimate, regardless of its content and process by which it was created, is received implicitly as a pin point number with the accuracy of multiple decimal points. This presents a problem for all parties involved.
I recently had a discussion with a gentleman who told me that prior to using our SLIM tool, the estimates in his organization were arrived at by casual hallway conversations, often started with, “how much do you think this will cost, and how long will it take?” A typical response is, “hmmm, I’d say about 6 months and $500K.” That innocent musing then becomes the information upon which business decisions are based, leadership bonuses may be won or lost, and the credibility of the dev team is on the line.
I’d strongly recommend adhering to some definitions when talking estimates. These definitions will help mitigate potential misunderstandings around the agreement of what makes an estimate:
| Target/Goal | What we hope to do or achieve. |
| Constraint | A practical limit on time, money, resources. |
| Estimate | Technical calculation of what we might be able to do, assuming a given scope, cost, schedule, staff, and uncertainty level. |
| Commitment | A business decision to select one estimate scenario and assign company resources to meet a target within some constraints. Usually includes contingency/management reserve. |
| Plan | Detailed list of tasks, activities, resources, and milestones. |
In the hallway exchange above, the project manager communicated the Target/Goal without considering the constraints of time, money or people – this is common and just part of human nature. We at QSM evangelize practicing some scientific processes when estimating (using empirical data for one) to ultimately arrive at a defensible estimate. In everyday life, we provide estimates all the time, albeit most with much less risk, for things like distance to work, how long a movie lasts, when you’ll get home.
Permeating each stage of these definitions is the importance of embracing uncertainty. No estimate will be 100% accurate (that happens when the project is complete). But if we acknowledge uncertainty and build it into our estimates, everyone is protected and the estimate accuracy increases.
While the Target shouldn’t be the end game, like it was in the example above, it’s a necessary starting point from where we can negotiate and communicate our way through from understanding Constraints, to an Estimate, then Commitment and finally a Plan.
For years I was guilty of using these terms interchangeably, but by giving each definition its due, the estimating process becomes less tenable because we collectively understand the terms.