Sources of Schedule Risk

(Excerpt from chapter 4 of Identifying and Managing Project Risk, © 2003 by Tom Kendrick. AMACOM)

Schedule risks are the most numerous in the Project Experience Risk Information Library (PERIL) database, representing well over a third of the records. They fall into three categories: delays, dependencies, and estimates. Delays occurred whenever something expected by the project—a part, a decision, a piece of information—was late. Schedule dependency risks relate to unanticipated linkages or missing inputs that primarily affect the project timeline (dependencies that primarily affect the project deliverables or the work are grouped with the risks associated with scope changes). The other category of schedule risk comes from duration estimates that are insufficient for completion of scheduled project activities. The summary:

Schedule Risks Count Cumulative
Impact (Weeks)
Average Impact
(Weeks)
Delay 46 134 2.9
Dependency 21 102 4.9
Estimates 15 70 4.7

Project problems sorted by subcategories within the three categories are summarized in Figure 4-1. As shown, the largest total impact came from various sources of dependency and delay. Although delay risk caused more problems overall, dependencies on other project work was the dominant subcategory.


Figure 4-1: Schedule risks in the PERIL database

Delay risks

Delay risk represents over half of the schedule risks, and nearly a sixth of all the risks in the PERIL database. Impact from delays was lower on average than for other risks, slightly less than three weeks. Most of the reported delays related to parts that were required for the project deliverable or hardware that was required to do project work. Delivery and availability problems were a common root cause for the delay, but there were also quite a few issues around international shipping, including customs, paperwork, and other associated concerns. Delays were also a result of parts or other hardware that arrived on time but were found to be defective. Time required to replace or repair things that did not work properly was a significant source of project slip. Delay of parts caused both the largest number of the delay risks and the most severe impact, almost four weeks on average.

Slow decisions caused quite a few project slips. Almost a quarter of the delay examples were due to inaction by managers or other stakeholders who did not act as quickly as necessary to keep the project on schedule. Sometimes the cause was poor access to the decision makers, or their lack of interest in the project. For other projects, delays were the result of extended debates, discussions, or indecision. Projects facing these issues lost nearly three weeks on average waiting for a response to a project request.

Projects also were delayed because they lacked information. Some of the delay was due to time differences separating parts of global project teams. Losing one or more days on a regular basis was common, due to misunderstandings and communication time lags. In other cases, access to information was poor, or delivery of needed reports was interrupted.

Potential delay risks may be difficult to anticipate, and many of them seem to be legitimately "unknown" risks. Thorough analysis of the input requirements at each stage of the project plan, however, will highlight many of them.

Dependency risks

Dependencies are the most severe category of schedule risk in the PERIL database, averaging almost five weeks of impact per incident. There are a number of dependency types, but the most numerous ones in the database are dependencies on other projects and on project support.

Dependency risks from other projects are not only the most numerous of the dependency risks, they also are the most damaging, with an average of over five weeks. In larger projects (often classified as programs), a number of smaller projects interact and link to each other. In addition to providing each other with information and deliverables that meet well-defined specifications (which is a scope risk exposure), each project within a larger program must also synchronize the timing of schedule dependencies to avoid being slowed down by (or slowing) other projects. Managing all these connections is difficult in complex programs, and the amount of damage increases with time; many of these risks in the PERIL database were noticed only late in the project. Even for the interfaces that were defined in advance, delay was fairly common due to the uncertainty in each project and likelihood that at least one of the related projects would encounter some sort of difficulty. With so many possible failure modes, it becomes almost certain that something will go wrong. Analysis of the connections and interfaces between projects is a key aspect of program management, and many of the risks faced by the projects become visible through interface management techniques.

Other dependencies that interfere with project schedules in the PERIL database are support problems. These include interruption of hardware services, such as computer systems or networks required by the project, and inadequate access to resources such as help desks, system support, and people who understood older but necessary applications. Several projects were delayed by outages for maintenance that was scheduled in advance but unknown to the project team. One project had severe impact when the legal and paperwork requirements for international shipments changed abruptly. Monitoring the environment of the project and its infrastructure for planned or likely changes can forewarn of many of these potential problems.

Estimating risks

Of all the types of schedule risk found in technical projects, estimating seems to be the most visible. People who work on technical projects are usually well aware of how inadequate their estimates are, and freely admit it. Despite this, the number of mis-estimated incidents in the PERIL database is not large, and their impact is about equal to the average for the database as a whole. One source of difficulty with estimating in technical projects is the relatively rapid change in the work, which makes the standard advice offered for improvement less useful. Good estimates, we are told, rely on history. If the environment is in constant flux, history may not seem so useful (more on this later in the chapter).

The most frequent type of estimating problem reported in the PERIL database is related to judgment. For a good number of projects, the issue was estimates that were consistently overoptimistic. Some estimates reported were too short by factors of three and four. Dealing with this source of estimating risk requires thorough planning, with appropriate understanding and decomposition of the work, so that the effort and steps required are known. It also requires good record-keeping. Metrics and project data archives are invaluable in creating future estimates that are more consistent with reality than past estimates have been, even for projects where things change rapidly. Having some data always beats having to guess. Another powerful tool in revealing and combating optimistic estimates is worst-case analysis. Not only will the answer to the question, "What might go wrong?" reveal something about the likely duration, it will also uncover new potential sources of risk.

A small number of cases of estimating risk involve learning curve issues. The impact of this was well above the average for the database, nearly seven weeks. The quality of the estimates when new technology or new people (or even worse, new technology and new people) are involved is not good. The portions of project work that require staff to do things they have never done before are always risky, and thorough analysis of the work can show which parts of the project plan are most exposed. Training plans must be established for the project whenever new skills and capabilities are necessary, and need to be explicit in the project timeline and budget.

There are also a number of cases in the PERIL database where the estimates used by the project were poor, but the root cause was outside the project. Technical projects frequently have aggressive deadlines determined in advance for them with little or no input from the project team. Even when the project plan shows the deadline to be unrealistic, the objective is retained. These projects are often doomed from the start; they represent a common type of overconstrained impossible project.

Schedule risks are generally uncovered through planning processes. Creating a comprehensive schedule using better processes for estimating, more thorough analysis of linkages and dependencies, and careful worst-case analysis will reveal many of the schedule exposures.