Project Planning, Scope & Quality

Introduction

MGMT8310
Week 1

1
© D. Knight
 Agenda
•Course Overview
•Introduction to scope and quality
management

2
© D. Knight
 Course Units
•Overview of Project Management
•Project Planning
•Scope Planning
•Scope Management
•Quality Planning
•Quality Management

3
© D. Knight
 Resources

Required (eText)
Kerzner, Harold, Project Management: A Systems
Approach to Planning, Scheduling and Controlling
(12th edition), Wiley Publishing

Find it in eConestoga

4
© D. Knight
 Evaluation

Graded Exercises 20%

(individual)
Mid-term Exam 40%

Final Exam 40%

5
© D. Knight
 What is a Project?

• A project – “a temporary endeavor undertaken to

create a unique product, service, or result”*

• Operations – work done to sustain the business

• Projects end when their objectives have been reached,

or the project has been terminated
Source: A Guide to the Project Management Body Of Knowledge (PMBOK® Guide), Sixth Edition, by Project Management Institute

© D. Knight
6
 Project Attributes
• A project:
• Unique purpose
• Temporary
• Developed using progressive elaboration or in iterative
fashion
• Requires resources, often from various areas of
organization
• Should have a primary customer or sponsor
• Project sponsor provides the direction and funding for the
project
• Involves uncertainty

7
© D. Knight
 Examples of Projects
• A young couple hires a firm to design and build them a new
house
• A retail store manager works with employees to display a new
clothing line
• A college campus upgrades its technology infrastructure to
provide wireless Internet access
• A group of musicians starts a company to help children develop
their musical talents
• A pharmaceutical company launches a new drug
• A television network develops a system to allow viewers to vote
for contestants and provide other feedback on programs

8
© D. Knight
 Project Lifecycle

© D. Knight
9
 10
© D. Knight
 Knowledge Areas

Source: A Guide to the Project Management Body Of Knowledge (PMBOK® Guide), Sixth Edition, by Project Management Institute 11
© D. Knight
 Project Processes

12
© D. Knight
 Link between the 3

13
© D. Knight Source: A Guide to the Project Management Body Of Knowledge (PMBOK® Guide), Sixth Edition, by Project Management Institute
 Planning Basics

• Goal of planning – implement plans

• Improved planning = better execution
• Organized planning improves effectiveness of planning
• Environment around project not perfect
• Flexible approach to planning
• Deal with planning obstacles methodically

Good planning separates a good PM from a bad PM

14
© D. Knight
 Planning – Define Objectives
• Cultivate project ideas into objectives
• Typical problems:
– Lack of agreement among stakeholders on
goals/objectives
– objectives too rigid to accommodate changing priorities
– insufficient time to define objectives
– not quantified well
– not documented well
– client and project team efforts not coordinated
– high personnel turnover

15
© D. Knight
 Project Management Plan
• Coordinates project planning documents
– Formal
– Approved
– Summary or detailed, simple or complex

• Guides execution, monitoring and control

- Facilitates communication among stakeholders
- Provides baseline
- Subsidiary plans

16
© D. Knight
 Scope & Quality
• What is Project Scope Management?

Answer: Defining and controlling the

work/deliverables included (and not included) in the
project

• What is Project Quality Management?

Answer: Ensuring that the project deliverable will

satisfy the customers’ stated and implied needs
17
© D. Knight
 Project Priorities,
Project Planning &
Project Requirements
MGMT8310
Week 2

© D. Knight
18
 Agenda

• Defining project scope

• Project Priorities
• Requirements management
• Requirements Management
Plan
• Scope Management Plan

© D. Knight
19
 Defining Project Scope

Step 4:
Step 5:
Step1: Step 3: Create
Step 2: Implement
Establish Create Work
Elicit project Change
Project Scope Breakdown
requirements Control
Priorities Statement Structure
Process
(WBS)

20
© D. Knight
 Causes of Project Trade-offs
• Shifts in the relative importance of criterions
related
to cost, time, and project performance
parameters
Establish • Budget – Cost
• Schedule – Time
Project • Performance – Scope

Priorities • PM meets with sponsor to determine project

priorities (scope, time or cost) as planning
begins.
• Important information if plans must be
adjusted during project execution
• e.g. we fall behind schedule; what do we
do – reduce scope, increase the budget,
or extend the schedule?

© D. Knight
21
 How can we adjust the scope, schedule or budget
parameters for the project?
• Constrain: no change
• parameter is fixed and cannot be changed
• Accept: reducing (or not meeting) a parameter.
Establish • meaning scope, time or cost can be changed in a
negative way from the project sponsor's point of
Project view (i.e. scope reduced, schedule extended, or
budget increased)
Priorities • Enhance: optimizing a criterion over others.
• if any change is made it should be improved from
the project sponsor's point of view (i.e. scope
increased, schedule shortened, or budget
decreased); enhance is the opposite of accept.
• Best approach is to determine which parameter is
constrained (fixed). Then determine which parameter
can is accept (can be reduced).

22
© D. Knight
 Scope Management Plan
Guidelines on how scope will be managed throughout
the project
• Scope statement to be used and who signs off.
• Work Breakdown Structure (WBS) to be used.
• WBS Dictionary to be used.
• Are there template documents or documents from a
similar project that can be used?
• Change Management process to be implemented.
• How will the deliverables by verified and which
stakeholder(s) will accept them.
• How will scope be controlled throughout the project?
• Roles and responsibilities for scope management.

23
© D. Knight
 Requirements Management Plan
• Describes how requirements will be
collected, analyzed, documented,
and managed throughout the
project.
• How requirements will be controlled
and changed if necessary.
• How requirements will be
prioritized.
• Product metrics to be used.
• Requirements Traceability Matrix to
be used.
• Roles and responsibilities in
requirements management.

24
© D. Knight
 Requirements Management
• Define & document stakeholders’ needs – stated and
unstated (a.k.a. explicit and implicit).
• A requirement can be defined as a capability that is
required in a product, service or result to satisfy
stakeholders’ needs
• The project team elicits, analyzes and records those
requirements.
• Requirements should be measurable during project
execution. The project team reports on progress.
• Foundation for the Scope Statement and Work
Breakdown Structure (WBS).
© D. Knight
25
 Requirements Management

Stakeholders may have

thought very little or very
Determining what much about what they want.
stakeholders want. Often the amount of thought
depends on the importance
or priority of the project.
Two things make the
requirements
process challenging.
Often the sponsor or other
Time available to the stakeholders pressure the
project manager/team to get
project team through planning and start
project execution.

26
© D. Knight
 Common Techniques to Elicit
Requirements

Interviewing Workshops, Questionnaires Observation Process

stakeholders and Facilitated Group and Surveys diagraming
experts Meetings

Prototypes

© D. Knight
27
 Collecting Requirements

28
© D. Knight
 Types of Requirements
Business Technical
Requirements Requirements

Describes ‘what’ Describes ‘how’

What the Define solutions for

organization will be how each project
able to do after need will be
project is complete satisfied

Directly linked to at
Changes in
least one business
capabilities
requirement

Source: https://www.pmi.org/learning/library/clear-project-requirements-joint-application-design- 29
© D. Knight 6928#:~:text=At%20the%20highest%20level%2C%20every,once%20the%20project%20is%20completed.
 Requirements Traceability Matrix

• Links requirements to their origin

• Ensures relevancy – business value = project
objectives
• Follows or traces requirements during project
• Links requirements to:
– business needs
– project objectives
– WBS
– Product development & design
– Test strategy & scenarios
30
© D. Knight
 Sample Requirements Traceability Matrix

Example - Requirements Traceabilty Matrix

Purpose:
Project Name
Prepared by: Date:

Requirement Name Category Source Implementation and Status Verification

No.

31
© D. Knight
 Defining Scope – MGMT8310

The Scope Statement Week 3

© D. Knight

32
 Define Scope
• Defining scope starts the development of the project
plan.
• Scope sets the stage to develop the project plan.
• Scope defines the project’s mission or goals
• Clearly defines the deliverables for the stakeholders
(end users)
• Scope definition brings focus for the project team
throughout the project

© D. Knight

33
 Define Scope
• Project manager ensures agreement with stakeholders on:
– Project objectives/deliverables
– Technical and business requirements

© D. Knight

34
 Competing Views of Project Scope
• Often stakeholders will have different views on what
project scope should be
• The project manager must work with the project sponsor
and key stakeholders to develop a common and agreed
upon product and project scope
• This work occurs during the requirements process and
development of a scope statement

© D. Knight
35
 Scope Checklist
Think of the scope checklist as a working copy of the Scope Statement.
The project team creating the scope statement uses it to collect information
(e.g. meeting with stakeholders)
1. Project objective
2. Deliverables
3. Milestones
4. Technical requirements
5. Limits and exclusions
6. Reviews with customer

© D. Knight

36
 Scope Statement
Scope Checklist is used to develop the Scope Statement.
Contents of the Scope Statement:
Product/service scope description
• Brief description (2-3 sentences)
•Deliverables (in scope) )

• Key deliverables
• Summary of the requirements
• Includes project management
• 2-3 sentences per deliverable
• Typical SS has 4-5 deliverables
•Exclusions (out of scope)
• Things that were discussed but didn’t become part of the project
• Brief 1-2 sentence description for each

© D. Knight

37
 Scope Statement
•Acceptance criteria
• What constitutes a finished product/service or how do we know the project is
complete
•Constraints
• Limits to the project (e.g. deadlines, resource availability
•Assumptions
• Things assumed to be true which affects how the project will run (e.g. assume that
the competition will not have a similar product)

© D. Knight

38
 Scope Statement
• Scope Statement is signed by the key stakeholder(s).
• It represents the agreed upon definition of the project scope.
• Often, until the scope statement is signed, there are competing visions of
the project among stakeholders.

© D. Knight

39
 Work Breakdown Structure

MGMT8310
Week 4

40
© D. Knight
 Creating the Work Breakdown Structure
• Project deliverables-oriented grouping of work.
• Defines the total scope of the project.
• Breaks all the work required for project into discrete
pieces of work & groups them into a logical hierarchy.
• Shows work that the project manager will manage.
– If it’s not on the WBS, the PM isn’t responsible for it.
• Two different forms:
– Chart
– Tabular or table – most commonly used as it’s easier to
work with

41
© D. Knight
 Le ve l
1 Construct a House
2 1.0 I nte rna l
3 1.1 El e ctri ci ty
4
4
4
3
1.1.1
1.1.2
1.1.3
1.2
El e ctri ca l s tructure
El e ctri ca l bui l d
HVAC e qui pme nt
Pl umbi ng
WBS
(Tabular Form)
4 1.2.1 Pl umbi ng s tructure
4 1.2.2 Pl umbi ng fi xture s & tri m
4 1.2.3 Te s ti ng & Cl e a ni ng
2 2.0 Founda ti on
3 2.1 Exca va ti on
4 2.1.1 Concre te
4 2.1.2 Forms
3 2.2 Ste e l As s e mbl y
4 2.2.1 Col umns
4 2.2.2 Be a ms
4 2.2.3 Joi s ts
2 3.0 Exte rna l
3 3.1 Ma s onry Work
4 3.1.1 Ma s onry founda ti on
4 3.1.2 Roof dra i ns
4 3.1.3 Ti l e s - toi l e ts
4 3.1.4 Roofi ng
3 3.2 Bui l di ng Fi ni s he s
4 3.2.1 Wa l l pa i nt
4 3.2.2 Ce i l i ng ti l e s
4 3.2.3 Wa l l pa pe r
4 3.2.4 Ca rpe ts
4 3.2.5 Ha rdwa re
2 4.0 Proje ct Ma na ge me nt
3 4.1 I ni ti a ti on
4 4.1.1 Proje ct Cha rte r
4 4.1.2 Sta ke hol de r Ana l ys i s
4 4.1.3 Ki ckoff Me e ti ng Source: https://www.workbreakdownstructure.com/work-breakdown-
3 4.2 Pl a nni ng structure-examples#list-home
4 4.2.1 Proje ct Pl a ns
3 4.3 Exe cuti on
4 4.3.1 Re s ource Ma na ge me nt
4 4.3.2 Qua l i ty Ma na ge me nt
3 4.4 Cl os i ng
4 4.4.1 Le s s ons Le a rne d
4 4.4.2 Cl os e -out me e ti ng 42
© D. Knight
3 4.5 Moni tori ng & Control l i ng
4 4.5.1 Sta tus Re ports
4 4.5.2 I s s ue Log
 WBS (Chart Form)
Level 1

Level 2

Level
3

Source: https://www.workbreakdownstructure.com/work-breakdown-
structure-examples#list-home

43
© D. Knight
 WBS
• Level 1 is the name of the project.
• Level 2 reflects the deliverables listed in the Scope
Statement (recommended practice).
• Lowest level are called work packages.
• WBS element refers to all work items grouped under a
deliverable.

44
© D. Knight
 Approaches to Develop the WBS

 Guidelines: Some organizations provide guidelines

to prepare WBS
 Analogy approach: Review WBSs of similar projects
& tailor it to your project
 Top-down approach: Start with the largest items of
the project & break them down
 Bottom-up approach: Start with the specific tasks &
roll them up – brainstorm tasks

45
© D. Knight
 Creating a Good WBS
• Difficult to create a good WBS
• Project manager and the project team must decide as a
group how to organize the work and how many levels to
include in the WBS
– Rules such as the 10/100 rule can help (i.e. a work package
should be between 10 and 100 hours of effort)
• People confuse work items on a WBS with specifications or
think WBS lists sequential steps
• The WBS is a ‘foundational document’ for the project
– Has all project work
– Serves as an input to planning other project areas (e.g. cost,
schedule)

46
© D. Knight
 WBS Dictionary

• Describes each WBS item in detail

• Format varies based on project needs.
• just a short paragraph describing each work package
• complex project, an entire page or more might be
needed for the work-package descriptions
• might describe the responsible person or organization,
resource requirements, estimated costs, and other
information

47
© D. Knight
 Sample WBS Dictionary Entry
Project Title: Just-In-Time Training Project
WBS Item Number:3.1.1.1.2
WBS Item Name: Administer survey
Description: The purpose of the survey for the supplier management training is to
determine the learning objectives for the executive, introductory, and advanced supplier
management courses (see WBS item 3.1.1.1.1 for additional information on the survey
itself). The survey will be administered online using the standard corporate survey
software. After the project steering committee approves the survey, the IT department will
send it to all employees of grade level 52 or higher in the purchasing, accounting,
engineering, information technology, sales, marketing, manufacturing, and human
resource departments. The project champion, Mike Sundby, VP of Human Resources, will
write an introductory paragraph for the survey. Department heads will mention the
importance of responding to this survey in their department meetings and will send an e-
mail to all affected employees to encourage their inputs. If the response rate is less than
30% one week after the survey is sent out, additional work may be required.

48
© D. Knight
 Scope Baseline
Consists of 3 documents:
• Approved project scope statement
• Work Breakdown Structure
• WBS dictionary

• PM manages the project to the baseline

• Performance in meeting project scope goals based on
scope baseline
• After the baseline is established, scope changes must go
through the change control process.

49
© D. Knight
Change Control

MGMT8310
Week 5
 Ensure
changes
within
Determine
how to
Consistent
approach
Change
scope &
beneficial
implement
the change
for all
changes
Management
to the
project - Purpose

51
© D. Knight
 Guides project W
h
team on how a
t
scope will be ’
s
controlled t
h
e
p
r
o
c
Change
How will
e
s
s
Management
request for
project
r
e
q
Plan
changes be u
e
handled s
t
o
r
s
m
u
s
t
f
o 52
© D. Knight l
l
 May be necessary for
product/business

Unforeseen requirements which

were not initially planned for.

May also impact budget & Scope

schedule.
Changes
WBS,
May require
Scope
revisions to
Statement

Communicate changes
53
© D. Knight
 Change Control Board (CCB)

Approves or rejects change requests

Reviews change requests:

• Impact on scope (also time, cost, risk, quality,

etc.)

Not all projects have formal CCB

54
© D. Knight
 Project Manager

Receives & log change requests

Preliminary analysis – impact on project Roles &

constraints
Responsibilities
Work with change requestors – clarifications,
issues or concerns

Documentation revisions/edits for approved

changes

Approve changes within PM’s authority

Participate on Change Control Board

55
© D. Knight
 01 02
03

Project Team/ Project Manager & Chair CCB,, Project

Stakeholders Team Sponsor, Project
• Address questions & Manager
• Submit change
requests on provide feedback • Approve changes –
standard forms scope, budget,
schedule
• Provide information
& details

Roles & Responsibilities

56
© D. Knight
 Scope Control

MGMT8310
Week 6

© D. Knight 57
 Agenda
• Scope control factors
• Scope Management success
factors

58
© D. Knight
 Scope Management Success Factors
Controlling and managing
scope throughout the project
will be facilitated by:
• Dedicated resources to
manage scope
• Clear and agreed to
requirements
• Communication and sign-off
of initial scope and any
changes

59
© D. Knight
 Effective Change Management
Consider the following when analyzing
requested scope changes:
• Stakeholders’ needs & added value resulting from a
scope change
• Market needs and the time required to make the change
• Financials – payback period, return on investment, net
present value, etc.
• Impact of the change of product lifecycle
• Competition’s ability to copy the change
• Product liability risk
• Impact to company’s reputation

60
© D. Knight
 Effective Change Management
Reasons to reject a change request:
• Excessive cost and may make negatively affect the
company’s competitiveness.
• Return on investment comes too late
• Tough competition
• Too many risks
• Technical complexity
• Legal & regulatory uncertainty
• Violates company policy (e.g. non-disclosure,
confidentiality)

61
© D. Knight