Sources of Scope Risk

While scope risks represented roughly one-third of the data in the Project Experience Risk Information Library (PERIL) database, they account for close to half of the total impact. The two broad categories of scope risk in PERIL relate to changes and to defects. By far the most damage was due to poorly managed change, but all scope risks represent significant exposure in typical high-tech projects. While some of the risk situations, particularly in the category of defects, were legitimately "unknown" risks, quite a few common problems could have been identified in advance through better definition of deliverables and a more thorough work breakdown structure. The summary:

Scope Risks	Count	Cumulative Impact (Weeks)	Average Impact (Weeks)
Changes	46	280	6.1
Defect	30	198	6.6

These root causes were further characterized by type, and a Pareto chart of overall impact by type of risk is summarized in Figure 3-1.

Figure 3-1: Scope risks in the PERIL database

Change risks

Change risk represents well over half of the scope risks reported in the PERIL database. There are three categories of scope change risks:

Scope creep: requirements that evolve and mutate as a project runs
Gaps: specifications or activities added to the project late
Scope dependencies: inputs or other needs of the project not anticipated at the start of a project

Scope creep is the most serious category, where the majority of the change risks in PERIL fall. Nearly all of these incidents represented unanticipated additional investment of time and money that could have been visible with clearer scope definition. The average impact on projects reporting scope creep was over two months of slip. Some of the changes were a result of a shift in the specifications. Others were specifications above and beyond the stated project objective that were added as the project ran. While in some, perhaps even most, of these cases, the changes represented good business decisions, there is no question that the projects would have been shorter, less expensive, and easier to run if the definitions ultimately used had been determined earlier. In some particularly severe cases, the changes in scope delayed the project so much that the product had little or no value. The need was no longer pressing, or it had been met by some other means. The tool that uncovers these problems most effectively is early establishment of a better, clearer, more thorough definition.

Scope creep also comes from within, generally from well-intentioned attempts by some part of the project team to "improve" the deliverable. While internally generated changes may have value, often they do not have enough to warrant the project impact they cause. Whatever the source, meandering definition of scope creates a great deal of scope risk. Scope creep is a universal and pervasive issue for technical projects.

Other project changes in the PERIL database resulted from gaps in the project scope that were discovered late in the project. Most of these risks are due to overlooked requirementsÑwork required for the project objective that went unrecognized until late in the project. In a small number of cases, the project objective was so unlike earlier work that the gaps were probably unavoidable. The additional insights provided in midproject by customers, managers, team members, or other project stakeholders were not available at the start of the project, so the work required was not visible. In most of the cases, however, the gaps came from incomplete analysis and could have been avoided. More thorough scope definition and project work breakdown would have clearly shown the missing and incomplete portions of the project plan.

A third category of change relates to unexpected scope dependencies. (Dependency risks that primarily affect the project timeline, rather than the scope, are included with schedule risks in the database.) Again, there were some changes that no amount of realistic analysis would have uncovered. While the legal requirements and other factors external to the project are generally stable, they may occasionally shift quickly and without warning. In the risk database, however, most of the situations were due to factors that should not have come as complete surprises. Some were due to changes in the infrastructure the project was depending upon, such as a new version of system or application software, or hardware upgrades. Some projects in the database were hurt due to an unplanned delay in access to new software versions or product releases. Investigation and more thorough analysis of the systems, software, and the infrastructure your project requires can uncover many dependency risks.

Defect risks

Technical projects rely on many complicated things to work as expected. Unfortunately, new things do not always operate as promised or as required. Even normally reliable things may break down, or fail to perform as desired in a novel application. Hardware failure was the most common defect risk of this sort in the PERIL database, followed by software problems. In several cases, the root cause was new, untried technology that the project was unable to use for the project because it lacked functionality or reliability. In other cases, a component created by the project (such as a custom integrated circuit, a board, or a software module) did not work initially and had to be redone. In still other cases, critical purchased components delivered to the project failed to work and required replacement. Nearly all of these risks are visible, at least as possibilities, through adequate analysis and planning.

Some hardware and software functional failures related to quality. In many projects, some components may work but fail to meet a stated standard of performance. Hardware may fail to meet a throughput standard or require too much power or emit excessive electromagnetic interference. Software may not be easy enough to operate or may not work in unusual circumstances. As with other defects, the definition, planning, and analysis of project work will help in anticipating many of these potential quality risks.

The third type of defect risk, after hardware and software problems, occurs above the component level. In many large technical programs, the work is decomposed into smaller, related sub-projects that execute in parallel. Successful integration of the outputs of each of the sub-projects into a single system deliverable requires not only that each of the components delivered operates as specified but also that the combination of all these parts also works as a functioning system. As computer users, we are more familiar with this exposure than we would care to be. When the software we use fails to play nicely together, we see a characteristic "blue screen of death" or the crash of a system or application with notification of some sort of "illegal operation." Integration risk is particularly problematic in projects, as it generally occurs very near the deadline and is rarely simple to diagnose and correct. Again, thorough analysis using disciplines such as software architecture and systems engineering can reveal much of this sort of risk early.

A more complete listing of the scope risks in the PERIL database is included in the Appendix. While uncovering scope risks begins with a review of past problems such as these, each new project you take on will also pose unique scope risks that can only be uncovered as you define deliverables and develop the project work breakdown structure.