Estimation
Estimating for the Business Plan
Having worked in sales and customer service at QSM for over 17 years, I speak to hundreds of professionals each year that are directly or indirectly involved with software development projects using many different development processes. One of the things that I hear from time to time is that estimating is not as important when working with more iterative development methodologies. Some of the reasons I hear most often are that “team sizes are smaller,” “work can be deferred until the next iteration,” “we are different,” and “we are agile.”
What Basketball Can Teach Us About Software Estimation
I discovered early on that the player who learned the fundamentals of basketball is going to have a much better chance of succeeding and rising through the levels of competition than the player who was content to do things his own way. A player should be interested in learning why things are done a certain way. The reasons behind the teaching often go a long way to helping develop the skill. — John Wooden
John Wooden is regarded as one of the greatest college basketball coaches. He believed that after talent, courage, and character, fundamentals built successful teams. Successful software projects result from knowing and practicing fundamentals as well, and it begins with estimation.
I thought it would be fun to see if Coach Wooden, by way of noted quotes, could help simplify a few SLIM core concepts.
Does Your Estimate Accurately Reflect the Five Dimensions of Software Trade-offs?
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.
Process and Tools Together
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.
For More Accurate Software Estimates, Avoid Hidden Risk Buffers
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.
Webinar Replay Now Available: Successful Estimating Processes Using the SLIM API
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.
Software Cost Estimation Article in The DACS Journal
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:
Part III: The Caveats
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.
Part II: Estimate the Estimate
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:
How Much Estimation?
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).
