Seen from an airplane window, the ground looks almost two dimensional. Only the largest features: cities, rivers, and mountain ranges, stand out against the background. The true complexity of the terrain only becomes apparent after we land and have to navigate through congested traffic, bad weather, and one-way streets.
Software projects are similar. Staffing and budget plans are often based on high level requirements that tell us what needs to be done, but not how to accomplish it. As business objectives are translated into the actions that need to be taken and the work products that must be produced, the size of the project, whether expressed in lines of code, function points, or RICEF objects, increases along with the time and effort required to create them.
This level of detail cannot be seen at the Requirements stage; it is invisible. But, it can be accounted for and managed. Software consultant, Capers Jones, has stated that software projects grow 1.5% per month. A QSM study based on IT projects found that 90% of those projects were larger than they were initially estimated to be. The average size growth was 15%. This bias towards size growth was not the result of poor estimating. At the time the initial estimates were done, the components that accounted for the size growth were simply not apparent.
SLIM-Estimate® provides two ways to account for the impact of size growth on cost and schedule. The simplest is to increase the estimated project size by 15%. The second is to estimate schedule and effort at higher levels of probability, 65-70% for effort and 85% for schedule if using QSM default levels of uncertainty around size and productivity. It is important to remember that in doing this you are not “padding” your estimate. The additional size is already there in your project. It’s just not visible – yet. Better to account for it sooner rather than later.