Module 2

STARTING
THE PROJECT
• Determine Appropriate Project Methodology/
Methods and Practices
• Plan and Manage Scope
• Plan and Manage Schedule
• Plan and Manage Budget and Resources
• Plan and Manage Quality of Products and
Deliverables
• Integrate Project Planning Activities
• Plan and Manage Procurement
• Establish Project Governance
Structure
• Plan and Manage Project/Phase
Closure
 Contents

Module 1 Module 2 Module 3

Creating a High- Starting the Project Doing the Work
Performing Team

Module 4 Module 5
Keep the Team on Keeping the
Track Business in Mind

2
Plan and Manage Scope
TOPIC B

3
STARTING THE PROJECT > PLAN AND MANAGE SCOPE

Deliverables and Tools

Requirements Documentation Agile estimating

Work performance reports Product backlog
Requirements Traceability Matrix Change requests
Product backlog
Scope management plan and
Requirements management plan

4
 Cause of Project Failures

 Change in organization’s priorities (41%)

 Change in project objectives (38%)
 Inaccurate requirements gathering (37%)

Source :2017, PMI, Pulse of the Profession ®

Requirements / Scope definitions

Scope Creep

5
5
Product Requirements

DEFINITION
The agreed-upon conditions or capabilities of a
product, service, or outcome that the project is
designed to satisfy.

6
Project Requirements

DEFINITION
The actions, processes, or other conditions the
project needs to meet e.g. milestone dates,
contractual obligations, constraints, etc.

7
Project and
Product
Requirements
 High-level requirements might
be documented in the project
charter.
 Verify that all requirements are
determined and documented.
 Provide the foundation for
building the WBS.

8
Requirements Management Plan

DEFINITION
A component of the project or program
management plan that describes how
requirements will be analyzed, documented, and
managed.

9
Requirements
Management Plan
 Planning, tracking, and reporting
information for requirements activities.
 Configuration management activities:
- Version control rules
- Impact analysis
- Tracing, tracking, and reporting

 Required authorization levels for change

approval
 Prioritization criteria / process
 Product metrics and accompanying
rationale
 Traceability structure, including
requirement attributes

10
Product Scope

DEFINITION

The features and functions that characterize a

product, service, or result.

11
Project Scope

DEFINITION
The work performed to deliver a product, service,
or result with the specified features and
functions. “Project scope” may include product
scope.

12
Project and Product
Scope
 Predictive - The scope baseline for
the project is the approved version
of the project scope statement,
work breakdown structure (WBS),
and associated WBS dictionary.

 Agile - Backlogs (including product

requirements and user stories)
reflect current project needs.

 Measure completion of project

scope against the project
management plan.

 Measure completion of the product

scope against product
requirements.
13
EEFs and OPAs
 Projects exist and operate in
environments that may influence
them, favourably or unfavourably.

 EEFs and OPAs are two major

categories of project influences.

14
Scope Management Plan

DEFINITION
A component of the project or program
management plan that describes how the scope
will be defined, developed, monitored, controlled,
and validated.

15
Scope Management Plan

 Should include processes to prepare

a project scope statement

 Enables the creation of the WBS from

the detailed project scope statement

 Establishes how the scope baseline

will be approved and maintained

 Specifies how formal acceptance of

the completed project deliverables
will be obtained.

 Can be formal or informal, broadly

framed or highly detailed.

16
Scope Management Tools and Techniques

Expert judgment

Internal and external experts

Alternatives analysis

Used to evaluate identified options in order to select the options or

approaches to use to execute and perform the work of the project.

Meetings

Team members help create the scope management plan

17
How to gather requirements and
define scope?
Sources
Document analysis
Focus groups
Observations
Data representation
Surveys
Mind mapping
Benchmarking
Affinity diagrams
Interviews
Context diagrams
Facilitated workshops Decision making
Storyboarding
Prototyping Multicriteria analysis
 Voting
Autocratic

18
Document Analysis

DEFINITION

A technique used to gain project requirements

from current documentation evaluation.

19
Document Analysis
Derive new project requirements from
existing documents such as:

 Business plans
 Service agreements
 Marketing materials
 Current process diagrams
 Application software documentation

20
Focus Groups

DEFINITION
An elicitation technique that brings together
prequalified stakeholders and subject matter
experts to learn about their expectations and
attitudes about a proposed product, service, or
result.

21
Focus Groups
 Loosely structured, information-sharing
sessions

 Moderator-guided, interactive

 Includes stakeholders and SMEs

 Qualitative research

22
Observations

DEFINITION
A technique used to gain knowledge of a specific
job role, task, or function in order to understand
and determine project requirements.

23
Questionnaires and Surveys

DEFINITION

Written format of questions designed to quickly

capture information from many respondents.

24
Questionnaires
and Surveys

Often used data

gathering technique:
• With varied audiences
• When a quick
turnaround is needed
• When respondents are
geographically
dispersed
• Where statistical
analysis could be
appropriate.
25
Benchmarking

DEFINITION
The comparison of actual or planned products,
processes, and practices to those of comparable
organizations to identify best practices, generate
ideas for improvement, and provide a basis for
measuring performance.

26
Benchmarking
 Evaluates and compares a
business’ or project’s practices
with others.

 Identifies best practices in order

to meet or exceed them.

27
Benchmark (Example)

Web

Telecom
75
Bugs per
KLOC
Military

50
Commercial

25

Project Type
28
Interviews

DEFINITION
A formal or informal approach to elicit
information from stakeholders by talking with
them directly.

29
Interviews

 Helps to identify a stakeholder's

requirements, goals, or expectations
for a project.

 Use to identify/define features and

functions of desired project’s
deliverables.

30
Facilitated Workshops

DEFINITION
Organized working sessions led by qualified
facilitators to determine project requirements
and to get all stakeholders together to agree on
project outcomes.

31
Data Representation
Tailor to project context and decision-
making criteria.

 Mind Mapping – Consolidate ideas

created through individual brainstorming
sessions into a single map to reflect
commonality and differences in
understanding and to generate new ideas

 Affinity Diagram – Allows large numbers

of ideas to be classified into groups for
review and analysis

32
Data Representation
Affinity Diagram
Mind Mapping

33
Context Diagrams

DEFINITION
Visual depiction of product scope, showing a
business system (process, equipment, computer
system, etc.) and how people and other systems
interact with it.

34
 Context Diagrams
Business Context Diagram Sample

Government Private Sector

Request for Request for

Funding Funding Funding Funding

Hardware, Software, and Educational

Support Services
User Community University Industry
Request for Hardware, Request for
Software, and Support Educational
Services

Request for
Educational
Educational
Services
Services

Education
Community

35
Storyboarding

DEFINITION

A prototyping method using visuals or images to

illustrate a process or represent a project
outcome.

36
Prototyping

Assists in the process of obtaining early

DEFINITION feedback on requirements by providing a
working model of the expected product before
building.

37
Group Decision-Making Techniques

Voting Autocratic decision Multicriteria decision

making analysis
Collective decision-making
and assessment One team member makes Method - Establish criteria
Determines several the decision for the group. in decision matrix e.g. risk
alternatives, with future levels, uncertainty, and
actions as the expected valuation
outcome Uses a systematic,
Use to generate, classify, analytical approach
and prioritize product Evaluate and rank many
requirements ideas

38
 Multi Criteria Decision Analysis
This technique utilizes a decision matrix to provide a systematic analytical
approach for establishing criteria, such as risk levels, uncertainty, and valuation,
to evaluate and rank many ideas

Total Benefit
Solution 1

Solution 2

Solution 3

Criteria Weights
39
Types of Voting
Unanimity
Everyone agrees on a single course of action.
Useful in project teams with great cohesion.
Example: Delphi technique

Majority
Decision reached with > 50% of group support
Tip: Create groups of an uneven number of
participants to ensure decisions are made and tie
votes avoided.

Plurality
Decision reached with largest block in a group
deciding, even if majority is not achieved.
Use this method when more than 2 options are
nominated.

Agile Methods
Thumbs up/down/sideways
Fist of Five

40
Requirements
Documentation
 Describes how individual requirements
meet project business need.
 Starts at a high level before providing
details.
 Requirements need to be unambiguous
(measurable and testable), traceable,
complete, consistent, and acceptable to
key stakeholders.
 Format can be simple (document listing
all requirements, categorized by
stakeholder and priority) or more
elaborate (executive summary, detailed
descriptions, attachments). Examples:
• Business Requirement Specification (BRS
• Product Requirement Document (PRD)
• System/Sub systems Specification (SSS)
• Functional Requirement Specification (FRS
• Operational Requirement Specification (OR
41
Types of Requirements
Business Stakeholder Transition and Readiness
Higher-level needs of the Stakeholder or Temporary capabilities
organization e.g. business issues or stakeholder group e.g. data conversion and training
opportunities, and reasons why a needs. Reporting requirements needed to transition from the
project has been undertaken. requirements. current as-is state to the desired future state.

Quality Project
Condition or criteria needed to validate the successful Actions, processes, or other conditions the
completion of a project deliverable or fulfilment of other project project needs to meet e.g. milestone dates,
requirements e.g. tests, certifications, validations. contractual obligations, constraints.

Solutions (Functional and Non-functional)

Describe features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder
requirements.
Functional requirements - Describe the behaviors of the product
e.g. actions, processes, data, and interactions that the product should execute.

Non-functional requirements - Supplement functional requirements to describe environmental conditions or qualities

required for the product to be effective
e.g. reliability, security, performance, safety, level of service, supportability, retention/purge, etc.

42
Nonfunctional Requirements
(Example)

Type Considerations
• How and when is the service available?
Availability • If the service were to become unavailable, how quickly can it
be restored to working?
• What level of service performance, speed, and throughput is
required?
Capacity
• Given the number of stakeholders using the service, is there
enough supply to meet demand?

• If there were a disaster of some kind, how quickly could the

Continuity
service be recovered to support operations.
• How well is the service and its information protected from
security risks and threats?
Security
• How do you guarantee the confidentiality, integrity, and
availability of the information?

43
High Quality Requirements

Clear and precise

Complete
Realistic
Measurable/Testable
Coherent/Consistent
Coordinated with
stakeholders
Prioritized

44
Tolerances
Tolerance levels enable you to effectively
manage an issue without needing to
escalate it every time.

Areas of tolerance might include:

 Budget
 Schedule
 Quality
 Accepted or baselined requirements,
including:
- Solution – functional/non-functional
- Business and Stakeholder
- Quality

45
Requirements Traceability Matrix

DEFINITION

Links product requirements from their origin to

the deliverables that satisfy them.

46
 Requirements Traceability Matrix
Example

ID Type Description Source Priority Owner Test

A01 Product/Functional No. of switch System Spec High Alex Factory
ports: 24 02/2021 inspection
2.0 report
A02 Product/Functional Signal latency: System Spec High Liat ATP
50 ms 02/2021 Document
3.5.1 01 5.3.2.1

It’s important to “close the loop” in advanced between

requirements and the way they are tested and validated!

47
GUIDELINES

Collecting Project Requirements

• Review:
– Scope management plan

– Requirements management plan

– Stakeholder engagement plan

– Project charter

– Stakeholder register

• Use tools and techniques such as interviews, focus groups, facilitated

workshops, group creativity techniques.

48
Project Scope Statement

DEFINITION

The description of the project scope, major

deliverables, assumptions, and constraints.

49
Project Scope Statement

50
Scope Tools and Techniques

Expert Judgment
Judgment provided by a group or
person, based upon expertise in an
application area, Knowledge Area,
discipline, industry, etc.

Product Analysis
Facilitation Defines products and services.
Includes asking questions about a
Effective guidance of a group to a product/service, forming answers
successful decision, solution, or to describe the use, characteristics,
conclusion. and other relevant aspects of what
is going to be delivered

Multi-criteria decision analysis Alternatives analysis

Technique of organizing decision Evaluation of choices available to
factors in a matrix to evaluate reach an objective.
options

51
Product Analysis

DEFINITION
A tool to define scope by asking questions about
a product and forming answers to describe the
use, characteristics, and other relevant aspects
of the product.

52
Product Analysis
Value Analysis
Systematic,
interdisciplinary
examination of factors
affecting the cost of a
Product Breakdown product or service
Splinter a product and its Requirements towards achieving the
work requirements into Analysis purpose at lowest cost
components to achieve a Process of and required standards of
clear understanding of identifying, validating, quality and reliability
work and documenting
specifications for
projects

Systems Analysis
Process of studying a
product /service to
identify its goals and
Value Engineering purposes and create
Structured technique Systems Engineering
systems / procedures
to optimize value in a Design, integration,
to achieve them
project and management of
efficiently
complex systems
over their life cycles

53
GUIDELINES

Develop a Project Scope Statement

• Review:
- Scope management plan (developing, monitoring, and controlling project
scope activities)
- Project charter (high-level project description and product characteristic
and project approval requirements)
• Requirements documentation
• OPAs – templates, processes, and procedures
• Use tools and techniques to define the project scope (expert judgment,
product analysis, alternatives generation, and facilitated workshops).
• Document the project scope statement and update project documents.

54
Work Breakdown Structure

DEFINITION
A hierarchical decomposition of a project’s total
scope of work to accomplish project objectives
and create the required deliverables.

55
Decomposition

DEFINITION
A technique of dividing and subdividing the
project scope and deliverables into smaller, more
manageable parts.

56
Decomposition - Example

57
Work Breakdown Structure

DMAIC
Project

1.0 2.0 3.0 4.0 5.0

Define Measure Analyze Improve Control

1.1 2.1 3.1 4.1 5.1

Work
Packages 1.2 2.2 3.2 4.2 5.2

1.3 2.3 3.3 4.3 5.3

58
Code of Accounts

DEFINITION Numbering system that uniquely identifies each

component of the WBS.

1.1.1
1.1
1.1.2
1
1.2 1.2.1
59
Work package

DEFINITION
The work defined at the lowest level of the WBS
for which cost and duration are estimated and
managed.

60
 WBS Tree
Build a house
Level 0
0.

Define Understand Find

Level 1 Plan Build Closure
requirements constraints professionals
1 2 3 4 5 6

Architectural Electricity Construction

Etc…..
Level 2 planning planning planning
4.1 4.2 4.3

Overall 1st floor 2nd floor

Level 3 planning planning planning
4.1.1 4.1.2 4.1.2.

1st floor Living room Study room TV room

Level 4 Kitchen layout
layout layout layout layout
4.1.2.1. 4.1.2.2 4.1.2.3 4.1.2.4 4.1.2.5

EXAMPLE

61
 WBS - Approaches

1. Process oriented

2. Modular oriented

3. Profession oriented

4. Business oriented

62
 Process Oriented WBS

Build a house

Define Understand Find relevant

Plan Build Closure
requirements constraints professionals

63
 Profession oriented WBS

Build a house

Architecture Plumbing Tiling Electricity Windows Etc…

64
 Modular oriented WBS

Build a house

Living Bath Bedroom Bedroom

Kitchen Basement Etc…
room room #1 #2

65
 Business oriented WBS

Build a house

1st floor 2nd floor Roof

Bathroom Bedroom #1

Living room Study room

Kitchen

66
Control
Accounts, Work
and Planning
Packages
Let’s explore the units of work
in a project WBS.

67
 WBS Terms
Project WBS: Covers all project scope and deliveries
(100% rule)

Control account (CA): Management control point

where scope, schedule and budget performance can
be measured and analyzed

Planning Package (PP) : A WBS component below

the control account with a known work but without
detailed breakdown

Work Package (WP) : The lowest level of the WBS.

Allows cost and duration estimation

Activities (Schedule planning)

68
Control Account

DEFINITION
A management control point where scope,
budget, actual cost, and schedule are integrated
and compared to earned value for performance
measurement.

69
Planning Package

DEFINITION
A WBS component below the control account
with known work content but without detailed
schedule activities.

70
Planning Work Using a WBS
1
 A control account has two or more Project
work packages. Name

 A planning package may or may not

be used. 1.1 2.1
Control Control
 Each work package is part of a single Account A Account B
control account.
1.2 1.3 2.2
 Identifiers provide a structure for
Planning Planning Planning
hierarchical summation of costs, Package A Package B Package
schedule, and resource information
and form a code of accounts.
1.2.1 1.2.2 2.2.1
Work Work Work
Package Package Package

Planning package
(optional layer) houses Lowest level - a work
work content, but no package with a unique
schedule or details. identifier; contains
detailed schedule and
cost information.

71
WBS Dictionary

DEFINITION
Provides detailed deliverable, activity, and
scheduling information about each component
in the WBS.

72
WBS Dictionary
Can include:

 Code of account identifier

 Description of work

 Assumptions and constraints

 Responsible organization

 Schedule milestones

 Associated schedule activities

 Resources required to complete

the work
 Cost estimations

 Quality requirements

 Acceptance criteria

 Technical references

 Agreement information

73
GUIDELINES

Create a WBS
• Review:
- Scope management plan
- Project scope statement
- Requirements documentation
• EEFs and OPAs
• Use tools and techniques e.g. decomposition
• Use expert judgment
• Include notes on work products that might be delivered incrementally
• Document the scope baseline

74
Scope Baseline

DEFINITION
Approved version of a scope statement, WBS,
and its associated WBS dictionary, that can be
changed using formal change control
procedures and is used as a basis for
comparison to actual results.

75
Scope Baseline
Components include:
Project scope statement
WBS
WBS dictionary

76
 Product Backlog

An ordered list of user centric requirements that a team

maintains for a product

• Simple and Precise

• Prioritized
• Definition of Done

77
Product and Iteration
Backlogs
Product backlogs A product backlog
 Change throughout the project. is a list of the
 Groom and refine the product expected work to
backlog continually; weekly or deliver the product.
monthly intervals are typical.
 Remove product backlog items
(PBIs) as work is completed.
- Edit and clarify PBIs as more
becomes known or as product
requirements change. Iteration backlogs include items
- Add PBIs when more work must from the product backlog that can
be done. conceivably be completed within
the time period based on the
team’s capacity.
Iteration backlog
 Teams must estimate effort and
understand business priorities.

78
Prioritization Techniques to
Determine Objectives
Use appropriate methods to learn the
order of work that needs to be done.

These can include:

 Review product backlog
 Kano Model
MoSCoW
must have
 MoSCoW (MSCW) Analysis
 Paired Comparison Analysis
 100 Points Method should have
could have
won’t have

79
Agile Scope Language
Example

80
Epic

DEFINITION

A very large collection of user stories. Epics can

be spread across many sprints.

81
Feature

DEFINITION

A set of related requirements that allows the

user to satisfy a business objective or need.

82
Working with
Features

 Scheduling aligned to features ensures

associated work is coordinated.

 Estimating features offers visibility to

when blocks of functionality can be
released to the business and end
users.

 Progress can be measured by drawing

a ratio of accepted to remaining
features.

83
User Stories

DEFINITION

Short descriptions of required functionality; told

from user’s point of view

Who What Why

As a <role> I can <capability>, so that <received benefit>

84
User Stories
 Help teams focus on that
value provided to the user.

 Suggest who will benefit from

the work and how.

 Driven by description instead

of technical specifications to
give holistic view

85
 Requirement’s Breakdown - Agile
Example

Order movie ticket

EPIC

Search for movie

Feature

Search by movie Search by Search by

name Cinema/Geography Janner/Rank
User story User Story User Story

1 2 3
86
 Story Mapping

High
A1 Then B1 Then C1
Priority Or

Or

Or
A2 B2 C2
Or

Or
A3 C3

Low

Or
Priority
87
Tools and Techniques for Verifying Scope

Tool and Technique Description

Checklist of required criteria for a deliverable to be considered ready for

Definition of Done
customer use.
Checklist for a user-centric requirement with all required information to
Definition of Ready
begin work.

Acceptance Criteria A set of conditions to meet before acceptance of deliverables.

Interval at or near the conclusion of a timeboxed iteration when the project

Iteration Reviews team shares and demonstrates the work produced during the iteration with
stakeholders.
A technique for determining the cause and degree of difference between
Variance Analysis
the baseline and actual performance.
An analytical technique that uses mathematical models to forecast future
Trend Analysis
outcomes based on historical results.

88
V model - Software Engineering
(Example)

‫תיקוף‬

‫אימות‬
 Summary - Practical Scope Artifacts
Requirement’s Traceability Matrix Scope Statement
Requirement’s Documents

Backlog
WBS + Dictionary Story Mapping
 End of
Module 2

E-mail: [email protected]

Office Phone: +972-52-7-33-77-77

91