CS5363

Lecture 6:
Project Planning: Scope and Work
Breakdown Structure

Reference:
Jack T. Marchewka, Information Technology Project, Wiley
2015
Chapter 5 – Project Planning: Scope and the Work
Breakdown Structure

Introduction
• Scope
– Define the work boundaries and deliverables of the project
• Part of project work and not part of project work
• Work breakdown structure (WBS)
– Define project activities
• The next steps
– Estimate how long each activity will take
– Determine the overall project schedule and budget

2
 Triple Constraint
• Triple constraint
– Scope, Budget, and Schedule
– Fig. 5.1
– When is a project in balance for triple constraint?
– How does a project become imbalanced?
• What happens to a triple constraint if scope increases?
• If the budget is reduced?
• If the schedule is extended?

4
 Project Scope Management

• Project scope
– All activities and deliverables to achieve MOV
– Performed before scheduling and cost estimation
• Scope management process from PMBOK Guide
– Plan scope management
– Collect requirements
– Define scope
– Create WBS
– Validate scope
– Control scope

Plan Scope Management

• Plan scope management

– Define how the project/product scope is defined, verified,
and changed if necessary

6
 Collect Requirements
• Collect Requirements
– Engage customers or users to define their needs
– Some common methods
• Interviews
• Workshops
• Brainstorming sessions
• Focus groups
• Surveys
• Observing people while they work

Defining Project Scope

• Define scope
– The scope boundary
• Establishing what is and what is not part of the project
– Project sponsor’s needs and expectations

8
 Defining Project Scope
– Project scope defined as statement of work (SOW)
• A description of a product, service, or system
– Should be defined in terms of deliverables
• Deliverables
– A tangible and verifiable work product
– Project-oriented vs product-oriented deliverables

Defining Project Scope

– Project-oriented deliverables (scope)
• Provide evidence of project progress
• Business case, project charter, project plan (PLC)
• Current systems study, requirements definition, design
document (SDLC)
• Deliverable structure chart (DSC) (e.g., Fig. 5.4)
– Shows deliverables of PLC and SDLC

10
11

Defining Project Scope

– Product-oriented deliverables (scope)
• Identify the features and functionality of the product or
system
• Defined using a use case diagram (e.g., Fig. 5.5)
– Actor, use cases, system boundary

12
 Use Case Modeling
• Use Case modeling
– Specify user’s requirements
– Define system functional requirements in terms of
Actors and Use cases

Use Case

Actor

13

Actors

• Actors are external to system

• Actors interact directly with system
• An actor could be:
– Human user
– External system
– Input device (sensor)
– Timer
• System - System makes decisions and not Actor

14
 Use Cases

• Use case
– Describes a complete sequence of interactions between the
actor and system
– Starts with input from an actor
– Use case name: Should describe an action, e.g., Validate
PIN

15

Figure 6.8 Online Shopping System

Actor and Use Cases

Browse Catalog

Make Order
Request

Customer

View
Order Status

CS5373

16
 Documenting Use Cases
• Name
• Summary - Short description of the use case
• Dependency (on other use cases)
• Actors – primary, secondary
• Precondition(s)
– Condition that exists before the use case executes
• Description of the main sequence
– Most common sequence
• Description of alternative sequences
– Deviations from the main sequence
• E.g., for error handling
– Identify step # where deviation starts
• Postcondition
– Condition that is true at the end of the use case

17

Make Order Request use case description

Use case name: Make Order Request
Summary: Customer enters an order request to purchase catalog items. The customer’s
credit card is checked for validity and sufficient credit to pay for the requested catalog
items.
Actor: Customer, Bank
Precondition: Customer has selected one or more catalog items
Main sequence:
1. Customer provides order request and customer account Id to pay for purchase.
2. System retrieves customer account information, including the customer’s credit
card details.
3. System requests to a bank checking the customer’s credit card for the purchase
amount and, if approved, creates a credit card purchase authorization number.
4. System creates a delivery order containing order details, customer Id, and credit
card authorization number.
5. System confirms approval of purchase and displays order information to customer.
6. System sends email confirmation to customer.

18
 Make Order Request use case description
Alternative sequences:
Step 2: If customer does not have an account, the system prompts the
customer to provide information in order to create a new account. The
customer can either enter the account information or cancel the order.
Step 3: If authorization of the customer’s credit card is denied (e.g., invalid
credit card or insufficient funds in the customer’s credit card account), the
system prompts the customer to enter a different credit card number. The
customer can either enter a different credit card number or cancel the order.
Postcondition: Customer has purchased items.

19

20
 Validate Scope
• Validate scope
– Project scope validated and formally accepted by sponsor and
stakeholders
– Verification of MOV
• Check if it is clearly defined and agreed
– Documentation of all deliverables
• Check if deliverables support the MOV
– Specification of quality standards
– Identification of milestones (Next slide)
– Review and acceptance by stakeholders

21

Milestones

• Milestone
– A significant event or achievement providing evidence
• A deliverable completed
• A phase is formally over
– Are deliverable and milestones the same?
• Closely related but not the same
– Reduce risk associated with a project
• Provide an opportunity to review the progress of the
project
– Provide a mechanism for quality control

22
 Control Scope
• Control scope
– Manage changes to the project scope
– Reasons to change
• Scope grope
– A project team’s inability to define the project scope
– Team and sponsor not understood what to do
• Scope creep
– Increase features or functions from the project sponsor
– Interesting or novel ideas from the project team itself
• Scope leap
– Fundamental and significant change in project scope
– Occur as changes in the business industry and competitive product

23

Control Scope
– Scope change control procedures
• Scope change request form
– Description of change request
– Justification
– Alternatives with impact on scope, schedule,
resources, and cost

24
25

The Work Breakdown Structure (WBS)

• WBS
– Define the activities or tasks for deliverable requirements
– Links the project scope to the schedule and budget
– Total scope of the project
• Divided into specific deliverables
• Work Packages
– Manageable units of work
• Decomposed from a project
– Defined with Project, Phase, Deliverable, and Milestone (Fig.
5.8)

26
27

Developing WBS
• Require several versions to include all work activities
• E.g., Web-based banking project (Fig. 5.9)
• Guidelines for WBS
– WBS supporting the project MOV
– Deliverable-oriented WBS
– The level of detail supporting planning and control
• Budget/schedule and progress measurement
– Involve the people who will be doing the work

28
29

Project Estimation
• Estimate each activity’s duration
– To develop a project schedule and budget
– Guesstimating, Delphi Technique, Time boxing, Top-down
estimating, bottom-up estimating, poker planning

• Guesstimating
– Estimation by guessing or just picking numbers out of the air
– Quick and easy, but no hard evidence

30
 Project Estimation
• Delphi Technique
– Involves multiple experts who arrive at a consensus on a
subject or issue
– If the estimates are reasonably close, they can be averaged
• Otherwise, be back to experts to discuss the differences
and make another estimate
– Take longer and cost more than most estimation methods

31

Project Estimation
• Time boxing
– Often used on Agile projects
• A box of time allocated for a sprint (iteration)
– A work stops at the end of a box of time
• Regardless of whether the work is complete

• Top-down estimating
– A common occurrence that results from a mandate
• Made by upper management
– Could be a reaction to the business environment

32
 • Bottom-up estimating
− Divide the project into smaller modules and then directly
estimate time and effort
• In terms of person-hours, person-weeks, or person-
months
− Most real-world estimating (E.g., Table)

33

Project Estimation
• Poker Planning
– A variation of Delphi technique
– A moderator answers any questions that estimator may have
– Estimated by multiple estimators (e.g., team members)
– Adjust the differences between estimators

34