Welcome to Food for Thought™, an e-newsletter from Software Quality Consulting. I've created free subscriptions for my valued business contacts. If you find this newsletter informative, I encourage you to continue reading. Feel free to pass this newsletter along to colleagues by clicking the Forward Email link at the bottom of this page. If you’ve received this newsletter from a colleague and would like to subscribe, please click this New Subscription link. If you don't wish to receive this newsletter, click the SafeUnSubscribe™ at the bottom of this page, and you won’t be bothered again.

Last month, we discussed the importance of having well-written, unambiguous requirements. This month, we’ll continue that theme by discussing why requirements are essential for creating accurate estimates and building realistic schedules.

Regular features to look for each month are:

• Monthly Morsel: Hints, tips, techniques and reference info related to this month’s topic

• Calendar: Conferences, workshops, and meetings of interest to software engineers, QA engineers and anyone interested in software development.

Estimating and Scheduling - Do You Believe in Magic?

“Industry surveys from organizations such as the Standish Group, as well as statistical data [...] suggest that the average [software] project is likely to be 6-12 months behind schedule and 50-100 percent over budget.”

Yourdon, E., Death March: The Complete Software Developer’s Guide to Surviving ‘Mission Impossible’ Projects, Prentice-Hall, 1997.

The ability of an organization to accurately estimate software tasks, build realistic schedules, and then meet those schedules is critical. Yet few organizations have been able to do this consistently. As a result, many organizations have little or no credibility when it comes to estimating and scheduling. There are many reasons why organizations perform poorly in this area. Some of the most common reasons include lack of training, inability to manage commitments made to customers, poorly written or non-existent requirements, and lack of management will. I’ve often observed projects where management didn’t want to hear what it would really take to develop the product – they actually chose, as Watts Humphrey said, “to believe in magic” rather than reality.

This article presents several examples of estimating and scheduling techniques that can help you develop better estimates and more realistic schedules…

From participating in and observing dozens of projects at dozens of organizations, I’ve identified several factors that lead to inaccurate estimates and unrealistic schedules:

• We play ridiculous negotiating games
  
  Project managers typically find themselves in a position where they must “negotiate” a schedule with Management. Often, this negotiation occurs before the requirements are known and is based on unrealistic expectations…
  

• We over-commit and under-deliver
  
  Many organizations fail to manage commitments made to customers and frequently over-commit. When an organization over-commits, it can't deliver what was promised when it was promised. Over-committing is a behavior exhibited by many companies and always results in under-delivering.

• Projects start with a pre-determined release date
  
  All too often, projects begin with pre-determined release dates that have been communicated to customers. Release dates are often set before requirements are defined.

• Tasks are estimated based on time available rather than time required
  
  Once the release date is set, the project manager must schedule backwards – start from the release date and work backwards to today. When this happens, tasks are estimated based on how much time is available rather than how much time a task actually requires. This always results in inaccurate task estimates and unrealistic schedules.

• Task interdependencies are not identified
  
  Anyone who has ever worked on a software development project understands the importance of identifying the interdependencies between tasks. But we frequently do not factor these interdependencies into our schedules.

• Unexpected things that always happen are ignored
  
  On every software project unexpected things happen. For example:
  
  
• the requirements WILL change
• key member(s) of the project team will leave
• key assumptions about the product/project prove wrong
• training for new tools/technology not provided
• dependencies arise that were previously unknown or ignored
• key resource(s) are pulled off to fight most recent “fire”

Pretending unexpected things won’t happen, results in unrealistic schedules.

Now that we have explored some of the reasons estimates and schedules are wrong, let’s look at what we can do to improve…

Accurately estimating software tasks is critical to developing realistic schedules. Coming up with consistently accurate estimates requires experience, discipline and information.

Experience. Accurate estimates are derived from past performance. There is no substitute for experience. The best way to improve estimating skills is to make estimates, do the work, and then compare the actual time to the estimates and reconcile the difference.

Discipline. Like most complex tasks, estimating requires discipline – following a proven process. Without discipline, estimating becomes nothing more than a guessing game.

Information. Since past performance is the most accurate predictor of future behavior, organizations need to collect, maintain, and utilize estimates and actuals from past projects. This information is invaluable in developing accurate estimates for new projects.

Developing accurate estimates is hard work that requires experienced people who have the discipline to follow a proven estimation process. It also requires support from management.

Estimating Techniques

There are several widely used techniques for accurately estimating either the size or cost of software projects. We’ll discuss a few of them:

• Function Points and Feature Points
• Constructive Cost Model - COCOMO II
• Wideband Delphi Method
  

Function Points and Feature Points

Function points are a way for estimating how big a software product will be based on functionality from the user's perspective. Function points were developed initially for information systems. The feature point extension applies a similar method for other types of software, such as real-time software, embedded software, communications software, etc.

Once function points are counted for a proposed system, an extensive body of empirical data can be used to relate function points to productivity and size of the product. Capers Jones also claims that function points can be useful for such things as normalizing defect data and estimating tests required and number of test runs.

COCOMO II

COCOMO II is a mathematical modeling and estimation tool that helps estimate the cost, effort, and schedule of a software development activity. The original COCOMO model was developed by Dr. Barry Boehm. COCOMO II reflects numerous changes in software development that have occurred since the publication of the original model in 1981.

The first version of the COCOMO II tool was released in 1997 and was calibrated to 83 data points that represent historical software development projects, using a 10% weighted average approach that blends empirical data with expert opinion.

Experience with COCOMO has shown that if an organization calibrates the model to its own empirical data, the accuracy of the results can be greatly improved over the generic calibration described above.

Wideband Delphi Method

This technique is useful for estimating attributes of complex tasks done for the first time, such as incorporating new technology into a product. This method helps improve the accuracy of estimates because:

• It requires several experienced people estimate the same task
• It requires that a detailed breakdown of the work be prepared
• It is an iterative process based on consensus

Given a task to estimate, several experienced engineers are each asked to estimate the task as if they were going to do the work themselves. The group is then brought together and each individual estimate is plotted on a graph. At this point, the variance between the estimates is usually large. This variance is often due to the fact that individuals may not have made the same set of assumptions. The assumptions each person made is then listed, discussed, and agreed to.

Once this happens, the group refines their estimates using the agreed to assumptions. Variance of the second estimate is much smaller. After two or three iterations, the estimate becomes more and more refined and accurate.

Step Two – Build Realistic Schedules

Management often doesn’t want a realistic schedule but rather, one that fits some expectation. Since many organizations operate with a culture that encourages the business to over-commit and under-deliver, it should come as no surprise that the main reason we often don’t have realistic schedules is because management doesn’t want them.

Businesses that value accurate, realistic schedules have them. Most companies today have the ability to develop such schedules, but are rarely required to.

Scheduling Techniques

The follow are some examples of effective scheduling techniques:

• Program Evaluation and Review Technique (PERT) and Critical Path Method (CPM)
• Critical Chain Planning
• Yellow Sticky Method

PERT and CPM

Most of us are familiar with PERT and CPM charts for software projects. At one time or another, anyone who has managed software projects has had to create schedules using these tools.

An important point to note about PERT and CPM is that they are a means not an end. They all depend on people creating information based on their knowledge of the project and the tasks. The tools cannot work without this information. Too often, I've seen project managers start out on a new project by creating PERT and CPM charts before any one has had a chance to identify and estimate the tasks. The techniques of estimation described earlier must precede the creation of PERT and/or CPM charts. Before creating a PERT or CPM chart, the following information must be created:

• Decomposition of product function
• Identification of all tasks required to be performed
• Estimates of effort for each task
• Interdependencies between tasks
• Assignment of specific resources to tasks

Once this information is available, building schedules using either PERT or CPM tools can begin.

Critical Chain Planning

Most projects have some degree of uncertainty associated with them. The Critical Chain Planning method, an outgrowth of the Theory of Constraints, attempts to address uncertainty by focusing on identifying and fixing bottlenecks in order to improve the throughput of the overall system.

In Critical Chain Planning, uncertainty is primarily managed by (a) using average task duration estimates; (b) scheduling backwards from the date a project is needed (to ensure work that needs to be done is done, and it is done only when needed); (c) placing aggregate buffers in the project plan to protect the entire project and the key tasks; and (d) using buffer management to control the plan. The key tasks are those on which the ultimate duration of the project depends, also known as the Critical Chain.

The Yellow Sticky Method

The Yellow Sticky Method helps people develop more accurate, realistic estimates of tasks they themselves will perform. It also includes identification of dependencies between tasks. By starting with more accurate estimates and including task dependencies, it is a rather simple and straightforward process to create a project schedule that is accurate, realistic, and that can actually be met.

This method is based on the following simple principles:

• Know what you are being asked to deliver - start with requirements.
  
• People who will be doing the work create estimates for the tasks they themselves will do and then help build the schedule.
  
• Project team members critique each other’s estimates.
  
• Everyone is held accountable for meeting their commitments.
  
• The organization under-commits. Customers are promised less than what can realistically be delivered.

Tasks are identified by members of the Project Team who will be doing the work and are based on the Software Requirements Specification (SRS). The following information is required for each task:

• Name - person who will do the task
  
• Task – a brief description of the task
  
• Duration – your estimate of how long it will take you to perform the task, if you could work uninterrupted
  
• Dependencies – work on this task can’t begin until dependent tasks are completed

Once the tasks are identified, the Project Team builds the schedule going forward by using the task dependency information. The process iterates until the Project Team is satisfied that they have built the best possible schedule.

Reality is Better than Magic!

Every month in this space you’ll find additional information related to this month’s topic.

• Books and Articles
  
  
  • DeMarco, T., The Deadline: A Novel about Project Management, Dorset House, 1997
    
    Tom Demarco’s great story based on many real-life events.
    
    
  • Yourdon, E., Death March: The Complete Software Developer’s Guide to Surviving ‘Mission Impossible’ Projects, Prentice-Hall, 1997.
    
    Yourdon’s classic provides recommendations for how to survive in an organization that places more faith in magic than in reality.
    
    
  • Rakitin, S., Software Verification and Validation for Practitioners and Managers, 2nd edition, Artech House, 2001.
    
    Chapters 12-14 contain a discussion of issues related to project estimating and scheduling, including the Yellow Sticky Method and Wideband Delphi.
    
    
  • Rakitin, S., “Creating Accurate Estimates and Realistic Schedules from Software Requirements”, ASQ Software Quality Professional, March 2002.
    
    A brief article that provides an overview of the Yellow Sticky Method.
    
    
• Function Points and Feature Points
  
  The International Function Point User Group (IFPUG) publishes function point counting rules and offers counting certification exams. The web site also lists many Function Point references.
  
  For information on Feature Points see:
  
  Jones, C., Applied Software Measurement, McGraw-Hill, 1991.
  
  For Function Point Training, contact Carol Dekkers at Quality Plus Technologies.

• Critical Chain Planning
  
  Goldratt, E., Critical Chain, North River Press, 1997
  
  Written as a novel, this book contains powerful yet simple techniques to solve project management's toughest problems.
  
  Goldratt, E., Theory of Constraints, North River Press, 1999
  
  This book walks you through the crucial stages of a continuous program: the five steps of focusing; the process of change; how to prove effect-cause-effect; and how to invent simple solutions to complex problems.
  
  Additional information on Critical Chain Planning:
  
  
  • Advanced Projects, Inc.
  • Pro-chain Solutions, Inc.

Every month, you’ll find news here about local and national events that are of interest to the software community …

• Software Quality Calendar
  
  There are many organizations that sponsor monthly meetings, workshops, and conferences. Find out what’s happening …
  
  
• Public Workshops Offered by IEEE Boston Section
  
  Are you interested in a workshop or short course on cutting edge topics? Learn more…
  
  
• Workshops Offered by Software Quality Consulting
  
  Software Quality Consulting offers workshops in many topics related to software development and software quality. Get more info...
  

If you know of an organization or event that isn’t listed here and would be of general interest, please send me an e-mail with the details…

Software Quality Consulting provides consulting, training, and auditing services tailored to meet the specific needs of our clients. We help you fine-tune your software development processes and improve the quality of your software. Our overall goal is to help you achieve Predictable Software Development™ – so that you can consistently deliver quality software with promised features in the promised timeframe. To learn more about us and how we can help your organization, visit our web site or send us an email.

I hope this newsletter has been informative and helpful. Your comments and feedback are most welcome.

• If you’re estimation or scheduling techniques produce accurate estimates and realistic schedules and are willing to share your experience, please send me the details and I will include this information in a future newsletter…
• Send me your feedback…

Thanks,

Steve Rakitin

info@swqual.com