PMP, 5TH EDITTION

1. By: Omer Alsayed Omer abbas
MBA, PMP, B.Sc.(Civil Eng.) : PMO manager EWU-DIU

2. “
Don’t do
anything
you don’t have
TO DO
-– Louis Fried

3. 5.2 Collect Requirements
5.3 Define Scope
•determining, documenting, and
managing stakeholder needs and
requirements to meet project
objectives.
•developing a detailed description
of the project and product.
5.4 Create WBS
5.5 Validate Scope
5.6 Control Scope
•subdividing project deliverables
and project work into smaller,
more manageable components.
•formalizing acceptance of the
completed project deliverables.
•monitoring the status of the
project & product scope and
managing changes to the scope
baseline.
5.1 Plan Scope
Management
•creating a scope management
plan –how scope will be
defined, validated, and
controlled.

4. Project Management Process Group
and Knowledge Area Mapping
Knowledge Area
4. Project Integration Management
Initiating
4Develop
Project Charter
Planning
Planning
4.2 Develop Project
Management Plan
Executing
4.3 Direct & Manage Project
Work
M& C
M& C
4.4 Monitor & Control Project Work
4.5 Perform Integrated Change
Control
5. Project Scope Management
5Plan Scope Management
5.2 Collect Requirements
5.3 Define Scope
5.4 Create WBS
6. Project Time Management
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
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
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
12. Project Procurement
Management
12Plan Procurement Management
12.2 Conduct Procurements
12.3 Control Procurements
13.2 Plan Stakeholder
Management
13.3 Manage Stakeholder
Engagement
13.4 Control Stakeholder
Engagement
4.6 Close Project
or Phase
5.5 Validate Scope
5.6 Control Scope
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
Closing
13. Project Stakeholder
Management
13Identify
Stakeholders
OSO OCT 2013
8.3 Control Quality
10.3 Control Communications
11.6 Control Risks
12.4 Close
Procurements

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:
defined
Validated
controlled
provides guidance and direction on how scope will be
managed throughout the project

7. Inputs
T&T
Project management
plan
Expert judgment
Project charter
Meetings
Enterprise
environmental factors
Organizational
process assets
Outputs
Scope management
plan
Requirements
management plan

8. Enterprise/
Organization
5.1Plan Scope
Management
4.1 Develop
Project charter
Scope management
plan
Requirements
management plan
Project charter
OPA
EEF
5.2 Collect
Requirements
4.2 Develop
Project M Plan
5.3 Define Scope
OSO OCT 2013
Project M Plan
4 Integration
5.4 Create WBS
5 Scope
6 Time
7 Cost
8 Quality
9 H. Resource
10 Commn.
11 Risk
12 Procurement
13 S/holders

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:
preparing
enables
establishes
specifies
control
• a detailed project scope statement;
•the creation of the WBS from the detailed
project scope statement;
•how the WBS will be maintained and
approved;
•how formal acceptance of the completed
project deliverables will be obtained
•how requests for changes to the detailed
project scope statement will be processed.

11. describes how requirements will be analyzed, documented,
and managed
How
requirements
activities
Configuration
management
activities
prioritization
Product metrics
Traceability
structure
• will be planned, tracked, and reported;
•
•
•
•
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;
• Requirements process;
• that will be used and the rationale for using
them;
• to reflect which requirement attributes will be
captured on the traceability matrix.

12. stakeholder
determining
Documenting
project
objectives
managing
•needs
•requirements
it provides the basis for defining and managing the
project scope including product scope

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. 5.1Plan Scope
Management
4.1 Develop Project
charter
Scope management
plan
Requirements
management plan
Project charter
8.1 Plan Quality
Management
5.2 Collect
Requirements
Stakeholder register
Management
5.3 Define Scope
13.2 plan
S/H management
OSO OCT 2013
Procurement
Requirements
documentation
Requirements
traceability matrix
13.1 Identify S/H
5.4 Create WBS
S/H management
plan
4 Integration
12.1 Plan
5.5 Validate Scope
5.6 Control Scope
5 Scope
6 Time
7 Cost
8 Quality
9 H. Resource
10 Commn.
11 Risk
12 Procurement
13 S/holders

15. Business requirements:
•higher-level needs of the organization as a whole (business issues or opportunities, & undertaken reasons )
Stakeholder requirements:
•needs of a stakeholder or stakeholder group.
Solution requirements:
•features, functions, and characteristics of the product, service, or result that will meet the business and
stakeholder requirements.
Transition requirements :
•temporary capabilities (data conversion and training requirements, needed to transition from the current “as-is”
state to the future “to-be” state).
Project requirements:
•the actions, processes, or other conditions the project needs to meet.
Quality requirements:
•capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment
of other project 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. 5.2.1.1 Scope Management Plan
•provides clarity as to how project teams will determine which type of requirements need to be collected for
the project.
5.2.1.2 Requirements Management Plan
•provides the processes that will be used throughout the Collect Requirements process to define and
document the stakeholder needs.
5.2.1.3 Stakeholder 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.4 Project Charter
•provide the high-level description of the product, service, or result of the project so that detailed
requirements can be developed.
5.2.1.5 Stakeholder Register
•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.

18. approach to elicit information
from stakeholders by talking to
them directly.
formal /informal
project participants,
sponsors
Individual /multiple
other executives
subject matter experts
asking –Q -recording

19. learn
expectations
subject matter experts
attitudes
about a proposed product, service, or result
prequalified stakeholders
trained moderator
• interactive discussion, designed to be more conversational
than a one-on-one interview.

20. key stakeholders
primary
technique for
to define product requirements.
quickly
defining
crossfunctional
requirements
In addition, issues can be
discovered earlier and resolved
more quickly than in individual
sessions
(JAD)
•joint application design/development sessions (software)
(QFD) / (VOC)
•Quality function deployment / voice of the Customer (manufacturing )
reconciling
stakeholder
differences.
interactive group
nature
trust,
foster relationships,
improve
communication
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.
increased stakeholder
consensus.

21. identify project and product requirements
Brainstorming
Nominal group
•to generate and collect MULTIPLE ideas
related to project and product requirements.
(voting or prioritization)
•enhances brainstorming with a VOTING
process used to rank the most useful ideas
for further brainstorming or for prioritization
Idea/mind mapping
Affinity diagram
•ideas created through individual
brainstorming sessions are
CONSOLIDATED into a single map to
reflect commonality and differences in
understanding, and generate new ideas
•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.

23. BRAINSTORMING
AFFINITY DIAGRAM

24. assessment process having multiple alternatives with an expected outcome in the
form of future actions
Unanimity
Majority
Plurality
Dictatorship.
EVERYONE
agrees on a
single course
of action.
(Delphi
technique)
more than 50
% of the
members of
the group.
LARGEST block
in a group
decides, even if
a majority is
not achieved..
ONE individual
makes the
decision for the
group

25. YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
Unanimity
Majority
YES
Plurality
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES NO
NO
NO
NO
NO
NO
Dictatorship

26. 5.2.2.6 Questionnaires &
•
•
•
•
•
5.2.2.7
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.
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
o
o
o
iterative cycles of mock-up creation,
user experimentation,
feedback generation,
prototype revision.
enough
feedback
cycles
performed,
requirements
are
sufficiently
complete
move to a
design or
build phase.
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

28. 5.2.2.9 Benchmarking
 identify best practices,
 generate ideas for improvement,
 provide a basis for measuring
performance.
practices, (processes and operations)
5.2.2.10 Context Diagrams
(an example of a scope model) visually
depict the product scope by
showing a business system
(process, equipment, computer
system, etc.),
o how people and other systems
(actors) interact with it.
o Context diagrams show:
o
• inputs to the business system,
• the actor(s) providing the input,
• the outputs from the business
system, and the actor(s) receiving
the output
Organization
A
Organization B
(internal or external)

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,
use cases,
Other
requirements
documentation,
problem/issue
logs,
business
process,
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
o
o
o
o
unambiguous (measurable and testable),
traceable,
complete,
consistent,
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.
Stakeholder
Requirements assumptions, dependencies, and constraints.
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. all of the requirements may NOT be included in the project, the Define Scope process selects
the FINAL project requirements from the requirements documentation
process of developing a DETAILED description of the project and product..
it describes the project boundaries by defining which of the requirements
collected will be INCLUDED in and excluded from the project scope
Inputs
Scope management
plan
Project charter
Requirements
documentation
Organizational
process assets
Tools & Techniques
Outputs
Expert judgment
Product analysis
Project scope
Alternatives generation statement
Facilitation Techniques Project documents
updates

34. 5.1Plan Scope
Management
4.1 Develop Project
charter
Scope management
plan
Project charter
6.3 Sequence
Activities
5.2 Collect
Requirements
Requirements
documentation
Enterprise/
Organization
OPA
Project scope
statement
Project documents
updates
OSO OCT 2013
4 Integration
6.5 Estimate
Activity Durations
5.3 Define Scope
6.6 Develop
Schedule
Project
Documents
5.4 Create WBS
5 Scope
6 Time
7 Cost
8 Quality
9 H. Resource
 Stakeholder register,
 Requirements documentation
 Requirements traceability matrix
10 Commn.
11 Risk
12 Procurement
13 S/holders

35. product
descriptions
high-level
tangible
accepted
methods
deliverables
Product analysis techniques

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.

39. process of SUBDIVIDING project deliverables and project work into smaller,
more manageable components.
it provides a structured VISION of what has to be delivered
5.4.1 Inputs
Scope management plan
Project scope statement
Requirements
documentation
Enterprise environmental
factors
Organizational process
assets
5.4.2 Tools & Techniques
5.4.3 Outputs
Decomposition
Expert judgment
Scope baseline
Project documents
updates

40. 5.1Plan Scope
Management
Enterprise/
Organization
4.2 Develop
Project M. Plan
Scope management
plan
5.2 Collect
Requirements
OPA
6.2 Define
Activities
Requirements
documentation
EEF
7.2 Estimate
Costs
5.3 Define Scope
Project scope
statement
7.3 Determine
Budget
5.4 Create WBS
11.2 Identify Risks
OSO OCT 2013
Project
Documents
4 Integration
Scope baseline
Project documents
updates
 Requirements documentation
Perform
Qualitative Risk
Analysis
11.3
5.5 Validate
Scope
5 Scope
6 Time
7 Cost
8 Quality
9 H. Resource
10 Commn.
11 Risk
12 Procurement
13 S/holders

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
Construction
Testing
Civil works
Concrete
works
Earth works
Structural
design
Excavation
EM design
backfilling
Sub-structure
Foundation
Electro-Mech.
Masonry
Landscaping
Elect
Subcontracting
Supplying
Superstructure
Plumbing
Concrete
Air-condition
Neck column
Columns
Tie beams
Beams
Flooring
Procurement
Slabs
Fire-fighting
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
Planning Package
Project
• management
control point where
scope, budget,
actual cost, and
schedule are
integrated and
compared to the
earned value for
performance
measurement.




• a work breakdown
structure
component below
the control account
with known work
content but without
detailed schedule
activities
CA-1
PP-1.1
CA-x
PP-1.2
PP-xx
WP 1.2.1
WP xxx
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.

45. FORMALIZING acceptance of the completed project deliverables.
it brings objectivity to the acceptance process and increases the chance of final
product, service, or result acceptance by validating each deliverable.
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

46. 4.2 Develop Project
M. Plan
Project management
plan
5.2 Collect
Requirements
4.6 Close Project
or Phase
Requirements
documentation
Requirements
traceability matrix
4.3 Direct and Manage
Project Work
Work performance
data
4.5 Perform
Integrated Change
Control
5.5 Validate Scope
8.3 Control
Quality
Change requests
Verified deliverables
Work performance
information
OSO OCT 2013
4 Integration
Project
Documents
Project documents
updates
5 Scope
4.4 Monitor and
Control Project
Work
Accepted deliverables
6 Time
7 Cost
8 Quality
9 H. Resource
 any documents that define the product
or report status on product completion
10 Commn.
11 Risk
12 Procurement
13 S/holders

47. 5.5.1.1 Project
Management Plan
5.5.1.2
Requirements
Documentation
5.5.1.3
Requirements
Traceability Matrix
•scope management plan: specifies how formal
acceptance of the completed project deliverables will
be obtained + The scope baseline.
•lists all the project, product, and other types of
requirements for the project and product, along with
their acceptance criteria.
•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. 5.5.3.1 Accepted
Deliverables:
•Deliverables that MEET the
acceptance criteria are formally
signed off and approved by the
customer or sponsor.
•
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.
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.
• Those deliverables may require
a change request for defect
repair.

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.
CQ
VS
C.Q. generally performed before V.S.
although the two processes may be performed in parallel
CQ
VS

51. monitoring the status of the project and product scope and managing changes to
the scope baseline.
it allows the scope baseline to be MAINTAINED throughout the project.
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

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 acrefeet (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.2 Develop Project
M. Plan
Project management
plan
5.2 Collect
Requirements
4.2 Develop
Project M. Plan
Requirements
documentation
Requirements
traceability matrix
4.3 Direct and Manage
Project Work
Work performance
data
4.5 Perform
Integrated Change
Control
5.6 Control Scope
OPA
OSO OCT 2013


Change requests
Work performance
information
Existing formal /informal scope,
control-related policies,
procedures, guidelines
Monitoring and reporting methods
and templates.
4 Integration
4.4 Monitor and
Control Project
Work
Project documents
updates
Enterprise/
Organization
Project
Documents
Project documents
updates
 Requirements documentation
 Requirements traceability matrix.
OPA updates
5 Scope
6 Time
7 Cost
8 Quality
9 H. Resource
10 Commn.
11 Risk
12 Procurement
13 S/holders

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.
Date Prepared:
Project Title:
Schedule Variance:
Planned Result
Root Cause:
Planned Response:
Actual Result
Cost Variance:
Variance
Planned Result
Actual Result
Root Cause:
Planned Response:
Variance

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. ‫ان للــه عبادا اختصهم بقضاء حوائــج الناس . حببهم اىل اخلري وحبب اخلري اليهـم اولئــك‬
)‫اآلمنون من عذاب اللـه يــوم القيامة. (اللهم اجعلنا منهم‬
omer2t
www.linkedin.com/pub/omeralsayed-mba-pmp®/40/609/610/
omer2t
https://www.facebook.com/pages/2tPMP/1429460070603068
http://www.slideshare.net/omeralsayed
“if you ever need my help, just let me know?”