1/3/2011

How to Quantitatively Measure the Quality of a

Schedule

Warren Kline
warren_kline@raytheon.com

1
 1/3/2011

Project Management is the application of knowledge, skills, tools and techniques to manage
activities to meet or exceed stakeholder expectations. One of the critical tools used to achieve
this end is the project schedule. Microsoft Project® is one of many software tools used to capture
and maintain the project schedule. Schedules captured in MS Project calendarize and connect all
the discrete tasks necessary to complete the work of the project successfully. A “good” schedule
is a tiered plan that does the following:
• Tracks top-level project objectives
• Is timely and accurate
• Provides summary project metrics
• Enables predictive course correction
• Enables “what if” analysis
• Organizes all required tasks logically
• Provides clear task definitions and realistic time spans
• Defines the interfaces between functions or teams
• Provides the project team with a basis for informed management decisions

In order to have your schedule meet the above description of a “good” schedule, experienced
project planners can develop a set of tenets to ensure the quality of the schedule. These tenets are
consistent with the Government’s Integrated Master Schedule (IMS) Data Item Description (DI-
MGMT-81650):
1. The schedule should be primarily made up of discrete tasks that have work associated
with them. Summaries and Milestones are needed for reporting and project tracking but
should not be the majority of the line items.
2. History has shown us that the closer a project is to completing the less we are able to
influence its final financial and schedule outcome, without a significant intervention. So
its important to know what percentage of the project is already complete.
3. All tasks should have a predecessor and successor, with a few exceptions like:
Authorization to Proceed (a start milestone) and tasks that are an end item deliverable to
parties outside the schedule. A good test is to ask: “If the output of the task’s effort does
not go to anyone else, why are we doing the work?”
4. Summaries should not have predecessors or successors. Most scheduling software
packages have difficulty calculating dates and critical paths when summary tasks and
detail tasks are linked. Linking summaries can result in a schedule calculation loop or
invalid critical path.
5. Task durations should be between 5 and 20 working days. Too much detail can make the
schedule unreadable, un-maintainable and ultimately unusable as a management tool. Too
little detail can make the schedule little more than window dressing. Sufficient detail
must exist to clearly identify all the key handoffs and must contain enough information to
know what state the project is in at any given point in time. Consensus among
experienced planners is that near term tasks should be a week to a month in length. Less
than a week and you will spend more time maintaining and updating the schedule than is
practical. Over a month and you will not be able to get an accurate estimate of progress
and forecasted completion dates.

2
 1/3/2011

6. Schedule progress should drive the end dates of the project. Not scheduling forward or
leaving uncompleted work in the past does not allow for a true picture of the project
status and projected end date.
7. Lag should be used sparingly and if it is used it should be documented as to its purpose.
Too often lag is used to force a start date rather than taking the time to establish the
correct linkages and project status. Lags can hide the true state of a project and misdirect
the critical path.
8. Tasks should not be artificially tied to dates. Durations and/or Resources combined with
schedule logic and calendars should determine schedule dates. If a significant number of
constrained dates are used then the schedule may not calculate the critical path and near
critical paths correctly.
9. All schedules should establish baseline dates for every task and milestone in the schedule
early in the project. Typically the customer and the contract require this to be done in 60
to 90 days after start and prior to a formal Integrated Baseline Review (IBR).
10. A resource loaded schedule should have resources assigned to all discrete tasks and
should not have resources assigned to summary tasks. Resource planning requires that all
discrete tasks be resource loaded in order to analyze and identify resource constraints or
over loaded resources.
11. All schedules should have a reasonably small amount of float or slack. Large positive or
negative float or slack values indicate a poorly constructed schedule. Large negative
floats indicate a logic error or a project that is no longer on track to meet its commitment
dates. Large positive float indicates poor or missing logic.
12. The majority of the linkages should be “Finish-to-Start”. Since most of the tasks
represent work that will have a start and an end resulting in some product or document
that is needed by someone else, the work is performed serially most of the time. If the
majority of the tasks require parallel linkages the tasks may be at to high a level. The first
indication that a schedule has been constructed to meet a required date is excessive
paralleling of tasks.
13. The critical path is one of the most important areas of the project schedule. It should be
the most difficult time-consuming and technically challenging portion of the schedule. It
should represent a small portion of the overall project schedule. The greater the
percentage of tasks on the critical path is the higher the schedule risk.
14. Most projects fall behind schedule during their normal execution. However a project
should not operate for a significant period of time with large negative float. Recovery
plans or workarounds should be identified and implemented. If non-are feasible then a re-
programming should be done to lay in a plan that can be executed to an agreed to
completion date.
15. All tasks should have a Work Breakdown Structure (WBS) assigned. The WBS is a key
to cost schedule integration. A missing WBS gives the appearance of work being done
that is not within the budget or scope of the project. Level of Effort (LOE) tasks do not
need to be in a project schedule. By their nature they add no value to measuring project
progress and may interfere with the calculation of the project’s true critical path and near
critical paths.
16. Actual dates must reflect when a task started and or completed. They should not be auto
generated and should not exist in the future. An actual finish date cannot be earlier than

3
 1/3/2011

the actual start date for a task. Many scheduling tools allow this obvious mistake to take
place.

If we have followed each of the above tenets, does that mean that we have created a good
schedule? Not necessarily. It only means we have likely constructed a sound schedule database.
If we have violated some of the above rules, does that mean we have created a bad schedule? Not
necessarily. Unique projects may have unusual circumstances that would cause a violation of
several of these rules. So how do we know what are the right set of rules or tenets for a particular
company or business?

The good, potentially bad, and likely bad percentages can be determined by analyzing known
good project schedules and applying several statistical analysis techniques to establish the
thresholds. By testing the tenets against known good schedules we are able to set thresholds for
analyzing a project schedule. If we test a series of good schedules and find they consistently have
the same results for a given tenet (mean, standard deviation and confidence interval) than we can
be reasonably sure our thresholds are set at the correct level.

Summary for % Tasks w/ Succ

Anderson-Darling Normality Test
A-Squared 0.59
P-Value 0.067

Mean 0.98500
StDev 0.02074
Variance 0.00043
Skewness -1.21121
Kurtosis 0.20011
N 6
Minimum 0.95000
1st Q uartile 0.96500
Median 0.99500
3rd Q uartile 1.00000
0.95 0.96 0.97 0.98 0.99 1.00 Maximum 1.00000
95% Confidence I nterval for Mean
0.96324 1.00676
95% Confidence I nterval for Median
0.95714 1.00000
95% Confidence I nterval for StDev
95% Confidence I ntervals
0.01294 0.05086
Mean

Median

0.95 0.96 0.97 0.98 0.99 1.00 1.01

Sample Statistical Analysis Using Known Good Schedules

Obviously, these tenets can only measure the structure of what you put in the schedule. It is
imperative that the schedule has fully captured the scope of work for the project and that there
are processes in place that ensure proper work distribution, clear and open communications
between responsible individuals or team leads, and the discipline to manage and control the cost
and or schedule changes.