Project Management Body of Knowledge

(PMBOK)
Lecture # 5
12 Principles of Project Management
▶ Be a diligent, respectful, and caring steward (see Section 3.1)
▶ Create a collaborative project team environment (see Section 3.2).
▶ Effectively engage with stakeholders (see Section 3.3).
▶ Focus on value (see Section 3.4).
▶ Recognize, evaluate, and respond to system interactions (see Section 3.5).
▶ Demonstrate leadership behaviors (see Section 3.6).
▶ Tailor based on context (see Section 3.7).
▶ Build quality into processes and deliverables (see Section 3.8).
▶ Navigate complexity (see Section 3.9).
▶ Optimize risk responses (see Section 3.10).
▶ Embrace adaptability and resiliency (see Section 3.11).
▶ Enable change to achieve the envisioned future state (see Section 3.12)
Tailor Based on Context
Tailor Based on Context
• Adapting to the unique objectives, stakeholders, and complexity of
the environment contributes to project success
• Tailoring is the deliberate adaptation of approach, governance, and
processes to make them more suitable for the given environment and
the work at hand. Project teams tailor the appropriate framework
that will enable the flexibility to consistently produce positive
outcomes within the context of the life cycle of the project.
Tailor Based on Context
• The business environment, team size, degree of uncertainty, and
complexity of the project all factor into how project systems are
tailored
• Project systems can be tailored with a holistic perspective, including
the consideration of interrelated complexities. Tailoring aims to
maximize value, manage constraints, and improve performance by
using “just enough” processes, methods, templates, and artifacts to
achieve the desired outcome from the project.
Tailor Based on Context
• Together with the PMO and considering governance, project teams
discuss and decide on the delivery approach and resources required
for producing outcomes on a project-by-project basis. This includes
the selection of the processes to use, development approach,
methods, and artifacts needed to deliver the project outcomes.
Tailoring decisions can be an implicit action of accepting an
established methodology. Conversely, tailoring can be an explicit
action of selecting and mixing specific elements to suit the unique
characteristics of the project and the project environment. Tailoring is
necessary to some degree in every project, because each project
exists in a particular context.
Tailor Based on Context
• Projects are often unique, even when the deliverable of the project
does not seem unique. This is because project contexts differ in that
the organization, its customers, its channels, and its environment are
dynamic elements. Those changes and ongoing learning may cause
project teams to use or develop different methods or approaches in
pursuit of success. The project team should examine the unique set of
conditions for each project, so that they can determine the most
appropriate methods of producing the desired outcomes.
Tailor Based on Context
• An existing methodology or common way of working can inform the
way in which a project is tailored. A methodology is a system of
practices, techniques, procedures, and rules used by those who work
in a discipline. Project teams may be required to assume the
methodology of the parent organization. That is, the project team
adopts a system of processes, governance, methods, and templates
that provide guidance on how to run the project. While this provides
a degree of consistency to projects within an organization, the
methodology itself may still need tailoring to suit each project.
Organizational policies and procedures prescribe authorized
boundaries within which the project team can tailor.
8th Principle: Build quality into processes and
deliverables
Quality
• Quality is the degree to which a set of inherent characteristics of a
product, service, or result fulfills the requirements. Quality includes
the ability to satisfy the customer’s stated or implied needs. The
product, service, or result of a project (referred to here as
deliverables) is measured for the quality of both the conformance to
acceptance criteria and fitness for use.
Quality Dimensions
▶ Performance

▶ Conformity

▶ Reliability

▶ Resilience

▶ Satisfaction

▶ Uniformity

▶ Efficiency
Quality Dimensions
 Performance. Does the deliverable function as the project team and
other stakeholders intended?
 Conformity. Is the deliverable fit for use, and does it meet the
specifications?
 Reliability. Does the deliverable produce consistent metrics each
time it is performed or produced?
 Resilience. Is the deliverable able to cope with unforeseen failures
and quickly recover?
Quality Dimensions
Satisfaction. Does the deliverable elicit positive feedback from end
users? This includes usability and user experience?
 Uniformity. Does the deliverable show parity with other deliverables
produced in the same manner?
 Efficiency. Does the deliverable produce the greatest output with the
least amount of inputs and effort?
 Sustainability. Does the deliverable produce a positive impact on
economic, social, and environmental parameters?
Quality
• Project teams measure quality using metrics and acceptance criteria
based on requirements. A requirement is a condition or capability
that is necessary to be present in a product, service, or result to
satisfy a need. Requirements, either explicit or implicit, may come
from stakeholders, a contract, organizational policies, standards, or
regulatory bodies, or a combination of these. Quality is closely linked
to the product acceptance criteria, as described in the statement of
work or other design documents. These criteria should be updated as
experimentation and prioritization occur and validated as part of the
acceptance process.
Quality
• Quality is also relevant to the project approaches and activities used
to produce the project’s deliverables. While project teams evaluate
the quality of a deliverable through inspection and testing, project
activities and processes are assessed through reviews and audits. In
both instances, quality activities may focus on detection and
prevention of errors and defects.
Quality
• The objective of quality activities is to help ensure that what is
delivered meets the objectives of the customer and other relevant
stakeholders in the most straightforward path. The intention is to
minimize the waste of resources and maximize the probability of
attaining the desired outcome. This results in:
Moving the deliverables to the point of delivery quickly, and
Preventing defects in the deliverables or identifying them early to avoid or
reduce the need for rework and scrap.
• The objective of quality activities is the same whether dealing with an
up-front, well-defined set of requirements or a set of requirements
that are progressively elaborated and incrementally delivered.
Quality
• Quality management processes and practices help produce
deliverables and outcomes that meet project objectives and align to
the expectations, uses, and acceptance criteria expressed by the
organization and relevant stakeholders. Close attention to quality in
project processes and deliverables creates positive outcomes,
including:
Project deliverables that are fit for purpose, as defined by acceptance criteria,
Project deliverables that meet stakeholder expectations and business
objectives,
Project deliverables with minimal or no defects,
Quality
• Close attention to quality in project processes and deliverables creates
positive outcomes, including:
 Timely or expedited delivery,
 Enhanced cost control,
 Increased quality of product delivery,
 Reduced rework and scrap,
 Reduced customer complaints,
 Good supply chain integration,
 Improved productivity,
 Increased project team morale and satisfaction,
 Robust service delivery,
 Improved decision making, and
 Continually improved processes.
9 th Principle: Navigate Complexity
Navigate Complexity
• A project is a system of elements that interact with each other.
Complexity is a characteristic of a project or its environment that is
difficult to manage due to human behavior, system behavior, and
ambiguity. The nature and number of the interactions determine the
degree of complexity in a project. Complexity emerges from project
elements, interactions between project elements, and interactions
with other systems and the project environment. Though complexity
cannot be controlled, project teams can modify their activities to
address impacts that occur as a result of complexity.
Navigate Complexity
• Project teams often cannot foresee complexity emerging because it is the
result of many interactions such as risks, dependencies, events, or
relationships. Alternatively, a few causes may converge to produce a single
complex effect, which makes isolating a specific cause of complexity
difficult.
• Project complexity occurs as the result of individual elements within the
project and project system as a whole. For example, complexity within a
project may be amplified with a greater number or diversity of
stakeholders, such as regulatory agencies, international financial
institutions, multiple vendors, numerous specialty subcontractors, or local
communities. These stakeholders can have a significant impact on the
complexity of a project, both individually and collectively.
Common Sources of Complexity

Human Behavior

System Behavior

Uncertainty and Ambiguity

Technological Innovation
Common Sources of Complexity
• Human behavior. Human behavior is the interplay of conduct,
demeanors, attitudes, and experience of people. Human behavior can
also contribute to complexity by introducing elements of subjectivity
such as personal agendas that conflict with the project’s goals and
objectives. Stakeholders located in remote locations may have
different time zones, speak different languages, and have different
cultural norms.
Common Sources of Complexity
• System behavior. System behavior is the result of dynamic
interdependencies within and among project elements. For example,
the integration of different technology systems may cause threats
that could impact project outcomes and success. The interactions
among components of the project system may lead to interconnected
risk, create emerging or unforeseeable issues, and produce unclear
and disproportional cause-and-effect relationships.
Common Sources of Complexity
• Uncertainty and ambiguity. Ambiguity is a state of being unclear, of
not knowing what to expect or how to comprehend a situation.
Ambiguity can arise from having many options or a lack of clarity on
the optimal choice. Unclear or misleading events, emerging issues, or
subjective situations can also lead to ambiguity.
Common Sources of Complexity
• Uncertainty is the lack of understanding and awareness of issues,
events, paths to follow, or solutions to pursue. Uncertainty deals with
the probabilities of alternative actions, reactions, and outcomes.
Uncertainty includes unknown unknowns and black swans, which are
emerging factors that are completely outside of existing knowledge or
experience.
• Within a complex environment, uncertainty and ambiguity can
combine to blur causal relationships to the point where probabilities
and impacts are ill defined. It becomes difficult to reduce uncertainty
and ambiguity to the point where relationships can be well defined
and therefore addressed effectively.
Common Sources of Complexity
• Technological innovation. Technological innovation can cause
disruption to products, services, ways of working, processes, tools,
techniques, procedures, and more. The introduction of desktop
computing and social media are examples of technological
innovations that have fundamentally changed the way project work is
performed. New technology, along with the uncertainty of how that
technology will be used, contributes to complexity. Innovation has the
potential to help move projects toward a solution, or to disrupt the
project when associated uncertainties are not defined, leading to
increased complexity.
10th Principle: Optimize Risk Responses
Risk
• A risk is an uncertain event or condition that, if it occurs, can have a
positive or negative effect on one or more objectives. Identified risks may
or may not materialize in a project.
• Project teams endeavor to identify and evaluate known and emergent
risks, both internal and external to the project, throughout the life cycle.
• Project teams seek to maximize positive risks (opportunities) and decrease
exposure to negative risks (threats). Threats may result in issues such as
delay, cost overrun, technical failure, performance shortfall, or loss of
reputation. Opportunities can lead to benefits such as reduced time and
cost, improved performance, increased market share, or enhanced
reputation.
Risk
• Project teams also monitor the overall project risk. Overall project risk is
the effect of uncertainty on the project as a whole. Overall risk arises from
all sources of uncertainty, including individual risks, and represents the
exposure of the stakeholders to the implications of variations in project
outcome, both positive and negative
• Project team members engage with relevant stakeholders to understand
their risk appetite and risk thresholds
• Risk appetite describes the degree of uncertainty an organization or
individual is willing to accept in anticipation of a reward
• Risk threshold is the measure of acceptable variation around an objective
that reflects the risk appetite of the organization and stakeholders. The risk
threshold reflects the risk appetite
Risk Response Strategies

Avoid

Mitigate

Accept

Transfer

Escalate
Strategies for threats
• Escalate. Escalation is appropriate when the project team or the project
sponsor agrees that a threat is outside the scope of the project or that the
proposed response would exceed the project manager’s authority.
Escalated risks are managed at the program level, portfolio level, or other
relevant part of the organization, and not on the project level. The project
manager determines who should be notified about the threat and
communicates the details to that person or part of the organization. It is
important that ownership of escalated threats is accepted by the relevant
party in the organization. Threats are usually escalated to the level that
matches the objectives that would be affected if the threat occurred.
Escalated threats are not monitored further by the project team after
escalation, although they may be recorded in the risk register for
information.
Strategies for threats
• Avoid. Risk avoidance is when the project team acts to eliminate the threat
or protect the project from its impact. It may be appropriate for high-
priority threats with a high probability of occurrence and a large negative
impact. Avoidance may involve changing some aspect of the project
management plan or changing the objective that is in jeopardy in order to
eliminate the threat entirely, reducing its probability of occurrence to zero.
The risk owner may also take action to isolate the project objectives from
the risk’s impact if it were to occur. Examples of avoidance actions may
include removing the cause of a threat, extending the schedule, changing
the project strategy, or reducing scope. Some risks can be avoided by
clarifying requirements, obtaining information, improving communication,
or acquiring expertise.
Strategies for threats
• Transfer. Transfer involves shifting ownership of a threat to a third
party to manage the risk and to bear the impact if the threat occurs.
Risk transfer often involves payment of a risk premium to the party
taking on the threat. Transfer can be achieved by a range of actions,
which include but are not limited to the use of insurance,
performance bonds, warranties, guarantees, etc. Agreements may be
used to transfer ownership and liability for specified risks to another
party.
Strategies for threats
• Mitigate. In risk mitigation, action is taken to reduce the probability
of occurrence and/or impact of a threat. Early mitigation action is
often more effective than trying to repair the damage after the threat
has occurred. Adopting less complex processes, conducting more
tests, or choosing a more stable seller are examples of mitigation
actions. Mitigation may involve prototype development (see Section
[Link]) to reduce the risk of scaling up from a bench-scale model of a
process or product. Where it is not possible to reduce probability, a
mitigation response might reduce the impact by targeting factors that
drive the severity. For example, designing redundancy into a system
may reduce the impact from a failure of the original component.
Strategies for threats
• Accept. Risk acceptance acknowledges the existence of a threat, but
no proactive action is taken. This strategy may be appropriate for low-
priority threats, and it may also be adopted where it is not possible or
cost-effective to address a threat in any other way. Acceptance can be
either active or passive. The most common active acceptance strategy
is to establish a contingency reserve, including amounts of time,
money, or resources to handle the threat if it occurs. Passive
acceptance involves no proactive action apart from periodic review of
the threat to ensure that it does not change significantly
Strategies for opportunities
• Escalate. This risk response strategy is appropriate when the project team
or the project sponsor agrees that an opportunity is outside the scope of
the project or that the proposed response would exceed the project
manager’s authority. Escalated opportunities are managed at the program
level, portfolio level, or other relevant part of the organization, and not on
the project level. The project manager determines who should be notified
about the opportunity and communicates the details to that person or part
of the organization. It is important that ownership of escalated
opportunities is accepted by the relevant party in the organization.
Opportunities are usually escalated to the level that matches the objectives
that would be affected if the opportunity occurred. Escalated opportunities
are not monitored further by the project team after escalation, although
they may be recorded in the risk register for information
Strategies for opportunities
• Exploit. The exploit strategy may be selected for high-priority
opportunities where the organization wants to ensure that the
opportunity is realized. This strategy seeks to capture the benefit
associated with a particular opportunity by ensuring that it definitely
happens, increasing the probability of occurrence to 100%. Examples
of exploiting responses may include assigning an organization’s most
talented resources to the project to reduce the time to completion, or
using new technologies or technology upgrades to reduce cost and
duration
Strategies for opportunities
• Share. Sharing involves transferring ownership of an opportunity to a
third party so that it shares some of the benefit if the opportunity
occurs. It is important to select the new owner of a shared
opportunity carefully so they are best able to capture the opportunity
for the benefit of the project. Risk sharing often involves payment of a
risk premium to the party taking on the opportunity. Examples of
sharing actions include forming risk-sharing partnerships, teams,
special-purpose companies, or joint ventures
Strategies for opportunities
• Enhance. The enhance strategy is used to increase the probability
and/or impact of an opportunity. Early enhancement action is often
more effective than trying to improve the benefit after the
opportunity has occurred. The probability of occurrence of an
opportunity may be increased by focusing attention on its causes.
Where it is not possible to increase probability, an enhancement
response might increase the impact by targeting factors that drive the
size of the potential benefit. Examples of enhancing opportunities
include adding more resources to an activity to finish early
Strategies for opportunities
• Accept. Accepting an opportunity acknowledges its existence but no
proactive action is taken. This strategy may be appropriate for low-
priority opportunities, and it may also be adopted where it is not
possible or cost-effective to address an opportunity in any other way.
Acceptance can be either active or passive. The most common active
acceptance strategy is to establish a contingency reserve, including
amounts of time, money, or resources to take advantage of the
opportunity if it occurs. Passive acceptance involves no proactive
action apart from periodic review of the opportunity to ensure that it
does not change significantly
11th Principle: Embrace Adaptability and
Resiliency
Embrace Adaptability and Resiliency
• Most projects encounter challenges or obstacles at some stage. The
combined attributes of adaptability and resiliency in the project
team’s approach to a project help the project accommodate impacts
and thrive
• Adaptability refers to the ability to respond to changing conditions
• Resiliency consists of two complementary traits: the ability to absorb
impacts and the ability to recover quickly from a setback or failure.
Both adaptability and resiliency are helpful characteristics for anyone
working on projects.
Embrace Adaptability and Resiliency
• A project rarely performs exactly as initially planned. Projects are
influenced by internal and external factors—new requirements,
issues, stakeholder influences, among other factors—which exist in a
system of interactions. Some elements within a project may fail or fall
short of expectations, requiring the project team to regroup, rethink,
and replan. On
Embrace Adaptability and Resiliency
• In a project environment, capabilities that support adaptability and
resilience include:
 Short feedback loops to adapt quickly;
 Continuous learning and improvement;
 Project teams with broad skill sets, coupled with individuals having extensive
knowledge in each required skill area;
 Regular inspection and adaptation of project work to identify improvement
opportunities;
 Diverse project teams to capture a broad range of experiences;
Embrace Adaptability and Resiliency
• In a project environment, capabilities that support adaptability and
resilience include:
Open and transparent planning that engages internal and external
stakeholders;
 Small-scale prototypes and experiments to test ideas and try new
approaches;
 Ability to leverage new ways of thinking and working;
 Process design that balances velocity of work and stability of requirements;
 Open organizational conversations;
 Diverse project teams with broad skill sets, cultures, and experience, coupled
with subject matter experts in each required skill area;
 Understanding from past learning of the same or similar endeavors;
Embrace Adaptability and Resiliency
• Envisioning outcomes rather than deliverables can enable solutions, harnessing a
better result than the one originally planned.
• Unexpected changes and circumstances in a project system can also present
opportunities. To optimize value delivery, project teams should use problem
solving as well as a holistic-thinking approach to changes and unplanned events.
When an unplanned event occurs, project teams should look for potential
positive outcomes that might be gained. For example, incorporating a change that
occurs late in a project time line could add competitive advantage by being the
first product in the market to offer the feature.
• Building adaptability and resiliency in a project keeps project teams focused on
the desired outcome when internal and external factors change, and it helps
them recover from setbacks. These characteristics also help project teams learn
and improve so that they can quickly recover from failures or setbacks and
continue making progress toward delivering value.
12th Principle: ENABLE CHANGE TO ACHIEVE
THE ENVISIONED FUTURE STATE
ENABLE CHANGE TO ACHIEVE THE
ENVISIONED FUTURE STATE
• Remaining relevant in today’s business environment is a fundamental
challenge for all organizations. Relevance entails being responsive to
stakeholder needs and desires. This requires continually evaluating
offerings for the benefit of stakeholders, rapidly responding to
changes, and acting as agents for change. Project managers are
uniquely poised to keep an organization prepared for changes.
Projects, by their very definition, create something new: they are
agents of change.
ENABLE CHANGE TO ACHIEVE THE
ENVISIONED FUTURE STATE
• Change management, or enablement, is a comprehensive, cyclic, and
structured approach for transitioning individuals, groups, and
organizations from a current state to a future state in which they
realize desired benefits. It is different from project change control,
which is a process whereby modifications to documents, deliverables,
or baselines associated with the project are identified and
documented, and then are approved or rejected.