Defining and Managing Project Scope

Information Technology Project Management. Providing Measurable Organizational Value, Third Edition
Chapter 5: Defining and Managing Project Scope

ISBN: 9780470371930 Author: Jack T. Marchewka
copyright © 2009 John Wiley & Sons Inc.
Defining and Managing Project Scope

Chapter Overview

Chapter 5 focuses on developing a scope management plan to define and manage the project and product deliverables of the project. After studying this chapter, you should understand and be able to:

* Identify the five processes that support project scope management. These processes, defined in the PMBOK Guide®, include scope planning, scope definition, create work breakdown structure (WBS), scope verification, and scope control.
* Describe the difference between product scope (i.e., the features and functions that must support the IT solution) and project scope (i.e., the deliverables and activities that support IT project methodology).
* Apply several tools and techniques for defining and managing the project’s scope.


This chapter focuses on defining and managing the work that must be accomplished by the project team over the course of the project. The term scope is used to define the work boundaries and deliverables of the project so what needs to get done, gets done—and only what needs to get done, gets done. Therefore, it is important to define not only what is part of the project work, but also what is not part of the project work. Any work not part of the project is considered to be outside of the project’s scope.
Project Scope Management Processes

The Guide to the Project Management Body of Knowledge (PMBOK Guide®) defines five project processes that support the knowledge area called project scope management. These processes are summarized in Table 5.1. This process group begins with scope planning once the project sponsor gives the project manager the authority and resources to develop a scope management plan. Scope planning lays out all the processes, tools, and techniques that will be used by the project team to define and manage the project’s scope. This plan can be a large, formal document, depending on the size and complexity of the project.

Table 5.1 Scope Management Processes
Scope Management Process Description
Scope planning
The development of a scope management plan that defines the project’s scope and how it will be verified and controlled throughout the project
Scope definition
A detailed scope statement that defines what work will and will not be part of the project and will serve as a basis for all future project decisions
Create work breakdown structure
The decomposition or dividing of the major project deliverables into smaller and more manageable components
Scope verification
Confirmation and formal acceptance that the project’s scope is accurate, complete, and supports the project’s MOV
Scope control
Ensuring that controls are in place to manage proposed scope changes once the project’s scope is set. These procedures must be communicated and understood by all project stakeholders

Scope definition and create work breakdown structure (WBS) both help to determine what is and is not included in the project work. This sets the work boundary for the project and identifies the project deliverables (as defined in the IT Project Methodology) and the product deliverables (the features and functionality of the IT solution). The WBS organizes and defines all the work to be completed by the project team in terms of a hierarchical decomposition of all of the project’s deliverables. In this text, we will begin the introduction of the WBS by introducing several tools that will lead to a more formal WBS that will be described in the next chapter. These tools include the Deliverable Definition Table (DDT) and the Deliverable Structure Chart (DSC) for defining the project-oriented deliverables, as well as the Context Data Flow Diagram (DFD) and Use Case Diagram (UCD) that can be used for defining the product-oriented deliverables. Accurate definition of these deliverables is critical for the next step when we plan and estimate the project’s schedule and budget.

Once the scope is defined, the process of scope verification confirms that the scope is complete and accurate. The project team and sponsor must agree to all of the project deliverables. This not only sets expectations, but also focuses the project team on what needs to get done and what is outside the scope of the project. The project’s scope should be considered complete if it supports the project’s MOV.

Time and resources will be wasted needlessly if the scope of the project is never defined accurately or agreed upon. However, changes to the scope may be inevitable as new information becomes available or if the needs of the organization change. Therefore, a process called scope change control is needed to handle these changes so that if a scope change is appropriate, the change can be approved in order to amend the project’s schedule and budget accordingly. In addition, scope change control procedures also protect the scope boundary from expanding as a result of increasing featurism, requests by project stakeholders to keep adding additional features and functions (i.e., bells and whistles) to the project once the scope has been set. Remember that the scope, schedule, and budget relationships suggest that increasing the project’s scope (i.e., expanding the scope boundary) will generally require an increase in schedule and budget. Therefore, adding additional work to the project’s scope will ultimately lead to a project that misses its deadline and costs more than originally estimated. Subsequently, once the project’s scope has been set, approved changes to the project’s scope must be reflected in the project’s baseline plan.

Together, the processes and techniques for defining and managing scope make up the scope management plan. Depending on the size and nature of the project, this plan can be separate and/or summarized in the project charter. Regardless, the procedures for defining and managing the scope of a project must be communicated and understood by all of the project’s stakeholders to minimize the likelihood of misunderstandings. Moreover, the project’s scope must align and support the project’s MOV. Why spend time and resources to perform work that will not add any value to the organization or help the project achieve its MOV? Again, work that does not add value consumes valuable time and resources needlessly. Figure 5.1 summarizes the components and processes of a scope management plan.

Figure 5.1 Scope Management Plan

[Click to enlarge]
Scope Planning

Failure to define what is part of the project, as well as what is not, may result in work being performed that was unnecessary to create the product of the project and thus lead to both schedule and budget overruns.

Olde Curmudgeon, PM Network Magazine, 1994

Scope planning begins with a process that formally authorizes the project manager and team to develop the scope management plan. In terms of the IT project methodology, this authorization is given after the project is formally accepted and funds are committed to developing the project charter and plan by the project sponsor or client. The business case provides important information about the project’s description, MOV, risks, assumptions, and feasibility. In addition, the business case provides information about the background of the project in terms of why it was proposed and how it aligns with the organization’s overall strategic plan.

Scope planning, however, is a process for defining and documenting the project work. More specifically, a project’s scope defines all the work, activities, and deliverables that the project team must provide in order for the project to achieve its MOV. It is an important step in developing the project plan since one must know what work must be done before an estimate can be made of how long it will take and how much it will cost. The scope management plan documents how the scope will be defined, verified, and controlled, as well as how the work breakdown structure will be defined and created.
Scope Boundary

Defining the scope boundary is the first step to establishing what is, and what is not, part of the project work to be completed by the project team. Think of the scope boundary as a fence designed to keep certain things in and other things out. As Figure 5.2 illustrates, any work within the scope boundary should include only the work or activities that support the project’s MOV. This work is what we want to capture and keep within our fence. On the other hand, a project team can spend a great deal of time doing work and activities that will not help the project achieve its MOV. As a result, the project will consume time and resources with very little return. Therefore, the scope boundary must protect the scope from these activities once it is set and agreed upon by the project stakeholders. Having a clear and agreed-upon definition of the project MOV is critical for defining and managing the scope boundary.

Figure 5.2 Scope Boundary

[Click to enlarge]
The Scope Statement

One way to define the scope boundary is to create a more detailed scope statement that documents the project sponsor’s needs and expectations. This can be based on the preliminary scope statement developed in the project charter. For example, let’s say we are outside consultants hired to develop an electronic commerce application for a bank. After developing and presenting a business case to our client, we have been given the authority to develop the project charter and plan. Although the business case provides a great deal of relevant information, we will still set up several meetings and interviews with key stakeholders in the bank. Based upon these meetings and interviews, we create a scope statement.
Scope Statement

1. Develop a proactive electronic commerce strategy that identifies the processes, products, and services to be delivered through the World Wide Web.
2. Develop an application system that supports all of the processes, products, and services identified in the electronic commerce strategy.
3. Integrate the application system with the bank’s existing enterprise resource planning system.

It is just as important to clarify what work is not to be included, that is, what work is outside the scope of the project. Often the scope of a project is defined through interviews, meetings, or brainstorming sessions. Stakeholders often suggest ideas that are interesting, but not feasible or appropriate for the current project.

Let’s say that in our example a certain bank vice president pushed for a customer relationship management (CRM) and a data mining component to be included in the application system. The bank’s president, however, has decided that the time and effort to add these components cannot be justified because launching the Web site in eight months is vital to bank’s competitive strategy. Let’s also assume that conducting technology and organizational assessments of our client’s current environment is an important piece of our project methodology. But because the bank would like to control some of the costs of this project, we agree that its IT department will conduct that study. The results of this study will then be documented and provided to us.

In this case, it is critical that we define explicitly both what is and what is not part of the project scope. Individuals from both organizations may believe that specific project work (i.e., the assessment study), system features, or functionality (i.e., CRM and data mining) will be part of this project. These beliefs may result in misunderstandings that lead to false expectations or needless work. To manage these expectations, it is useful to list explicitly what is not part of the project’s scope.
Out of Scope for This Project

1. Technology and organizational assessment of the current environment
2. Customer resource management and data mining components

Setting the scope boundary for the project not only sets expectations, but also can define the constraints of the project and how the product of the organization fits within the organization, that is, the system must integrate with the organization’s existing systems.

The scope statement provides a very general and high-level view of the project work and provides only a starting point for defining the scope of our project. At the beginning of a project, our understanding of the project’s scope may be limited. However, as we work more closely with our client, more information is uncovered and our understanding of the project increases. Subsequently, the project scope will evolve from being very general and high level to more detailed and defined.
Project Scope Definition

Developing a scope statement is a useful first step for defining the scope of the project and setting a boundary. A project’s scope, however, should also be defined in terms of the deliverables that the team must provide. These deliverables can be divided into project-oriented deliverables and product-oriented deliverables. This separation gives the team a clearer definition of the work to be accomplished and improves the likelihood of accurately assigning resources and estimating the time and cost of completing the work. Moreover, a clear definition of the project’s deliverables sets unambiguous expectations and agreement among all of the project stakeholders. This will provide the important details needed to create the work breakdown structure.
Project-Oriented Scope

Project-oriented deliverables, or scope, support the project management and IT development processes that are defined in the information technology project methodology (ITPM). Project scope includes such things as the business case, project charter, and project plan and defines the work products of the various ITPM phases. Project-oriented deliverables also include specific deliverables such as a current systems study, requirements definition, and the documented design of the information system. These are deliverables supported by the systems development life cycle (SDLC) component of the overall ITPM.

Project-oriented deliverables require time and resources and, therefore, must be part of the overall project schedule and budget. Their role is to ensure that the project processes are being completed so that the project’s product (i.e., the information system) achieves the project’s MOV and objectives. Project-oriented deliverables also provide tangible evidence of the project’s progress (or lack of progress). Finally, they allow the project manager to set a baseline for performance and quality control because they usually require some form of approval before work on the next project phase or deliverable begins.
Project-Oriented Scope Definition Tools

All of the project deliverables must have a clear and concise definition. One way to communicate the project’s deliverables is to create a deliverable definition table (DDT). An example of a DDT for our bank’s electronic commerce system is illustrated in Table 5.2.

Table 5.2 Deliverable Definition Table
Deliverable Structure Standards Approval Needed By Resources Required
Business case
As defined in the project methodology
Project sponsor
Business case team & office automation (OA) tools
Project charter & project plan
As defined in the project methodology
Project sponsor
Project manager, project sponsor, & OA tools
Technology & organizational assessment
As defined in the project methodology
Project manager & project sponsor
Bank’s systems analysts users, case tool, and OA tools
Requirements definition
As defined in the project methodology
Project manager
System analyst, users, case tool, & OA tools
User interface
As defined in the user interface guidelines
Project sponsor
System analyst, programmer, users, & integrated development environment (IDE)
Physical & technical design
As defined in the project methodology
Project manager & project sponsor
System analyst, programmer, & case tool
Application system
Files & database
As defined in the project methodology
Project sponsor
Programmers, system analysts, network specialists, program development tools, and relational database management system
Testing plan
As defined in the project methodology
Project manager
System analysts & OA tools
Testing results
As defined in the test plan
Project manager
Programmers, system analysts, & OA tools
Change management and implementation plan
As defined in the project methodology
Project manager
Systems analysts & OA tools
Training program
User documentation & training class
As defined in the implementation plan
Project manager & project sponsor
Trainers, documentation writers, & OA tools
Final report & presentation
As defined in the project methodology
Project sponsor
Project sponsor, project manager, & OA tools
Project evaluations & lessons learned
As defined in the project methodology
Project manager & senior
Project team, knowledge management system

SOURCE: Inspired by Graham McLeod and Derek Smith, Managing Information Technology Projects (San Francisco: Boyd & Fraser, 1996), 51–52.

The purpose of the DDT is to define all of the project-oriented deliverables to be provided by the project team. Each deliverable should have a clear purpose. In addition, it is important to define the structure of the deliverable. For example, a deliverable could be a document (paper or electronic), prototype, presentation, or the application system itself. This sets the expectation of what will be delivered by the project team. Moreover, the standards provide a means to verify whether the deliverable was produced correctly. These standards could be defined within the IT Project methodology, controlling agency (e.g., International Organization for Standardization), or through various quality standards established by the organization. In general, each deliverable must be verified and approved by the project sponsor and/or the project manager. It is important that the responsibility for approving a deliverable be clearly defined as well. Once a deliverable is approved, the project team is authorized to begin work on the next deliverable. This provides authorization control as well as a basis for logically sequencing the work. Finally, it is important that the resources required to complete the deliverable be defined. This will provide the foundation for determining not only what resources will be needed for the project, but also for estimating the time and cost in completing each deliverable.

Once the deliverables have been defined in the DDT, a deliverable structure chart (DSC) can be developed as an interim step to define detailed work packages that will be used to estimate the project schedule and budget. Later on, these work packages will be used to create a work breakdown structure (WBS)—a tool used to help create the project plan. Figure 5.3 provides an example of a deliverable structure chart that maps the project life cycle and systems development life cycle phases to the deliverables defined in the DDT.

Figure 5.3 Deliverable Structure Chart (DSC)

[Click to enlarge]
Quick Thinking—Sinking a Project

The trade magazine Computerworld contains a section called Sharkbait that allows people to submit real stories about their professional experiences. An anonymous writer described a situation where an IT manager decided to add a “cool new feature” to the next release of an internal software application. The new feature was added to the scope of the project, and the developers developed and tested it at an additional cost of about $50,000. When the application was given to the users for acceptance testing, they were surprised to find the new functionality. Immediately, they sent the application back to the developers and informed them that they would not pay for something they did not ask for or need. The IT manager was soon transferred to another position.

1. Were the users justified in rejecting the application even though it contained a “cool new feature”?
2. What lessons can we learn from this experience?

SOURCE: Adapted from “Scope Creep?”, Computerworld, 10/29/2007,
Product-Oriented Scope

Although the electronic commerce application system is listed as a project-oriented deliverable, we really do not have a clear idea what exactly will be delivered to the client at this point in our project. In general, the application system will be the largest project deliverable and will, therefore, require the most time and resources to complete. Identifying the features and functionality of the application system (and their complexity) will be pivotal for estimating the time and cost of producing this deliverable.
Product-Oriented Scope Definition Tools

Product scope therefore focuses on identifying the features and functionality of the information system to be implemented. A useful tool for refining the scope boundary and defining what the system must do is a modeling tool called a context level data flow diagram (DFD). A DFD is a process model that has been available for quite some time and is often taught in systems analysis and design courses. A context level DFD, however, presents a high-level representation of the system that has one process (i.e., a circle or rounded rectangle that represents the system as a whole) and depicts all the inflows and outflows of data and information between the system and its external entities. The external entities are usually represented by a square and can be people, departments, or other systems that provide or receive flows of data. Arrows represent the directional flow of data between external entities and the system. Each arrow and entity should be labeled appropriately. Lower level DFDs can be developed later to model the processes and flows of data in greater detail. An example of a context level DFD for our banking electronic commerce system is provided in Figure 5.4. As you can see, the high level features and functionality of the system focus on what the system must do.

Figure 5.4 Context Level Data Flow Diagram (DFD)

[Click to enlarge]

Another useful tool for defining the product scope is the use case diagram, which has been used in the object-oriented world as part of the Unified Modeling Language (UML). While Jacobson (Jacobson, Cristerson et al. 1992) introduced the use case as a tool for software development, a use case diagram can provide a high level model for defining, verifying, and reaching agreement upon the product scope.

The use case diagram is a relatively simple diagram in terms of symbols and syntax, but it is a powerful tool for identifying the main functions or features of the system and the different users or external systems that interact with the system. At this early stage of the project, the use case can provide a high level diagram that can be further refined and detailed during requirements analysis later in the project.

Actors are people (users, customers, managers, etc.) or external systems (i.e., the bank’s ERP system) that interact, or use, the system. Think of actors in terms of roles (e.g., customer) instead of as specific individuals (e.g., Tom Smith). A use case, on the other hand, depicts the major functions the system must perform for an actor or actors. When developing a use case diagram, actors are identified using stick figures, while use cases are defined and represented using ovals. Figure 5.5 provides an example of a use case diagram for the bank example.

Figure 5.5 Use Case Diagram

[Click to enlarge]

As you can see in Figure 5.5, the use case diagram provides a simple yet effective overview of the functions and interactions between the use cases and the actors. The box separating the use cases from the actors also provides a system boundary that defines the scope boundary. Use cases inside the boundary are considered within the scope of the project, while anything outside of the boundary is considered outside the scope of the project. Listing the actors provides an opportunity to identify various stakeholders and can be useful for understanding the needs of the organization as a whole. It can be useful not only for addressing competing needs among various stakeholders, but for identifying security issues as well (Fowler and Scott 1997). The development of a use case diagram is an iterative process that can be developed during a joint application development (JAD) session. JAD is a group-based method where the users and systems analysts jointly define the system requirements or design the system (Turban, Rainer, and Potter 2001).

The use case diagram used to define the product scope can be used to refine the level of detail and functionality later on in our project. Following our example, the use case diagram in Figure 5.5 identifies the customer actor as using the system to transfer payments. However, a scenario or set of scenarios could be developed during the analysis and design phases of our project to determine how a customer would transfer funds successfully, while another scenario might focus on what happens when a customer has insufficient funds in their account. This level of detail is more suited to the requirements definition rather than the scope definition. At this point, it is more important to identify that the system must allow a customer to transfer funds than to identify how the funds may be transferred. Later on, the product scope can be compared or measured against the detailed requirements. These detailed requirements will be defined during the SDLC component of the ITPM.

But what is the appropriate level of detail for defining the product scope? Knowing the right level of detail is more an art than a science. The right level allows the project manager to estimate the time it will take to produce the application system accurately. As the next chapter shows, estimating the time and effort to produce the application system deliverable depends on the size of the application, the number of features incorporated, and their level of complexity. Therefore, the quality of the estimates will be greatly influenced by our understanding of the information system to be delivered.

The time and resources committed to developing the project charter and plan may limit the amount of time and energy we can devote to defining the details of the information system. Thus, the objective during this planning stage of the project should be to secure enough detail about the information system to allow us to estimate the time and effort needed to produce this deliverable. During the analysis and design phases, we can commit more time and resources to increasing our understanding and to documenting the level of detail needed to build and deliver the system.
Project Scope Verification

Once the project’s scope has been defined, it must be verified and formally accepted by the project sponsor and other appropriate stakeholders. Project scope verification is the scope management process that provides a mechanism for ensuring that the project deliverables are completed according to the standards described in the DDT. Gray and Larson (2000) provide a project scope checklist for ensuring that the deliverables are completed—and completed correctly. This checklist has been adapted to include the MOV concept.

* MOV—Is the project’s MOV clearly defined and agreed upon? Failure to define and agree upon the MOV could result in scope changes later in the project, which can lead to added work impacting the project’s schedule and budget.
* Deliverables—Are the deliverables tangible and verifiable? Do they support the project’s MOV?
* Quality standards—Are controls in place to ensure that the work was not only completed, but completed to meet specific standards?
* Milestones—Are milestones defined for each deliverable? Milestones are significant events that mark the acceptance of a deliverable and give the project manager and team the approval to begin working on the next deliverable. In short, milestones tell us that a deliverable was not only completed, but reviewed and accepted.
* Review and acceptance—Are both sides clear in their expectations? The project’s scope must be reviewed and accepted by the project stakeholders. The project sponsor must formally accept the boundary, product to be produced, and the project-related deliverables. The project team must be clear on what it must deliver. In both cases, expectations must be realistic and agreed upon.

Scope Change Control

According to the PMBOK®Guide, scope change control is concerned with managing actual changes to the project’s scope as and when they occur, to ensure that any changes to the project’s scope will be beneficial. Scope control is also concerned with:

* Scope grope—Scope grope is a metaphor that describes a project team’s inability to define the project’s scope. This situation is common early in a project when the project team and sponsor have trouble understanding what the project is supposed to accomplish. Scope grope can be minimized by having a clearly defined MOV and by following or applying the processes, concepts, and tools described in this chapter.
* Scope creep—Scope creep refers to increasing featurism, adding small yet time- and resource-consuming features to the system once the scope of the project has been approved. For example, a project sponsor may try to add various bells and whistles to the project scope. Yet, scope creep does not always come from the project sponsor side. The project team itself may come across interesting or novel ideas as the project work progresses. Its enthusiasm for adding these ideas can divert its attention or add features and functions to the system that the project sponsor did not ask for and does not need. Scope creep must be identified and controlled throughout the project because it will lengthen the project schedule and, in turn, lead to cost overruns.
* Scope leap—If scope creep is caused by increasing featurism, scope leap suggests a fundamental and significant change in the project scope. For example, the original scope for the bank’s electronic commerce project was to provide new products and services to its customers. Scope creep may be adding a new feature, such as a new product or service, not originally defined in the project’s scope. Scope leap, on the other hand, is an impetus to change the project so that the electronic commerce system would allow the bank to obtain additional funding in the open market. Adding this activity would dramatically change the entire scope and focus of the project. Scope leap can occur as a result of changes in the environment, the business, and the competitive makeup of the industry. Scope leap entails changing the MOV and, therefore, requires that the organization rethink the value of the current project. If this change is critical, the organization may be better off pulling the plug on the current project and starting over by conceptualizing and initiating a new project.

Quick Thinking—Going Full Circle

A programmer is approached by the company’s engineer to “whip up a small database to track issues on the manufacturing line as tests are run.” The programmer agrees, but a newly hired engineer who hears about the project convinces the programmer’s manager that what’s really needed is a more robust system that will not only track test results but run the manufacturing line. Consultants are brought in and the engineer is wined and dined. Before long, it is decided that to have a really good system a new network will have to be installed on the line, additional coding will be necessary so that orders can be taken from the company’s mainframe, and new equipment will be needed to replace some of the older equipment on the line. The engineer travels across the country to look at new equipment, and after a year of research and $100,000 spent on consultants, the engineer presents his recommendation to the company’s president. The cost of the system will be just over $2 million to install with an addition of four new full-time staff to run things. The president shoots the proposal down, and the engineer resigns to go work for the consulting company. A week after the engineer leaves, the programmer is approached by the original engineers and is asked to create the database they wanted originally. A week later they have their database and are happy.

1. How could something like this have gotten so far?
2. Is there any way to avoid this situation?

SOURCE: Adapted from Who are You Calling a Scope Creep?, Computerworld, December 5, 2007.
Scope Change Control Procedures

A scope change procedure should be in place before the actual work on the project commences. It can be part of, or at least referenced in, the project charter so that it is communicated to all project stakeholders. This procedure should allow for the identification and handling of all requested changes to the project’s scope. Scope change requests can be made, and each request’s impact on the project can be assessed. Then, a decision whether to accept or reject the scope change can be made.

A scope change procedure may include a scope change request form. An example of a scope change request form is illustrated in Figure 5.6. Regardless of the format for a scope change request form, it should contain some basic information. First, the description of the change request should be clearly defined so that the project manager and project team understand fully the nature and reason for the scope change. Second, the scope change should be justified, which separates the would likes from the must haves. In addition, several alternatives may be listed in order to assess the impact on scope, schedule, resources, and cost. Often a trade-off or compromise will be suitable if the impact of the scope change is too great. The project sponsor must understand and approve these impacts because the baseline project plan will have to be adjusted accordingly. Alternatives may include reducing functionality in other areas of the project, extending the project deadline, or adding more resources in terms of staff, overtime, or technology. Finally, all scope changes must be approved so that additional resources can be committed to the project.

Figure 5.6 Scope Change Request Form

[Click to enlarge]

However, nothing can be more frustrating than making a request and then not hearing anything. Too often requests fall through the cracks, leading to credibility concerns and accusations that the project manager or project team is not being responsive to the client’s needs. Therefore, a scope change control procedure should be logged with the intention that each request will be reviewed and acted upon. As seen in Figure 5.7, an example of a Change Request Log includes information as to who has the authority to make the scope change decision and when a response can be expected.

Figure 5.7 Scope Change Request Log
Request Number Request Title Date of Request Requested by Priority (L, M, H) Authority to Approve Request Expected Response Date Scope Change Approved? (Y/N)

Although this may seem like the beginning of a bureaucracy, it is really designed to protect all project stakeholders. Too often the project manager and project team feel the pressure to say yes to each and every scope change request because their refusal may be interpreted as being uncooperative. Unfortunately, introducing scope creep will impact the schedule and budget. As the deadline passes or as costs begin to overrun the budget, the project manager and team then may come under fire for not controlling the project objectives.

Still, a project manager and team should not say no to every scope change request. Some changes will be beneficial and warranted as the project proceeds. The question then becomes: What should be the basis for making a scope change decision?

As you have seen, the project’s MOV guides the project planning process. Similarly, the project’s MOV can also guide scope change decisions. A scope change request should be approved if—and only if—the scope change can bring the project closer to achieving its MOV; otherwise, why bother adding additional work, resources, time, and money to activities that will not bring any value to the organization?
Benefits of Scope Control

The most important benefit of scope change control procedures is that they keep the project manager in control of the project. More specifically, they allow the project manager to manage and control the project’s schedule and budget. Scope control procedures also allow the project team to stay focused and on track in terms of meeting its milestones because it does not have to perform unnecessary work.
Chapter Summary

Although scope is the work to be performed on the project, a project’s scope can be defined as the boundary and deliverables that the project team will provide to the project sponsor. A scope boundary acts as a fence to ensure that what needs to get done, gets done—and only what needs to get done, gets done. Performing work that does not help the project achieve its MOV needlessly consumes valuable time and resources. Therefore, the project’s boundary helps the project team define the limits of the project and how it will interact with its environment. In addition, deliverables are tangible units of work that ensure that the project is on track. Deliverables may be product oriented or project oriented. Product-oriented deliverables focus on the high level features and functionality of the application system—the project’s product. On the other hand, project-oriented deliverables focus on the project’s processes as defined in the IT project methodology.

The Project Management Body of Knowledge Guide® identifies five processes that support project scope management: scope planning, scope definition, create work breakdown structure, scope verification, and scope control.

Scope grope is a common occurrence in the early stages of the project. Often the project team struggles to define what the project is all about and what work must be done. By applying the concept of an MOV and the tools introduced in this chapter, the time a project team spends searching for these answers should be reduced. Scope creep, on the other hand, is a common occurrence in many projects. It entails adding additional features or functions to the scope once the scope has been set and approved. This phenomenon can increase the schedule and budget, causing the project to miss its deadline and budget targets. Scope creep can be managed by (1) verifying that the scope is accurate and complete by using a scope verification checklist, and (2) ensuring that appropriate scope changes are approved and reflected in the baseline plan by having scope change procedures. The MOV concept can guide this decision process. For example, scope changes that move the project closer to achieving its MOV should be approved, while those that do not merely waste time and resources. Lastly, scope leap entails a major and fundamental change to the project scope. It may be the result of a changing business environment or the competitive makeup of the industry. Such a radical departure from the original business case may require the project stakeholders to rethink the viability of the current project.
Review Questions


What is meant by project scope?


Briefly describe the five scope management processes.


Briefly describe the scope planning process.


Briefly describe the scope definition process.


Briefly describe the scope verification process.


Briefly describe the scope change control process.


Describe the scope management plan in Figure 5.1.


Why is it important to define the project’s scope accurately and completely?


What is a scope boundary? What purpose does it serve?


What is the difference between product-oriented deliverables and project-oriented deliverables?


How does a project’s scope support the MOV concept?


What is a scope statement? What purpose does it serve?


What is a context dataflow diagram (DFD)? What purpose does it serve?


How does a use case diagram help to define the project’s scope?


What is a deliverable definition table (DDT)? What purpose does it serve?


What is a deliverable structure chart (DSC)? How does it map to a deliverable definition table (DDT)?


What is a work breakdown structure (WBS)? How does it map to the DDT and DSC?


Briefly describe what must be included in a scope verification checklist.


What is the purpose of verifying a project’s scope?


What is the purpose of scope change control procedures?


Briefly describe scope grope.


Briefly describe scope creep.


Briefly describe scope leap.


What are the benefits of having scope control procedures?


Briefly describe what should be included on a scope change request form.


What is the purpose of a scope change request log?

Extend Your Knowledge

1. Using the Web or library, find an article about an unsuccessful IT project. Discuss whether poor scope management had any bearing on the project’s being unsuccessful.
2. Discuss the statement: Failing to define what is not part of the project is just as important as failing to define what is part of the project.
3. Choose a company that sells a product or service on the Web. Using this Web site as a guide, develop the following (even though the application is already in existence). You may make assumptions where necessary, but be sure to document them.
1. Scope statement
2. Context level DFD
3. Use case diagram

Global Technology Solutions

On Friday evening Tim Williams and Kellie Matthews were still at the GTS office, working on the project charter and project plan for Husky Air. Rubbing her eyes, Kellie asked, “I know we defined the goal of the project by developing the MOV, but what about the work that has to be done to get us there?”

“Glad you asked,” Tim said as he put down his personal digital assistant on the desk in front of him. “I think we’re ready to start defining the scope of the project, which will help us define all of the deliverables and activities that support the MOV.”

“I remember working on a project that never seemed to end,” she replied. “The users always wanted to add more bells and whistles to the system, and the project ended up missing its deadline and costing a lot more than we had planned.”

Tim thought for a moment, then asked. “So, what can we learn from that experience?”

Kellie smiled. “First of all,” she said. “I think we need to have a plan in place to make sure that the scope of the project is well defined. I think part of our problem was that we never really got a clear idea of the project’s goal, so we never defined the scope of the project properly. And secondly, we should’ve had some kind of process in place to control scope changes once we started the project.”

Tim agreed. “That sounds like an excellent idea. But why not just say no to any scope change requests?”

Kellie sat back in her chair. “The way I see it, if we say yes to each and every scope change request, we run the risk of escalating the project’s schedule and, in turn, the project’s budget. On the other hand, if we say no to all scope change requests, we run the risk of missing some opportunities or appearing nonresponsive to our client’s needs.”

“Good point, but how do you know when to say yes to a scope change and when to say no?” asked Tim.

“I guess we could let the project’s MOV be our guide,” she answered. “If a scope change supports the MOV, then it’s worth doing. Otherwise, if it doesn’t support the MOV, then the scope change isn’t worth the time or money. Besides, the client has to make the decision whether the change in scope is worth the increase in schedule and cost. All we can do is keep the schedule and budget under control and then point out to them how any requested scope change will impact the project.”

Tim stood up, saying “I think what we need is a scope management plan that can be part of the project charter. It’s also important that we let everyone involved with the project know about it. Let’s call it a day and get started on it first thing Monday morning.”

Kellie agreed. “That’s the best idea I’ve heard all day. Why don’t you go ahead? I’ll lock up after I make a few phone calls.”
Things to Think About

1. What is the importance of ensuring that the scope of a project has been defined completely and accurately?
2. What is the relationship between the project’s MOV and its scope?
3. What is the importance of having scope control procedures in place?
4. Why should a scope control process be communicated to all of the stakeholders of a project?

Husky Air Assignment—Pilot Angels
The Scope Management Plan

Your client, Husky Air, has given your team the authority to develop the project’s scope. The project’s scope defines the project work. It includes the work boundaries and deliverables that you will deliver to your client.

Please provide a professional-looking document that includes the following:

1. Project name, project team name, and the names of the members of your project team
2. A brief project description
3. The project’s MOV—(This should be revised or refined if necessary.)
4. A Deliverable Structure Chart (DSC)—This should be based on the project life cycle and the systems development life cycle. You should begin by creating a hierarchical chart that defines all of the project and system development phases. The system development phases will depend largely on the development approach you use (waterfall, rapid applications development, etc.). After you have identified all project phases, the next step in developing a DSC is to identify at least one project or product deliverable for each phase.
5. A use case diagram (UCD)—A UCD defines the high-level features and functionality that the application system should include. Although Figure 5.5 provides an example of a use case, you can build one:
1. Draw a box to represent the system boundary.
2. Draw stick figures to represent the actors of the system. Actors can be users, managers, customers, or even other systems that will interact with or use the application system. Actors should be drawn on the outside of the system boundary. Be sure to label each actor with a descriptive name to describe the actor’s role.
3. A use case is a particular function that the application system will perform. Draw an oval inside the system boundary for each function and label the oval with a descriptive name. Examples of use cases are: update customer information, print employee overtime report, create new vendor record, and so forth. This important step during your project necessitates a great deal of interaction with your client. Unfortunately, you will not have access to a real client, so you can be creative. Keep in mind, however, that additional (and often unused) functionality will require more time and resources to build the system, thus adding to the project’s schedule and budget. You and your team need to be aware that any features and functionality of the system should help the organization achieve its MOV.
4. Draw a connecting line to identify the actors who will make use of a particular use case.
6. A scope change process—Together, the DSC and UCD define what will and what will not be part of the project scope. In short, the project team is responsible for delivering everything that is listed in the DSC and UCD. Unfortunately, items may be overlooked and often needs will change. Adding deliverables or functionality to the system is an important decision. Therefore, develop a logical process that your client and team will follow for identifying, cataloging, managing, and responding to a scope change request. Be sure to include templates or examples of any forms or logs that will be used to support the scope change process.

Case Studies
Just Say No?

Many project managers agree that “half-baked” or “hare-brained” ideas becoming projects and excessive scope creep are two key causes of challenged and failed projects. And a half-baked idea that turns into a project with excessive scope creep can be a nightmare for the project manager and team.

Top management is often under pressure to develop new and innovative products and services that move the organization toward profitability and competitive leadership. However, many times these ideas include a number of less than stellar ideas that get turned into projects. This can occur as a result of “management by magazine,” when a manager reads an article and forms a new vision. Unfortunately, many project managers fail to object because the organization may have a culture where such things aren’t questioned or a belief that senior management could never be wrong.

Moreover, scope creep can be a key challenge, especially when the customer or sponsor has unreasonable or unrealistic expectations. Many project managers may feel they don’t have the ability, experience, or power to just say no. Their only option may be to do as they’re told and comply begrudgingly even though they know that the likelihood of their project’s success is small.

Gopal Kapur believes that this is where the idea of intelligent disobedience can come into play. Intelligent disobedience is a quality taught to guide dogs for the blind. For example, a blind person may initiate the move to cross a busy street by giving a signal to the guide dog to move forward. If traffic blocks the crosswalk, the guide dog will disobey the command. This failure to comply with an unsafe command is intelligent disobedience, and the dog owner must learn to trust the guide dog.

A project manager can apply the concept of intelligent disobedience by saying no to demands that can be detrimental to the project or the organization. This, however, requires trust and empowerment, as well as the project manager’s ability to read the danger signals when a project is a half-baked idea or when scope creep becomes excessive. On the other hand, the project sponsor or customer must trust and respect the project manager’s judgment.

1. What determines whether a project manager will react with intelligent disobedience or begrudging compliance?
2. How can half-baked ideas that turn into projects and excessive scope creep be minimized?
3. The vice president of marketing read an article on a plane that interactive marketing on the World Wide Web is the hottest trend. Subsequently, she believes that your organization should develop an interactive marketing Web site or else your organization will be at a competitive disadvantage. After meeting with her, you find that this is really more of a half-baked idea than a real project. She also says not to worry, that “We’ll firm up the project as we go along.” If you were asked to be the project manager, how would you handle this situation?

Adapted from Gopal K. Kapur, Intelligent Disobedience, Computerworld, August 30, 2004.
The Vasa

The Vasa was a Swedish warship built in 1628 for King Gustavus Adolphus. On her maiden voyage, the ship floundered and keeled over in a light wind after sailing less than a nautical mile. Wives and children of the 125 crew were invited to take part in the festivities; however, around 50 perished in the tragedy.

In the 17th century, Sweden rose to become one of the most powerful states in the Balkan Sea. Gustavus Adolphus became Sweden’s king at the age of 17 in 1611 and was considered a born leader of great intellect and bravery. A decade later, Sweden was involved with a war with Poland, and looking at the possibility of war with Germany. This required a strong navy, but several setbacks during the 1620s weakened Sweden’s military dominance: a Swedish squadron of 10 shops ran aground in 1625 and was wrecked by a bitter storm while two large warships were outmaneuvered by the Polish navy and defeated in 1627; in 1628, three more ships were lost within a month.

In January 1625, the king ordered Admiral Fleming to sign a contract with Henrik Hybertson and his brother Arend to build four ships, two smaller ones with keels of 108 feet (33 m) and two larger ones of 135 feet (41 m). After losing the 10 ships in a storm, the king sent a concerned letter to Admiral Fleming instructing him to tell Henrik Hybertson that the schedule for the two smaller ships must be expedited. The king also requested that these ships have 120 foot (37 m) keels and include two enclosed gun decks so that they could carry more armament. This presented a dilemma for Hybertson because the timber had already been cut for the specifications outlined in the contract for one smaller ship and one larger ship. Moreover, no one had built a ship with two gun decks before. Hybertson tried to convince the king to follow the original specifications, but the king demanded that the ships be built according to his new measurements. Master Shipwright Hybertson soon became ill in 1625 and died in the spring of 1627, never seeing the Vasa completed. The project was handed over to Hybertson’s assistant, Hein Jacobsson, who had very little management experience and no detailed records or plans from which to work.

In 1628, Admiral Fleming ordered a test of the Vasa’s stability. This consisted of having 30 sailors running from one side of the ship to the other to assess how the ship would rock. The test was aborted only after three runs; otherwise the ship would have keeled over. The two shipbuilders, Jacobsson and his assistant Johan Isbrandsson, were not present for the test. A member of the crew was heard to make a remark about the ship’s instability, but the admiral replied that “The master shipbuilder surely has built ships before, so there is no need to have worries of that kind.” No doubt the admiral, captain, and crew had wished the king were present, but he was fighting in Poland and sending a stream of messages instructing that the ship be launched immediately.

During the stability test, the ship’s armament was being produced and artists were working feverishly to complete the decorations. The number and types of armaments to be carried by the redesigned Vasa went through a number of revisions as well. The original design called for 32 24-pound guns, but the 135-foot version was to carry 36 24-pound guns, 24 12-pound guns, eight 48-pound mortars, and 10 smaller guns. After further revisions, the king finally ordered the Vasa to carry 64 24-pound guns (32 on each deck) and as many as 60 24-pound guns. The idea was to arm the Vasa with powerful guns and a high stern that could act as a firing platform in boarding actions for the 300 soldiers the ship was to carry.

Moreover, it was customary for warships to be decorated ornately with hundreds of gilded and painted sculptures of Biblical, mythical, and historical themes to glorify the authority and power of the king and to frighten or taunt the enemy. The 500 sculptures added considerably to the effort and cost of the ship as well as raising the ship’s center of gravity and contributing to its instability. During this period, no methods for calculating the ship’s center of gravity, heeling characteristics, and stability existed, so shipbuilders and captains had to design and learn how a ship handled through trial and error.

On August 10, 1628 Captain Sofring Hansson ordered the Vasa to set sail on its maiden voyage. The wind was relatively calm with only a light breeze from the southwest. The gun ports were open so that a salute could be fired as the ship left her shipyard in Stockholm. Suddently, a gust of wind filled her sails and the ship heeled to port. The ship slowly righted herself, but another gust pushed the ship again to her port side where water began to flow through her open gun ports. The Vasa heeled even further, until she sank in about 100 feet of water not far from shore. The ship sank in front of hundreds or even thousands of people who had come to see the ship sail on her first voyage. Survivors clung to debris while many boats rushed to their aid. Despite heroics and the short distance to shore, records indicate that as many as 50 people perished with the ship.

The king was notified of the Vasa’s fate by letter. He wrote a reply that “imprudence and negligence” must have been the cause and that the guilty parties would be punished. Captain Hansson survived and was imprisoned immediately to await trial. The captain and crew were interrogated regarding the handling of the ship as well as the sobriety of the captain and crew. Crew members and contractors blamed each other and everyone swore that they had done their job without fault. When asked why the ship was built to be so narrow and so unstable, the shipwright Jacobsson said that he had simply followed orders as directed by the long dead and buried Henrik Hybertsson, who had followed the king’s orders. In the end, no one was sent to prison or found guilty of negligence. The disaster was explained as an act of God, but the sinking of the Vasa ended up being a major economic disaster for a small country.

1. What were some of the major problems associated with this project?
2. What lessons can we learn from the sinking of Vasa that can be applied to IT projects?

SOURCE: Vasa (ship); Richard E. Fairley and Mary Jane Willshire, Why the Vasa Sank: 10 Problems and Some Antidotes for Software Projects, IEEE Software, March/April 2003, 18–25.

Fowler, M. and K. Scott 1997. UML Distilled: Applying the Standard Object Modeling Language. Reading, MA: Addison-Wesley.

Gray, C. F. and E. W. Larson 2000. Project Management: The Managerial Process. Boston: Irwin McGraw-Hill.

Jacobson, I., M. Cristerson, P. Jonsson, and G. Overgaard 1992. Object-Oriented Software Engineering: A Use-Case Driven Approach. Reading, MA: Addison-Wesley.

Project Management Institute (PMI) 2004. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Newtown Square, PA: PMI Publishing.

Turban, E., R. K. Rainer, Jr., and R. E. Potter 2001. Introduction to Information Technology. New York: John Wiley.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License