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, 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, 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…

With this information available to develop schedules...	You can create schedules accurate to…
Marketing bullet points	Year
Software Requirements Spec (SRS)	Quarter within the year
SRS + High Level Design	Month within the Quarter

• 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, 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

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

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)

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)

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

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 discussed last month can result in a significant improvement in your ability to become a more Predictable Software Development organization…