3. Professional
Responsibility
• The PMP Code of Professional Conduct is the
authoritative guide on how the PMP should
act as a professional, and how the PMP should
behave with customers and the public in
general.
• The PMP exam candidate will be tested on
their knowledge of the PMP Code of
Professional Conduct.
4. Professional
Responsibility
The five areas of professional responsibility
consist of the following:
• Ensuring integrity
• Contributing to the knowledge base
• Applying professional knowledge
• Balancing stakeholder interests
• Respecting differences
5. Responsibilities to the
profession
• The PMP/ CAPM must adhere to a high set of
principles, rules, and policies.
• This includes the organizational rules and policies,
the certification process, and the advancement of
the profession.
• On the exam, always choose the answer which best
supports the PMP profession and the higher set of
principles the candidate is expected to adhere to.
6. Balancing Stakeholders
needs
• Balance Stakeholder’s Objectives
– Understand the various competing stakeholders’
interests and needs
– Comprehend the conflict resolution techniques
useful in handling differing objectives
– Be able to resolve conflicts in a fair manner
– Exercise negotiation skills based on proper
information
7. Complying with Rules and
Policies
Honesty is expected in all areas regarding the PMP
examination process including:
• Exam applications must be honest and reflect actual
education and work experience.
• Test items, questions, answers, and scenarios are not to
be shared with other PMP/ CAPM candidates.
• PMP renewal information must reflect an honest
• assessment of education and experience.
• Continuing education information must be honest and
accurate; continuing education reporting must reflect
actual courses completed
8. Applying Honesty to the
Profession
• The candidate is expected, at all times, to
provide honesty in experience
documentation, the advertisement of skills,
and the performance of services.
• The PMP must, of course, adhere to and
abide by all applicable laws governing the
project work. In addition, the ethical
standards within the trade or industry should
also be adhered to.
9. Advancing the Profession
• The PMP/ CAPM must respect and recognize
the intellectual work and property of others.
• The PMP/ CAPM can’t claim others’ work as
their own.
• He/ She must give credit where credit is due.
• Work, research, and development sources
must be documented and acknowledged by
the PMP when relying on others’ work.
10. Responsibilities to the Customer
and to the Public
• The candidate also has a responsibility to the
customer of the project and the public.
• Projects that affect internal customers are expected
to meet requirements and standards, and fulfill the
business need of the performing organization.
• Essentially, the candidate is working for the
customer.
11. Enforcing Project
Management Truth &
Honesty
• The candidate must represent themselves and their
projects truthfully to the general public.
• This includes statements made in advertising, press
• releases, and in public forums.
• When project managers are involved in the creation of
estimates, truth is also expected.
• The candidate must provide accurate estimates on
time, cost, services to be provided—and realistic
outcomes of the project work.
12. Eliminating Inappropriate
Actions
• A PMP/ CAPM must avoid conflicts of interest
and scenarios where conflicts of interest could
seem apparent, opportunistic, or questionable
to the customer or other stakeholders.
• In addition, the candidate must not accept any
inappropriate gifts, inappropriate payments,
or any other compensation for favors, project
management work, or influence of a project.
13. Respecting Differences
• Interact with team and stakeholders in a
professional and cooperative manner
– Understand cultural diversity, norms and
stakeholders’ communication styles
– Show flexibility towards diversity, tolerance and
self control
– Becoming empathetic to differences
15. What is the PMBOK Guide
The Project Management Book of Knowledge
(pmbok) is a recognised standard for the
project management profession.
• A standard is a formal document, it describes
norms, methods, processes and practices.
16. What is a project
According to PMBOK a project ''is a
temporary endeavor undertaken to create
a unique product, service or result.’’
17. Project Characteristics
You’ve just learned that a project has several
characteristics:
• Projects are unique.
• Projects are temporary in nature and have a definite
beginning and ending date.
• Projects are completed when the project goals are achieved
or it’s determined the project is no longer viable.
• A successful project is one that meets or exceeds the
expectations of your stakeholders
18. Operational Work
Operational Works are quite opposite in nature to
Projects. Operations are ongoing and repetitive.
They involve work that is continuous without an
ending date, and you often repeat the same
processes and produce the same results.
19. Project Management vs. Operations
The purpose of operations is to keep the
organization functioning, while the purpose of a
project is to meet its goals and to conclude.
At the completion of a project, the end product
(or result) may get turned over to the organization’s
operational areas for ongoing care and
maintenance.
20. What is Project Management
Project Management is the application of
knowledge, skills, tools and techniques to
meet the project requirements. It is the
responsibility of the project manager to
ensure that project management techniques
are applied and followed.
21. What is a Portfolio
Portfolios are a collections of programs
and projects grouped together to support
a strategic business goal or objective. The
programs may not be related other than
the fact that they are helping to achieve
that common goal.
22. What is a Program
• Programs are groups of related projects that are
managed using the same techniques in a coordinated
fashion. When projects are managed collectively as
programs, it’s possible to capitalize on benefits that
wouldn’t be achievable if the projects were managed
separately.
• A project may or may not be part of a program but a
program will always have projects.
23.
24. SUBPROJECT
Projects are frequently divided into more
manageable components or subprojects.
Subproject are often contracted to an external
enterprise or to another functional unit in the
performing organization.
Subprojects can be referred to as projects and
managed as such
25. What is a Project Management Office
The project management office (PMO) is an
organisational body or entity assigned to
oversee the management of projects and
programs throughout the organization.
26. Primary Function of PMO
A Primary function of PMO is to support project managers in a
variety of ways which may include, but are not limited to:
• Managing shared resources across all the projects administered by the
PMO.
• Identifying and developing project management methodology, practices &
standards.
• Coaching, mentoring , training and oversight.
• Monitoring compliance with project management standard policies,
procedures , and templates via project audits.
• Developing and managing project policies, procedures, templates, and
other shared documentation ( organizational process assets);
• Co coordinating communication across projects
27. Role of a Project Manager
• The Project Manager is the person responsible for accomplishing the
project objectives.
• Project managers strive to meet the triple constraint by balancing project
scope, time, and cost goals.
• Depending on the organization structure , a project manager may report to
functional manager.
• In other cases project manager may be one of the several project managers
who report to a portfolio or program manager that is ultimately responsible
for enterprise wide projects . In this type of structure, the project manager
works closely with the portfolio or program manager to achieve the project
objectives
28. Project Manager Skills
Skills every good project manager should have:
• Integration Skills
• Communication skills
• Planning and Organizational skills
• Leadership Skills
• Team Building and Motivational Skills
• Budgeting Skills
• Conflict Management Skills
• Negotiation and Planning Skills
29. Organisational Structure
Just as projects are unique, so are the organizations
in which they’re carried out. Organizations have their
own styles and cultures that influence how project
work is performed.
.
One of the keys to determining the type of organization you work in is measuring how much
authority senior management is willing to delegate to project managers
30. Types of Organisational
Structure
Although uniqueness abounds in business
cultures, all organizations are structured in one of
three ways:
• Functional
• Projectized
• Matrix
31. Functional Organisation
One common type of organization is the functional
organization. Chances are you have worked in this type of
organization. This is probably the oldest style of organization
and is therefore known as the traditional approach to
organizing businesses.
Functional organizations are centered on specialties and
grouped by function, which is why it’s called functional
organization. As an example, the organization might have a
human resources department, finance department,
marketing department, and so on.
33. Projectized Organisations
In this type structure, organisational resources are dedicated to
projects and project work in purely projectized organizations. Project
managers almost always have ultimate authority over the project in
this structure and report directly to the CEO.
In a purely projectized organization, supporting functions such as
human resources and accounting might report directly to the project
manager as well. Project managers are responsible for making
decisions regarding the project and acquiring and assigning
resources. They have the authority to choose and assign resources
from other areas in the organization or to hire them from outside if
needed.
35. Matrix Organisations
This form is an attempt to maximize the strengths of both the
functional and projectised forms. Team members report to two
bosses, the project manager and functional manager (i.e., VP
Engineering). Communication goes from team member to both
bosses. Team member do project work in addition to normal
departmental work.
• In a strong matrix, power rests with the project manager, in a weak
matrix power rests with the functional manager and the power is
comparable to that of a coordinator or expediter.
• In a balanced matrix, the power is shared between the functional
manager and the project manager.
36. Project Expediter and Coordinator
• Project Expediter- The project expediter acts
primarily as a staff assistant and communications
coordinator. The expediter cannot personally make or
enforce decisions.
• Project Coordinator- This position is similar to the
project expediter except the coordinator has some
power to make decisions, have some amount of
authority and reports to a higher- level manager.
37. Who are project Stakeholders
• Stakeholders are persons or organizations who are actively involved in
the project or whose interests may positively or negatively be
affected by the performance or completion of the project.
• Stakeholders have varying levels of responsibility and authority and
can change over the project life cycle.
• Project management team must continuously identify both external
and internal stakeholders.
• Project manager must manage the influence of various stakeholders in
relation to the requirements and balance stakeholders’ interest.
39. Enterprise Environmental Factors
• Refer to both internal & external environmental factors that surround or
influence a project’s success.
• As an input in almost all project management process.
• May enhance or constrain project management options.
• May have positive or negative influence on the outcome.
• Examples:
Organizational culture, structure, and processes
Government or industry standards
Infrastructure
Existing human resources
Personnel administration
Company work authorization systems
Marketplace conditions
Stakeholder risk tolerances
Political climate
Organization’s established communications channels
Commercial databases
Project management information
40. Organizational Process Assets
• Processes & Procedures
Organizational standard processes such as standards, policies
Standardized guidelines, work instruction, proposal evaluation criteria, and
performance measurement criteria
Templates
Financial control procedures
Procedures for prioritizing, approving, and issuing work authorization, etc.
• Corporate Knowledge Base
Process measurement databases
Project files
Historical information & lesson learned knowledge bases
Issue and defect management databases
Configuration management knowledge bases
Financial databases, etc.
41. Project Management Process
Groups
Project management processes organize and
describe the work of the project. The
PMBOK®Guide describes five process groups
used to accomplish this end. These processes
are performed by people and, much like
project phases, are interrelated and
dependent on one another.
42. The five process groups are:
• Initiating
• Planning
• Executing
• Monitoring and Controlling
• Closing
43. Project Management Processes
All these process groups have individual processes that collectively
make up the group. For example, the Initiating process group has
two processes called Develop Project Charter and Identify
Stakeholders.
Collectively, these process groups—including all their individual
processes—make up the project management process.
Projects start with the Initiating process and progress through all the
processes in the Planning process group, the Executing process
group, and so on, until the project is successfully completed or it’s
canceled. All projects must complete the Closing processes, even if
a project is killed.
44. Knowledge Areas
There are nine knowledge areas and they are:
• Integration Management
• Scope Management
• Time Management
• Cost Management
• Quality Management
• Human Resource Management
• Communication Management
• Risk Management
• Procurement Management
45. Knowledge Areas
• Each Knowledge area has further Processes.
There are a total of 42 processes. Each
process has inputs, outputs and "tools and
techniques" (ITTO’s). The PMBOK primarily
covers each of the processes and it's ITTO’s in
detail. You need to understand the concepts
related to each of the input, output and "tools
and techniques".
46.
47. Project Life cycle
The project life cycle is the agglomeration of
all phases in the project.
All projects are divided into phases, and all
projects, large or small, have a similar life cycle
structure: These are:
• Starting the project
• Organizing and preparing
• Carrying out the project work
• Closing the project
48. Characteristics of the Project Life
Cycle
The project life cycle serves to define the beginning and the
end of a project.
Phases are generally sequential and are usually defined
by some form of technical information or technical
component handoff.
Deliverables from the preceding phase are usually approved
before work starts on the next phase.
49. Characteristics of the Project Life Cycle
Most project life-cycles share a number of common
characteristics:
Cost and staffing levels are low at the start, higher
toward the end, and drop rapidly as the project draws to a
conclusion.
The ability of the stakeholders to influence the final
characteristics of the project’s product and the final
cost of the project is highest at the start and gets
progressively lower as the project continues.
50. The probability of successful completion generally
gets progressively higher as the project continues.
Characteristics of the Project Life Cycle
The probability of successfully completing the
project is lowest, and hence risk and uncertainty are
highest, at the start of the project.
51. Project Phases and the Project Life
Cycle
A project life cycle is a collection of project
phases that defines:
What work will be performed in each phase.
What deliverables will be produced and when.
Who is involved in each phase.
How management will control and approve work produced in
each phase.
A deliverable is a product or service produced or provided as
part of a project
53. Handoffs
Project phases evolve through the life cycle in
a series of phase sequences called handoffs, or
technical transfers. The end of one phase
sequence typically marks the beginning of the
next.
54. Phase-to-Phase Relationships
There are three basic types of phase–to Phase
relationships:
• A Sequential relationship : where a phase can only start
once the previous phase is complete.
• An Overlapping relationship : where the phase starts prior
to completion of the previous one (Fast tracking).
Overlapping phase may increase risk and can result in
rework.
• An Iterative relationship : where only one phase is planned
at any given time and the planning for the next is carried out
as work progresses on the current phase and deliverables
58. The Key to Overall Project Success:
Good Project Integration Management
• Project managers must coordinate all of the other
knowledge areas throughout a project’s life cycle.
• Many new project managers have trouble looking at
the “big picture” and want to focus on too many
details.
60. Project Integration Management Processes:
• Develop the project charter: Work with stakeholders to
create the document that formally authorizes a project—
the charter.
• Develop the project management plan: Coordinate all
planning efforts to create a consistent, coherent
document—the project management plan.
• Direct and manage project execution: Carry out the
project management plan by performing the activities
included in it.
61. Project Integration Management Processes (cont’d)
• Monitor and control the project work: Oversee
project work to meet the performance objectives of
the project.
• Perform integrated change control: Coordinate
changes that affect the project’s deliverables and
organizational process assets.
• Close the project: Finalize all project activities to
formally close the project.
62. How do Projects come about:
• As a result of Needs and Demands, namely:
Market need
Customer Request
Strategic opportunity/business need
Technological advance
Legal requirement
Ecological impacts
Social need
63. Strategic Planning and Project Selection
• Strategic planning involves determining long-term objectives, predicting
future trends, and projecting the need for new products and services.
• Organizations often perform a SWOT analysis:
– Strengths, Weaknesses, Opportunities, and Threats
• As part of strategic planning, organizations should:
– Identify potential projects.
– Use realistic methods to select which projects to work on.
– Formalize project initiation by issuing a project charter.
64. Project Selection Methods
There are many ways to select a project to be
initiated from among many possible projects.
Project selection methods measure the value of
what the product, service, or result of the project
will produce and how it will benefit the
organization.
65. Methods for Selecting Projects
• There is usually not enough time or
resources to implement all projects.
• Methods for selecting projects include:
– Focusing on broad organizational needs.
– Categorizing projects.
– Performing net present value or other financial
analyses.
– Using a weighted scoring model.
– Implementing a balanced scorecard.
65
66. Project Selection Methods
There are generally two categories of
selection methods:
• Benefit Measurement Methods (Comparative
approach).
• Constrained Optimization Methods
(Mathematical models).
67. Benefit Measurement Method
• Murder Board
A panel of people who try to shoot down a new
project idea.
• Peer Review
• Economic Models
• Benefit Compared to Cost
69. Economic Models for Project
Selection
• Present Value
• Net Present Value
• Internal Rate of Return
• Payback Period
• Benefit Cost Ratio
70. Net Present Value
• Net present value (NPV) analysis is a method of
calculating the expected net monetary gain or loss from
a project by discounting all expected future cash inflows
and outflows to the present point in time.
Note:
• Projects with a positive NPV should be considered if
financial value is a key criterion.
• The higher the NPV, the better.
71. Internal Rate of Return
• The internal rate of return (IRR) is the most difficult
equation to calculate of all the cash flow
techniques.
• It is a complicated formula and should be
performed on a financial calculator or computer.
• Technically speaking, IRR is the discount rate when
the present value of the cash inflows equals the
original investment.
72. Internal Rate of Return cont’d
Note:
When choosing between projects or when
choosing alternative methods of doing the
project, projects with higher IRR values are
generally considered better than projects
with low IRR values.
73. Payback Period
• The payback analysis/payback period is another important
financial consideration.
• The payback period is the amount of time (number of time
periods) it will take to recoup your investment in the project
before you start accumulating profit.
• Many organizations want IT projects to have a fairly short
payback period.
74. Project Selection – Economic Models
Concepts you should know:
• Present value (PV): The value today of future cash flows.
• Net present value (NPV): Project with positive & greater NPV
value is better.
• Internal rate of return (IRR): Project with greater IRR value is
better.
• Payback period: The shorter the payback period the better.
• Benefit-cost ratio: compares the benefits to the costs of different
options relates to costing projects and to determining what work
should be done. Project with greater benefit-cost ratio value is
better.
75. Project Selection – Economic Models
Method MAIN POINT
Present value (PV): value today of future cash flows
Net present value
(NPV):
greater NPV value is better
Internal rate of
return (IRR):
greater IRR value is better
Payback Period time periods it takes to recover your investment
SHORTER Payback Period THE BETTER
Benefit-cost ratio ABOVE 1; greater benefit-cost ratio value is better.
76. Weighted Scoring Model
• A weighted scoring model is a tool that provides a systematic
process for selecting projects based on many criteria.
• Steps in identifying a weighted scoring model:
1. Identify criteria important to the project selection
process.
2. Assign weights (percentages) to each criterion so they
add up to 100 percent.
3. Assign scores to each criterion for each project.
4. Multiply the scores by the weights to get the total
weighted scores.
• The higher the weighted score, the better.
76
78. Implementing a Balanced Scorecard
• Drs. Robert Kaplan and David Norton developed this
approach to help select and manage projects that align
with business strategy.
• A balanced scorecard is a methodology that converts an
organization’s value drivers, such as customer service,
innovation, operational efficiency, and financial
performance, to a series of defined metrics.
• See www.balancedscorecard.org for more.
79. Project Selection – Key Terms
• Economic Value Added (EVA): concerned with whether the
project returns to the company more value than it costs.
• Opportunity Cost: the opportunity given up by selecting one
project over another.
• Sunk Costs: Are expended costs, should not be considered
when deciding whether to continue with a troubled project.
• Law of Diminishing Returns: after a certain point, adding
more input/resource will not produce a proportional increase
in productivity.
80. Why have a Project Charter
• It formally recognises (authorise) the existence of the
project, without it a project does not exist.
• It gives the project manager authority to spend money
and commit corporate resources.
• It provides high level requirements for the project. The
project charter is broad enough so it does not need to
change as the project changes.
81. Why have a Project Charter
• It provides direction on the project’s objectives and
management.
• Key project stakeholders should sign a project
charter to acknowledge agreement on the need and
intent of the project; a signed charter is a key output
of project integration management.
82. Develop Project Charter
The process of developing a document that formally authorizes a project or phase,
and documenting initial requirements that satisfy the stakeholders’ needs and
expectations.
83. Develop Project Charter
• Projects are authorized by someone external to the
project such as sponsor, PMO, portfolio steering
committee.
• The project charter can be created by them or
delegated to Project Manager.
84. Develop Project Charter: Inputs
• Statement of Work (SOW)
A narrative description of products or services to be
delivered by the project. The SOW references:
Business need
Product scope description
Strategic plan
• Business case
Provide the necessary information from business
standpoint to determine whether or not the project is
worth the required investment.
85. Develop Project Charter: Inputs cont’d
• Contract
Applicable when the project is being done for an external
customer.
• Enterprise Environmental Factors
Government or industry standards
Organization infrastructure
Marketplace conditions
• Organizational Process Assets
Organizational standard processes, policies
Templates
Historical information and lessons learned
86. Develop Project Charter: Tools & Techniques
• Expert Judgment
The expertise of individuals or groups with specialized
knowledge or training to assist with the technical or
management details.
They include:
Internal customers – people within the organization
Consultants
Stakeholders
Professional & technical associations
Industry groups
PMO
87. Develop Project Charter: Outputs
• The Project Charter
The project charter documents the business
needs, current understanding of the customer’s
needs, and the new product,
service, or result that it is intended to satisfy.
88. Develop Project Charter: Outputs cont’d
The project charter documents :
– Project purpose or justification
– Measurable project objectives and related success criteria
– High-level requirements
– High-level project description
– High-level risks
– Summary milestone schedule
– Summary budget
– Project approval requirements
– Assigned project manager, responsibility and authority level
– Name and authority of the sponsor or other person(s) authorizing
the project charter
89.
90.
91. Develop Project Management Plan
• The Develop Project Management Plan process includes
the actions necessary to define, integrate, and coordinate
all subsidiary plans into a project management plan.
• The Develop Project Management Plan process brings all
these subsidiary plans together, along with the outputs of
the Planning group processes, into one document called
the project management plan.
• The project management plan defines how the project is
executed, monitored and controlled, and closed.
92. Develop Project Management Plan
The process of documenting the actions necessary to define,
prepare, integrate and coordinate all subsidiary plans.
93. Develop Project Management Plan:
Inputs
• Project Charter
• Outputs from Planning Processes
Outputs from many of the planning processes described in
chapter 5 through 12 are integrated to create the project
management plan.
Any baselines and subsidiary management plans that are an
output from the other planning processes are inputs to this
process.
In addition, updates to these documents can necessitate
updates to the project management plan.
94. Subsidiary Management Plans
These subsidiary plans include, but are not limited to:
• Project scope management plan
• Schedule management plan
• Cost management plan
• Quality management plan
• Process improvement plan
• Staffing management plan
• Communication management plan
• Risk management plan
• Procurement management plan
95. Develop Project Management Plan:
Inputs
• EEF
Government or industry standards
PMIS
Organizational structure and culture
Infrastructure
Personnel administration
• OPA
Standardized guidelines, work instructions, evaluation criteria, etc.
Project management plan template
Change control procedures
Project files re: past projects
96. Project Management Plan (Output)
• The strategy for managing the project and the processes in
each knowledge area.
• Covers how you will define, plan, manage, and control the
project.
• How to handle a problem on a project?
look at your management plan to see how you planned to
handle such a problem.
• The project management plan can be either summary level or
detailed, and can be composed of one or more subsidiary
plans and other components. Each of the subsidiary plans and
components is detailed to the extent required by the specific
project.
97. The Project Management Plan
A Project Management Plan includes:
• Project Charter
• Budget
• Schedule
• Resources
• Scope Statement
• Responsibility charts/assignments
• Subsidiary Management Plans
98. Develop Project Management Plan (cont…)
Those other components include, but are not
limited to:
Milestone list
Resource calendar
Schedule baseline
Cost baseline
Quality baseline
Risk register
99. Project Baseline
Project baseline refers to the original version of
the project management plan. Once the project
management plan is base-lined, it may only be
changed by raising a change request.
100. Baseline (Performance measurement baseline)
• The project management plan contains scope, schedule, and cost baselines,
against which the project manager will need to report project
performance.
• Baseline created during planning.
Scope baseline
The project scope statement, work breakdown structure (WBS), and WBS
dictionary.
Schedule baseline
The agreed-upon schedule, including the start and stop times.
Cost baseline
The time-phased cost budget.
• Deviations from baselines are often due to incomplete risk identification
and risk management.
101. Configuration Management Plan
This plan describes how configuration
management will be performed on the
project.
The configuration management system
defines configurable items, such as product
specifications, and the change control
procedures on those items.
102. Configuration Management
• Ensures that the descriptions of the project’s products
are correct and complete.
• Involves identifying and controlling the functional and
physical design characteristics of products and their
support documentation.
• Configuration management specialists identify and
document configuration requirements, control changes,
record and report changes, and audit the products to
verify conformance to requirements.
103. Change Management Plan
• Describes how changes will be managed and controlled.
• Covers for the project as whole.
• May include:
- Change control procedures (how and who)
- The approval levels for authorizing changes
- The creation of a change control board to approve changes.
- A plan outlining how changes will be managed and controlled.
- Who should attend meetings regarding changes.
- Tools to use to track and control changes
Each knowledge area are described in the individual management plans
104. Requirements Management Plan
Describes how the requirements will be elicited,
analyzed, documented, prioritized, and managed
throughout the project.
Requirements drive the features and
characteristics of the project’s deliverables. This
plan is created in the Collect Requirements
process.
105. Stakeholder Analysis
• A stakeholder analysis documents important (often sensitive)
information about stakeholders such as:
– Stakeholders’ names and organizations.
– Their roles on the project.
– Unique facts about each stakeholder.
– Their level of influence on and interest in the project.
– Suggestions for managing relationships with each
stakeholder.
108. Kickoff Meeting
Kick-off meeting happens after the planning
phase and before the project execution. It is
typically used to communicate responsibilities
of key stakeholders.
109. Project Execution
• During project execution the project team
focuses on completing the tasks assigned.
• The Sponsor protects the project from
changes and loss of resources.
• The Project Manager integrates all the pieces
into the project as a whole.
110. Project Execution (Cont…)
• Project execution involves managing and
performing the work described in the project
management plan.
• The majority of time and money is usually
spent on execution.
• The products of the project are produced
during project execution.
111. Coordinating Planning and Execution
• Project planning and execution are intertwined
and inseparable activities.
• Those who will do the work should help to plan
the work.
• Project managers must solicit input from the
team to develop realistic plans.
112. Important Skills for Project Execution
• General management skills such as
leadership, communication, and political
skills.
• Product, business, and application area skills
and knowledge.
• Use of specialized tools and techniques.
113. Direct and Manage Project Execution
This process requires implementation of
approved changes covering:
• Corrective action
• Preventive action
• Defect repair
114. Direct & Manage Project Execution
This is the process for performing the work defined in the project management
plan to achieve the project’s objectives
115. Using Software to Assist in Project Integration Management
• Several types of software can be used to assist in project
integration management:
– Word processing software creates documents.
– Presentation software creates presentations.
– Spreadsheets or databases perform tracking.
– Communication software such as e-mail and Web authoring
tools facilitate communications.
• Project management software can pull everything together and
show detailed and summarized information. The exam does not focus
on any specific system (for example Microsoft Project ).
116. Project Execution: Tools and Techniques
• Project Management Information Systems:
Hundreds of project management software
products are available on the market today,
and many organizations are moving toward
powerful enterprise project management
systems that are accessible via the Internet.
117. Project Management
Information System (PMIS)
Project Management Information System
(PMIS) is a system that keeps track of status
of all the project tasks. It is used to track the
status of the project.
118. Change Requests
• When a change request is received, the following
steps must be taken (in this order):
• Evaluate (assess) the impact of change to the project
• Create alternatives including cutting other tasks,
crashing, fast-tracking etc.
• Meet with management, sponsors etc.
• Meet with the customer if necessary
119. Monitoring and Controlling Project
Work
• Changes are inevitable on most projects, so it’s
important to develop and follow a process to
monitor and control changes.
• Monitoring project work includes collecting,
measuring, and disseminating performance
information.
• Outputs of monitoring and controlling project work
include Change Requests, Project management plan
updates and project document updates.
120. Monitor & Control Project Work
•This process includes tracking, reviewing and regulating the progress to meet the
performance objectives defined in the project management plan.
121. Monitor & Control Project Work: Input
• Performance Reports : Reports should be prepared by
the project team detailing activities ,
accomplishments ,milestones ,identified issues and
problems . Performance reports can be used to report
the key information , but not limited to :
– Current status
– Significant accomplishments for the period
– Scheduled activities
– Forecasts
– Issues
122. Perform Integrated Change Control
The process of reviewing all change requests,
approving changes, and managing changes to
the deliverables, organisational process
assets, project documents and the project
management plan.
123. Perform Integrated Change
Control
• The integrated change control process is a control function
that is done from project initiating through project closing.
• This is where all the recommendations for changes,
corrective actions, preventive actions and defect repairs
are evaluated across all the knowledge areas and either
approved or rejected.
• Changes to any part of the project management plan or the
product of the project are handled in the integrated change
control process.
124. Integrated Change Control
• Three main objectives are:
– Influence the factors that create changes to
ensure that changes are beneficial.
– Determine that a change has occurred.
– Manage actual changes as they occur.
• A baseline is the approved project
management plan plus approved changes.
126. Change Control System
A formal, documented process that
describes when and how official
project documents and work may
be changed.
Describes who is authorized to make
changes and how to make them.
127. Change Control Board
Change Control Board is formed to review
change requests. It is used to approve or
reject change requests. After the project
scope has been baselined, each requested
change must go through a change control
review process.
128. Change Control Boards (CCBs)
• A formal group of people responsible for
approving or rejecting changes on a project.
• CCBs provide guidelines for preparing change
requests, evaluate change requests, and manage
the implementation of approved changes.
• CCBs include stakeholders from the entire
organization.
129. Configuration Management
• Ensures that the descriptions of the project’s products are
correct and complete.
• Involves identifying and controlling the functional and
physical design characteristics of products and their support
documentation.
• Configuration management specialists identify and document
configuration requirements, control changes, record and
report changes, and audit the products to verify conformance
to requirements.
130. Defines how you will manage changes to the deliverables and the resulting
documentation, including which organizational tools you will use.
PMIS
Configuration
Management System
Change Control System
131. Closing Projects
• To close a project, you must finalize all
activities and transfer the completed or
cancelled work to the appropriate people.
• Main outputs include:
– Administrative closure procedures.
– Contract closure procedures.
– Final products, services, or results.
– Organizational process asset updates.
132. Close Project or Phase
Projects come to an end for several reasons:
• They’re completed successfully.
• They’re canceled or killed prior to completion.
• They evolve into ongoing operations and no longer exist as
projects.
There are four formal types of project endings you might
need to know for the exam:
• Addition
• Starvation
• Integration
• Extinction
133. Close Project or Phase
• Addition- Projects that evolve into ongoing
operations are considered projects that end due to
addition; in other words, they become their own
ongoing business unit.
• Starvation- When resources are cut off from the
project or are no longer provided to the project, it’s
starved prior to completing all the
requirements and you’re left with an unfinished
project on your hands.
134. Close Project or Phase
• Integration- Integration occurs when the resources of the
project—people, equipment, property, and supplies— are
distributed to other areas in the organization or are
assigned to other projects.
• Extinction- This is the best kind of project end because
extinction means the project has been completed and
accepted by the stakeholders. As such, it no longer exists
because it had a definite ending date, the goals of the
project were achieved, and the project was closed out.
135. Close Project
The Close Project or Phase is the process of formal completion of all project related
activities.
136. Lessons Learned
At the end of each phase of a project, a lessons
learned document must be prepared. The lessons
learned document defines what was done right,
wrong etc. It is required to be completed in order
for the project to be completed.
Also called “Post – Mortem”
137. Assumptions
Assumptions are beliefs held to be true for the purposes
of the project – you don’t have to prove them, but they
must be documented in the Project Plan. As they are
assumptions then be aware that they have an element of
risk attached to them. If assumptions later turn out to be
false during the execution of the project then this may
lead to changes in project scope.
138. Project Constraints
Every project has to manage at least
three basic constraints; time, cost and
scope. The success of a project depends
on the skills and knowledge of a project
manager to take into consideration
these constraints and develop the plans
and processes to keep them in balance.
141. Project Scope Management
• Processes required to ensure that project includes all
the work required, and only the work required, to
complete the project.
• Managing a project scope is primarily concerned with
defining and controlling what is and is not included in
the project.
• Scope management defines how the deliverables of
project will be verified and accepted.
• Develop project management plan, under integration
produces the scope management plan which will
define how the scope shall be defined, verified and
controlled.
142. Scope management means:
• Not letting people randomly add to the scope
without a structured change control system.
• Making sure all changes fit within the project
charter.
• Preventing extra work or “gold plating”.
• Uncontrolled scope is called scope creep.
143. In the project context the term scope may refer to:
• Product scope : the features and functions that are to be
included in a product or service. Completion of product scope
is measured against requirements.
• Project scope : The work that must be done in order to deliver
a product with the specified features and functions.
Completion of project scope is measured against the project
management plan.
Both types of scope management must be well integrated to
ensure the work of the project will result in the delivery of the
specified product.
144. project scope, product scope & requirements
Example: Lets say you have a plot of land and you want to build a house
on it.
Product: The house
Product Scope: The house should have 3 storey's, 1000 sq. m of
built up area, 4 bedrooms with attached baths, 2 living room, a
kitchen, basement and a garage. The exteriors should be white.
Project Scope: Hiring a building contractor, an architect and an
interior designer, acquiring legal permits, estimating the cost, taking
bank loan, planning for risks such as rains and storms, designing the
house, buying building materials,
145. Example: project scope, product scope & requirements
constructing the house, conducting inspections, conducting
regular site visits to track the progress, resolving disputes,
Making payments and compensations, closing contracts and
moving in.
Requirements: In addition to product scope, there could be
other requirements for the house. Using a particular grade of
cement could be your quality requirements. Making the house
earthquake- proof could be a performance requirement. Getting
a weekly progress update from your contractor, and making
monthly payments could be your project management
requirements.
146. Documenting the Scope Management Plan
The scope management plan describes how the
project team will go about defining project scope,
verifying the work of the project, and managing and
controlling scope. The PMBOK Guide does not go
into detail regarding this plan, but there are some
things you may need to know about this plan for the
exam.
147. Project Scope Management Plan
The project scope management plan should contain the
following:
• The process you’ll use to prepare the project scope
statement.
• A process for creating the work breakdown structure
(WBS).
• A definition of how the deliverables will be verified for
accuracy and the process used for accepting
deliverables.
• A description of the process for controlling scope change
requests, including the procedure for requesting changes
and how to obtain a change request form.
149. Project Scope Management Processes:
• Collect Requirements : the process of defining and
documenting stakeholder’s needs to meet the project
objectives.
• Define Scope : the process of developing a detailed
description of the project and the product.
• Create WBS: the process of subdividing the project
deliverables and the project work into smaller, more
manageable components
• Verify Scope : the process of formalizing acceptance of the
completed project deliverables
• Control Scope : the process of monitoring the status of the
project and product scope and managing changes to the
scope baseline.
150. Requirements
• Requirements describe the characteristics of the
deliverables. They might also describe functionality
that a deliverable must have or specific conditions a
deliverable must meet in order to satisfy the
objective of the project.
• Requirements are typically conditions that must be
met or criteria that the product or service of the
project must possess in order to satisfy the
objectives of the project.
151. Collect Requirements• Collect requirements is the process of defining and
documenting stakeholders’ needs to meet the project
objectives .
• Requirements include the quantified and documented needs
and expectations of the sponsor, customer, and other
stakeholders.
• These requirements need to be elicited , analyzed, and
recorded in enough detail to be measured once project
execution begins .
• Collecting requirements is defining and managing customer
expectations . Requirements become the foundation of the
WBS. Cost , Schedule, and quality planning are all built upon
these requirements
152. Collect Requirements
• The development of requirements begins with an
analysis of the information contained in the project
charter and the stakeholder register .
• Many organizations categorize requirements into
project requirements and product requirements
• Project requirements : business requirements, project
management requirements ,delivery requirements etc
• Product requirements: technical, security,
performance , etc
154. Collect Requirements: Tools &
Techniques
Interviews :
• Is a formal or informal approach to discover information
from stakeholders by talking to them directly
• It is typically performed by asking prepared and
spontaneous questions and recording the responses .
• Interviewing experienced project participants,
stakeholders and subject matter experts can aid in
identifying and the defining the features and the
functions of the desired project deliverables .
155. Collect Requirements – Tools &
Techniques
Focus Groups :
• Focus groups bring together prequalified
stakeholders and subject matter experts to learn
about their expectations and attitudes about a
proposed product, service, or result .
• A trained moderator guides the group through an
interactive discussion , designed to be more
conversational than a one-on-one interview
156. Collect Requirements – Tools &
Techniques
Facilitated workshops:
Cross-functional stakeholders come together in a
facilitated workshop to discuss and define requirements
that affect more than one department. For example, if
you’re implementing a software package that impacts
several business units, you’ll need representatives from
each unit together in a workshop so that each of their
needs are represented and prioritized. This way, all the
participants understand the various needs and have
a facilitated forum to discuss and resolve their issues.
157. Collect Requirements – Tools &
Techniques
Group Creativity Techniques : Group creativity
involves several techniques, like brainstorming,
nominal group technique, the delphi technique, and
affinity diagrams.
• Brainstorming : a technique used to generate and
collect multiple ideas related to the project and
product requirements .
158. Collect Requirements – Tools &
Techniques
Group Creativity Techniques :
• Nominal Group Technique : enhances
brainstorming with a voting process used to
rank the most useful ideas for further
brainstorming or prioritization (Brainstorming
+ Voting)
159. Collect Requirements – Tools &
Techniques
Group Creativity Techniques :
• The Delphi Technique is an anonymous
method to query experts. Delphi technique
uses an experienced Facilitator.
• The responses are only available to the
facilitator.
• Participants can express ideas or opinions
without fear or being intimidated.
160. Collect Requirements – Tools &
Techniques
Group Creativity Techniques :
• Idea/mind mapping : ideas created through
individual brainstorming are consolidated into a
single map to reflect commonality and differences in
understanding , generate new ideas (Brainstorming
+Map).
• Affinity Diagram : this technique allows large
number of ideas to be sorted into groups for review
and analysis
161. Collect Requirements – Tools &
Techniques
Group Decision Making Techniques : there are
multiple
methods of reaching a group decision :
• Unanimity :everyone agrees on a single course of
action
• Majority : support from more than 50% of the
members of the group.
• Plurality : the largest block in a group decides even
if a majority is not achieved.
• Dictatorship : one individual makes the decision for
the group
162. Collect Requirements – Tools &
Techniques
Questionnaires and Surveys:
This technique involves querying a large
group of participants via questionnaires or
surveys. These tools allow you to gather
information quickly and apply statistical
analysis, if needed, to the results.
163. Collect Requirement : Tools &
TechniquesObservation:
This technique is typically a one-on-one experience
where an observer sits side by side with the
participant to observe how the participant interacts
with the product or service. This technique is also
known as job shadowing. For example, you may use
this technique to determine requirements for an
upgrade to a software product. Sitting with the user
and watching their interactions with the product
enables the observer to uncover requirements they
would not have ordinarily discovered.
164. Collect Requirements – Tools &
Techniques
Prototypes :
Prototyping is a technique involving constructing a
working model or mock-up of the final product for
participants to experiment with. The prototype does not
usually contain all the functionality the end product
does, but it gives participants enough information that
they can provide feedback regarding the mock-up. This is
an iterative process where participants experiment and
provide feedback and the prototype is revised and the
cycle starts again
165. Balance Stakeholder’s Requirement
• There is a need to balance stakeholder’s requirement.
• Some issue are so complex they cannot be resolved by PM alone.
• Facilitate the resolution of competing requirement, consider:
1. business case,
2. project charter,
3. project scope statement,
4. project constraints
What you can do:
Conflict resolution, team building, meeting, problem solving skills, escalation,
approval from stakeholder.
• Stakeholder request to do or add something that is not related to the reason
of project created should be rejected!
166. Collect Requirements: Outputs
Requirements Documentation
As mentioned earlier, requirements quantify and prioritize
the wants, needs, and expectations of the project sponsor
and stakeholders. Requirements typically start out high-level
and are progressively elaborated as the project progresses.
You must be able to track, measure, test, and trace the
requirements of the project. If you can’t measure or test
whether the requirement satisfies the business need of the
project, the definition of success is left to the subjective
opinions of the stakeholders and team members.
167. Requirements Documentation
The requirements document may include the following elements:
• Business need for the project and why it was undertaken
• Objectives of the project and the business objectives the
project hopes to fulfill
• Functional requirements and Nonfunctional requirements
• Quality requirements
• Acceptance criteria
• Business rules
• Organizational areas and outside entities impacted
• Support and training requirements
• Assumptions and constraints
168. Collect Requirements- Outputs
Requirements Management Plan :
• Documents how requirements will be analyzed , documented
and managed throughout the project.
• The type of phase relationship you choose to manage the
project will determine how requirements are managed
throughout the project. For example, in a sequentially phased
project, it’s possible to define requirements in later phases of
the project after some work has been completed. In an
overlapping phased relationship, you’ll need to define and
document most all the requirements early in the life cycle.
• Configuration management is often used to manage and track
changes to deliverable (product, service or result)
requirements.
169. Requirements Management Plan
The Requirements Management Plan should include the following:
• How planning, tracking, and reporting of requirements activities
will occur
• How changes to the requirements will be requested, tracked, and
analyzed along with other configuration management activities
• How requirements will be prioritized
• What metrics will be used to trace product requirements
• What requirements attributes will be documented in the
traceability matrix
• Remember that the requirements management plan can be
considered a subsidiary management plan and be included in the
project management plan.
170. Requirements Traceability Matrix
It is a matrix that links requirements to their origin and traces
them throughout the project life cycle .It helps to ensure that
requirements approved in the requirements documentation are
delivered at the end of the project. It can include:
• Unique identifier
• Textual description
• Rationale
• Owner source
• Status
• Date Completed
172. Define Scope
Scope is collectively the product, service, or result of the
project.
Now that you’ve documented the project requirements,
you’re ready to further define the needs of the project in the
Define Scope process. The project scope statement (an output
of this process) is what you’ll use to develop and document a
detailed description of the deliverables of the project and the
work needed to produce them. This process is progressively
elaborated as more detail becomes known.
173. Define Scope
This is the process of developing a detailed description of the project and
product
174. Define Scope – Tools and Techniques
1. Product Analysis
• The purpose of product analysis is to analyze the objectives stated
by the customer or sponsor and turn them into real requirements.
(Product breakdown, systems analysis, value engineering,
requirements analysis and value analysis).
2.Alternative Identification
• Identifying alternatives is a technique used to generate different
approaches to execute and perform the work of the project.
Brainstorming
Lateral Thinking
Pair wise comparison
175. Lateral Thinking
Lateral thinking is a form of alternatives
identification that can be used to help define scope.
Edward de Bono created this term and has done
extensive research and writing on this topic. The
simplest definition is that it’s thinking outside the
box.
Lateral thinking is a process of separating the problem, or in
our case the components of project scope (the deliverables
and requirements), looking at them from angles other than
their obvious presentation and encouraging team members
to come up with ways to solve problems or look at scope that
are not apparently or obvious.
176. Lateral Thinking Example
Question: How could your pet Yorkie fall from the
window of an 18-story building and live?
Answer: The question asks how your pet could fall
from an 18-story building and live; however, the
question doesn’t state that your pet fell from the
18th floor. So, your pet Yorkie fell from the
basement-level window.
177. Define Scope - Outputs
Project Scope Statement
• Project scope statements describes, in detail
(remember SOW), project deliverables and
work required to create these deliverables.
• It helps to create a common understanding
among stakeholders (avoid scope creep)
• Project team can perform detailed planning
now
179. What is Work Breakdown Structure (WBS)?
The PMBOK Guide describes a WBS as “a deliverable-oriented
hierarchical decomposition of the work to be executed by the project
team, to accomplish the project objectives and create the required
deliverables…the WBS defines the total scope of the project.” Like the
Scope statement, the WBS serves as a foundational agreement among
The stakeholders and project team members regarding project scope.
Work that doesn’t fit into the WBS does not fit within the project.
• Projects are normally too big to manage and WBS breaks the project
works into smaller more manageable components arranged according
to deliverables.
• This is a top down effort, break works down from top to bottom.
180. Create WBS
• Each level of WBS is a smaller piece of the level
above.
• The top most level of each WBS is the total project
itself.
• Work is broken down to the lowest level possible till
further division is logically not possible or the work
can be confidently estimated and scheduled.
• WBS represents total work specified in the current
approved scope statement and shall be revised if a
major scope change occurs.
181. Create WBS Cont’
• Work package: lowest level WBS component which can
be scheduled, cost estimated, monitored and controlled.
• WBS Structure can be organized by
- Phases
- Major deliverables
- Subprojects e.g. contracted work.
• Beware of excessive decomposition. It can lead to non-
productive management effort, inefficient use of
resources (performing work)
182. Control Accounts
• Unique identifiers are normally taken from the
organization’s code of accounts to track cost by category.
• Each item in WBS need to be estimated, resourced,
budgeted and controlled. If management need to measures
Performance (budget & time), WBS shall be linked to
accounting system.
• Normally control account is placed in WBS for this purpose.
• Control account is placed above work package level in WBS
• Each control account may have more than one work
package but one work package shall only be linked to one
control account.
183. 100% Rule
• Each WBS levels represents a breakdown of WBS
level above.
• Lowest level in the WBS is called work package
• If the lowest levels are rolled up to the higher levels,
the total must represents the total work of the
project. This is called 100% rule.
• This ensures that no work is left out or no extra work
is added.
184. Develop WBS
100% rule: WBS includes 100% of the work defined by project scope and capture ALL deliverables (external,
internal, interim) in term of work to be completed including project management.
185. Develop WBS: Tool & Technique
Decomposition
• This technique involves breaking down the
deliverables into smaller, more manageable
components of work.
• The idea here is to break down the deliverables to a
point where you can easily plan, execute, monitor
and control, and close out the project deliverables.
• Each level of WBS is a more detailed definition of the
level above it.
188. WBS Dictionary
In order to more clearly define the work necessary for project completion the WBS Dictionary is
used. The WBS Dictionary includes but not limited to the following: level, WBS element, element
name, description of work, deliverable.
189. WBS Dictionary
WBS dictionary should include the following elements for each
component of the WBS:
• Code of accounts identifier
• Description of the work of the component
• Organization responsible for completing the component
• List of schedule milestones
• Required resources
• Cost estimates
• Quality requirements
• Criteria for acceptance
• Technical references
• Contract information
190. Scope Baseline
The Scope Baseline is a component of the
project management plan and include the
following:
• Project scope statement
• Work Breakdown Structure (WBS)
• WBS Dictionary
191. Verify Scope
• It is the process of obtaining formal
acceptance of the project scope by the
stakeholders.
• It requires reviewing deliverables and work
results to ensure that all were completed
correctly and satisfactorily
• If the project is terminated early, the scope
verification process should establish and
document the level and extent of completion
192. Verify Scope Cont’d.
• Scope verification is concerned with
acceptance of deliverables but Quality control
is concerned with meeting the quality
requirements specified.
• Quality control is normally performed prior to
scope verification but both may be performed
in parallel.
194. Verify Scope : Tools & Techniques
Inspection
• To complete scope verification, the work must be inspected.
• This may require measuring, examining, and testing the
product to prove it meets customer requirements.
• Inspection usually involves the project manager and customer
inspecting the project work for verification, which in turn
results in acceptance.
• Depending on the industry, inspection may also be known as:
Reviews, Product Reviews, Audits & Walkthroughs.
195. Verify Scope : Outputs
• Accepted Deliverables: This is a formal process that requires
signed documentation of the acceptance by the sponsor or
customer.
• Change Requests : those completed deliverables that have
not been accepted are documented , along with the reasons
for non-acceptance . Those deliverables may require a change
request for defect repair .
• Project Document Updates : Project documents that may be
updated include any documents that define the product or
report status on product completion
196. Control Scope
• Monitor the status of project and product
scope and manages any changes to scope
baseline.
• Is part of integrative change control.
• Uncontrolled scope changes result in scope
creep.
197. Control Scope
The process of monitoring the status of the project and product scope and managing changes to
the scope baseline.
198. Control Scope – Tools &
Techniques
1. Variance Analysis :
• Project performance measurements are used to assess
the magnitude of variation from the original scope
baseline .
• Important aspects of the project scope control include
determining the cause and the degree of variance
relative to the scope baseline and deciding whether
corrective or preventive action is required
199. Control Scope - Outputs
1.Work Performance Measurements: Measurements can include
planned vs. actual technical performance or other scope
performance measurements. This information is documented and
communicated to the stakeholders.
2. Change Requests : change requests to the scope baseline or other
components of the project management plan. Change requests can
include preventive or corrective actions or defect repairs .
3. Project Management Plan Updates :
• Scope Baseline Updates
• Other Baseline Updates
4. Project Document Updates : requirements documentation update,
requirements traceability matrix updates , etc
200. Scope Change
Changes to scope will likely require that you repeat
some of the project planning processes and make
any needed adjustments, including updating the
project documents. Scope changes require an update
to the project scope statement. This may require an
update to the WBS and WBS dictionary as well.
Scope baseline updates are part of the project
management plan updates.
201. Scope Change Cont’d
Scope changes include any changes to the project
scope as defined by the agreed upon WBS. This in
turn might require changes or updates to project
objectives, costs, quality measures or controls,
performance measurements baselines, or time in the
form of schedule revisions. Scope changes almost
always affect project costs and/or require schedule
revisions
202. You are the project manager of a project.
You have just completed the Collect
Requirements and Define Scope. What
should you do next?
A. Control Scope
B. Create WBS
C. Value analysis
D. Verify Scope
QUESTION NO: 1
203. QUESTION NO: 2
A summary WBS is usually developed in the:
A. close-out phase
B. Conceptual phase
C. implementation phase
D. planning phase
204. QUESTION NO: 3
The work that must be done in order to deliver
a product with the specified features and
functions is:
A. Project verification
B. Project scope
C. Project control
D. Product scope
205. QUESTION NO: 4
The project manager is assigned in the?
A. Management Plan
B. SOW
C. Charter (contract)
D. Planning Stage
206. QUESTION NO: 5
You are a project manager for Dutch Harbor Consulting. Your
latest project involves the upgrade of an organization's operating
system on 236 servers. You performed this project under contract.
You are in the closing process and know that product verification
is for what purpose?
A. To verify that all the work was completed correctly and satisfactorily
B. To evaluate project goals and ensure that the product of the project
meets the requirements
C. To verify the goals of the project and ensure that the product of the
project is complete
D. To evaluate all the work of the project and compare the results to
project scope
208. TIME MANAGEMENT
The PMBOK states that Project Time
Management is the Knowledge Area that
“includes the processes required to
accomplish timely completion of the project.
209. TIME MANAGEMENT
Project Time Management Processes:
• Activity Definition
• Activity Sequencing
• Activity Resource Estimating
• Activity Duration Estimating
• Schedule Development
• Schedule Control
210. Process Groups & Time ManagementProcess Groups & Time Management
ActivitiesActivities
Initiating PlanningPlanning Executing ControllingControlling Closing
Activity DefinitionActivity Definition
Activity SequencingActivity Sequencing
Resource EstimatingResource Estimating
Duration EstimatingDuration Estimating
ScheduleSchedule
DevelopmentDevelopment
Schedule ControlSchedule Control
211. Project Time Management Processes
• Activity definition: Identifying the specific activities that the project
team members and stakeholders must perform to produce the
project deliverables.
• Activity sequencing: Identifying and documenting the relationships
between project activities.
• Activity resource estimating: Estimating how many resources a
project team should use to perform project activities.
• Activity duration estimating: Estimating the number of work periods
that are needed to complete individual activities.
• Schedule development: Analyzing activity sequences, activity
resource estimates, and activity duration estimates to create the
project schedule.
• Schedule control: Controlling and managing changes to the project
schedule.
211
212. Define Activity
• Involves identifying and documenting the work that
is planned to be performed
• This process identifies the deliverables at the lowest
level of the work breakdown structure (WBS), called
the work package
• The work package is then broken down into smaller
components called schedule activities
*These provide a basis for estimating, scheduling, executing, and
monitoring and controlling the project work
213. 1.Define Activity1.Define Activity
Inputs
01. Scope
Baseline
02. OPA
03. EEF
04. Constraints
05. Assumptions
Outputs
01. Activity list
02. Activity
Attributes
03. Milestones list
Tools & Techniques
01. Decompositions
02. Templates
03. Rolling Wave
Planning
04. Expert Judgment
Identifying the specific activities that must be performed to produce the various
project deliverables.
214. – The Project Management Plan contains the
schedule management plan, which provides
guidance on the development and planning of
schedule activities.
– Decomposition: The process of subdividing the
project work packages into smaller, more
manageable components called schedule
activities.
215. Define Activity ( Tools & Techniques)
Templates
• A standard activity list or a portion of an activity list
from a previous project can often be used as a
template.
Rolling Wave Planning
• A form of progressive elaboration planning where
the work to be accomplished at the near term is
planned in detail at a low level of the WBS, while
the work far in the future is planned at relatively
high levels of the WBS.
216. Rolling Wave Plan
• Detailed decomposition of work may not be
possible for works that will be completed in
the future since project team is not fully
aware of details of work. Team waits for the
more details and only work in the near future
is decomposed. This is called Rolling Wave
Planning
• Work in the near term is elaborated in more
detail than work to performed in the future.
217. Expert judgment, in the form of project team
members with prior experience developing project
scope statement
Milestone list (Output) are typically major
accomplishments of the project and mark the
completion of major deliverables or some other
key event in the project. For example, approval and
sign-off on project deliverables might be
considered milestones.
218. Define Activity (Outputs)
• An activity list is a tabulation of activities to be included on
a project schedule. The list should include:
– The activity name
– An activity identifier or number
– A brief description of the activity
• Activity attributes provide more information about each
activity, such as predecessors, successors, logical
relationships, leads and lags, resource requirements,
constraints, imposed dates, and assumptions related to the
activity.
220. Sequence Activities
• Activity list prepared are now logically sequenced.
• A dependency or relationship between activities established.
• Dependencies shall be determined in order to use critical
path analysis.
• Can be performed by using manual or automated techniques
or project management software
222. Dependency Determination
• Mandatory dependencies: Also referred to as hard logic Required
as per contract or inherent in the nature of the work. Usually involve
physical limitations (e.g., you cannot build the ceiling until walls are
constructed) Are determined by the project management team during
the activity sequencing process.
• Discretionary dependencies: Also referred to as preferred logic,
preferential logic, or soft logic Are determined by the project
management team during the activity sequencing process Should be
used with care and well documented, since they may limit later
scheduling options.
223. External Dependency
• External dependencies: Are determined by the
project management team during the activity
sequencing process. Involve a relationship
between project and non-project activities
such as activities outside the project team’s
control (e.g., dependence on external sources
for deliveries, environmental factors governed
by statutes, etc
224. Network Diagrams
• Network diagrams are the preferred
technique for showing activity sequencing.
• A network diagram is a schematic display of
the logical relationships among, or sequencing
of, project activities.
• Two main formats are the Arrow and
Precedence diagramming methods.
224
225. Precedence Diagramming MethodPrecedence Diagramming Method
(PDM)(PDM)
• Activities are represented by boxes
• Arrows show relationships between activities
• More popular than ADM method as used by PM software
• Better at showing different types of dependencies
• In PDM, finish-to-start is the most common relationship
226. Precedence Diagramming
Method(PDM)
Includes four types of dependencies or logical relationships:
– Finish-to-start (FS)
– Finish-to-finish (FF)
– Start-to-start (SS)
– Start-to-finish (SF)
The PDM is also called Activity–On-Node (AON) and it does not
use dummy activities nor does it allow for loops or
conditional branches.
227. Arrow Diagramming Method (ADM)Arrow Diagramming Method (ADM)
• Uses arrows to represent activities
• Connects activities with nodes
• Uses only finish-to-start dependencies
• May require dummy activities to define relationships
228. PERT( Program Evaluation and Review
Technique)
• Program Evaluation and Review Technique (PERT) has the following
characteristics.
– It uses three estimates per activity - optimistic, pessimistic and most
likely
– It can be drawn only using AOA diagrams
– It can have dummy events
• PERT utilizes more information than CPM as it considers the "Pessimistic"
and "Optimistic" values in addition to the "Most Likely" value in its
calculations. The following are formula used by PERT -
Mean = (P + 4M + O)/6
Standard Deviation = (P-O)/6
Variance = ((P-O)/6)2
• GERT is another type of network diagram. It can support looping.
229. Applying Leads and Lags
• A Lead may be added to start an activity before the
predecessor activity is finished. Ex: Furniture may be
installed 2 weeks prior to completion of painting (Finish
to start relationship with 2 weeks lead)
• Lag introduces waiting period between activities. Lag
introduces a delay in the successor activity.
230. Sequence Activities : Outputs
1. Project Schedule Network Diagrams :
• It can be produced manually or by using a project
management software
• Project Schedule Network Diagrams are not final
schedule For the exam, know that, in its pure form, the
network diagram shows just dependencies.
2. Project Document Updates
231. Estimate Activity Resources
• All projects, from the smallest to the largest, require
resources. Before estimating activity durations, you must
have a good idea of the quantity and type of resources
that will be assigned to each activity
• The term resources in this case does not mean just
people; it means all the physical resources required to
complete the project.
• People
• Equipment
• Materials
232. 3. Estimate Activity Resources3. Estimate Activity Resources
Inputs
01. Activity list
02. Activity Attribute
03. Resource calendars
04. EEF
05. O.P.A
Outputs
01. Activity Resource
Requirements
02. Resource Breakdown
Structure (R.B.S)
03. Project Document Updates
Tools & Techniques
01. Expert judgment
02. Alternative Analysis
03. Published Estimating Data
04. Bottom Up Estimating
05. Project Management Software
-this process is concerned with determining the types of resources needed and in
what quantities for each schedule activity.
233. Resource Calendars( Input)- is a calendar that is used
To reflect specific working hours, vacations, leaves of
absence, and planned personal time for individual
resources. Resource calendars can be used for human
resources as well as equipment.
Alternative Analysis (Tool & Technique)-is used
When thinking about the methods you might use to
accomplish the activities your resources have been
assigned. Many times, you can accomplish an activity in
more than one way, and alternatives analysis helps
decide among the possibilities.
234. Estimate Activity ResourcesEstimate Activity Resources(Tools &
Techniques)
Published Estimating data- Estimating data may
include organizational guidelines, industry rates or
estimates, production rates, and so on.
Bottom Up Estimating-Bottom-up estimating is
A process of estimating individual schedule
activities or costs and then adding these
together to come up with a total estimate for the
work package.
235. Activity Resource EstimatingActivity Resource Estimating
(Outputs)(Outputs)
Activity Resource Requirements – Activity resource
requirements provide an estimate of the type and quantity
of resources needed to complete activities. The Schedule
Development process considers when the required
Resources will be used.
Resource Breakdown Structure (RBS) - The Resource
Breakdown Structure (RBS) displays the hierarchical
structure of the categories and types of resources needed.
236. Estimate Activity Durations
• Here the network diagram is updated by estimating duration
for each activities.
• The Activity Duration Estimating process attempts to estimate
the work effort and number of work periods needed to
complete each schedule activity.
• A person or team most familiar with work of the project shall
estimate duration to make it more accurate.
• All data and assumptions used for estimation shall be
documented for future analysis (remember this, we need this
information during the risk management process)
237. 4.4. Estimate Activity Durations
Inputs
01. Activity list
02. Activity Attribute
03. Activity Resource
Requirements
04. Resource
calendars
05. Project Scope
Statement
06. O.P.A
07. E.E.F
Outputs
01. Activity duration
estimates
02. Project Document
updates
Tools & Techniques
01. Expert judgment
02. Analogous
estimating
03. Parametric
Estimating
04. Three Point
Estimates
04. Reserve Analysis
(contingency)
- estimating the number of work periods that will be needed to complete
individual activities.
238. Analogous Estimating
Analogous Estimating, is a form of expert judgment
and is also known as Top-down Estimating.
Analogous estimates are typically less time
consuming and less costly than other estimating
techniques, but it’s also less accurate.
239. Estimate Activity Durations : Tools &
Techniques
Parametric Estimating
• Parametric estimate uses a statistical relationship between
historical data and other variables.
• More accurate than analogous estimate
• Example : A resource will take 20hrs per module and hence
1000 modules will take 50hrs (50X20 = 1000hrs)
• Estimation is done by multiplying quantity of work by labor
hours per unit of work.
240. Three-Point Estimates
Three-point estimates, as you can probably
guess, use three estimates that when
averaged come up with a final estimate. The
three estimates you’ll use in this technique are the
most likely estimate, an optimistic estimate, and a
pessimistic estimate.
Three-point estimates are needed for PERT estimates and Monte Carlo simulations
241. Three-Point Estimates
PERT analysis calculates An Expected t(E)
activity duration using a weighted average of
three estimates : t(E) = [to+4tm+tp]/6
• PERT analysis consider estimation
uncertainties and risks and hence accuracy of
estimate is improved.
242. Reserve Analysis
Reserve time, also called buffers, time reserves, or
contingency reserve in the PMBOK Guide, means a
portion of time that is added to the activity to
account for schedule risk or uncertainty. You might
choose to add a percentage of time or a set number
of work periods to the activity or the overall
schedule.
For example, you know it will take 100 hours to run new cable, you also know that sometimes you hit problem
areas when running the cable. To make sure you don’t impact the project schedule, you build in a reserve time of 10
percent of your original estimate to account for the problems you might encounter.
243. Activity Duration Estimates
You use the inputs and tools and techniques to
establish these estimates. Activity duration
estimates are an estimate of the required work
periods needed to complete the activity. This is a
quantitative measure usually expressed in hours,
weeks, days, or
months.
244. Develop Schedule
• The Develop Schedule process is the heart of
the Planning process group.
• The creation of the project schedule is
iterative. It’s rare for a schedule to get
created, approved, and implemented without
some iterative examination, arrangement, and
management input—though on smaller
projects it may be possible.
245. Develop Schedule
Schedule Management Plan
• A Guide to the PMBOK notes that the schedule
management plan (a subsidiary of the project
management plan) is produced as part of the
Develop Project Management Plan process and
contains the criteria for formatting, developing,
and controlling the project schedule.
247. Develop Schedule (tools &
Techniques)
Schedule Network Analysis
• Schedule network analysis is a technique that
generates the project schedule. It employs a
schedule model and various analytical
techniques, such as critical path method,
critical chain method, what-if analysis, and
resource leveling to develop the schedule.
248. Develop Schedule (Tools &
Techniques)
Critical path method (CPM) is a schedule network analysis
technique. It determines the amount of float, or schedule
flexibility, for each of the network paths by calculating the
earliest start date, earliest finish date, latest start date, and
latest finish date for each activity.
The critical path (CP) is generally the longest full path on the
project. Any project activity with a float time that equals zero
is considered a critical path task.
250. Floats
• Floats are not the same as lead or lag.
• Lead or lags are introduced (manually) to correct the
sequence while float is calculated in CPM method
• Float for all activities on critical path will be zero value.
• A forward pass through the network diagram determines the
early start and finish dates.
• A backward pass determines the late start and finish dates
251. Types of Floats (or Slacks)
Float time is also called slack time and there are three
types of float:
• Total Float – The amount of time an activity can be delayed
without delaying the project end date or milestone.
• Free Float – The amount of time an activity can be delayed
without delaying the early start date of successor activity.
• Project Float – The amount of time a project can be delayed
without delaying an externally imposed project completion
date (other than calculated by CPM) by customer.
253. Critical Chain Method
Critical chain method is a schedule network analysis
technique that will modify the project schedule by
accounting for limited or restricted resources. After the
project schedule network diagram is constructed using
duration estimates, dependencies, and constraints,
resource availability is entered into the scheduling tool.
The modified schedule is calculated and you’ll find that it
often changes the critical path. The new critical path
showing the resource restrictions is called the critical
chain.
254. Schedule Compression
Schedule compression is the method of shortening the
project schedule without changing the scope. Need for
compression occurs if a customer need a date
prior to the end date shown in original schedule or to
bring back a project schedule back to baseline.
• Crashing – This approach adds more resources to activities on
the critical path to complete the project earlier. Crashing
almost always result in increased cost. Many options are
considered and the option with maximum compression with
minimum cost impact is selected.
255. Schedule Compression
• Fast Tracking –Critical activities that would
normally be done in sequence are allowed to
be done in parallel or with some overlap. Fast
track may result in rework and increases risk.
Communication requirements increases
during fast tracking.
256. Develop Schedule: Outputs
The schedule can be displayed in a variety of
ways:
• Project Schedule Network Diagram
• Gantt Charts/ Bar Charts
• Milestone Charts
The purpose of the Schedule Development process is to
determine the start and finish date for the each of the project
activity. The project schedule should be approved and
signed off by stakeholders and functional managers.
This assures that they have read the schedule, understand the dates and resource
commitments, and will likely cooperate
257. Control Schedule
Schedule Control is concerned with:
1. Determining the current status of the project
schedule
2. Influencing the factors that create schedule changes.
3. Determining that the project schedule has changed,
and
4. Managing the actual changes as they occur.
258. 6. Control Schedule6. Control Schedule
Inputs
1.ProjectManagement
Plan
2. Project Schedule
3. Work Performance
Information
4. O. P.A
Outputs
1. Work performance
Measurements
2. Project Management
Plan Updates
3. Organizational
Process Assets
Updates
4. Change Requests
5. Project Document
Updates
Tools & Techniques
1. Performance reviews
2. Variance Analysis
3. Project management
software
4. Resource Leveling
5. What if Scenarios
6. Adjusting Leads &
Lags
7. Schedule Compression
8. Scheduling Tool
- controlling changes to the project schedule.
259. Control Schedule ( Tools & Techniques)
• Performance Reviews- Performance reviews
measure , compare, and analyze schedule performance
such as actual start and finish dates, percent complete, and
the remaining duration for the work in progress .
• Variance Analysis- Variance analysis is a key factor
in monitoring and controlling project time because this
technique helps determine variances in schedule start and
end dates.
260. Control Schedule : Outputs
The Schedule Control process has the following outputs:
1. Work Performance Measurements- Calculated
Schedule Variance (SV) and Schedule Performance Index
(SPI) are documented and communicated with
Stakeholders.
2. Organizational process asset updates (lessons
learned)
3. Change Requests – Approved schedule baselines shall
be only updated through integrative change control. SV &
SPI may result in change requests for baseline update for
baseline update.
4. Project Management Plan Update
5. Project Document updates – Schedule data
261. Schedule Control
• Perform reality checks on schedules.
• Allow for contingencies.
• Don’t plan for everyone to work at 100 percent
capacity all the time.
• Hold progress meetings with stakeholders and be
clear and honest in communicating schedule
issues.
263. Solution: SD = (P-O)/6 = (7-3)/6 = 2/3
Source: PMP Exam Prep by Rita Mulcahy
Q1. The estimate for a task is O = 3
days, P = 7 days, M = 4 days. What
is the standard deviation of the
task?
A. 5/6 of a day
B. 2/3 of a day
C. 1 ½ days
D. 5 2/3 days
264. Q2. A project has three critical paths.
Which of the following BEST
describes how this affects the
project?
A. It makes it easier to manage
B. It increases the project risk
C. It requires more people
D. It makes it more expensive
Source: PMP Exam Prep by Rita Mulcahy
265. Source: PMP Exam Prep by Rita Mulcahy
Q3. You are taking over a project and determine
the following: Task B has an early finish of
day 3, a late finish of day 6, and an early start
of day 2. Task L is being done by a hard-to-
get resource. The CPI is 1.1 and the SPI is 0.8.
Based on the information above, what would
you be most concerned about?
A. Float
B. Resources
C. Cost
D. Schedule
269. Project Cost Management
According to PMBOK, Project Cost Management
includes the processes involved in estimating,
budgeting, and controlling so that the project can be
completed within the approved budget costs. Project
Cost Management include the following processes:
• Estimate cost- The process of developing an
approximation of the monetary resources needed to
complete project activities.
270. Project Cost Management
• Determine Budget- The process of
aggregating the estimated cost of individual
activities or work packages to establish an
authorized cost baseline.
• Control Cost- The process of monitoring the
status of the project to update the project
budget and managing changes to the cost
baseline
271. Quick Facts Cost Management
• Costing is different from Pricing. Costing includes the
monetary resource required to complete the project
and pricing normally include a profit margin.
• Costing is based on WBS and controlled by Control
Accounts
• Costing shall be ideally done by the team who perform
the work
• Schedule get affected by funding and project manager
shall manage the link with organization.
• Final schedule can be done only after costing and final
costing can only be done after risk since risk
management involves budget for handling risk.
272. Project Cost Management
Life cycle costing
Project cost management should also consider the effect of project
decisions on the subsequent recurring cost of using, maintaining, and
supporting the product, service or result of the project.
• Value analysis (value engineering)
- Looking at less costly way to do the same work within the same scope.
• Law of Diminishing Returns
- E.g. adding twice resource to task may not get the task done in half
cost/time.
• Cost will also affect the schedule
• Cost risk vs. Type of contract
• Time value of money (depreciation)
273. Types of Cost
• Variable Costs
Change with the amount of production/work e.g. material,
supplies, wages.
• Fixed Costs
Do not change as production change e.g. set-up, rental.
• Direct Costs
Directly attributable to the work of project e.g. team travel,
recognition, team wages.
• Indirect Costs
overhead or cost incurred for benefit of more than one project.
E.g. taxes, fringe benefit, janitorial services
274. Estimate CostDeveloping an approximation or estimate of the costs of the resources
needed to complete a project.
275. Estimate Cost: Tools & Techniques
Bottom-up Estimating
• Cost estimation starts from bottom level.
• Each WBS work package is estimated and
rolled up to higher level.
• While this method is more expensive, it is also
one of the most accurate.