Food for Thought�An e-newsletter published by Software Quality Consulting, Inc.
October 2007, Vol. 4 No. 8
Estimating and Scheduling for Dummies, Part 2

What topics would you like to see in this newsletter?  Each month, this
newsletter tries to provide you with useful information.  This is a two-way
street and your feedback is important.  Please send your thoughts and comments
to [email protected].

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

Welcome to Food for Thought(TM), an e-newsletter from Software Quality 
Consulting (http://www.swqual.com/index.html?Intro). 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 this Forward Email link
(http://ui.constantcontact.com/roving/sa/fp.jsp?plat=i&p=f&m=sctz69n6). If
you�ve received this newsletter from a colleague and would like to subscribe,
please click this Enter New Subscription link (http://www.swqual.com/newsletter/
Subscribe.htm?Newsletter). If you don't wish to receive this newsletter, click
the SafeUnSubscribe(TM) link at the bottom of this newsletter, and you won�t be 
bothered again.

Your continued feedback on this newsletter is most welcome. Please send 
your comments and suggestions to [email protected].

*** In This Issue ***

In This Months� Topic, I discuss practical techniques to improve your 
estimating and scheduling skills...

Regular features to look for each month are:

- Monthly Morsels
  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 for Dummies
Part II - Estimating 

What is it about schedules that cause seemingly rational people to behave 
so irrationally? How many times has this happened to you...

- Your boss asks you for a schedule for a set of new features described 
  only by a few bullets in a Marketing PowerPoint presentation. 

- You reply, �We don�t have enough information to create a schedule.� 

- Your boss says, �Either you come up with a schedule or I will make one 
  up for you! And by the way, it has to be done by end of the quarter.� 

So you make up a bogus schedule that you know can�t be met. The project 
starts and eventually encounters problems (what a surprise!). Features are 
cut and testing time is reduced. The software is released very late, with 
far too many bugs, and doesn�t have all the promised features. Needless to 
say, your boss and your customers are not happy.

THE GAMES WE PLAY 

In my recent e-newsletter on Mission Critical Software (http://www.swqual.com/
newsletter/vol4/no6/vol4no6.html), I discussed the incredible accomplishments of
the Space Shuttle Team in developing highly reliable software for the on-board
computers. One of the basic tenets of the Space Shuttle development team was:

To deliver grown-up software, we need to behave like grown-ups. 

As Watts Humphrey [2] observed: 

  �[...] management�s undisciplined approach to commitments contributes to 
  every one of the five most common causes of project failure:

  - Unrealistic schedules 
  - Inappropriate staffing 
  - Changing requirements 
  - Poor quality work 
  - Believing in magic� 

Of all the things software development organizations do, scheduling is one 
where we rarely behave like grown-ups. Ed Yourdon [1] identified some of 
the childish scheduling games we play:

- Doubling and Add Some 

  In this game, your boss asks you how long it will take you to perform 
  some task. After thinking about the task, you figure it would take you 
  about 1 month to complete the work. Since you were recently burned by 
  bad estimates, you decide to double your estimate to 2 months. Knowing 
  your boss, you decide to add a bit extra just to be on the �safe side�. 
  So a task that should take about one month is estimated at 2.5 months.

- Reverse Doubling 

  In this game, your boss takes your estimate, which he/she knows is 
  inflated, and simply cuts it in half.

- Guess the Date 

  In this silly game, you boss already knows the answer he/she wants. You 
  have to guess until you come up with the answer that the boss wants to 
  hear. 

People often make commitments to customers to deliver something without 
consulting the development and test organizations. As a result, the 
project team has to develop a schedule by working backwards from the end 
date. This is what I call a �scheduled-backwards� project. On a typical 
scheduled-backwards project:

- The project starts with a predetermined end date that is set before the 
  requirements are set. 

- Customers are promised more than can reasonably be delivered in the 
  promised timeframe. 

- Tasks are estimated based on how much time is available rather than how 
  much time the tasks actually require. 

- Task interdependencies are not identified since there�s no time to 
  factor them in. 

- It is assumed that all the unexpected things that ALWAYS happen on every 
  project will somehow NOT happen on this project. For example, we know 
  that: 

  - The requirements WILL change. 
  - A key member of the project team WILL leave. 
  - A key assumption WILL prove wrong. 
  - Previously unknown or ignored dependencies WILL arise. 
  - Key resources WILL be pulled off to fight the next �fire�. 

What happens on scheduled-backwards projects? Eventually, the schedule 
slip can�t be ignored so the Project Manager cuts features and cranks up 
coding. Whatever process the development team was using is abandoned. 
Design Reviews are cancelled and testing time is drastically cut. Does 
this sound familiar? 

The result is everyone loses!

- The Organization loses because the release is late, lacks keys features 
  and is very buggy. 

- Your Customers lose because they have to deal with a late release, 
  without the key features they were expecting, and with far too many 
  bugs. 

- Your Company loses as your reputation for meeting commitments and 
  delivering quality products suffers. 

I think it is time to establish some basic scheduling principles...

SCHEDULING LAWS OF NATURE

Here are some basic principles that always apply for schedules:

- Good schedules can only come from good estimates. 

  In last month�s e-newsletter (http://www.swqual.com/newsletter/vol4/
  no7/vol4no7.html), I defined good estimates as:

  - An estimate is good if it is within X% of how long it actually takes 
    to do the work. 

  Similarly, a good schedule is defined as:

  - A good schedule is a schedule based on factual information and one 
    that completes within X% of the predicted end date. 

  As with estimates, you decide how good the schedule needs to be based on 
  factors such as business targets, customer commitments, risk, etc.

- The goodness of schedules is directly related to the level of detail of 
  the information upon which schedules are based. 
 
  Here�s an example of what this means...

- When things (such as requirements, resources, assumptions, etc.) change, 
  schedules need to be adjusted to reflect these changes. 

  One of the most common reasons schedules are not accurate is because we 
  fail to adjust schedules to reflect changes. For some reason, we assume 
  that changes can be accommodated without any impact to the schedule.

- There�s no such thing as a schedule-neutral change. 

  Every change, whether it is to a requirement, a resource, or an 
  assumption clearly has an impact on schedules. Removing features has a 
  schedule impact - and not always the impact you might expect. Often, 
  taking features out means more work, not less.

- The best people to develop schedules are people who are actually going 
  to do the work. 

  Most of us have had to work on projects where schedules have been handed 
  down from on high by who knows who. How motivated are you to meet a 
  schedule set by someone else? Most people aren�t motivated to meet 
  someone else�s schedule - usually because whoever created the schedule 
  has no idea what you do and how you do it.

- Microsoft Project (or any other tool) can�t create schedules - only 
  people can create schedules. 

  The tendency in our industry is to use tools to do everything. Tools 
  can�t create schedules - only people can. Once you have created a 
  schedule, tools can be used to track progress, identify critical paths, 
  etc.

Now that we have identified some problems and basic principles, let�s look 
at examples of good scheduling skills.

GOOD SCHEDULING SKILLS

As illustrated in the diagram below...

- Good requirements lead to good estimates. 

- Accurate schedules are based on good estimates. 

- Estimating and scheduling activities need to reflect actual resources 
  and dependencies. 

- Estimating and scheduling are iterative activities based on many 
  assumptions - documenting these assumptions is critical. 

Once a schedule is created, there WILL BE GAPS between what is desired and
What can be accomplished. These gaps result from factoring in targets and
commitments. Beware! When a schedule aligns perfectly to the targets and
commitments (http://www.swqual.com/newsletter/vol4/no7/vol4no7.html), it usually
indicates that this is a scheduled-backwards schedule.

Managing the GAPS - the difference between what can be done and what the 
business would like - is what Project Management is supposed to be about. 
Good project managers are expert at reconciling these differences and 
reaching reasonable compromises...

SCHEDULING BEST PRACTICES

Here are a few examples of scheduling best practices...

- Yellow Sticky Method (http://www.swqual.com/training/yellow.html)

  My favorite method for developing accurate schedules is the Yellow 
  Sticky Method. I like this method because it is simple and works 
  extremely well for small to medium (up to say 25 people or so) project 
  teams. I have taught this method to dozens of project teams who have 
  reported excellent results.

- Gantt Charts (http://www.netmba.com/operations/project/gantt/)

  A Gantt chart is a bar chart that illustrates a project schedule. Gantt 
  charts illustrate start and finish dates of terminal elements and 
  summary elements of a project. Some Gantt charts also show the 
  dependency relationships between activities. Gantt charts can show 
  current schedule status using percent-complete shadings and a vertical 
  TODAY line.

  Some project management tools (like Microsoft Project) can represent a 
  schedule as a Gantt Chart.

- Program Evaluation and Review Technique (PERT - http://www.netmba.com/
  operations/project/pert/) 

  PERT is a method for analyzing tasks involved in completing a given 
  project, especially time needed to complete each task, and identifying 
  minimum time needed to complete total project. 

  PERT is used where time rather than cost is most critical factor. Some 
  project management tools can represent a schedule as a PERT chart.

- Critical Path Method (CPM - http://www.netmba.com/operations/project/cpm/) 

  CPM is a mathematically based algorithm for scheduling a set of project 
  activities. Any project with interdependent activities can apply this 
  method of scheduling. Construct a model that includes the following:

  - A list of all activities required to complete the project. 
  - Time (duration) that each activity will take to complete. 
  - Dependencies between the activities. 

  CPM is often used in conjunction with PERT. Some project management 
  tools can represent a schedule as a CPM network.

- Critical Chain Methodology (http://en.wikipedia.org/wiki/Critical_chain)

  This is without a doubt one of the more complex techniques I�ve seen. 
  The C ritical chain methodology is based on methods and algorithms 
  developed in theory of constraints [4]. In this approach, 
  terminal-element start and finish dates function as random variables. 
  The project is managed not by traditional schedules but rather by using 
  buffer management and a relay race mentality.

SUMMARY

As Fred Brooks observed:

  �It is difficult to make a vigorous, plausible, and job-risking defense 
  of an estimate that is derived by no quantitative method, supported by 
  little data, and certified chiefly by the hunches of managers�. [3]

Applying basic Principles of Scheduling listed above with the Estimating
Techniques (http://www.swqual.com/newsletter/vol4/no7/vol4no7.html) discussed
last month can result in a significant improvement in your ability to become a
more Predictable Software Development organization...

�Til next time...

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

*** Monthly Morsels ***

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

- References: 

  [1] Yourdon, E., Death March: The Complete Software Developer�s Guide to 
  Surviving �Mission Impossible� Projects, Upper Saddle River, NJ: 
  Prentice-Hall PTR, 1997 

  [2] Humphrey, W., Winning with Software: An Executive Strategy, 
  Addison-Wesley, 2002

  [3] Brooks, F., The Mythical Man-Month, 25th Anniversary Edition, 
  Addison-Wesley, 1995

  [4] Goldratt, E., Critical Chain, Gower Publishing, 1997

- Estimating and Scheduling Training Courses and Workshops 

  The following are some public courses and workshops on estimating and 
  scheduling:
  
  - Software Project Management Boot Camp 
    (http://www.construx.com/Page.aspx?nid=17&id=10)

  - Software Estimation in Depth
    (http://www.construx.com/Page.aspx?nid=15&id=32)

  - Building Accurate Schedules from Software Requirements
    (http://www.ieeeboston.org/edu/2007fall/course_building_schedules.htm)

  - Project Management Best Practices 
    (http://www.processimpact.com/seminars.shtml#pmbp)

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

*** Calendar ***

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 of interest to software professionals. Find out what�s 
  happening...
  (http://www.swqual.com/links/upcoming.html)

- Workshops Offered by Software Quality Consulting 

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

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

*** About SQC ***

Software Quality Consulting provides consulting, training, and auditing 
services tailored to meet the specific needs of clients. We help clients 
fine-tune their software development processes and improve the quality of 
their software products. The overall goal is to help clients achieve 
Predictable Software Development(TM) � so that organizations can consistently 
deliver quality software with promised features in the promised timeframe. 

To learn more about how we can help your organization, visit our web site
(http://www.swqual.com/index.html?AboutSQC) or send us an email
([email protected]).

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

I hope this newsletter has been informative and helpful. Your comments and 
feedback are most welcome. Send me your feedback... ([email protected])

Thanks,

Steve Rakitin
[email protected]

Food for Thought, Predictable Software Development, Act Like a Customer,
and ALAC are trademarks of Software Quality Consulting, Inc.
Copyright 2007. Software Quality Consulting, Inc. All rights reserved.
Graphic design by Sage Studio