Food for Thought: Estimating and Scheduling - Do You Believe in Magic?
An e-newsletter published by Software Quality Consulting, Inc.
October 2004, Vol. 1 No. 2 

To view a web version of this newsletter, click on the following link:
http://www.swqual.com/newsletter/vol1/no2/vol1no2.html.

--------------------------------------------------------------------------

Welcome to Food for Thought(TM), an e-newsletter from Software Quality 
Consulting (http://www.swqual.com). 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 (http://www.swqual.com/newsletter/Subscribe.htm).
If you don't wish to receive this newsletter, click the SafeUnSubscribe(TM)
at the bottom of this page, and you won't be bothered again.

Feedback from last month's edition was very positive and encouraging. Your 
feedback is most welcome. Please send your comments and suggestions to 
[email protected].

----------------------------------------------------------------------------

***In This Issue***

Last month (http://www.swqual.com/newsletter/vol1/no1/vol1no1.html), 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. 

-------------------------------------------------------------------------------

***This Month's Topic***

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...

Why are estimates and schedules wrong most of the time? 
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...

Step One - Develop Accurate Estimates 

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.

  Learn More... (http://www.ifpug.org/)


  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.

  Learn more... (http://sunset.usc.edu/research/COCOMOII/cocomo_main.html)

  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.

  Learn More... (http://www.processimpact.com/articles/delphi.pdf)


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.

  Learn more... (http://www.npd-solutions.com/critical.html)

  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. 

  Learn more... (http://www.swqual.com/training/yellow.html)

Reality is Better than Magic! 

When it comes to meeting schedules, the track record of our industry is 
pitiful. It's not that we don't know how to do this better, we just choose 
not to. If meeting commitments to your customers is important, look at 
what you do from an estimating and schedule-building perspective. Collect 
information on the accuracy of your estimates. At the end of each project, 
identify those task estimates that differed significantly from the actual 
task duration. Ask why. Do the same with schedules. By reconciling the 
differences between estimates and actuals, your estimating and scheduling 
skills will improve. Basing schedules on reality, no matter how painful, 
is always better than believing in magic. 

---------------------------------------------------------------------------

***Monthly Morsels***

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.
    (http://www.swqual.com/book/summary.html)

    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.
    (http://www.swqual.com/book/creating.pdf)

    A brief article that provides an overview of the Yellow Sticky Method.


- Function Points and Feature Points

  The International Function Point User Group (http://www.ifpug.org/) 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 (http://www.qualityplustech.com/home.html).
 
- 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. (http://www.advanced-projects.com/) 
  - Pro-chain Solutions, Inc. (http://www.prochain.com/index.asp)

---------------------------------------------------------------------------

***Cakendar***

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 ...
  (http://www.swqual.com/links/upcoming.html)

- Public Workshops Offered by IEEE Boston Section

  Are you interested in a workshop or short course on cutting edge topics? 
  Learn more...
  (http://www.ieeeboston.org/)

- Workshops Offered by Software Quality Consulting

  Software Quality Consulting offers workshops in many topics related to 
  software development and software quality. Get more info...
  (http://www.swqual.com/seminars/courses.html)

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... 
   
--------------------------------------------------------------------------

***About SQC***

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(TM) - 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
[email protected]

Food for Thought and Predictable Software Development are trademarks of Software 
Quality Consulting, Inc. 
Copyright (c) 2004. Software Quality Consulting, Inc. All rights reserved. Graphic 
design by Sage Studio