MIT422 – Technology and Project Management

1
Project Scope Management

Project Scope Management

At the end of the module the student is expected to:
1. Understand the concept of project scope management
2. Enumerate and discuss the process involved in project scope
management.
3. Define project scope.
4. Discuss the Work breakdown structure in relation to project scope
management.
5. Define validation scope.

Introduction
According to the 2009 Standish Group Chaos report only 32% of IT projects
are delivered on time, on budget and have the required features and
functions asked for. In addition, 44% of projects were late, over budget and
were delivered with incomplete features or functionality. The final 24%
remaining were complete failures dues to cancellation prior to completion or
were delivered and never used. These failures have cost numerous
companies millions of dollars and countless reputation points as a result. For
a project to be a successful one, project managers must be able to define the
scope of the project. Project scope defines the boundaries of the project,
what to include and what not to include, this process must be clear from start
so that the project can be delivered on time and on budget.
Here is the definition of Scope, it refers to all the work involved in creating
the products of the project and the processes used to create them, its also
refers to the detailed set of deliverables or features of a project. Deliverables
can be product related, such as a piece of hardware or software, or process-
related, such as a planning document or meeting minutes.
Project Scope Management is the management of the process that is required
to ensure that a project includes all the work necessary to complete the
project successfully. It is concerned primarily with controlling what is and
what is not in the scope. The following are the processes involved in project
scope management.

Course Module
Project Management Scope
Collecting requirements
It is the process of defining and documenting stakeholders need to meet the
project activities. The document for collecting requirements is developed in
the project planning phase.
Ways on how to gather / collect requirements
 Interview
 Holding of focus group workshops
 Giving of Questionnaire and surveys
 Benchmarking

Defining scope
This is the process of developing a detailed description of the Project and
product. So while Collecting requirement list, all the different requirements
of the Project and the resulting product or service are defined.

Creating the Work breakdown structure

A work breakdown structure (WBS) is a deliverable oriented grouping of the
work involved in a project that defines its total scope.
Creating work breakdown structure is done using a technique called
decomposition. It is basically the process of subdividing project deliverables
and project work into smaller and more manageable components.

Validating the scope

This is the process which is a part of project monitoring and control process
group. This process includes reviewing deliverables with the customer or
sponsor to ensure that they are completed satisfactorily and obtaining formal
acceptance of deliverables by the customer or sponsor.
 MIT422 – Technology and Project Management
3
Project Scope Management

Controlling the scope

Control Scope is the last process group of project scope management. It is
again a part of project monitoring and control process group. Control scope is
the process of monitoring the status of the project and Product scope and
managing changes to the scope baseline. This process ensures that all
requested changes and recommended corrective or preventive actions are
processed through the integrated change control process.

Defining scope
The main purpose of the scope definition is to clearly describe the
boundaries of your project. Clearly describing the boundaries is not enough
when it comes to project. You need to get the client's agreement as well.
The main purpose of the scope definition is to clearly describe the
boundaries of your project. Clearly describing the boundaries is not enough
when it comes to project. You need to get the client's agreement as well.
In the project scope definition, the elements within the scope and out
of the scope are well defined in order to clearly understand what will be the
area under the project control. Therefore, you should identify more elements
in detailed manner and divide them among the scope and out of scope.

Scope Creep
Scope creep is something common with every project. This refers to the
incremental expansion of the project scope. Most of the time, the client may
come back to the service provider during the project execution and add more
requirements.
Most of such requirements haven't been in the initial requirements. As a
result, change requests need to be raised in order to cover the increasing
costs of the service provider.
Due to business cope creep, there can be technological scope creep as well.
The project team may require new technologies in order to address some of
the new requirements in the scope.
In such instances, the service provider may want to work with the client
closely and make necessary logistic and financial arrangements.

Example of Project Scope Statement

PROJECT OBJECTIVE
To construct a high-quality, custom home within five months at cost not to
exceed Php150,000.
DELIVERABLES
 A 2,200-square-foot, 2½-bath, 3-bedroom, finished home.
Course Module
  A finished garage, insulated and sheetrocked.
 Kitchen appliances to include range, oven, microwave, and
dishwasher.
 High-efficiency gas furnace with programmable thermostat.
MILESTONES
 Permits approved—March 5
 Foundation poured—March 14
 Dry in. Framing, sheathing, plumbing, electrical, and mechanical
inspections passed—May 25
 Final inspection—June 7
TECHNICAL REQUIREMENTS
 Home must meet local building codes.
 All windows and doors must pass NFRC class 40 energy ratings.
 Exterior wall insulation must meet an “A” factor of 21.
 Ceiling insulation must meet an “R” factor of 38.
 Floor insulation must meet an “R” factor of 25.
 Garage will accommodate two large-size cars and one 20-foot
Winnebago.
 Structure must pass seismic stability codes.
LIMITS AND EXCLUSIONS
 The home will be built to the specifications and design of the original
blueprints provided by the customer.
 Owner responsible for landscaping.
 Refrigerator is not included among kitchen appliances.
 Air conditioning is not included but prewiring is included.
 Contractor reserves the right to contract out services.
 Contractor responsible for subcontracted work.
 Site work limited to Monday through Friday, 8:00 A.M. to 6:00 P.M.
CUSTOMER REVIEW
 Hadji and Joan

Work Breakdown Structure

A Work Breakdown Structure (WBS) is a decomposition of all the work
necessary to complete a project. A WBS is arranged in a hierarchy and
constructed to allow for clear and logical groupings, either by activities or
deliverables. The WBS should represent the work identified in the approved
Project Scope Statement and serves as an early foundation for effective
schedule development and cost estimating. Project managers typically will
develop a WBS as a precursor to a detailed project schedule. The WBS
should be accompanied by a WBS Dictionary, which lists and defines WBS
elements.
The goals of developing a WBS and WBS Dictionary are 1) for the project
team to proactively and logically plan out the project to completion, 2) to
collect the information about work that needs to be done for a project, and 3)
to organize activities into manageable components that will achieve project
 MIT422 – Technology and Project Management
5
Project Scope Management

objectives. The WBS and WBS Dictionary are not the schedule, but rather
the building blocks to it. The progression of WBS and WBS Dictionary
development is as follows:

The WBS and WBS Dictionary should not be static documents. WBS
construction is subject to project management progressive elaboration, and
as new information becomes known, the WBS should be revised to reflect
that information. A Project Team that has substantial changes to its WBS
should reference the project’s Change Management Plan for guidance on
management of changes to project scope.
Example
Below is a simplified WBS example with a limited number of organizing
levels. The following list describes key characteristics of the sample WBS:
 Hierarchical Levels – contains three levels of work
 Numbering Sequence – uses outline numbering as a unique identifier
for all levels
 Level one is 1.0, which illustrates the project level.
 Level two is 1.X (1.1, 1.2, 1.3, etc.), which is the summary level, and
often the level at which reporting is done.
 Level three is 1.X.X (1.1.1, 1.1.2, etc.), which illustrates the work
package level. The work package is the lowest level of the WBS where
both the cost and schedule can be reliably estimated.
 Lowest Level Descriptions – expressed using verbs and objects, such
as “make menu.”

Course Module
 WBS Example - Banquet

Provide
Level 1 1.0
Banquet

Level 2
1.1 1.2 1.3 1.4 1.5 1.6

Plan and Room and

Dinner Guests Staff Speakers
Supervise Equipment

1.3.1
1.1.1 Create 1.2.1 Make 1.4.1 Make 1.5.1 Hire
Identify Site/ 1.6.1 Invite
Plan Menu Guest List Shoppers
Room
1.2.2
1.4.2
1.1.2 Make Create 1.3.2 Set up 1.5.2 Hire 1.6.2
Receive
Budget Shopping Tables/Chairs Cooks Transport
RSVPs
List
1.1.3 Prepare 1.6.3
1.3.3 Lay out 1.4.3 Create 1.5.3 Hire
Disbursements/ 1.2.3 Shop Coordinate
Settings/Utensils Name Tags Servers
Reconciliation Topics

1.1.4
1.4.4 Review 1.5.4 Hire 1.6.4 Backup
Coordinate 1.2.4 Cook 1.3.4 Decorate
Special Needs Hosts for No-shows
Activities

Level 3 1.3.5 Prepare

1.2.5 Serve 1.5.5 Hire 1.6.5 Send
Equipment, Pots,
Dinner Cleanup Thank Yous
Etc.

WBS Numbering
In a WBS, every level item has a unique assigned number so that work can be
identified and tracked over time. A WBS may have varying numbers of
decomposition levels, but there is a general scheme for how to number each
level so that tasks are uniquely numbered and correctly summarized. Below
is the general convention for how tasks are decomposed:
 Level 1 – Designated by 1.0. This level is the top level of the WBS and
is usually the project name. All other levels are subordinate to this
level.
 Level 2 – Designated by 1.X (e.g., 1.1, 1.2). This level is the summary
level.
 Level 3 – Designated by 1.X.X (e.g., 1.1.1, 1.1.2). This third level
comprises the subcomponents to each level 2 summary element. This
effort continues down until progressively subordinate levels are
assigned for all work required for the entire project.
If tasks are properly subordinated, most project scheduling tools will
automatically number tasks using the above convention.

WBS Construction Methods

Although there are different methods of decomposing project work and
creating a WBS, the most straightforward and effective way is to use some
form of visual display of the deliverables, phases, or activities. Ideally, all
Project Team members will convene and brainstorm all work required to
complete project deliverables successfully. Involvement of all team members
in this process increases the likelihood that the resulting WBS will be
comprehensive. Typically, team members start by identifying all project
deliverables or milestones and then decompose them one at a time into a
detailed and sequential list of the detailed activities required to complete the
deliverable or milestone. One way of visually conducting this process is by
using post-it notes to represent each deliverable and sub-activity.
 MIT422 – Technology and Project Management
7
Project Scope Management

WBS Types
 Deliverable-oriented WBS
 Process-centered WBS
 Deliverable-Oriented WBS
A deliverable-oriented WBS is built around the project’s desired outcomes or
deliverables. This type of WBS would likely include the following
characteristics:
 Level 2 items are the names of all vendor project deliverables that are
expected to be required as part of a contract. Level 2 should also
include any agency deliverables tasks.
 Level 3 items are key activities required to produce the Level 2
deliverables.
 Additional levels are used depending upon the magnitude of the
deliverables and the level of detail required to reliably estimate cost
and schedule.
 In the deliverable-oriented WBS, all deliverables are identified, and all
work is included.
Statewide projects procured as Firm-Fixed-Price contracts are well suited to
the deliverable-oriented approach. Organized this way, project managers
and agency management can review interim progress against deliverables
and easily determine the percentage of the work that is complete.
Sometimes, a deliverable-oriented WBS and its associated schedule can be
confusing to read because their items are not organized sequentially at the
highest level. They are, however, very useful in demonstrating progress
against contracted deliverables.
Process-Centered WBS
A process-centered WBS is similar to a deliverable-oriented WBS except that
it is organized, at the highest level, by phases or steps in a process rather
than by deliverables. The benefit of using a process-centered WBS is that it
encourages the inclusion of process-required deliverables, such as System
Development Life Cycle (SDLC) deliverables. Regardless of the type of WBS
employed, project teams should ensure that all contractual and SDLC
deliverables are accounted for in the WBS. A process-centered WBS typically
includes the following:
 Level 2 activities are phases or schedule checkpoints/milestones.
These activities could be SDLC phases such as Initiation, Planning, etc.
 Level 3 activities are those activities required to complete Level 2
phases or milestones. Multiple tasks are included for any work that
needs to be done in multiple phases.
 Additional levels are used depending on the duration of the phase or
schedule and the level of detail required to reliably estimate cost and
schedule.

Course Module
  In the process-centered WBS, all deliverables are identified, and all
work is included. This comprehensiveness will reduce the risk of “off
balance sheet” work tasks, which might have unexpected impacts on
the project schedule.

How Many Levels?

Two industry-standard methods exist for determining how many levels a
WBS should have:
Traditionally, the Project Management Body of Knowledge advocates a
predetermined seven-level model, which has the advantage of clear labels
and definitions of each level (e.g., program, project, task, subtask, work
product, and level of effort); the disadvantage to this model is that it requires
a level of detail that may be unnecessary. Models/methods with
predetermined levels and level definitions make clear what information
needs to be included and where, but they lack flexibility.
The more contemporary approach is to let the project characteristics dictate
the number of levels used in the judgment of the Project Manager. It is a
good practice to identify the number of levels to be used so that a project
maintains consistency when building the WBS. The number of levels must be
sufficient to allow the Project Manager to reliably estimate schedule and cost
and effectively monitor and control work packages.

How Much Detail?

The WBS should be sufficiently detailed to allow the Project Manager to
reliably estimate schedule and cost. One point of view is that the lowest level
of project detail should be no more than 40 total hours of work and should be
assignable to only one person. This level of detail allows the Project Manager
to easily assess what project work is complete, who is responsible for
executing what work, and what tasks are at variance with the baseline plan.
Another good measure is the “8 – 80” rule, which recommends that the
lowest level of work should be no less than 8 hours and no more than 80
hours. Level of detail for work packets should be documented in the WBS
Dictionary or the Project Management Plan.

Sample WBS Dictionary

As the Project Manager and Team discuss and define the WBS and address
how many levels and how much detail should go into the WBS, the Project
Team should create a WBS Dictionary to capture task characteristic
information, including task names, work products, level of effort, resources,
dependencies, and others. The WBS Dictionary should be consistent with the
WBS. The information captured in the WBS Dictionary will help the Project
Manager to later develop the detailed baseline schedule. The WBS Dictionary
may be in table or excel format.
 MIT422 – Technology and Project Management
9
Project Scope Management

Table 1. WBS Dictionary - Table Format Example

WBS #: 1.1.1 Task: Create Plan

Est. Level of 40 hrs Owner: Project Manager

Effort:

Resources Subject Matter Work Products: MS Project Plan

Needed: Experts

Description of Development of a detailed project plan that lists all key

Task: resources, tasks, milestones, dependencies, and
durations.

Input:  Approved Project Charter

 SMEs
Dependencies:  Approval of Budget

Risk:  Changes to IT Apps plans and deliverables

 IT Apps implementation releases, which conflict with
implementation
WBS #: 1.1.2 Work Item: Make Budget

Est. Level of 16 hrs Owner: Project Manager

Effort:

Resources CFO, CIO, Work Products: ITPR

Needed: Executive
Sponsor

Description of Development and documentation of the project budget

Task: based on plan and resources.

Input:  Approved Project Charter

 SMEs
Dependencies:  Approval of Project Charter

Risk:  Changes to IT Apps plans and deliverables

 IT Apps implementation releases which conflict with
implementation

Course Module
 Table 2. WBS Dictionary - Excel Format Example

WBS Fields

Est. Level
WBS # Task Description of Task Work Products Owners
of Effort

1 PLANNING All task management and

management activities

1.1 Plan and Roll-up Task Project N/A

Supervise Manager

1.1.1 Create Plan Development of WBS, work WBS, Project 40 hrs

package identification, schedule Manager
formulation, staffing projection, WBS Dictionary,
resource estimation. Followed MS Project Plan
by development of a detail
project plan that list all the key
resources, task, milestones,
dependencies, and duration.

1.1.2 Create Budget Development and ITPR Project 40 hrs

documentation of the project Manager
budget based on plan and
resources

1.1.3 Prepare Development of disbursement Purchase Orders, CFO 40 hrs

Disbursement / process for the project including Deliverable Product
Reconciliation acceptance/approval forms. Acceptance Form

1.1.4 Coordinate Ongoing planning activities for Meeting Minutes Project 8

Activities the project including weekly Manager hrs/week
meetings

Success Criteria
The key to a good WBS and WBS Dictionary is the engagement of project
team members to comprehensively identify and discuss activities for the
project. A Project Manager must ensure that all the work that needs to be
accomplished for the project is contained within the WBS Dictionary and is
understood by team members. All work should have clearly defined
duration, resources, dependencies, and level of effort. A Project Manager
should elicit feedback from all team members to ensure that the WBS and
WBS Dictionary are valid and comprehensive prior to developing the detailed
schedule.

Validating Scope
Validate Scope is the process of formalizing acceptance of the completed
project deliverables. Validating project and product scope takes place with
the project sponsor and/or customer. It should take place as each deliverable
is completed. It signifies that the customer or sponsor approves and accepts
the deliverable.
 MIT422 – Technology and Project Management
11
Project Scope Management

Controlling Scope
The goal of scope control is to influence the factors that cause scope changes,
to ensure that changes are processed according to procedures developed as
part of integrated change control, and to manage changes when they occur.
You cannot do a good job of controlling scope if you do not first do a good job
of collecting requirements, defining scope, and validating scope.
Best practices:
1. Keep the scope realistic. Don’t make projects so large that they can’t be
completed. Break large projects down into a series of smaller ones.
2. Involve users in project scope management. Assign key users to the
project team and give them ownership of requirements definition and
scope validation.
3. Use off-the-shelf hardware and software whenever possible. Many IT
people enjoy using the latest and greatest technology, but newer
technologies often introduce risks into the project. If a new technology’s
features and functions do not adequately balance these risks, it is better
to avoid the risks and use technologies that are trusted from prior
experience.
4. Follow good project management processes. others, there are well-
defined processes for managing project scope and other aspects of
projects.
Suggestions for Improving User Input
1. Develop a good project selection process for IT projects.
2. Have users on the project team
3. Have regular meetings with defined agendas.
4. Deliver something to project users and sponsors on a regular basis.
5. Do not promise to deliver what the team cannot deliver in a particular
time frame.

Course Module
6. Locate users with the developers.