Defining and Managing Project
Scope
Project Planning Framework
MOV
Scope
Sequence
Phases
Schedule
Tasks
Resources
Time
Estimates
Budget
Scope Management Processes

Scope Planning


Scope Definition


The decomposition or dividing of the major project deliverables (i.e., scope) into smaller
and more manageable components
Scope Verification


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 (More detail in Chapter 6)


The development of a scope management plan that defines the project’s scope and how it
will be verified and controlled throughout the project
Confirmation and formal acceptance that the project’s scope is accurate, complete, and
supports the project’s MOV (Measurable organizational values)
Scope Control

Ensuring that controls are in place to manage proposed scope changes once the project’s
scope is set. Must be communicated to all project stakeholders.
Scope Management Plan
Scope
Planning
Documents how
the team will
define and
develop the
project’s scope
and WBS, as well
as processes for
verifying and
controlling the
project and
product
deliverables.
Scope
Management
Plan
Scope
Definition
Create
WBS
Scope
Verification
Builds upon the
preliminary
project scope
statement to
define all the
project and
product
deliverables,
including the
processes and
criteria for
acceptance.
A project
planning tool
that that
decomposes or
subdivides and
organizes the
project’s scope
into a
deliverableorientated
hierarchy.
A formalized
acceptance from
the appropriate
stakeholders
that the defined
project scope is
complete
Detailed
Project
Scope
Work
Breakdown
Structure
Scope
Verification
Checklist
Scope
Control
A defined
process for
managing
changes to
project and
product scope
and the impact
of those changes
to the project’s
schedule and
budget.
Scope
Change
Control
Process
Scope Planning
Initiating process to begin defining and documenting the project work
(i.e., deliverables) needed to achieve the project’s MOV(Measurable
organizational values)
Extra work that will not help the project achieve its MOV (Measurable
organizational values) will only needlessly increase the project’s schedule
and budget
 This process begins at a high level and will become more detailed as
the project progresses and more information becomes available
 Attempts to answer the question: What is and what is not to be
delivered by this project?
 Makes the project sponsor’s needs and expectations explicit
 Tools:
 Scope Boundary
 Scope Statement
Scope Boundary
Work within the Scope Boundary
Must Support the
Project’s MOV
Work Outside of the Project Scope
Scope Statement
1.
2.
3.
Develop a proactive electronic commerce strategy that identifies
the processes, products and services to be delivered through the
World Wide Web.
Develop an application system that supports all of the processes,
products, and services identified in the electronic commerce
strategy.
The application system must integrate with the bank’s existing
enterprise resource planning system.
Out of Scope
1.
2.
Technology and organizational assessment of the current
environment
Customer resource management and data mining
components
Project Scope Definition



The scope boundary and scope statement provide a
useful first step
The project’s scope must now be defined in more
detail in terms of specific deliverables that provide a
basis for developing the project’s work breakdown
structure (WBS)
Tools:




Deliverable Definition Table
Deliverable Structure Chart
Context Level Data Flow Diagram
Use Case Diagram
Scope

Project-Oriented Deliverables


Support the project management and IT development
processes defined in the Information Technology Project
Methodology (ITPM).
Tools



Deliverable Definition Table (DDT)
Deliverable Structure Chart (DSC)
Product-Oriented Deliverables



Specific features and functionality of the application system
First cut of requirements definition
Tools


Context Dataflow Diagram (DFD)
Use Case Diagram (UCD)
Deliverable Definition Table (DDT)
Deliverable
Structure
Standards
Approval
Needed
By
Resources
Required
Business Case
Document
As defined in
the
Project
Methodology
Project
Sponsor
Business Case
Team, & office
automation (OA)
tools
Project Charter &
Project Plan
Document
As defined in
the
Project
Methodology
Project
Sponsor
Project manager,
project sponsor
& OA tools
Current
Study
Document
As defined in
the
Project
Methodology
Project
Manager &
Project
Sponsor
Systems
analysts users,
case tool and
OA tools
System
Deliverable
Structure
Chart
Initialize & Conceptualize
Business Case
Analysis
Strategic EC Plan
Systems Proposal
Electronic
Commerce
Banking Project
Project Charter & Plan
Project Charter & Project Plan
Design
Logical Design
Technical Design
Execute & Control
Construction
EC Application System
Close Project
Final Project Report
Formal Acceptance
Testing
Test Plan
Test Results
Evaluate Project Success
Project Evaluations
Lessons Learned
Implementation
Documentation
Training Program
Conversion Plan
Context Data Flow Diagram
Account Balance Info
Account Balance Request
Product/Service Request
Customer
ber
m
u
tN
n
u
o
Acc
Info
n
o
i
sact
n
a
r
T
Cus
tom
er I
nfo
Product
&
Service
Info
Fund Transfer Request
Fund Transfer Confirmation
0
E-Commerce
Banking
System
Promotion Info
Usage
Reports
Senior
Management
ERP
System
Account Info
Transaction Confirmation
EC Banking System
Check Balances
View Transaction
Histories
Get Account Info
View Check Images
Order Checks
Update Account
Balances
ERP System
Pay Bills
Customer
Transfer Funds
Print Reports
Change Address
Manager
Apply for Loans
Check Interest
Rates
Find Product/
Service Info.
Get Branch Info.
Look up ATM Locati
ons
Use Case
Diagram
Project Scope Verification

MOV


Has the project’s MOV been clearly defined and agreed upon?
Deliverables


Are the deliverables tangible and verifiable?
Do they support the project’s MOV?
Quality Standards
 Milestones



Significant events that mark the acceptance of a deliverable
Review and Acceptance

Formal Signoff
Scope Change Control


Concerned with managing changes to the project’s scope
and to ensure that these changes are beneficial when they
occur
Mitigates:




Scope Grope
Scope Creep
Scope Leap
Tools/Procedures:


Scope Change Request Form
Scope Change Request Log
Scope
Schedule
Budget
Scope Change Request Form
Requestor Name: _______________
Request Title: __________________
Request Description:
Request Date: __________
Request Number: _______
Justification:
Possible Alternatives:
Impacts
Scope
Schedule
Resources Required
Cost
Recommendation:
Authorized By:
Date:
Alternative 1
Alternative 2
Alternative 3
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)
Benefits of Scope Control

Keeps the project manager in control of the project.


Authorized changes to the project’s scope are reflected in
changes to the project’s schedule and budget.
Allows the project team to stay focused and on track

They do not have to perform unnecessary work.
Use Case Modeling
UML Background



Unified Modeling Language
Collection of 9 Object-Oriented Modeling Tools (one of
which is use case diagrams)
Attempt to unify modeling of systems processes and data
A definition of Use Case
(Ivar Jacobson)

A behaviorally related sequence of
interactions performed by an actor
in a dialogue with the system to
provide some measurable value to
the actor.
Keywords in the definition




“Behaviorally related” – self contained unit that is an
end in itself, with no intervening time delays.
“Actor” must initiate the Use Case, and see it
through completion.
“Measurable value” – the Use Case MUST achieve
some business goal.
Use Cases are goal oriented (the what, not the how),
and cannot be half-done.
Use Case Modeling


Use case modeling is the
process of modeling a system’s
functions in terms of business
events, who initiated the events,
and how the system responds
to the events.
Useful for eliciting
requirements and
understanding how users
interact with the system.
Triggers
Actor
Use Case
Typical questions to find actors





Who/what will be interested in the system?
Who/what will want to change data in the
system?
Who/what will want to interface with the
system?
Who/what will want information from the
system?
Actors can include external databases, time,
employees, or any external entity that interacts
with your system
Rules for Use Cases


Use cases must be simple and easy to read
If a use case threatens to become too complicated,
consider breaking it up into different use cases.
Use Case Conventions
Triggers
Actor
Use Case
The relationship
between an actor and a
use case is said to be a
“communication
relationship”. Other
possibilities: verifies,
designs, tests,
implements
Relationships between use
cases


<<extends>> Adds
steps to an existing use
case. Is optional, unless
directly initiated by an
actor
<<includes>> The first
use case needs
information from
another use case to
complete its function. Is
always completed
Receives Bill
Bill Student
«uses»
Bursar’s
Office
Student
Registers for Class
«extends»
Registers for
Special Class
Approves
Faculty
Use Case Modeling Benefits





As a basis to help identify objects and their high-level
relationships and responsibilities.
A view of system behavior from an external person’s
(user’s) viewpoint.
An effective tool for validating requirements.
An effective communication tool.
As a basis for a user’s manual.
Scope Creep

All requirements originate with the events to be satisfied,
and the use cases that satisfy them. If it isn’t defined as an
event and satisfied by a use case, then it is a change
request that requires some form of change control
action.