Estimating Updates

Over the last couple of weeks, we have been updating the estimating pages on our website, partly in response to the #NoEstimating idiocy.

There is no way an organization that intends to survive will undertake future work without an idea of the required resources, time, and cost needed to achieve the objective and an understanding of the anticipated benefits – this is an elementary aspect of governance. This requires estimating! BUT there are two distinctly different approaches to estimating software development and maintenance:

1.  Where the objective is to maintain and enhance an existing capability the estimate is part of the forward budgeting cycle and focuses on the size of the team needed to keep the system functioning appropriately.  Management’s objective is to create a stable team that ‘owns’ the application. Methodologies such as Scrum and Kanban work well, and the validity of the estimate is measured by metrics such as trends in the size of the backlog.  For more on this download De-Projectizing IT Maintenance from: https://mosaicprojects.com.au/PMKI-ITC-040.php#Process1

2.  Where the objective is to create a new capability, project management cuts in.  Projects need an approved scope and budget which requires an estimate! The degree of detail in the estimate needs to be based on the level of detail in the scope documents. If the scope, or objectives, are only defined at the overall level, there’s no point in trying to second guess future developments and create an artificially detailed estimate. But, with appropriate data high level estimates can be remarkably useful. Then, once the project is approved, normal PM processes cut in and work well. Some of the sources of useful benchmarking data are included in our update estimating software list at: https://mosaicprojects.com.au/PMKI-SCH-030.php#Cost

The #NoEstimating fallacies include:

The fantasy that software is ‘different’ – its not! All projects have a degree of uncertainty which creates risk. Some classes of project may be less certain than others, but using reliable benchmarking data will tell you what the risks and the range of outcomes are likely to be.

Estimates should be accurate – this is simply WRONG (but is a widely held myth in the wider management and general community)! Every estimate of a future outcome will be incorrect to some degree.  The purpose of the estimate is to document what you thought should occur which provides a baseline for comparing with what is actually occurring. This comparison highlights the difference (variance) between the planned and actual to create management information. This information is invaluable for directing attention towards understanding why the variance is occurring and adjusting future management actions (or budget allowances) to optimize outcomes.

Conclusion

The fundamental flaw in #NoEstimating is its idiotic assumption that an organization that commits funding and resources to doing something without any concept of how long its is going to take, or what it will cost will survive.  Good governance requires the organizational leadership to manage the organization’s assets for the benefit of the organization’s stakeholders. This does not preclude risk taking (in many industries risk taking is essential). But effective risk taking requires a framework to determine when a current objective is no longer viable so the work can be closed down, and the resources redeployed to more beneficial objectives. For more on portfolio management and governance see: https://mosaicprojects.com.au/PMKI-ORG.php  

In summary #NoEstimating is stupid, but trying to produce a fully detailed estimate based on limited information is nearly as bad.  Prudent estimating requires a balance between what is known about the project at the time, a proper assessment of risk, and the effective use of historical benchmarking data to produce a usable estimate which can be improved and updated as better information becomes available.  For more on cost estimating see: https://mosaicprojects.com.au/PMKI-PBK-025.php#Process1