PROJECT SCOPE MANAGEMENT

 Elements of project scope management

associated with project success.

 User Involvement
 Clear business objectives
 A minimized or clearly defined scope
 Firm Basic Requirements.
 Defining a scope is the most difficult aspect of project
management.
 Scope refers to all the work involved in creating the products
of a project and processes to create them.
 Deliverables: Products Produced as part of Project.
 It may be
 H/W,S/W
 Process Related
 Planning Document

 Meeting Minutes

 Project Scope Management includes

 The processes involved in defining and controlling what
work is or is not included in a project.
 It ensures that stakeholders and project team have the same
understanding about the product and the processes which
will be used to create them.
 FIVE MAIN PROCESSES INVOLVED IN
PROJECT SCOPE MANAGEMENT
1. Collecting Requirements
 Defining and documenting the functions and features of
the products produced and processes used.
 Project team creates stakeholders requirement
documentation , a requirements management plan and a
requirement traceability matrix, as the output of the
requirement collection process.
2. Defining scope
 It involves reviewing the project charter,requirement
documents and organizational process assets to create a
scope statement.
 The main outputs
 Project scope statement
 Updates to project documents
3. Creating WBS
 Subdividing the major project deliverables into smaller more
manageable components
 The main work
 WBS Structure
 WBS Dictionary

 A scope Baseline

 Updates to Project Documents

4. Verifying Scope
 Formalizing the acceptance of the project deliverables.
 The main output
 Formal Acceptance
 Change request (if not accepted)
 Key Stakeholders
 Customer and sponsor inspect and formally accept the
deliverable.
5. Controlling Scope
 It Controls the changes to project scope
throughout the life of the project.
 Scope changes often influence the team’s
ability to meet project time and cost goals, so
project managers must carefully weigh the cost
and benefits of the scope changes.
 The Main Outputs
 Change requests
 Work Performance Measurements
 Updates to organizational process assets
 Project management plan
 Project Documents
 COLLECTING REQUIREMENTS
 It is the most difficult step in PSM and also the very
first step.
 Major Consequence of not defining the Requirements
well is REWORK.
 Which Consumes a lot more cost.

 Problem Part: “People often don’t have a consistent

definition of what requirements are how to collect
them, and how to document them.”
 WHAT IS A REQUIREMENT?
 “A condition or capability that must be met or possessed by a
system, product, service, result or component to satisfy a contract,
standard, specification, or other formal documents.”

HOW TO COLLECT REQUIREMENTS

 Interviewing stakeholders one-by-one is often very effective but
very expensive and time consuming.
 Holding focus groups, facilitated workshops, and using
group creativity and decision making techniques to collect
requirements are normally easy and less expensive than one by one
interviews.
 Questionnaires and Surveys
 Observation can also be good technique.
 Prototyping is a commonly used for requirements collection.
 The project’s Size complexity will decide how much time should be
spent on collecting requirements.
HOW DO YOU DOCUMENT REQUIREMENTS?
 Review the project charter
 Review the stakeholders register to ensure that all
key stakeholder’s have a say in determining
requirements.
 People those who have worked on the complex
projects such as building a new airplane, know that
paper documenting requirements for a plane can
weigh more than the plane itself!
 Requirements documents are often generated by
software and include text, images, diagrams, videos,
and other media.
 Requirements are often broken into:
 Functional requirements
 Service requirements
 Performance requirements
 Quality requirements
 Training requirements
 The requirements management plan describes
how project requirements will be analyzed,
documented, and managed.
 A requirements traceability matrix (RTM) is a
table that lists requirements, various attributes
of each requirement, and the status of the
requirements to ensure that all requirements are
addressed.
Requirement Name Category Source Status
No.

R32 Laptop Hardware Project Complete.

memory charter Laptops
and ordered
corporate meet
laptop requirement
specification by having
s 4GB
of memory.
 DEFINING SCOPE
 Good Scope definition is very important.
 It helps to improve the accuracy of time, cost and
resource estimates, it defines a baseline for
performance measurement and project control and it
aides in communicating clear work responsibilities.
 The main tools and techniques required to define
scope include expert judgment, product analysis,
alternatives identification, and facilitated workshops.
 The main outputs are:
 Project Scope Statement
 Project Document Updates.
 PROJECT CHARTER
 Project Title: Information Technology (IT)
Upgrade Project
 Project Start Date: March 4 Projected Finish Date:
December 4
 Key Schedule Milestones:
 Inventory update completed April 15
 Hardware and software acquired August 1
 Installation completed October 1
 Testing completed November 15
 Budget Information: Budgeted $1,000,000 for
hardware and software costs and $500,000
 for labor costs.
 Project Manager: Kim Nguyen, (310) 555 2784,
knguyen@[Link]
 Project Objectives: Upgrade hardware and software
for all employees (approximately 2,000) within nine
months based on new corporate standards. See attached
sheet describing the new standards. Upgrades may affect
servers, as well as associated network hardware and
software.
 Main Project Success Criteria: The hardware,
software, and network upgrades must meet
 all written specifications, be thoroughly tested, and be
completed in less than ten months.
 Employee work disruptions will be minimal.
 Approach:
 Update the information technology inventory database to
determine upgrade needs
 Develop detailed cost estimate for project and report to CIO
 Issue a request for quote to obtain hardware and software
 Use internal staff as much as possible for planning,
analysis, and installation
 The project scope statement should also reference
supporting documents, such as product
specifications that will affect what products are
produced or purchased, or corporate policies,
which might affect how products or services are
produced.
DIFFERENCE IN PROJECT SCOPE
STATEMENT
 Project Charter:Upgrades may affect servers . . . (listed
under Project Objectives)
 Project Scope Statement, Version 1:
 Servers: If additional servers are required to support this
project, theymust be compatible with existing servers. If it
is more economical to enhance existing servers, a detailed
description of enhancementsmust be submitted to
theCIOfor approval. See current server specifications
provided in Attachment 6. The CEOmust approve a
detailed plan describing the servers and their location at
least two weeks before installation.
 Project Scope Statement, Version 2:
 Servers: This project will require purchasing ten new
servers to support Web, network, database, application,
and printing functions. Virtualization will be used to
maximize efficiency. Detailed descriptions of the servers
are provided in a product brochure in Appendix 8 along
with a plan describing where they will be located.
 WORK BREAKDOWN STRUCTURE (WBS)
 Deliverable-oriented grouping of work involved in project that
defines total scope of project.
 The WBS represents a logical decomposition of the work to be
performed and focuses on how the product, service, or result is
naturally subdivided. It is an outline of what work is to be
performed.
 WBS is essential in Planning and executing the Project because it is
the foundation for developing the Project Schedules (PERT / and
GANNT chart) for identifying Milestones in the Scheduling and for
managing Costs.
 Outputs :

WBS, WBS dictionary , A scope Baseline, Project document updates

WORK PACKAGE
 It is a task at the lowest level of WBS.
 A work package also represents the level of work
that the project manager monitors and controls.
DELIVERABLES AND MILESTONES

• Deliverables
– Tangible, verifiable work products
– Reports, presentations, prototypes, etc.

• Milestones
– Significant events or achievements
– Acceptance of deliverables or phase completion
– Cruxes (Proof of Concepts)
– Quality control
– Keeps team focused
 EXAMPLE OF WBS: “HOLIDAY”

holiday

20
travel
documents booking household

passport tickets choose confirm

resort cat!

insurance
brochures

Cha
pter
5
Pla
nni
ng
 DEVELOPING THE WBS
• The WBS Should Be Deliverable-Oriented
– Ensure WBS allows for the delivery of all the
project’s deliverables as defined in project scope
• The Level of Detail Should Support Planning
and Control
• Developing the WBS Should Involve the
People Who Will Be Doing the Work
• Learning Cycles and Lessons Learned Can
Support the Development of a WBS
ESTIMATION TECHNIQUES - THE PROJECT MANAGEMENT
APPROACH
1. Top-Down
2. Bottom Up
• Top-Down Estimating
– Top and middle managers determine overall project schedule
and/or cost.
– Lower level managers are expected to breakdown schedule/budget
estimates into specific activities (WBS).
– Often couched in terms of what a project should cost and how long
it should take as decreed by a member of top management who
thinks those parameters are appropriate.
– May be a response to the business environment.
– May lead to a death march project.
 Bottom-Up Estimating
 Most common form of project estimation
 Schedules & budgets are constructed from the WBS
 Starts with people who will be doing the work
 Schedules & budgets are the aggregate of detailed activities &
costs
 THE DICTIONARY OF THE WBS

Companion document to the WBS that describes each WBS

element.
For each WBS element, the WBS dictionary includes a
statement of work, a list of associated activities, and a list of
milestones.

Other information can include the responsible organisation,

start and end dates,
Resources required,
An estimate of cost,
Charge number,
Contract information,
Quality requirements,
Technical references.

 WBS elements should be cross-referenced as appropriate.

 VERIFYING SCOPE
 Proper procedures must be developed for the scope
verification to meet unique project needs
 Scope Creep :
The tendency for project scope to keep getting bigger
and bigger.
 Projects fail due to Scope Problems such as scope
creep what went wrong at what time ?

It is important to verify the project scope throughout

the life of the project and develop a process for
controlling scope changes
Inputs : Project Management Plan (PMP),
Requirement Documentation, Requirement Traceability
Matrix and validated deliverables
Main tool : Inspection
 CONTROLLING SCOPE :
Goal :
 To control the factors that cause scope changes.
 Assure changes are processed according to procedures
developed as part of integrated change control
 Manage Changes when they occur.
Inputs : Project Management Plan (PMP), Requirement
Documentation, Requirement Traceability Matrix, Work
Performance data, Organizational processes and validated
deliverables
Main tool : Variance Analysis (Difference between
Planned and Actual Performance)
Outputs : Work Performance data, Organizational
processes assets updates, Change requests, Project
Management Plan (PMP) Updates and Project Document
updates.