Software Project Management Meets Six Sigma

	Bookmark This Page Email This Page Format for Printing Cite This Article Submit an Article Read More Articles
	Related Tools & Articles Managing IT Demands Through Project Portfolios Six Sigma for Software… More Than a New Tool Software Vendor Partnership Cost Reduction With Six Sigma
	Discussion Forum "Using DMAIC you can reduce the schedule and effort over-run, which is common for almost 90% of the projects. You can also measure the variance and then analyse the causes of the over-run. The causes may be wrong estimation of the project, low productivity of the employees, wrong skill set of employees, improper allocation of work, some technical problems, and the list goes on..." Software Timeline Management

B

New from iSixSigma Six Sigma Project Tracking Software Review Project Selection Research Report DMAIC Best-Sellers Project Examples

y David L. Hallowell

Part 2: Top Down Project Effort, Duration, and Defect Prediction
Read Part 1: Bottom-up Project Duration and Variation Prediction

Part One of this article, Bottom-up Project Duration and Variation Prediction, focused on the tasks as a basis for estimating software project effort and duration. Using a work breakdown structure to identify manageable tasks, estimate their duration, and find the project critical path, we reviewed a variety of methods for rolling up project level schedule and resource estimates.

In this article we'll view the same problem from the top down. Using some high level attributes of the work-product being planned (related to its functionality, complexity, and size) and a measure of an organization's project-delivery capability, we will study the approaches for estimating project effort and duration. Looking ahead to a follow-on article, we will see that defects (in-process and released) can also be usefully estimated as part of the top-down view.

Sizing The Work-Product
Top down estimation begins with an assessment of the "size" of the work-product being planned. This idea isn't widely appreciated in software engineering - where project managers often jump directly from requirements to duration estimates. A construction project-manager wouldn't imagine committing to a deadline without establishing and tracking some good size estimates, like the number of square feet, number of windows, doors, etc. to be designed and built.

Sizing refines our understanding of requirements (some say, "If you can't size it you don't understand it"), creating an intermediate measure that is a better predictor of effort and duration than the raw requirements could be. Further, sizing provides an important check for scope creep throughout the project. Failing to pay attention to size we may agree to add functionality without appropriately updating effort and duration.

While the ins and outs of sizing are an article in themselves, we outline some key approaches in Table 1. There is rich history and experience around Lines of Code and Function Point¹ counting. Useful results are being reported for other proxies like use-case counting² and object/property counts³. With so many choices there is known risk in getting stuck in 'method wars' about approach is best. Better to pick one, begin sizing, and using measures and feedback to tune the quality of the estimates it supports.

Table 1: Software Sizing Methods

Assessing The Organization's Delivery Capability
The capability of the organization signing up to deliver a work-product of a particular size is, of course, an important part of the equation governing how long it will take, how much it will cost, and how good it will be. The Six Sigma notion of 'process capability' focuses here on the software factory. In contrast with the manufacturing model, where tangible measures of speeds and feeds and outputs abound, the software factory involves much less tangible measures related to people, communication, understanding, and the use of time.

Figure 1 illustrates what we know in our bones about the dynamics that connect our software process capability and the effort and duration required for the delivery of a certain sized work-product.

Figure 1: Project Effort And Duration Dynamics

Line A in Figure 1 shows that, for a product of certain size in an organization with a particular delivery process capability or 'productivity', there is a limited range over which we can trade off effort and duration. Moving to the right on the line we compress the schedule, adding people-hours to reduce duration. The curve illustrates the non-linear nature of the limited payback we get in that case; a lot of extra effort for a small improvement in the schedule. Moving to the left on the line we relax the schedule in an effort to reduce cost. The shaded regions indicate that there's a point (on the right) where adding more people won't improve the schedule⁴ and (on the left) where few people can't feasibly complete the project over arbitrarily long time.

Line B in Figure 1 shows the impact of reducing size and/or improving the organization's delivery productivity. The same dynamics that applied to line A operate over a region of generally lower effort and duration. Since we can't change productivity overnight, we often react to a schedule or effort-availability crunch by reducing the size of a particular release. Of course if we fail to manage size, we may unwittingly be promising to deliver in a region that's actually impossible. In that case we've created an "expectations failure" - an all too common occurrence in the software business.

Using An Estimating Model
There are a number of commercially available packages that use a combination of industry data and one's own project history to embody the messages in Figure 1 and make useful estimates⁵. One of those companies (QSM, Larry Putnam) has published a number of good books that describe the data and thought process that supported their original modeling work^6,7. Using data on size, effort, and duration for thousands of software projects they fit an equation (Figure 2), focused on an organization's delivery capability (Productivity Parameter, or Productivity Index in his terms) and its relationship to size, effort and duration dynamics.

Figure 2: Putnam Equation

(Putnam's Equation is described in his seminal works on software project estimation. The exponents [1/3 and 4/3 in Putnam's model] express the non-linearity that our experience has shown to be in the effort-duration tradeoffs.

As the equation's raw numbers for 'PP' are a bit unwieldy in scale, Putnam built a productivity index (PI) scale to use as a practical benchmark. Without fathoming the depths of the equation, it's sufficient to take away the observation that an organization with higher PI can deliver more size with less composite effort and duration than one with a lower PI. Also note that PI aggregates our 'software process capability,' summing the influence of things like our experience level, communication effectiveness, interruptions, tools, and more.

Putnam also quantified the notion of 'schedule compression' using a term he called 'Manpower Buildup Index (MBI, Figure 3).

Figure 3: Manpower Buildup Index (MBI)

Manpower Buildup Index (MBI) is one way that schedule compression has been quantified for estimation purposes. In simple terms, an uncompressed schedule (MBI=1) could be thought of as one where the tasks are given the duration that the work breakdown structure and bottom-up estimate suggest they require. 10% and 20% schedule reductions correspond generally to MBI ratings of about 3 and 5 respectively.

Building An Estimating Model
If an organization has enough project history, with accurate enough measures of effort, duration, size, and schedule compression, regression analysis can be used to build and calibrate an estimating model. Figure 4 shows some results from such a model, built using data from a number of sources across the industry. We use this model in training as a project 'flight simulator' which tracks with software industry experience.

Figure 4: Coefficients In A Nonlinear Regression Model

(Coefficients in a nonlinear regression model for estimating the 'Y' project effort using the 'xs' size, productivity (PP) and schedule compression (MBI).)

A few examples of estimating model output can help solidify the discussion about productivity, size, schedule compression, effort, and duration.

Figure 5: Estimating Model Input And Output

The first three rows in Figure 5 illustrate a project of size 500 Function Points, being planned by an organization with software process capability (PI) 17. As schedule compression increases from 1 to 5 the duration is reduced some, but not without exacting a strong, non-linear penalty in effort. The next three rows consider a project in an organization with PI 18. The outputs show they are able to deliver a project of the same size with less effort in less time, - regardless of schedule compression case to case.

Contouring Resources
While the first output of a top-down estimating model has given us a handle on total effort, we know that the way work gets done in a project often follows a contour similar to the one in Figure 6. This curve follows a Rayleigh distribution, which has been fit effort over time for a wide variety of project types.

Figure 6: Rayleigh Distribution Model

(Rayleigh Distribution models 'the way work actually gets done' over time. This can help contour our resource planning.)

The Rayleigh curve models the way that our estimated project resources (in this case about 18 person-months of effort) will be contoured over time. As no project hits the ground running at full speed, this curve shows we need only about 1.5 full time employees (FTEs) at the outset. After about 3 months we will need 3 people, and then less staff as the activity winds down. This is in contrast with what some would call 'rectangular scheduling' where we might have been convinced that our 18 person-month project could be staffed with 2 people for 9 months. Rectangular scheduling is the ultimate in schedule compression - and no one knows of a project where the real work was actually contoured that way.

Putting It All Together
Having reviewed at this point both the bottom-up and top-down approaches to estimation one might ask "Which one is best?" The best answer is probably 'both.' A good software project manager may actually bring three estimates into view:

1. Bottom up estimate, using work-breakdown structure, critical path, task estimates, and rollups for effort and duration. As we have seen, this kind of estimate identifies tasks, resources, and critical path - supporting the project plan with crucial detail.
   
   
2. Top-down estimate, using what we know about size, "PI" (or equivalent) and schedule compression. This estimate encompasses the history of real projects in our own and/or software industry history. It will often be more pessimistic than our bottom up estimate, as it brings the non-linear effort-duration dynamics into view. This can be an important sobriety test for the linear optimism project managers too often embrace.
   
   
3. The Gut / Prior Experience. One's cumulative experience in similar projects can provide estimates that deserve some consideration in balance with the bottom-up and top-down views. As one understands and reconciles the tension between all these estimates they can work to converge on a rational, defensible compromise.

Looking Ahead
A natural build on this two part series is the topic of defect dynamic modeling. It turns out that the Rayleigh distribution and some of its relatives can be quite useful in estimating defect densities during development phases, through test, and after release. In a subsequent article we will explore the theory and practice related to that aspect of estimation, connecting it with the foundation we have built for effort and duration modeling.

About The Author
David L. Hallowell is a Managing Partner of Six Sigma Advantage, Inc. and has 20+ years experience as an engineer, manager and Master Black Belt. As Digital’s representative to Motorola’s Six Sigma Research Institute he worked on the original courseware for Black Belts and the application of Six Sigma to software. Mr. Hallowell has supported Six Sigma deployments and trained many Black Belts and trainers worldwide.

With a special focus on Design for Six Sigma, he has led development teams to breakthrough improvements in the concept development and design of a number of commercial products. Mr. Hallowell has patents and publications in the area of microelectronics packaging and high speed interconnect. He has authored courses in Software DFSS, Design of Experiments, C++ , and Computational Intelligence Tools. He is a co-founder of Six Sigma Advantage Inc., where he co-authored the Black Belt, Green Belt, and Foundation curriculum. He can be reached via email at dhallowell@6siga.com.

References
1 The International Function Points Users Group ( IFPUG, www.ifpug.com) maintains a body of knowledge, training, and case studies on function point counting.
2 "Some Case Stidies In the Use of Metrics to Support Process Improvement." Anthony Hemens. ESEPG Conference Proceedings, London, 2003.
3 "Planning and Estimating Complex Web-Based Projects." Dr. Richard Bechtold, Patricia Larsen. SEPG Conference Proceedings, Boston, 2003.
4 "Adding people to a late project makes it later" Paraphrased from The Mythical Man-Month. Brooks. Addison-Wesley. 1995.
5 The 'big 3' suppliers are probably Software Productivity Research (www.spr.com), Quantitative Software Management (www.qsm.com), and Galorath (www.galorath.com).
6 Putnam, L. and Myers, W., Measures for Excellence. Yourdon Press. 1992.
7 Ibid. Industrial Strength Software. IEEE Computer Society. 1997.