I love it when there is a post about Myths and Half-Truths, that is itself full of Myths and Half Truths. Orginal text in Italics, the Myth Busted and Half Truth turned into actual Truth beow each
Myth: If your estimates are a range of dates, you are doing a good job managing expectations.
- Only the earlier, lower, more magical numbers will be remembered. And those will be accepted as firm commitments.
If this is the case, the communication process is broken. It's not the fault of the estimate or the estimator that Dilbert style management is in place. If this condition persists, better look for work somewhere else, because there are much bigger systemic problems there.
- The lower bound is usually set at "the earliest date the project can possibly be completed". In other words, there is absolutely no way the work can be completed any earlier, even by a day. What are the chances of hitting that exact date? Practice shows - close to nil.
The lower bound, most likely, and upper bounds must have a confidence level. The early date with a 10% confidence says to the reader, there is no hope of making that. But the early alone gets stuck in the mind as a cofirmation bias.
Never ever communicate a date, a cost, a capability in the absence of the confidence level for that number.
Making the estimate and management expectations have no connection to each other. Poor estimates make it difficult to manage expectations, because receiving the estimates loose confidecen in the estimator when the estimates have no connection with the actual outcomes of the project.
Half-truth: You can control the quality of your estimate by putting more work into producing this estimate.
It's not the work that is needed, it's the proper work. Never confuse effort with results. Reference Class Forecasting, Parametric models, and similar estimating tools along with the knowledge of the unlying uncertaities of the processes, technology, and people connected with delivering the outcomes of their efforts.
- By spending some time learning about the project, researching resources available, considering major and minor risks, one can produce a somewhat better estimate.
- The above activities are only going to take the quality of the estimate so far. Past a certain point, no matter how much effort goes into estimating a project, the quality of the estimate is not going to improve. Then the best bet is to simply start working on the project.
Of course this ignores the very notion of Subject Matter Expertise. Why are you asking someone who only knows one thing - a one trick pony to work on yu new project. This is naive hiring and management.
This would be like hiring a commercial builder with little or no understanding of modern energy efficient building, solar power and heating, thermal windows, and high efficiency HVAC systems and asked him to build a LEADS Compliant office building.
Why would you do that? Why would you hire software developers that had little understanding of where technology is going? Don’t they read, attend conferences, and look at the literature to see what’s coming up?
Myth: People can learn to estimate better, as they gain experience.
People can learn to estimates as they gain skill, knowledge, and experience. All three ae needed. Experience alone is necessary but far from sufficient. Experience doing it wrong doesn't lead to improvement, only confirm that bad estimates are the outcome. There are a nearly endless supply of books, papers, and articles on how to properly estimate. Read, take a course, talk to experts, listen, and you'll be able to determine where you are going wrong. Then your experience is will of value, beyond confirming you know how to do it wrong.
- It is possible to get better at estimating – if one keeps estimating the same task, which becomes known and familiar with experience. This is hardly ever the case in software development. Every project is different, most teams are brand new, and technology is moving along fast enough.
That's not the way to improve anyting in the software development world. If you wrote code for a single function over and over again, you'd be a one-trick-pony.
The notion of projects are always new, is better said projects are new to me. Fix that by finding someone who knows what the new problem is about and hire them to help you. Like the builder above dobn't embark on a project where you don't have some knowledge of what to do, how to do it, what prolems will be encountered and what their solutions are. That's a great way to waste your customers money and join a Dath March project.
- Do not expect to produce a better estimate for your next project than you did for your last one.
Did you not keep a record of what you did last time. Were you paying attention to what happened? No wonder your outcomes are the same.
- By the same token, do not expect a worse estimate. The quality of the estimate is going to be low, and it is going to be random.
As Inigo Montoya says: You keep using that word. I do not think it means what you think it means.All estimates are random variables. These random variables come from an underlying statistcial process - a Reference Class - of uncertainty about or work. Some are reducible some are irreducible. Making decisons in the presence of this uncertainty is called risk management. And as Tim Lister says Risk Management is how Adults Manage Projects.
Half-truth: it is possible to control the schedule by giving up quality.
The trade offs between cost, schedule, and performance - quality is a performance measure in our Software Intensive Systems domain, along with many other ...ilities. So certainly the schedule can be controlled by trading off quality.
- Only for short-term, throw-away temporary projects.
This is not a Myth, it's all too common. I'm currently the Director of Program Governance, where this decision was made lomg ago and we're still paying the price for that decision.
- For most projects, aiming for lower quality has a negative effect on the schedule.
