3. 5.1 Plan Scope
Management
•creating a scope management
plan –how scope will be
defined, validated, and
controlled.
5.2 Collect Requirements
•determining, documenting, and
managing stakeholder needs and
requirements to meet project
objectives.
5.3 Define Scope
•developing a detailed description
of the project and product.
5.4 Create WBS
•subdividing project deliverables
and project work into smaller,
more manageable components.
5.5 Validate Scope
•formalizing acceptance of the
completed project deliverables.
5.6 Control Scope
•monitoring the status of the
project & product scope and
managing changes to the scope
baseline.
4. Project Management Process Group
and Knowledge Area Mapping
Knowledge Area Initiating Planning Executing M& C Closing
4. Project Integration Management
4Develop
Project Charter
4.2 Develop Project
Management Plan
4.3 Direct & Manage Project
Work
4.4 Monitor & Control Project Work
4.5 Perform Integrated Change
Control
4.6 Close Project
or Phase
5. Project Scope Management
5Plan Scope Management
5.2 Collect Requirements
5.3 Define Scope
5.4 Create WBS
5.5 Validate Scope
5.6 Control Scope
6. Project Time Management
6Plan Schedule Management
6.2 Define Activities
6.3 Sequence Activities
6.4 Estimate Activity Resources
6.5 Estimate Activity Durations
6.6 Develop Schedule
6.7 Control Schedule
7. Project Cost Management
7Plan Cost Management
7.2 Estimate Costs
7.3 Determine Budget
7.4 Control Costs
8. Project Quality Management 8Plan Quality Management
8.2 Perform Quality
Assurance
8.3 Control Quality
9. Project Human Resource
Management
9.1 Plan Human Resource
Management
9.2 Acquire Project Team
9.3 Develop Project Team
9.4 Manage Project Team
10. Project Communications
Management
10Plan Communications Management
10.2 Manage
Communications
10.3 Control Communications
11. Project Risk Management
11Plan Risk Management
11.2 Identify Risks
11.3 Perform Qualitative Risk Analysis
11.4 Perform Quantitative Risk Analysis
11.5 Plan Risk Responses
11.6 Control Risks
12. Project Procurement
Management
12Plan Procurement Management 12.2 Conduct Procurements 12.3 Control Procurements
12.4 Close
Procurements
13. Project Stakeholder
Management
13Identify
Stakeholders
13.2 Plan Stakeholder
Management
13.3 Manage Stakeholder
Engagement
13.4 Control Stakeholder
Engagement
OSO OCT 2013
Planning M& C
5. Product scope.
• The features and functions that characterize a product, service, or
result
Project scope.
• The work performed to deliver a product, service, or result with the
specified features and functions.
• The term project scope is sometimes viewed as including product
scope.
6. creating a scope management plan that documents how the
project scope will be:
provides guidance and direction on how scope will be
managed throughout the project
defined Validated controlled
8. 4 Integration 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders
EEF
OPA
Enterprise/
Organization
5.1Plan Scope
Management
Scope management
plan
5.2 Collect
Requirements
OSOOCT2013
4.1 Develop
Project charter
Project charter Requirements
management plan
5.3 Define Scope
5.4 Create WBS
4.2 Develop
Project M Plan
Project M Plan
9. Project management plan
•influence the approach taken for planning scope and managing project scope
Project charter
•high-level project description and product characteristics
Enterprise environmental factors
•Organization’s culture,
•Infrastructure,
•Personnel administration
•Marketplace conditions.
Organizational process assets
•Policies and procedures
•Historical information and lessons learned knowledge base.
10. describes how the scope will be defined, developed, monitored,
controlled, and verified include Process:
• a detailed project scope statement;preparing
•the creation of the WBS from the detailed
project scope statement;enables
•how the WBS will be maintained and
approved;establishes
•how formal acceptance of the completed
project deliverables will be obtainedspecifies
•how requests for changes to the detailed
project scope statement will be processed.control
11. describes how requirements will be analyzed, documented,
and managed
How
requirements
activities
• will be planned, tracked, and reported;
Configuration
management
activities
• how changes to the product will be initiated,
• how impacts will be analyzed,
• how they will be traced, tracked, and reported,
• the authorization levels required to approve
these changes;
prioritization • Requirements process;
Product metrics
• that will be used and the rationale for using
them;
Traceability
structure
• to reflect which requirement attributes will be
captured on the traceability matrix.
12. it provides the basis for defining and managing the
project scope including product scope
determining Documenting managing
stakeholder
•needs
•requirements
project
objectives
13. Inputs
Scope management plan
Requirements management plan
Stakeholder management plan
Project charter
Stakeholder register
T&T
Interviews
Focus groups
Facilitated workshops
Group creativity techniques
Group decision-making techniques
Questionnaires and surveys
Observations
Prototypes
Benchmarking
Context diagrams
Document analysis
Outputs
Requirements documentation
Requirements traceability matrix
14. 4 Integration 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders
5.1Plan Scope
Management
Scope management
plan
5.2 Collect
Requirements
OSOOCT2013
4.1 Develop Project
charter
Project charter
Requirements
management plan
5.3 Define Scope
5.4 Create WBS
13.1 Identify S/H
Stakeholder register
13.2 plan
S/H management
S/H management
plan
Requirements
traceability matrix
5.5 Validate Scope
5.6 Control Scope
8.1 Plan Quality
Management
Requirements
documentation
12.1 Plan
Procurement
Management
15. •higher-level needs of the organization as a whole (business issues or opportunities, & undertaken reasons )
Business requirements:
•needs of a stakeholder or stakeholder group.
Stakeholder requirements:
•features, functions, and characteristics of the product, service, or result that will meet the business and
stakeholder requirements.
Solution requirements:
•temporary capabilities (data conversion and training requirements, needed to transition from the current “as-is”
state to the future “to-be” state).
Transition requirements :
•the actions, processes, or other conditions the project needs to meet.
Project requirements:
•capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment
of other project requirements.
Quality requirements:
16. Solution
requirements:
Functional
requirements
the behaviors of the product.
(processes, data, and interactions
with the product).
Nonfunctional
requirements
supplement functional requirements
describe the environmental
conditions or qualities required for
the product to be effective
(reliability, security, performance,
safety, level of service, supportability,
retention/purge, etc).
17. •provides clarity as to how project teams will determine which type of requirements need to be collected for
the project.
5.2.1.1 Scope Management Plan
•provides the processes that will be used throughout the Collect Requirements process to define and
document the stakeholder needs.
5.2.1.2 Requirements Management Plan
•to understand stakeholder communication requirements and the level of stakeholder engagement in order
to assess and adapt to the level of stakeholder participation in requirements activities.
5.2.1.3 Stakeholder Management Plan
•provide the high-level description of the product, service, or result of the project so that detailed
requirements can be developed.
5.2.1.4 Project Charter
•identify stakeholders who can provide information on the requirements. The stakeholder register also
captures major requirements and main expectations stakeholders may have for the project.
5.2.1.5 Stakeholder Register
18. approach to elicit information
from stakeholders by talking to
them directly. formal /informal
Individual /multiple
asking –Q -recording
project participants,
sponsors
other executives
subject matter experts
19. • interactive discussion, designed to be more conversational
than a one-on-one interview.
prequalified stakeholders
expectations
subject matter experts
attitudes
trained moderator
l e a r n
about a proposed product, service, or result
20. In addition, issues can be
discovered earlier and resolved
more quickly than in individual
sessions
key stakeholders
to define product requirements.
reconciling
stakeholder
differences.
quickly
defining
cross-
functional
requirements
primary
technique for
interactive group
nature
trust,
foster relationships,
improve
communication
increased stakeholder
consensus.
(JAD)
•joint application design/development sessions (software)
(QFD) / (VOC)
•Quality function deployment / voice of the Customer (manufacturing )
User stories (used with agile methods):
•the stakeholder who benefits from the feature (role),
•what the stakeholder needs to accomplish (goal),
•the benefit to the stakeholder (motivation).
•"As a user, I want to search for my customers by their first and last names.
21. identify project and product requirements
Brainstorming
•to generate and collect MULTIPLE ideas
related to project and product requirements.
(voting or prioritization)
Nominal group
•enhances brainstorming with a VOTING
process used to rank the most useful ideas
for further brainstorming or for prioritization
Idea/mind mapping
•ideas created through individual
brainstorming sessions are
CONSOLIDATED into a single map to
reflect commonality and differences in
understanding, and generate new ideas
Affinity diagram
•allows large numbers of ideas to be
CLASSIFIED into groups for review and
analysis.
Multi-criteria decision analysis
•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.
24. assessment process having multiple alternatives with an expected outcome in the
form of future actions
EVERYONE
agrees on a
single course
of action.
(Delphi
technique)
Unanimity
more than 50
% of the
members of
the group.
Majority
LARGEST block
in a group
decides, even if
a majority is
not achieved..
Plurality
ONE individual
makes the
decision for the
group
Dictatorship.
25. NO
YESYES YESYES YES YESYES YES YESYES
Unanimity
YESYES YES YES YESYESYES NO NO
Majority
NOYESYES YES YESYES NO NO
Plurality
Dictatorship
26. 5.2.2.6 Questionnaires & Surveys
• designed to quickly accumulate
information from a large number of
respondents.
• most appropriate with varied
audiences,
• quick turnaround is needed,
• respondents are geographically
dispersed,
• statistical analysis is appropriate.
5.2.2.7 Observations
“job shadowing.”
• direct way of viewing individuals in
their environment
• helpful for detailed processes when
the people that use the product
have difficulty or are reluctant to
articulate their requirements.
27. 5.2.2.8 Prototypes
• a working model of the expected product
• early feedback on requirements.
• tangible, it allows real experiment
:abstract.
• support the concept of progressive
elaboration in
o iterative cycles of mock-up creation,
o user experimentation,
o feedback generation,
o prototype revision.
Storyboarding :
• a prototyping technique showing sequence or
navigation through a series of images or
illustrations.
o used on a variety of projects in a variety
of industries, (film, advertising,
instructional design, and on agile and
other software development projects).
o In software development, storyboards
use mock-ups to show navigation paths
through webpages, screens, or other
user interfaces
enough
feedback
cycles
performed,
requirements
are
sufficiently
complete
move to a
design or
build phase.
28. 5.2.2.9 Benchmarking
identify best practices,
generate ideas for improvement,
provide a basis for measuring
performance.
5.2.2.10 Context Diagrams
(an example of a scope model) visually
depict the product scope by
o showing a business system
(process, equipment, computer
system, etc.),
o how people and other systems
(actors) interact with it.
o Context diagrams show:
• inputs to the business system,
• the actor(s) providing the input,
• the outputs from the business
system, and the actor(s) receiving
the output
practices, (processes and operations)
(internal or external)
Organization A Organization B
29. Document analysis is used to elicit requirements by analyzing existing
documentation and identifying information relevant to the requirements.
business plans,
marketing
literature,
agreements,
requests for
proposal,
current process
flows,
logical data
models,
business rules
repositories,
application
software
documentation,
business
process,
use cases,
Other
requirements
documentation,
problem/issue
logs,
policies, procedures,
regulatory
documentation
(laws, codes, or
ordinances, etc).
30. • how individual requirements meet the business need for the
project.
• Requirements may start out at a high level and become
progressively more detailed as more about the requirements is
known.
• Before being base-lined, requirements need to be:
o unambiguous (measurable and testable),
o traceable,
o complete,
o consistent,
o acceptable to key stakeholders.
• format :
o simple (all the requirements categorized by stakeholder and priority)
o executive summary, detailed descriptions, and attachments
31. Business requirements:
•Business and project objectives for traceability;
•Business rules for the performing organization; and
•Guiding principles of the organization
Stakeholder requirements:
•Impacts to other organizational areas;
•Impacts to other entities inside or outside the performing organization; and
•Stakeholder communication and reporting requirements.
Solution requirements:
•Functional and nonfunctional requirements;
•Technology and standard compliance requirements;
•Support and training requirements;
•Quality requirements;
•Reporting requirements, etc.
Project requirements, such as:
•Levels of service, performance, safety, compliance, etc.;
•Acceptance criteria.
Transition requirements.
Requirements assumptions, dependencies, and constraints.
Stakeholder Requirement Category Priority
Acceptance
Criteria
32. • RTM is a grid that links product requirements to the deliverables that satisfy them.
• ensure that each requirement adds business value by linking it to the business and
project objectives.
• It provides a means to track requirements throughout the project life cycle, helping
to ensure that requirements approved in the requirements documentation are
delivered at the end of the project.
• Finally, it provides a structure for managing changes to the product scope.
Tracing includes, but is not limited
to, tracing requirements for the
following:
Business needs, opportunities,
goals, and objectives;
Project objectives;
Project scope/WBS deliverables;
Product design;
Product development;
Test strategy and test scenarios;
and
High-level requirements to more
detailed requirements.
33. process of developing a DETAILED description of the project and product..
Inputs
Scope management
plan
Project charter
Requirements
documentation
Organizational
process assets
Tools & Techniques
Expert judgment
Product analysis
Alternatives generation
Facilitation Techniques
Outputs
Project scope
statement
Project documents
updates
it describes the project boundaries by defining which of the requirements
collected will be INCLUDED in and excluded from the project scope
all of the requirements may NOT be included in the project, the Define Scope process selects
the FINAL project requirements from the requirements documentation
36. develop as many potential OPTIONS as possible in order to identify
different approaches to execute and perform the work of the project
37. Product scope description.
•characteristics of the product, service, or result described in the project charter and requirements
documentation.
Acceptance criteria.
•A set of conditions that is required to be met before deliverables are accepted.
Deliverable.
•Any unique and verifiable product, result, or capability to perform a service that is required to be produced to
complete a process, phase, or project. Deliverables also include ancillary results (project management reports
and documentation)
Project exclusion.
•Generally identifies what is excluded from the project. Explicitly stating what is out of scope for the project
helps to manage stakeholders’ expectations.
Constraints.
•A limiting factor that affects the execution of a project or process. (predefined budget or any imposed dates or
schedule milestones , contractual provisions).
Assumptions.
•A factor in the planning process that is considered to be true, real, or certain, without proof or demonstration.
Also describes the potential impact of those factors if they prove to be false.
•Project teams frequently identify, document, and validate assumptions as part of their planning process.
38.
39. 5.4.1 Inputs
Scope management plan
Project scope statement
Requirements
documentation
Enterprise environmental
factors
Organizational process
assets
5.4.2 Tools & Techniques
Decomposition
Expert judgment
5.4.3 Outputs
Scope baseline
Project documents
updates
process of SUBDIVIDING project deliverables and project work into smaller,
more manageable components.
it provides a structured VISION of what has to be delivered
41. approved version of a scope statement, work breakdown structure (WBS),
and its associated WBS dictionary, that can be changed only through
formal change control procedures and is used as a basis for comparison
Project scope statement.
• description of the project scope, major deliverables, assumptions,
and constraints.
WBS.
• a hierarchical decomposition of the total scope of work to
accomplish the project objectives and create the required
deliverables.
WBS dictionary.
• provides detailed deliverable, activity, and scheduling information
about each component in the WBS..
42. BPBC building
B.1
Engineering
B.1.1
Design
B1.1.1
Arch
B1.1.1.1
Structural
design
EM design
Testing
Construction
Civil works
Earth works
Excavation
backfilling
Concrete
works
Sub-structure
Foundation
Neck column
Tie beams
Flooring
Super-
structure
Concrete
Columns
Beams
Slabs
Masonry
Electro-Mech.
Elect
Plumbing
Air-condition
Fire-fighting
Landscaping
Procurement
Sub-
contracting
Supplying
100 percent rule
•The total of the work at the lowest
levels should roll up to the higher
levels so that nothing is left out and
no extra work is performed.
43. Control Account
• management
control point where
scope, budget,
actual cost, and
schedule are
integrated and
compared to the
earned value for
performance
measurement.
Planning Package
• a work breakdown
structure
component below
the control account
with known work
content but without
detailed schedule
activities
Control accounts are placed at selected management points in the WBS.
Each control account may include one or more work packages,
but each of the work packages should be associated with only one control account.
A control account may include one or more planning packages.
Project
CA-1
PP-1.1 PP-1.2
WP 1.2.1
CA-x
PP-xx
WP xxx
44.
45. FORMALIZING acceptance of the completed project deliverables.
Inputs
Project management
plan
Requirements
documentation
Requirements
traceability matrix
Verified deliverables
Work performance data
Tools & Techniques
Inspection
Group decision-making
techniques
Outputs
Accepted deliverables
Change requests
Work performance
information
Project documents
updates
it brings objectivity to the acceptance process and increases the chance of final
product, service, or result acceptance by validating each deliverable.
46. 4 Integration 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders
4.2 Develop Project
M. Plan
Project management
plan
5.5 Validate Scope
OSOOCT2013
4.6 Close Project
or Phase
8.3 Control
Quality
Verified deliverables
Project documents
updates
4.5 Perform
Integrated Change
Control
Accepted deliverables
4.4 Monitor and
Control Project
Work
5.2 Collect
Requirements
Project
Documents
any documents that define the product
or report status on product completion
4.3 Direct and Manage
Project Work
Work performance
data
Requirements
documentation
Requirements
traceability matrix
Change requests
Work performance
information
47. 5.5.1.1 Project
Management Plan
•scope management plan: specifies how formal
acceptance of the completed project deliverables will
be obtained + The scope baseline.
5.5.1.2
Requirements
Documentation
•lists all the project, product, and other types of
requirements for the project and product, along with
their acceptance criteria.
5.5.1.3
Requirements
Traceability Matrix
•links requirements to their origin and tracks them
throughout the project life cycle.
5.5.1.4 Verified
Deliverables
•project deliverables that are completed and checked
for correctness through the Control Quality process.
5.5.1.5 Work
Performance Data
•include the degree of compliance with requirements,
number of nonconformities, severity of the
nonconformities, or the number of validation cycles
performed in a period of time.
48. 5.5.2.1 Inspection
reviews, product reviews, audits, walkthroughs.
o measuring, examining, and
validating to determine
whether work and
deliverables MEET
requirements and product
acceptance criteria.
5.5.2.2 Group Decision-Making
Techniques
o used to reach a
CONCLUSION when the
validation is performed by
the project team and other
stakeholders.
49. • Formal documentation received from the
customer or sponsor acknowledging formal
stakeholder acceptance of the project’s
deliverables is forwarded to the Close
Project or Phase process.
• Those deliverables may require
a change request for defect
repair.
5.5.3.1 Accepted
Deliverables:
•Deliverables that MEET the
acceptance criteria are formally
signed off and approved by the
customer or sponsor.
5.5.3.2 Change Requests:
•The completed deliverables that
have NOT been formally accepted
are documented, along with the
reasons for non-acceptance of
those deliverables.
50. Validate Scope
• primarily concerned with
ACCEPTANCE of the
deliverables,
Control Quality
• primarily concerned with
CORRECTNESS of the
deliverables and meeting
the quality requirements
specified for the
deliverables.
C.Q. generally performed before V.S.
although the two processes may be performed in parallel
CQ VS
CQ
VS
51. monitoring the status of the project and product scope and managing changes to
the scope baseline.
Inputs
Project management plan
Requirements
documentation
Requirements traceability
matrix
Work performance data
Organizational process
assets
Tools & Techniques
Variance analysis
Outputs
Work performance
information
Change requests
Project management plan
updates
Project documents updates
Organizational process
assets updates
it allows the scope baseline to be MAINTAINED throughout the project.
52. • Controlling the project scope ensures all requested
changes and recommended corrective or preventive
actions are processed through the Perform Integrated
Change Control process
• Control Scope is also used to manage the actual changes
when they occur and is integrated with the other control
processes.
• The uncontrolled expansion to product or project scope
without adjustments to time, cost, and resources is
referred to as SCOPE CREEP.
• Change is inevitable; therefore some type of change
control process is mandatory for every project
53. June 1923
•elevation of 1,825 ft (556 m) above sea level,
•175 ft (53 m) above the stream bed.
•capacity of 30,000 acre·ft (37,000,000 m3)
July 1, 1924
•capacity of the reservoir 32,000 acre-
feet (39,000,000 m3).
March 1925
•capacity of 38,000 acre-feet (47,000,000 m3)
•height would be 185 ft (56 m)
March 1, 1926
•Water began to fill the reservoir.
March 12, 1928
•Two and a half minutes before midnight > the
St. Francis Dam disastrously failed.
54. 4 Integration 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders
4.2 Develop Project
M. Plan
Project management
plan
5.6 Control Scope
OSOOCT2013
4.2 Develop
Project M. Plan
Enterprise/
Organization
OPA
Project documents
updates
4.5 Perform
Integrated Change
Control
Project documents
updates
4.4 Monitor and
Control Project
Work
5.2 Collect
Requirements
Project
Documents
Requirements documentation
Requirements traceability matrix.
4.3 Direct and Manage
Project Work
Work performance
data
Requirements
documentation
Requirements
traceability matrix
Change requests
Work performance
information
OPA updates
Existing formal /informal scope,
control-related policies,
procedures, guidelines
Monitoring and reporting methods
and templates.
55. Scope baseline.
• compared to actual results to determine if a change, corrective action, or preventive
action is necessary.
Scope management plan
• how the project scope will be monitored and controlled.
Change management plan.
• defines the process for managing change on the project.
Configuration management plan.
• defines those items that are configurable, those items that require formal change control,
and the process for controlling changes to such items.
Requirements management plan.
• plan and describes how the project requirements will be analyzed, documented, and
managed.
56. • determining the CAUSE and DEGREE of difference between
the baseline and actual performance to decide whether
corrective or preventive action is required.
Planned Result Actual Result Variance
Root Cause:
Planned Response:
Schedule Variance:
Project Title: Date Prepared:
Cost Variance:
Planned Result Actual Result Variance
Root Cause:
Planned Response:
57. 5.6.3.1 Work Performance Information
• includes correlated and contextualized information on how the project
scope is performing compared to the scope baseline.
• changes received, scope variances and their causes, schedule/cost
impact , forecast.
5.6.3.2 Change Requests
• Analysis of scope performance can result in a change request to the
scope baseline /other components
5.6.3.3 Project Management Plan Updates
• Project management plan updates may include, but are not limited to:
• Scope Baseline Updates.
• Other Baseline Updates.
58. “if you ever need my help, just let me know?”
http://www.slideshare.net/omeralsayed
omer2t
omer2t
https://www.facebook.com/pages/2t-
PMP/1429460070603068
www.linkedin.com/pub/omer-
alsayed-mba-pmp®/40/609/610/
