A recent series of posts by Karl Wiegers eloquently discusses the "reality of tradeoffs" software professionals deal with every day, going beyond the typical success drivers (time, cost, and quality) to include product features and staff. He shares inspiring practical information by making distinctions between constraints, drivers, and degrees of freedom, each representing the amount of flexibility the project manager has to adjust a key factor.

SLIM-Estimate has modeled the non-linear interdependencies of these metrics for over thirty years. It accounts for Wiegers’s five project success factors explicitly, showing the tradeoffs between them in real time. I have mapped Wiegers’s Five Dimensions to SLIM-Estimate’s parameters to show how you can use SLIM-Estimate quantify the trade-offs Wiegers describes.

At QSM we offer Estimation Process Consulting Services and the SLIM-Estimate tool. In my 16 years at QSM, I have probably spoken with hundreds of project managers about the pain that they have in the estimation area. Many tell me that they want to finish implementing their process before they bring in a tool.

One of the things that I have learned over the years is that it can be extremely beneficial to bring in the tool while the process is being developed. A successful estimation process implementation is about getting the right project data in the right place for consistent collaboration and results. Implement both the process and the tool at the same time and you can save a ton of money in rework costs down the road. 

A good estimation tool provides a roadmap and a communication vehicle for a successful estimation process. The tool collects the core metrics that the process requires. It also streamlines the results to give the user exactly what they need to know: risk, size, duration, effort, reliability, and productivity.

Some will spend years writing and implementing their process. Why not get the estimation tool in place sooner to make things easier?

A colleague of mine recently sent me a blog post explaining the difference between project contingency and padding.  The blogger made the distinction that padding is what often gets added to an individual’s estimate of the effort required to perform a task (in her example, a software development task) to account for project ‘unknowns’.  The estimator determines the most likely required effort, then pads it with a little more effort in order to arrive at an estimate to which he or she can commit.  Thus, padding represents an undisclosed effort reserve (and implied schedule reserve) to buffer against potential risk.  Contingency reserve, she explains, is “an amount of money in the budget or time in the schedule seen and approved by management.  It is documented.  It is measured and therefore managed.”  Ms. Brockmeier is correct in promoting contingency as the better management tool.  The challenge is having a method to measure and document this contingency and the known unknowns it is buffering.

Implicit Risk Buffer

Padding is a natural result of bottoms-up, effort-based estimation techniques.  Estimating low-level WBS elements creates more opportunity for padding, because the number of unknowns grows with the task list.  The estimator is consciously or unconsciously assessing the risk of each task, considering its dependencies and complexities.  What is being implied in the effort estimate is: 1] an assessment of product size and complexity, and 2] a productivity valuation.

If you were unable to attend our most recent webinar, Successful Estimating Processes Using the SLIM API, a replay is now available.

How do best in class development organizations achieve maximum return on investment from their estimation programs? By leveraging the SLIM API for integrations between estimation tools and detail-oriented products, development teams are able to simplify estimation processes and broaden the estimation program user base. Presented by Carl Engel of IBM Global Services, Scott Lancaster of State Street, and Larry Putnam, Jr. of QSM, this webinar explores two successful implementations of the SLIM API between third party tools and the SLIM Suite. 

Carl Engel is the Estimating Program Manager for IBM's Global Business Services responsible for the development and deployment of performance benchmarking and estimating process, methods and tools including the support for nearly 1,000 SLIM Suite users. Carl has been with IBM for 12 years as an Associate Partner and has had previous roles as the program manager for IBM's project management methodology and tools. He is an IBM certified Executive Project Manager, PMP with over 30 years of program and project management experience primarily in very large scale efforts in the nuclear industry and U.S. National Laboratories.

The February issue of the DACS Journal of Software Technology focuses on Software Cost Estimation and Systems Acquisition. My contribution, which you can read here, addresses the challenges faced by estimators and the value of establishing a historical baseline to support smarter planning, counter unrealistic expectations, and maximize productivity.

Using several recent studies, my paper addresses the following questions:

• What is estimation accuracy, and how important is it really?
• What is the connection between the Financial Crisis of 2008 and software estimation?
• Why do small team projects outperform large team projects?
• How can you find the optimal team size for your project?

Read the full article.

In Part 1 of How Much Estimation? we noted that there is an optimal amount of time and effort that should be spent in producing an estimate based on the target cost of a project and business practice being supported.

In Part 2: Estimate the Estimate, we saw that the formula to calculate this optimal time (as measured at NASA)  calculates the Cost of Estimate as the Target_Cost raised to the power 0.35 (approximately the cube root of the Target Cost).  The factor that defines the business practice (either by early lifecycle phase or perhaps by the “expected precision” of the estimate) is a linear factor ranging from a value of 24 to a value of 115.

Those Caveats!

I mentioned that there were caveats with the calculation.  Here they are:

In Part 1 of How Much Estimation, we observed that both too much time and effort and too little time and effort spent on estimating are less than optimal.  Combining:

• The cost of producing an estimate—which is a function of the number of people working on the estimate and how long they work
• The cost of variance in the results of the estimate—that is, how much the estimate varies from experienced actuals and what that variance will likely cost the project.  This is typically a function of the number of unknowns at the time of estimating for which the project cannot easily adjust and which will require additional unplanned resources of time, effort, and staff.

We get a U-shaped curve, at the bottom of which is the optimal time: we’ve spent enough time and effort to minimize the sum of the cost of estimate and the cost of variance.

The question is: how to calculate this point?  It will not be the same for a very large complex project and a very small simple project.  Also we don’t want a complicated and time-consuming approach to calculate the cost of estimate—it should be quick and simple.

NASA’s Deep Space Network (DSN) projectⁱ developed a mechanism for this calculation based on two simple parameters:

Target Cost of Project

This is goal cost of the project as first envisaged in the project concept.  It is NOT the estimated cost of the project (which hasn’t been calculated yet).  Projects for which we expect and plan to spend a lot of money should clearly have more time and effort spent in estimating simply because more is at risk.

How much time and effort should we spend to produce an estimate?  Project estimation, like any other activity, must balance the cost of the activity with the value produced.

There are two extreme situations that organizations must avoid:

The Drive-By Estimate

The drive-by estimate occurs when a senior executive corners a project manager or developer and requires an immediate answer to the estimation questions: “When can we get this project done?”  “How much will it cost?” and “How many people do we need?" (the equally pertinent questions: “How much functionality will we deliver?” and “What will the quality be?” seem to get much less attention).

Depending on the pressure applied, the estimator must cough up some numbers rather quickly. Since the estimate has not been given much time and attention, it is usually of low quality. Making a critical business decision based on such a perfunctory estimate is dangerous and often costly.

The Never-Ending Estimate

Less common is the estimation process that goes on and on.  In order to make an estimate “safer” an organization may seek to remove uncertainty in the project and the data used to create the estimate. One way to do that is to analyze the situation more and more. Any time we spend more time and more effort in producing an estimate we will generally produce a more precise and defensible result. The trouble is the work we have to do to remove all the uncertainty is pretty much the same work we have to do to run the project. So companies can end up in the odd situation where, in order to decide if they should do the work what resources they should allocate to the project, they actually do the work and use up the resources.

After being away from QSM and the software world for three years, I was blown away by SLIM v8.0's dynamic product integration. I knew it was coming, yet I was still impressed by the simplicity and power of analysis promoted by real-time data and tool links across the SLIM Suite that frees managers to focus on the important program issues.

SLIM-MasterPlan is the center of the SLIM Suite product integration.  It improves upon previously existing program management features of aggregating multiple SLIM-Estimate projects and ancillary tasks with two new capabilities: 

• Linking SLIM-Control workbooks to provide real-time project tracking and control at the program level 
• Performing What If analysis at this higher management view to consider a wider range of potential outcomes.

The What If analysis feature is what I want to highlight.

A good personal development coach knows the "power of the question."  Questions lead to discovery, innovation, and action that brings about positive change.  Better questions lead to better answers.  SLIM's power and distinction has always been fast and easy evaluation of the impact of change, and exploring the realm of possible outcomes.  That's what we are doing when we ask ourselves "What If…?" (or our boss asks us - and we better know the answer!).  SLIM's solution logs make it easy to compare estimates, plans, and forecasts to alternative solutions, QSM trends, and your historical project database.

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.