PMBOK 7 READING NOTES

THE STANDARD FOR PROJECT MANAGEMENT

1 – Introduction
1.1 Purpose of The Standard for Project Management (PM)
 The standard applied regardless of industry, location, size or delivery approach (e.g., predictive, hybrid or
adaptive).
1.2 Key Terms and Concepts
 Outcome – an end result or consequence of a process or project with a broader intent by focusing on benefits
and value that project was undertaken to deliver.
 Portfolio – projects, programs, subsidiary portfolios, and operations managed as a group to acheve strategic
objectives.
 Product – an artifact that is produced, quantifiable and can be an end or component item.
 Program – related projects, programs and activities managed to obtain benefits not available from managing
them individually.
 Project – temporary endeavor to create a unique product, service or result with a beginning and end to the
project work of phase of the project. Can be a standalone or part of program or portfolio.
 Project Management – application of knowledge, skills, tools and techniques to meet project requirements.
 Project Manager – person assigned to lead the project team that is responsible for achieving the project
objectives.
 Project Team – set of individual performing the work of the project to achieve its objectives.
 System for Value Delivery – collection of strategic business activities aimed at building, sustaining, and/or
advancing an organization. Portfolios, programs, projects, products and operations can all be part of
organization’s system for value delivery.
 Value – worth, importance or usefulness of something. Different stakeholders perceive value in different
ways.
1.3 Audience For This Standard
 Foundational reference for stakeholders participating in a project including project practitioners, consultants,
educators, students, sponsors, stakeholders and vendors.

2 – A System for Value Delivery

2.1 Creating Value
 Projects exist within a larger system, such as governmental agency, organization or contractual arrangement.
 Organizations create value for stakeholders.
 Examples of projects that produce value include: creating a new product, service or result; creating positive
social/environmental contributions; improving efficiency, productivity, effectiveness or responsiveness;
enabling changes needed to facilitate transition to future state; sustaining benefits enabled by previous
programs/projects.
2.1.1 Value Delivery Components
 Various components that can be used individually and collectively to create value including portfolios,
programs, projects, products and operations.
 Working together, components comprise a system for delivering value that is aligned with the organizations
strategy.

1
 (Refer to image) A system for value delivery is part of an
organization’s internal environment subject to policies,
procedures, methodologies, frameworks, governance
structures, etc.
 Internal environment exists within external environment
(the economy, competitive environment, legislative
constraints, etc.).
 Example - the system can have two portfolios with
programs and projects. There can also be stand-alone
program with projects and stand-along projects not
associated with portfolios or programs. Any
projects/programs could include products.
 Operations can directly support and influence portfolios,
programs and projects, and other business functions such
as payroll, supply chain, management, etc.
 Portfolios, programs and projects influence each other as
well as operations.
 Components in value delivery system create deliverables used to produce outcomes. Outcomes create
benefits, i.e., gains realized by the organization. Benefits create value.
2.1.2 Information Flow
 A value delivery system works most effectively when information and feedback are shared consistently
among all components, keeping system aligned
with strategy and attuned to environment.
 Refer to image – black arrows represent
information from senior leadership onwards
sharing strategic info; portfolios share desired
outcomes, benefits, and value; deliverables and
info on support and maintenance are passed on to
operations.
 Refer to image – light grey arrows represent
reverse flow of info where info from operations
suggests adjustments, fixes and updates, as well
as how well strategy is advancing;
programs/projects provide performance info and progress; portfolios provide evaluations on performance.
2.2 Organizational Governance Systems
 Governance systems provide a framework with functions and processes that guide activities. The framework
can include elements of oversight, control, value assessment, integration among components and decision-
making capabilities.
 Provide an integrated structure for evaluating changes, issues and risks associated with the environment and
any component in the value delivery system, including portfolio objectives, program benefits and
deliverables.
 Project governance includes defining the authority to approve changes and make other business decisions
related to the project. It is aligned with program and/or organizational governance.
2.3 Functions Associated with Projects
 People drive project delivery by fulfilling functions necessary for the project to run effectively and efficiently.
 Decentralized coordination is where project team members self-organize and self-manage.
 Centralized coordination is with leadership and guidance of a designated project manager.
 Project team may be supported by additional functions depending on the deliverables, industry, organization,
and other variables.

2
 The needs of the project, organization and environment influence which functions are used on a project and
how they are carried out.
2.3.1 Provide Oversight and Coordination
 Function helps the project team achieve the project objectives by orchestrating the project work.
 Can include leading the planning, monitoring and controlling activities; may involve some evaluation and
analysis of activities; monitoring and working to improve the health, safety and overall well-being of project
team members.
 Also includes consulting with executive and business unit leaders, improving project performance, or meeting
customer needs. Can also include assisting in business analysis, tendering and contract negotiation and
business case development.
 Oversight involved in follow-on activities after project deliverables are finalized but before formal project
closure.
 Supports portfolios and programs when project is initiated and is tailored to fit the organization.
2.3.2 Present Objectives and Feedback
 Contribute perspectives, insights and clear direction from customers and end users.
 Projects need clear direction from customers and end users regarding project requirements, outcomes and
expectations.
 In adaptive and hybrid project environments, the need for ongoing feedback is greater because project teams
are exploring and developing product elements within specific increments.
 Sometimes the customer or end user engage with project team for periodic review and feedback, or a
representative of customer or client participates on project team.
2.3.3 Facilitate and Support
 Involves encouraging project team member participation, collaboration and a shared sense of responsibility
for the work output.
 Facilitation helps project team create consensus around solutions, resolve conflicts and make decisions. It’s
also required to coordinate meetings and contribute in unbiased way.
 Supporting people through change and helping address obstacles that can prevent success through evaluating
performance and providing feedback to help with learning, adapting and improving.
2.3.4 Perform Work and Contribute Insights
 Provides the knowledge, skills and experience necessary to produce the products and realize the outcomes of
the project.
 Gaining insights from cross-functional project team members representing different parts of the organization
can provide a mix of internal perspectives, establish alliances with key business units, and encourage project
team members to act as change agents within their functional areas.
2.3.5 Apply Expertise
 Provide the knowledge, vision and expertise in a specific subject for a project.
 Offer advice and support throughout the organization, and contribute to the project team’s learning process
and work accuracy.
 Can be external to the organization or internal project team members, required for the whole or part of the
project.
2.3.6 Provide Business Direction and Insight
 Involves prioritizing requirements or backlog items based on business value, dependencies and technical or
operational risk.
 Provide feedback to teams and set direction for next increment or element.
 Involves interacting with other stakeholders, customers and their project teams to define product direction.
 In adaptive and hybrid environments, direction and insight can be provided using specific cadence.
 In predictive environments, there can be designated checkpoints for presentation of and feedback on project
progress.
2.3.7 Provide Resources and Direction

3
 Advocate for the project and team by helping to secure decisions, resources and authority that allow project
activities to progress.
 Liaison between senior management and the project team, play a supporting role in keeping projects aligned
to business objectives, remove obstacles and address issues outside bounds of project team’s decision
authority.
 Provide an escalation path for problems, issues or risks that team cannot resolve or manage.
 Facilitate innovation by identifying opportunities within project and communicating with senior management.
 May monitor project outcomes after closure to ensure intended business benefits are realized.
2.3.8 Maintain Governance
 Approve and support recommendations made by project team and monitor project progress in achieving
desired outcomes.
 Maintain links between project teams and strategic/business objectives that can change over the course of the
project.
2.4 The Project Environment
 Internal and external environments can influence planning and other activities in a favourable, unfavourable
or neutral impact on project, stakeholders and teams.
2.4.1 Internal Environment
 Internal factors can arise from the organization itself, a portfolio, program, another project, or combination.
 Examples include:
o Process Assets – tools, methodologies, approaches, templates, frameworks, patterns or PMO
resources;
o Governance Documentation – policies and processes;
o Data Assets – databases, document libraries, metrics, data, artifacts from previous projects.
o Knowledge Assets – tacit knowledge among project team members, SMEs, other employees;
o Security and Safety – procedures and practices for facility access, data protection, levels of
confidentiality, proprietary secrets;
o Organizational Culture, Structure, & Governance – vision, mission, values, beliefs, cultural norms,
leadership style, hierarchy and authority relationships, organizational style, ethics, code of conduct;
o Geographic Distribution of Facilities and Resources – work locations, virtual project teams, shared
systems;
o Infrastructure – existing facilities, equipment, organizational and telecommunication channels, IT
hardware, availability, capacity;
o IT Software – scheduling software, configuration management systems, web interfaces to online
automated systems, collaboration tools, work authorization systems;
o Resource Availability – contracting and purchasing constraints, approved providers and
subcontractors, collaboration agreements, contracting and purchasing constraints, availability of
subcontractors, time lines;
o Employee Capability – general and specialized expertise, skills, competencies, techniques and
knowledge.
2.4.2 External Environment
 Examples include:
o Marketplace Conditions – competitors, market share, brand recognition, technology trends,
trademarks;
o Social and Cultural Influences and Issues – political climate, regional customs and traditions, public
holidays and events, code of conduct, ethics and perceptions;
o Regulatory Environment – national and regional laws/regulations related to security, data protection,
business conduct, employment, licensing and procurement;
o Commercial Database – standardized cost estimating data and industry risk study information;
o Academic Research – industry studies, publications and benchmarking results;

4
 o Industry Standards – products, production, environment, quality and workmanship;
o Financial Considerations – currency exchange rates, interest rates, inflation, taxes and tariffs;
o Physical Environment – working conditions and weather.
2.5 Product Management Considerations
 Product management involves the integration of people, data,
processes and business systems to create, maintain and
develop a product or service throughout its life cycle.
 Product management may initiate programs or projects at any
point in the product lifecycle to create or enhance specific
components, functions or capabilities to create additional
value for customers and sponsoring organization.
 Product management can exist in different forms, including:
o Program Management Within a Product Lifecycle –
incorporates related projects, subsidiary programs
and program activities. Does not work well with large
or long-running products;
o Project Management Within a Product Lifecycle –
oversees development and maturing of product capabilities as an ongoing business activity. Portfolio
governance charters individual projects as needed to perform enhancements and improvements or
product unique outcomes;
o Product Management Within a Program – applies the full product life cycle within boundaries of a
given program. A series of subsidiary programs/projects will be chartered to achieve specific benefits
for a product which can be enhanced through product management ideologies like competitive
analysis, customer acquisition and customer advocacy.

3 – Project Management Principles

 The 12 principles of PM are intended to guide behaviour of people involved in projects.
 PMI Code of Ethics and Professional Conduct is based on 4 values, which is complimentary to the principles:
o (1) Responsibility, (2) Respect, (3) Fairness, and (4) Honesty.
 The degree of principle application are influenced by context of the organization, project, deliverables, project
team, stakeholders, and other factors.
 No principle contradicts one another but they can overlap with each other, and can overlap with General
Management Principles.
 The 12 principles are:
o (1) Be a diligent, respectful and caring steward; (2) Create a collaborative project team environment;
(3) Effectively engage with stakeholders; (4) Focus on value; (5) Recognize, evaluate, and respond to
system interactions; (6) Demonstrate leadership behaviours; (7) Tailor based on context; (8) Build
quality into processes and deliverables; (9) Navigate complexity; (10) Optimize risk responses; (11)
Embrace adaptability and resiliency; (12) Enable change to achieve the envisioned future state.
3.1 Be a Diligent, Respectful, and Caring Steward
 Within the organization, stewardship includes:
o Operating in alignment with the organization, objectives, strategy, vision, mission and long-term
value;
o Commitment to and respectful engagement of project team members;
o Diligent oversight of organizational finances, materials and other resources;
o Understanding appropriate use of authority, accountability and responsibility.

5
 Outside of the organization:
o Environmental sustainability and use of
materials/natural resources;
o Relationship with external stakeholders;
o Impact of organization/project on market,
community and outside regions;
o Advancing state of practice in professional
industries.
 Stewards adhere to other duties including:
o Integrity – behave honestly and ethically in all
engagements and communications, serve as role
models, challenge team members/peers/other
stakeholders to consider their words and
actions, be empathetic, self-reflective and open
to feedback;
o Care – pay close attention and exercise same level of care over project matters for internal business
affairs as they would for personal matters, identify and communication potential downsides to project
outcome to stakeholders, create transparent working environment, open communication, opportunities
for stakeholders to raise concerns;
o Trustworthiness – protect projects from breaches of trust, represent themselves, their roles, their
project team and authority accurately, proactively identify conflicts between personal interests and
those of organizations or clients;
o Compliance – comply with laws, rules, regulations and requirements that are authorized within or
outside of organization.
3.2 Create a Collaborative Project Team Environment
 Involves contributing factors that support a culture which
enables individuals to work together and provide synergistic
effects from interactions:
o Team Agreements – set of behavioural parameters and
norms established by project team and upheld
through individual and project team commitment.
Should be created at the beginning of a project and
evolve over time to continue to work together
successfully;
o Organizational Structures – used to help coordinate
the individual effort associated with project work.
Are any arrangement of or relation between the elements of project work and organizational
processes. Can be based on roles, functions or authority. Examples include:
 Definitions of roles and responsibilities;
 Allocation of employees and vendors into project teams;
 Formal committees tasked with a specific objective;
 Standing meetings that regularly review a given topic;
o Processes – enable completion of tasks and work assignments.
 Project teams are influenced by the culture of the organization and can tailor their structure to best accomplish
project objective.
 By fostering inclusive and collaborative environments, knowledge and expertise are more freely exchanged.
 Clarity on roles and responsibilities can improve team culture. Regardless of who is accountable or
responsible, a collaborative project teams takes collective ownership of project outcomes:

6
 o Authority – having the right to make relevant decisions, establish or improve procedures, apply
project resources, expend funds or give approvals;
o Accountability – condition of being answerable for an outcome. It is not shared;
o Responsibility – being obligated to do or fulfill something. It can be shared.
 Other elements include diversity which can enrich environment by bringing together different perspectives,
different length of contracts to work on the project (i.e., short or long term basis) to challenge everyone
involved, and respect which allows for differences and leverage them productively.
 Incorporating standards, ethical codes, and other guidelines can help support possible conflict.
3.3 Effectively Engage with Stakeholders
 Stakeholders can affect projects including:
o Scope/Requirements – reveal need to add,
adjust, or remove elements of scope
and/or project requirements;
o Schedule – offer ideas to accelerate
delivery or slow down or stop delivery of
key activities;
o Cost – reduce or eliminate planned
expenditures or add steps, requirements,
restrictions that increase cost or require
additional resources;
o Project Team – restrict or enable access to people with skills, knowledge, and experience needed to
deliver the intended outcomes, and promote learning culture;
o Plans – provide information for plans or advocate for changes to agreed activities and work;
o Outcomes – enabling or blocking work required for the desired outcomes;
o Culture – establishing or influencing the level and character of engagement of the project team and
organization;
o Benefits Realization – generating and identifying long-term goals so that project delivers intended
value;
o Risk – defining risk thresholds of the project and participating in subsequent risk management
activities;
o Quality – identifying and requiring quality requirements;
o Success – defining success factors and participating in evaluation of success.
 Other stakeholder characteristics and engagement ideologies:
o May come and go throughout life cycle;
o Degree of interest, influence or impact may change over time;
o Need to be effectively engaged so that their interests, concerns and rights are understood – identify,
analyze and proactively engage with stakeholders from start to end to enable project success;
o Project team is a group of stakeholders which engages with other stakeholders;
o Communication is a key part of engagement but also includes awareness of ideas of others,
assimilation of other perspectives, and collective shaping of a shared solution;
o Engagement relies on interpersonal skills including taking initiative, integrity, honesty, collaboration,
respect, empathy and confidence which can increase likelihood of project success;
o Engagement helps project teams detect, collect and evaluation information, data and opinions creating
a shared understanding and alignment, which enables project outcomes.
 Stakeholder engagement enables opportunities for stronger project performance and outcomes in addition to
increasing stakeholders satisfaction, this helps the project team find solutions that may be more acceptable to
a broader range of stakeholders.

7
3.4 Focus on Value
 Value focuses on the outcome of the deliverables and
may be expressed as financial contribution, measure of
public good achieved, or customer’s perceived benefit.
 Many projects are initiated based on a business case
due to an identified need to delivery or modify a
process, product or service with the project intent to
provide the desired outcome that addresses the need
with a valued solution. Business cases contain
supporting and interrelated elements:
o Business Need – rationale for project, clear
statement of the business need which helps
project team understand the business drivers
for the future state and allows the project team to identify opportunities or problems to increase
potential value from project outcome;
o Project Justification – explains why the business need is worth the investment and why it should be
addressed at this time, accompanied by a cost-benefit analysis and assumptions;
o Business Strategy – reason for the project and all needs are related to strategy to achieve value.
 During project lifecycle, project can undergo change where the project team continuously evaluates project
progress and direction against the desired outputs, baselines and business case to confirm that the project
remains aligned to the need and will deliver its intended outcomes.
 Value is subjective where the same concept can have different values for different people and organizations.
Because all projects have a range of stakeholders, different values generated for each group of stakeholders
have to be considered and balanced with the whole, while placing priority on customer perspective.
 There may be different forms of value that maximize value to the customer, organization or other
stakeholders. If the project does not have a fixed, up-front scope, the team can optimize value by working
with the customer to determine which features are worth investment.
 To support value realization, project teams shift focus from deliverables to intended outcomes to allow project
teams to deliver on the vision/purpose, rather than simply creating a deliverable that may support the intended
project outcome, but may not fully achieve the vision or purpose of the project.
 Value contribution of project could be short or long-term measures, may be mixed with operational activities
and be difficult to isolate. A reliable evaluation of value should consider the whole context and entire life
cycle of project’s output.
3.5 Recognize, Evaluate, and Respond to System Interactions
 A system is a set of interacting and interdependent
components that function as a unified whole. A project
is multifaceted entity that exists in dynamic
circumstances, exhibiting the characteristics of a
system.
 A project works within other larger systems and a
project deliverable may become part of a larger system
to realize benefits. Interconnected structures are
known as system of systems.
 Project may also have subsystems that are required to
integrate effectively to deliver the intended outcome.
Requires project teams to interact and align subsystem work on a regular basis.
 Systems thinking considers timing elements of systems, such as what the project delivers or enables over
time. Project teams should think beyond the end of the project to the operational state of the project’s
deliverable, so that intended outcomes are realized.

8
 As projects unfold, internal and external conditions are continuously changing. With systems thinking,
including constant attention to internal and external conditions, the project team can navigate to a wide
spectrum of changes and impact to keep the project in agreement with relevant stakeholders.
 Systems thinking applies to how the project team views itself. The project system often brings together a
diverse project team engaged in working for a common objective. This diversity brings value to project teams
but they need to consider how to leverage those differences effectively, so that the project team works
cohesively.
 Project teams should operate with awareness of changing system dynamics with the following skills:
o Empathy with business areas;
o Critical thinking with big picture focus;
o Challenging of assumptions and mental models;
o Seeking external review and advice;
o Use of integrated methods, artifacts and practices for a common understanding of project work,
deliverables and outcomes;
o Use of modeling and scenarios to envision how system dynamics may interact and react;
o Proactive management of the integration to help achieve business outcomes.
 Recognizing, evaluating and responding to system interactions can lead to positive outcomes:
o Early consideration of uncertainty and risk to explore alternatives;
o Adjust assumptions and plans throughout the project life cycle;
o Provision of ongoing information and insights that inform planning and delivery;
o Clear communication of plans, progress and projections to relevant stakeholders;
o Alignment of project goals and objectives to customer organization’s goals, objectives and vision;
o Ability to adjust changing needs of end user of project deliverables;
o See synergies and savings between aligned projects or initiatives;
o Exploit opportunities not otherwise captured or see threats posed to/by other projects;
o Clarity regarding best project performance measurement and their influence on behaviour of people
involved in the project;
o Decisions that benefit organization as a whole;
o More comprehensive and informed identification of risks.
3.6 Demonstrate Leadership Behaviours
 Higher performing projects demonstrate effective leadership behaviours more frequently, and from more
people than most projects.
 Leadership is not exclusive to any specific role – high-
performing projects may feature multiple people
exhibiting effective leadership. Anyone working on a
project can demonstrate effective leadership traits, styles
and skills.
 More conflict and confusion can emerge when too many
participants attempt to exert project influence in multiple,
misaligned directions.
 Leadership should not be confused with authority (the
right to exercise power). Individuals may use their
authority to influence, motivate, direct others or act when
others do not perform or act as directed or requested, this
is not the same as leadership.
 It takes leadership to motivate a group toward a common goal.

9
 There are many different types of leadership style but no single style has proven to be universally the best or
recommended. Effective leadership is best when it fits a certain situation, (e.g., in moments of chaos,
empowered delegation with competent and engaged staff).
 High performing projects show a pattern of continuous improvement down to the personal level. Project team
member deepens leadership acumen by adding or practicing skills:
o Focusing project team around agreed goals;
o Articulating motivating vision for project outcomes;
o Seeking resources and support for the project;
o Generating consensus on the best way forward;
o Overcoming obstacles to project progress;
o Negotiating and resolving conflict within team and between the team and other stakeholders;
o Adapting communication style and messaging to be relevant to the audience;
o Coaching and mentoring team members;
o Appreciating and rewarding positive behaviours and contributions;
o Providing opportunities for skill growth and development;
o Facilitating collaborative decision making;
o Employing effective conversations and active listening;
o Empowering members and delegating responsibilities;
o Building a cohesive project team that takes responsibility;
o Showing empathy for team and stakeholder perspectives;
o Have self-awareness of own bias and behaviours;
o Managing and adapting to change during project life cycle;
o Facilitating a fail-fast/learn quickly mindset by acknowledging mistakes;
o Role modeling of desired behaviours.
 Projects work best when leaders understand what motivates people. Knowing how to best
communicate/motivate people, or take action when required, can help improve team performance and manage
obstacles to project success.
 By blending styles, continuing skill growth and leveraging motivators, any project team member/stakeholder
can motivate, influence, coach and grow the team, regardless of role or position.
3.7 Tailor Based on Context
 Project teams tailor appropriate framework that will
enable flexibility to consistently produce positive
outcomes within context of life cycle of the project.
 Business environment, team size, degree of
uncertainty and complexity of the project all factor
into how project systems are tailored.
 Together with PMO, teams decide on delivery
approach and resources required for producing
outcomes on project-by-project basis including the
selection of processes to use, development approach,
methods and artifacts needed to deliver outcomes.
 Projects are unique, even when deliverables does not seem unique. Project contexts differ where the
organization, customers, channels and environment are dynamic elements.
 An existing methodology or common way of working can inform the way a project is tailored. Teams may be
required to assume methodology of parent organization which provides consistency to projects but the
methodology itself may still need tailoring to suit each project.

10
 Processes that are not tailored may add little value to the project or outcomes while increasing cost and
lengthening schedule.
 Project teams must also communicate tailoring decisions to stakeholders associated with that approach.
 A tailored project can product direct and indirect benefits to the organization:
o Deeper commitment from team members after partaking in defining the approach;
o Reduction in waste in terms of actions/resources;
o Customer-oriented focus, as needs are important influencing factor in tailoring;
o More efficient use of resources.
 Positive outcomes include:
o Increase innovation, efficiency and productivity;
o Lessons learned that can be shared and applied to future projects;
o Further improvement of organization’s methodology;
o Improved outcomes, processes or methods through experimentation;
o Integration with multidisciplinary teams of methods and practices used to deliver results;
o Increased adaptability for the organization.
 Tailoring is iterative in nature and is a constant process itself during life cycle. Constantly collect feedback on
how methods and processes are working as project progresses to evaluate effectiveness and add value.
3.8 Build Quality into Processes and Deliverables
 Quality includes ability to satisfy customer’s stated
or implied needs.
 The product, service, or result of a project
(deliverables) is measured for the quality of both
the conformance to acceptance criteria and fitness
for use.
 Quality can have several different dimensions:
o Performance – does the deliverable
function as intended?
o Conformity – is the deliverable fit for use,
meet specifications?
o Reliability – does the deliverable produce consistent metrics when performed/produced?
o Resilience – can the deliverable code with unforeseen failures and recover?
o Satisfaction – elicit positive feedback from end users (usability and UX)?
o Uniformity – show parity with other deliverables produced in the same manner?
o Efficiency – produce greatest output with the least amount of inputs and effort?
o Sustainability – positive impact on economic, social and environmental parameters?
 Quality is measured using metrics and acceptance criteria based on requirements which is a condition or
capability that is necessary to be present in a product, service or result to satisfy a need.
 Requirements may come from stakeholders, a contract, organizational policies, standards, regulatory bodies,
or combination.
 Quality is closely linked to product acceptance criteria, as described in statement of work or other design
documents.
 Quality is also relevant to the project approaches and activities used to produce project deliverables. Teams
evaluate quality of deliverable through inspection and testing. Activities and processes are assessed through
reviews and audits. Both focus on detection and prevention of errors and defects.
 Objective of quality is ensure that what is delivered meets objectives of the customer and other relevant
stakeholders, taking the most straightforward path:
o Move deliverables to the point of delivery quicky; and,

11
 o Prevent defects in the deliverables or identify them early to avoid or reduce the need for rework and
scrap.
 Close attention to quality in project processes and deliverables creates positive outcomes including:
o Project deliverables that are fit for purpose as defined by acceptance criteria;
o Deliverables that meet stakeholders expectations and business objectives;
o Deliverables with minimal or no defects;
o Timely or expedited delivery;
o Enhanced cost control;
o Increased quality of product delivery;
o Reduced rework, scrap and customer complaints;
o Good supply chain integration;
o Improved productivity;
o Increased team morale and satisfaction;
o Robust service delivery;
o Improved decision making;
o Continually improved processes.
3.9 Navigate Complexity
 Complexity is a characteristic of a project or its
environment that is difficult to manage due to
human or system behaviour, and ambiguity.
The nature and number of interactions
determine degree of complexity.
 Complexity cannot be controlled but teams can
modify activities to address impacts that occur
as a result of it.
 Isolating a specific cause of complexity is
difficult since it’s a result of many interactions
such as risks, dependencies, events or
relationships.
 Common sources of complexity are:
o Human Behaviour – introduces elements of subjectivity such as personal agendas and conflict with
goals and objectives, remote locations, different time zones, different languages and cultural norms.
o System Behaviour – result of dynamic interdependencies within and among project elements.
Interactions among components of system may lead to interconnected risk, create
emerging/unforeseeable issues, and produce cause-and-effect relationships.
o Uncertainty and Ambiguity – In a complex environment, they can combine to blur relationships where
probabilities and impacts are ill defined. Its difficult to reduce both where relationships can be well
defined and addressed effectively.
o Technological Innovation – Can cause disruption to products, services, ways of working, processes,
tools, techniques, procedures and more. Innovation has the potential to help move projects toward a
solution, or to disrupt the project when associated uncertainties are not defined.
 Teams can identify elements of complexity throughout project by continually looking at project component
and project as a whole for signs of complexity.

12
 Knowledge of systems thinking, complex adaptive systems, experience from past project work,
experimentation, and continuous learning leads to
increased ability to navigate complexity when it
emerges.
3.10 Optimize Risk Responses
 Teams seek to maximize positive risks (opportunities)
and decrease negative risks (threats):
o Threats – delay, cost overrun, technical failure,
performance shortfall, loss of reputation;
o Opportunities – reduced time and cost,
improved performance, increased market share
or enhanced reputation.
 Teams monitor overall project risk which can arise
from all sources of uncertainty. Management of overall
risk aims to keep project risk exposure within an
acceptable range.
 Risk appetite is the degree of uncertainty an organization or individual is willing to accept in anticipation of a
reward.
 Risk threshold is a measure of acceptable variation around an objective that reflects the risk appetite of the
organization and stakeholders.
 Risk threshold reflects the risk appetite. Risk threshold of +/- 5% around a cost objective reflects a lower risk
appetite than a risk threshold of +/- 10%. The risk appetite and risk threshold inform how the team navigates
risk in a project.
 Risk responses can reduce threats and increase opportunities. Teams should consistently identify risk
responses with the following characteristics:
o Appropriate and timely to the significance of the risk;
o Cost effective;
o Realistic within the project context;
o Agreed to by relevant stakeholders;
o Owned by a responsible person.
 Risk can exist within the enterprise, portfolio, program, project and product.
 Organizations and teams that employ consistent risk evaluation, planning and proactive risk implementation
find effort to be less costly than reacting to issues when risk materializes.
3.11 Embrace Adaptability and Resiliency
 Adaptability is the ability to respond to changing
conditions. Resiliency is the ability to absorb
impacts and ability to recover quickly from a
setback or failure.
 The view that projects should hold firm to plans
and commitments made during early stages, even
after new or unforeseen factors emerge, is not
beneficial to stakeholders as this limits the
potential for generating value.
 In project environments, capabilities that support
adaptability and resilience include:
o Short feedback loops to adapt quickly;
o Continuous learning and improvement;

13
 o Teams with broad skill sets, and individuals with extensive knowledge in each skill area;
o Regular inspection and adaptation of work to identify improvement opportunities;
o Diverse teams to capture broad range of experiences;
o Open and transparent planning that engages internal and external stakeholders;
o Small-scale prototypes and experiments to test ideas and try new approaches;
o Leverage new ways of thinking and working;
o Process design that balances velocity of work and stability of requirements;
o Open organizational conversations;
o Diverse project teams with broad skill sets, cultures and experience, and SMEs;
o Past learning understanding;
o Anticipate multiple scenarios and prepare for multiple eventualities;
o Defer decision making to last responsible moment;
o Management support;
o Open-ended design that balances speed and stability.
 Envisioning outcomes rather than deliverables can enable solutions, harnessing better results than originally
planned. Teams should be prepared to adapt its plans and activities to take advantage of opportunities, with
the support of project sponsor, product owner and customer.
 Unexpected changes in project system can present opportunities – teams should use problem solving and
holistic thinking to changes and unplanned events to find positive outcomes that might be gained.
3.12 Enable Change to Achieve the Envisioned Future State
 Remaining relevant means being responsive to
stakeholder needs and desires, continually
evaluating offerings for the benefit of stakeholders,
rapidly responding to changes and acting as agents
for change.
 Change management 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.
 Change management is different from project
change control which is a process where
modifications to documents, deliverables or
baselines associated with the project are identified
and documented, then approved or rejected.
 Change can originate from internal sources such as need for new capability or performance gap, or external
sources such as technological advances, demographic changes or socioeconomic pressures.
 Enabling stakeholder change is part of facilitating the project to provide the required deliverables as well as
intended outcome.
 Enabling change can be a challenge. Effective change management uses motivational strategy rather than
forceful one. Engagement and two-way communication create an environment in which adoption and
assimilation of change can occur or identify valid concerns.
 Team works with relevant stakeholders to address resistance, fatigue, and change absorption to increase
probability of change adoption. Includes communicating vision and goals early in the project to achieve buy-
in, as well as benefits and impact on work to all levels throughout the project.
 Adapt speed of change to change appetite, cost and ability of stakeholders and environment to assimilate
change. Attempting too many changes in too short a time can lead to resistance due to change saturation.
 Even if change is agreed to, people still have difficulty working through actions that will deliver benefits.
Project may include activities to reinforce change after implementation to avoid returning to initial state.

14
A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK GUIDE)
1 – Introduction
1.1 Structure of the PMBOK Guide
 Section 2 Project Performance Domains – identifies 8 performance domains that form an integrated system to
enable successful delivery of outcomes.
 Section 3 Tailoring – describes what tailoring is and presents an overview of what to tailor and how to go
about tailoring individual projects.
 Section 4 Models, Methods, and Artifacts – brief description of commonly used models, methods, and
artifacts which illustrate the range of options project teams can use.
1.2 Relationship of the PMBOK Guide and The Standard for Project
Management
 A principle is a fundamental norm, truth, or value. Principles for project
management (PM) provide guidance for the behaviour of people involved
in projects as they influence and shape the performance domains to produce
the intended outcomes.
 Principles guide behaviour, while performance domains present broad areas
of focus in which to demonstrate that behaviour.
1.3 Changes to the PMBOK Guide
 Shift from process-based standard to one based on principles. The 8 project
performance domains represent a group of related activities that are critical
for the effective delivery of project outcomes.
 Tailoring is deliberate adaptation of PM approach, governance and
processes to make them more suitable for the given environment. Tailoring
is driven by guiding PM principles, organizational values and culture.
 Includes an array of commonly used models, methods, and artifacts that can be used.

2 – Project Performance Domains

 A project performance domain is a group of related activities that are critical for the effective delivery of
project outcomes. There are eight domains:
o (1) Stakeholders; (2) Team; (3) Development Approach and Life Cycle; (4) Planning; (5) Project
Work; (6) Delivery; (7) Measurement, and; (8) Uncertainty.
 Domains operate as an integrated system, with each domain being interdependent of the other to enable
successful delivery of the project and outcomes.
 The domains run concurrently throughout the project, regardless of how value is delivered.
 The specific activities undertaken within each domain is determined by the organization context, the project,
deliverables, project team, stakeholders, etc.
2.1 Stakeholder Performance Domain
 Stakeholder: an individual, group or organization
that may affect, be affected by, or perceive itself
to be affected by a decision, activity or outcome
of a project, program or portfolio.
 Stakeholder Analysis: a method of systematically
gathering and analyzing quantitative and
qualitative information to determine whose
interests should be taken into account throughout
the project.

15
 Entails working with stakeholders to maintain alignment and engaging with them to foster positive
relationships.
 Can include few stakeholders or potentially millions, different stakeholders in different project phases, and
influence, power or stakeholder interests can change through course of the project. Different examples at
different levels include:
o Project manager, PM team, project team;
o Governing bodies, PMOs, steering committees;
o Suppliers, customers, end users, regulatory bodies.
 Effective stakeholder identification, analysis and engagement includes those internal and external to
organization, supportive of the project, and those not supportive or are neutral.
2.1.1 Stakeholder Engagement
 Includes implementing strategies and actions to promote productive involvement of stakeholders.
 Activities start before or when project starts and continue
throughout the project.
 Defining and sharing a clear vision at the start of the project
can enable good relationships and alignment throughout the
project.
2.1.1.1 Identity
 Carried out prior to forming the project team. Identification
elaborates the initial work and is continuous throughout the
project.
 Some stakeholders are easy to identify (e.g., customer,
sponsor, project team, end users) but others can be difficult if
not directly connected to the project.
2.1.1.2 Understand and Analyze
 Understand stakeholders’’ feelings, emotions, beliefs and
values which can lead to additional threats or opportunities for
outcomes and can also change quickly.
 Analyze aspects of each stakeholder’s position on and
perspective of the project, consider aspects like:
o Power, impact, attitude, beliefs, expectations, degree of influence, proximity to the project, interest in
the project, and other aspects surrounding stakeholder interaction with the project.
 Also consider how stakeholders interact with each other, if they form alliances or hinder project objectives.
2.1.1.3 Prioritize
 Prioritize stakeholders and focus on those with the most power and interest to prioritize engagement.
 As events unfold throughout the project, team may need to reprioritize based on new stakeholders or evolving
changes in stakeholder landscape.
2.1.1.4 Engage
 Entails working collaboratively with stakeholders to introduce the project, elicit requirements, manage
expectations, resolve issues, negotiate, prioritize, problem solve and make decisions.
 Communication can take place via written or verbal means, and can be formal or informal (i.e., verbal formal
includes presentations, project reviews, briefings, product demos, brainstorming; verbal informal includes
conversations, ad hoc discussions; written formal includes progress reports, project documents, business case;
written informal includes brief notes, email, instant messaging/texting, social media).
 Communication methods include push, pull and interactive methods:
o Push – used for one-way communications with individual or groups of stakeholders. Inhibits ability
to immediately gauge reaction and assess understanding and should be used deliberately (e.g.,
memos, emails, status reports, voice mail, etc.).

16
 o Pull – information sought by the stakeholder where information is used for indirect sensing of
stakeholder concerns (e.g., intranet to find communication policies or templates, searching internet,
using online repositories, etc.).
o Interactive – includes an exchange of information with one or more stakeholders and is considered
true engagement (e.g., conversations, phone calls, meetings, brainstorming, product demos, etc.).
 With all forms of communication, quick feedback loops are useful to:
o Confirm degree to which stakeholder(s) heard the message;
o Determine if stakeholders agree with the message;
o Identify any unintended messages that were detected;
o Gain other helpful insights.
2.1.1.5 Monitor
 Identify and analyze new stakeholders, assess whether the current engagement strategy is effective or needs
adjustment. The amount and effectiveness of stakeholder engagement is monitored throughout the project.
 Determine the degree of stakeholder satisfaction by conversations, project and iteration reviews, product
reviews, stage gates, surveys, etc.
2.1.2 Interactions with Other Performance Domains
 Stakeholders impact all aspects of the project – define and prioritize requirements and score, participate in
planning, determine acceptance and quality criteria for deliverables and outcomes.
 Stakeholders such as customers, senior management, project management, office leads, or program managers
will focus on measures of performance for the project and its deliverables. These interactions are examples of
how Stakeholder Performance Domain integrates and interweaves with other performance domains.
2.1.3 Checking Results
 Refer to image for outcomes and ways of checking them.

2.2 Team Performance Domain

 Entails establishing the culture and environment that
enables a collection of diverse individuals to evolve
into a high-performing project team through
encouraging leadership behaviours from all team
members.
 Project Manager: person assigned by the performing
organization to lead the project team that is
responsible for achieving the project objectives.
 Project Management Team: the members of the team
who are directly involved in PM activities.
 Project Team: a set of individuals performing the
work of the project to achieve its objectives.

17
2.2.1 Project Team Management and Leadership
 Applying knowledge, skills, tools and techniques for management and leadership activities.
 Management activities focus on meeting project objectives (e.g., effective processes, planning, coordinating,
measuring, and monitoring work).
 Leadership focuses on people (e.g., influencing, motivating, listening, enabling, etc.).
2.2.1.1 Centralized Management and Leadership
 Leadership is usually practiced by all team members, but management may be centralized or distributed.
 When centralized, accountability is usually assigned to one individual, such as project manager or similar
role. A project charter or other authorizing document can provide approval for project manager to form a
project team to achieve outcomes.
2.2.1.2 Distributed Management and Leadership
 Instead of having a designated project manager, someone within the project team may serve as facilitator to
enable communication, collaboration and engagement and the role may shift among team members.
 Servant leadership focuses on understanding and addressing the needs and development of team members in
order to enable the highest possible team performance.
 Servant leaders place emphasis on developing team members by asking questions like:
o Are project team members growing as individuals?
o Are team members becoming healthier, wiser, freer and more autonomous?
o Are team members more likely to become servant leaders?
 Servant leaders allow teams to self-organize and increase levels of autonomy through passing decision
making opportunities to members. Servant leader behaviours include:
o Obstacle Removal – maximize delivery by removing impediments to their progress, including solving
problems and removing obstacles that may be imposing on team’s work;
o Diversion Shield – protect team from internal nod external diversions that redirect team from current
objectives.
o Encouragement and Development Opportunities – learning what motivates team members as
individuals and finding ways to reward them for good work helps keep members satisfied.
2.2.1.3 Common Aspects of Team Development
 Vision and Objectives – communicated throughout the project, includes referencing the intended outcomes
when the team is engaged in making decisions and
solving problems.
 Roles and Responsibilities – ensure team members
understand and fulfill their roles and responsibilities,
includes identifying gaps in knowledge and skills
and strategies to address gaps through training,
mentoring or coaching.
 Project Team Operations – facilitating team
communication, problem solving and coming to a
consensus includes working with the team to develop
a charter and set of operating guidelines/team norms.
 Guidance – directed to overall team to keep everyone in the right direction. Individual team members also
provide guidance on particular task/deliverable.
 Growth – identifying areas where team is performing well and pointing out areas that can be improved helps
the team grow. Working collaboratively, team can identify goals for improvement and take steps to meet those
goals. This can also apply to individuals.
2.2.2 Project Team Culture
 Project’s team culture may be established deliberately through team norms or informally through behaviours
and actions of team members, but operates within the organization’s culture while reflecting team’s individual
ways of working and interacting.

18
 Human beings have a set of biases, some unconscious and some conscious. Being open and transparent about
biases up front establishes a culture of openness and trust that enables consensus and collaboration.
 Project manager is key in establishing and maintain safe, respectful, nonjudgmental environment that allows
team to communicate openly. Desired behaviours include:
o Transparency – being transparent in how one thinks, chooses, processes information and holds biases
helps others identify and share their own processes;
o Integrity – includes ethical behaviour and honesty. Honesty through surfacing risks, communicating
assumptions and basis of estimates, delivering bad news early, ensuring status reports are accurate.
Ethical behaviour includes surfacing potential defects/negative effects in product design, disclosing
conflicts of interest, ensuring fairness, making decisions based on environmental, stakeholder and
financial impacts;
o Respect – demonstrate respect for how person things, skills, perspective and expertise;
o Positive Discourse – different opinions and misunderstandings are inevitable but present an
opportunity for dialogue rather than debate. A dialogue entails working with others to resolve
divergent opinions to arrive at a resolution all parties can embrace.
o Support – supporting team members through problem solving and removing impediments builds
supportive culture and leads to trusting and collaborative environment. Can also be shown by
providing encouragement, empathy and active listening.
o Courage – demonstrating courage it takes to make a suggestion, disagree, or try something new
enables culture of experimentation and communicates to others that it’s safe to be courageous and try
new approaches.
o Celebrating Success – as work takes priority, team members may defer recognizing demonstrations of
innovation, adaptation, service to others, and learning but recognizing contributions in real time can
keep team and individuals motivated.
2.2.3 High-Performing Project Teams
 Factors associated with high-performing project teams include but not limited to:
o Open Communication – open and safe communication allows for productive meetings, problem
solving, brainstorming, etc. Also impacts other factors like shared understanding, trust and
collaboration;
o Shared Understanding – purpose for project and benefits it will provide held in common;
o Shared Ownership – more ownership for the project outcomes team feels, better likely they are to
perform;
o Trust – team in which members trust each other is willing to go the extra distance to deliver success;
o Collaboration – collaboration rather than working in silos or compete tend to generate more diverse
ideas and end up with better outcomes;
o Adaptability – adapting the way they work to environment and situation is more effective;
o Resilience – when issues/failures occur, high-performing teams recover quickly;
o Empowerment – feeling empowered to make decisions about the way they work perform better than
being micromanaged;
o Recognition – recognizing teams for the work they put in and performance they achieve are more
likely to continue performing well, reinforces positive team behaviour.
2.2.4 Leadership Skills
2.2.4.1 Establishing and Maintaining Vision
 Project vision summarizes the project’s purpose clearly and succinctly. It describes a realistic, attractive view
of the future project outcomes.
 The vision is a powerful motivational tool, a way to create passion and meaning for the project’s envisioned
goal. A common vision helps keep people pulling in the same direction.
 A collaboratively developed vision should answer questions like:

19
 o (1) What is the project purpose?; (2) What defines successful project work?; (3) How will the future
be better when outcomes are delivered?; (4) How will the team know it’s drifting from the vision?
 A good vision is clear, concise and actionable and does the following:
o (1) Summarizes the project with a powerful phrase/short description; (2) Describes the best
achievable outcome; (3) Creates a common, cohesive picture in team members’ minds, and; (4)
Inspires passion for the outcome.
2.2.4.2 Critical Thinking
 Includes disciplined, rational, logical, evidence-based thinking. It requires an open mind and the ability to
analyze objectively.
 Can include conceptual imagination, insight, intuition, reflective thinking and metacognition (thinking about
thinking and being aware of one’s awareness).
 Critical thinking is applied by team members to:
o Research and gather unbiased, well-balanced information;
o Recognize, analyze and resolve problems;
o Identify bias, unstated assumptions and values;
o Discern the use of language and the influence on oneself and others;
o Analyze data and evidence to evaluate arguments and perspectives;
o Observe events to identify patterns and relationships;
o Apply inductive, deductive and abductive reasoning appropriately;
o Identify and articulate false premises, false analogy, emotional appeals and other faulty logic.
2.2.4.3 Motivation
 Two aspects of motivating people: (1) Understanding what motivates project team members to perform; (2)
working with team in a way that they remain committed to the project and outcomes.
 Intrinsic motivation comes from the inside of an individual or is associated with the work, is associated with
finding pleasure in the work itself rather than focusing on rewards. Most work done on projects is aligned
with intrinsic motivation.
 Examples of motivation factors include: achievement, challenge, belief in the work, making a difference, self-
direction and autonomy, responsibility, personal growth, relatedness and being part of a project team.
 Extrinsic motivation is performing work because of an external reward like a bonus.
 People are not motivated by just one thing but there is a dominant motivator. To effectively motivate team
members, it’s helpful to know each member’s dominant motivator. Tailoring motivation methods based on
individual preferences helps elicit the best individual and team performance.
2.2.4.4 Interpersonal Skills
 Interpersonal skills include emotional intelligence, decision making and conflict resolution.
o Emotional Intelligence: the ability to recognize our own emotions and those of others which is used to
guide thinking and behaviour. There are four key areas for defining and explaining EI:
 Self-Awareness – ability to conduct a realistic self-assessment and includes understanding our
own emotions, goals, motivations, strengths and
weaknesses;
 Self-Management – or self-regulation, is ability to
control and redirect disruptive feelings and impulses, the
ability to think before acting, suspending snap
judgements and impulse decisions;
 Social Awareness – empathy and understanding and
considering other people’s feelings, including ability to
read nonverbal cues and body language;
 Social Skill – managing groups of people, such a project
teams, building social networks, finding common ground
with various stakeholders and building rapport.

20
  Self-awareness and management are required to remain calm and productive during difficult
project circumstances while social awareness and skills allow for better bonds with team
members and stakeholders.
o Decision Making: decisions are made daily and some can be inconsequential to project outcome and
others will be very impactful.
 Unilateral Decisions – has the advantage of being fast but prone to error compared to
engaging wisdom of diverse people. Can also demotivate impacted people since they may
feel their views and concerns were not considered.
 Group Based Decisions – taps into broad knowledge base of a group, increases buy-in to the
outcome, and commitment to the decision. Requires time and interruption to teamwork.
 Diverge/Converge Pattern – stakeholders are first engaged to generate broad set of solution
alternatives or approaches which is done individually to avoid influencing stakeholders. Then
the team converges on a preferred solution.
 Goal is to make decisions quickly while engaging diverse knowledge inclusively.
 In the end, a decision is based on the presented analysis with considerations for
stakeholder expectations.
 Roman voting, wideband Delphi estimating and fist of five voting aim to engage
individual input while voting at the same moment, minimizing groupthink.
 Decisions Beyond Authority – team can investigate alternatives, consider impacts and escalate
decision to someone with proper authority. Don’t bring problems, bring solutions.
o Conflict Management: happens on all projects which operate in dynamic environments and face many
mutually exclusive constraints including budget, scope, schedule and quality which lead to conflicts.
Not all conflict is negative and addressing it before it escalates beyond useful debate leads to better
outcomes through the following approaches:
 Keep Communication Open and Respectful – keep a safe environment to explore the source
of conflict, without this people will stop communicating. Make sure words, tone of voice and
body language remain nonthreatening.
 Focus on the Issues, Not the People – conflict based on people precepting situations
differently, it should not be personal. Focus on resolving the situation, not casting blame.
 Focus on the Present and Future, Not the Past – if something similar happened previously,
bringing this up will intensify the current situation even more, not resolve current situation.
 Search for Alternatives Together – Damage can be repaired by looking for resolutions and
alternatives together and create more constructive relationships, moving conflict into
problem-solving space where people can work together.
2.2.4 Tailoring Leadership Styles
 Leadership styles are tailored to meet the needs of the project, environment and stakeholders:
o Experience With the Type of Project – teams may be more self-managing and require less leadership
with experience. When a project is new, more oversight and directive leadership is used;
o Maturity of the Project Team Members – team members with more maturity in the technical field may
need less oversight and direction then members new to the organization, team or specialty;
o Organizational Governance Structures – expectation that organizational leadership style of top
management is recognized in the team’s leadership which includes the degree to which authority and
accountability is centralized or decentralized;
o Distributed Project Teams – to minimize pitfalls of distributed teams, technology can be used to
increase and improve communication. Examples include: ensure collaboration sites exist, have
project team site for all relevant information available, use audio and video for meetings, use
technology for ongoing contact like texting/messaging, build in time to get to know remote team
members, have at least one face-to-face meeting to establish relationships.
2.2.6 Interactions with Other Performance Domains

21
 Team Performance Domain emphasizes skills used by project managers and team members throughout the
project and are woven into all other aspects of the project.
 Team members are called on to demonstrate leadership qualities and skills, communicating project vision and
benefits to stakeholders while planning and throughout life cycle, employing critical thinking, problem
solving and decision making while engaging in
project work.
 Accountability for outcomes is demonstrated
throughout Planning and Measurement
Performance Domains.
2.2.7 Checking Results
 Refer to image for outcomes and ways of checking
them.
2.3 Development Approach and Life Cycle
Performance Domain
 Entails establishing the development approach,
delivery cadence and project life cycle needed to
optimize project outcomes.
 Deliverable: unique/verifiable product, result or
capability to perform a service that is required to
complete a process, phase or project.
 Development Approach: method used to create and
evolve the product, service or result during project life
cycle (e.g., predictive, iterative, incremental, adaptive
or hybrid method).
 Cadence: rhythm of activities conducted throughout
project.
 Project Phase: collection of related activities that
culminates in the completion of one or more
deliverables.
 Project Life Cycle: series of phases that project passes through from start to completion.
2.3.1 Development, Cadence and Life Cycle Relationship
 Type of deliverable(s) determines how it can be developed.
 Type of deliverables and development approach influence number and cadence for deliveries.
 Deliverable approach and desired delivery cadence determine life cycle and its phases.
2.3.2 Delivery Cadence
 The timing and frequency of project deliverables:
o Single Delivery – deliver at the end of the project;
o Multiple Deliveries – may have multiple components that are delivered at different times throughout
the project. Can be sequential throughout (e.g., new clinical drug) or separately where they do not
need to come in a specific order. (e.g., update building security badges, code pads, etc.) but
everything is concluded before project is complete;
o Periodic Deliveries – like multiple but are on a fixed delivery schedule, such as monthly or
bimonthly;
o Continuous Delivery – delivering feature increments immediately to customers, often through small
batches of work and automation technology. Emphasis is on delivering benefits and value throughout
the product life cycle. There are aspects that are development oriented similar to a project but similar
to a program, there can be many development cycles as well as maintenance activities. Works best
with teams that are stable and remain intact.

22
2.3.3 Development Approaches
 Three commonly used approaches are predictive, hybrid and adaptive. Are
often viewed as a spectrum from predictive to adaptive on the other end.
o Predictive – useful when project and product requirements can be
defined, collected and analyzed at the start of the project (waterfall
approach). The scope, schedule, cost, resource needs and risks can
be well defined in early phases of life cycle, and are relatively
stable with minimal change throughout. Allows for reduction of
level of uncertainty early in the project as much of planning is done
up front;
o Hybrid – combination of adaptive and predictive and is useful when there is uncertainty or risk
around the requirements. Use an iterative or incremental development approach:
 Iterative is useful for clarifying requirements and investigating various options, may produce
sufficient capability to be considered acceptable prior to final iteration;
 Incremental used to produce deliverable throughout a series of iterations. Each adds
functionality within a redetermined time frame. The deliverable contains the capability to be
considered completed after final iteration.
o Adaptive – useful when requirements are subject to high level of uncertainty and volatility and likely
to change throughout the project. A clear vision is established at start of project and initial known
requirements are refined, detailed, changed or replaced with user feedback, environment or
unexpected events;
 Also use iterative and incremental approaches but on far side of adaptive, iterations tend to
get shorter and product is more likely to evolve based on stakeholder feedback;
 Agile approaches can be considered adaptive.
2.3.4 Considerations for Selecting a Development Approach
2.3.4.1 Product, Service or Result
 Variables to consider when selecting development approach:
o Degree of Innovation – deliverables where scope/requirements are understood, team has worked with
before, planning up front is well suited to predictive. Deliverables with high degree of innovation or
where team does not have experience better suited to adaptive;
o Requirements Certainty – if requirements well known, easy to define, predictive fits well. When they
are uncertain, volatile or complex and expected to evolve, adaptive is better fit;
o Scope Stability – scope is stable and not likely to change, predictive. If scope expected to have many
changes, approach closer to adaptive would be useful;
o Ease of Change – related to requirements certainty and scope stability, if nature of deliverable is
difficult to manage and incorporates change, then predictive. Deliverables that adapt easily can use
adaptive;
o Delivery Options – if can be developed/delivered in pieces, aligned with incremental, iterative or
adaptive. Some large projects may be planned using predictive but may be some pieces that can be
developed/delivered incrementally;
o Risk – require analysis before choosing development approach. Some high-risk require significant up-
front planning to reduce threats. Some can reduce risk by building them modularly and adapting
design to take advantage of emerging opportunities;
o Safety Requirements – rigorous safety requirements often use predictive due to need for up-front
planning to ensure all requirements are identified, planned for, created, integrated and tested;
o Regulations – significant regulatory oversight may need to use predictive due to required process,
documentation and demonstration needs.
2.3.4.2 Project
 Project variables that influence the development approach:
o Stakeholders – adaptive requires significant stakeholder involvement throughout the process;

23
 o Schedule Constraints – if need to delivery something early even if not finished, iterative or adaptive;
o Funding Availability – in funding uncertainty environments, benefit from adaptive or iterative
approach to allow market testing with minimum upfront investment.
2.3.4.3 Organization
 Organizational variables influence the development approach:
o Organizational Structure – structures with many levels, rigid reporting and bureaucracy uses
predictive approach. Projects that use adaptive tend to have a flat structure and operate with self-
organizing teams;
o Culture – managing and directing culture fits with predictive where work is planned out and progress
measured against baselines. Adaptive fit better with organization that emphasizes self-management;
o Organizational Capability – shifting from predictive to adaptive and using agile methods entails
shifting mindset starting at the executive level. Policies, ways of working, reporting structure and
attitude all aligned in order to employ adaptive methods;
o Project Team Size and Location – adaptive agile work better with teams of 7 +/- 2. Adaptive favours
teams located in the same physical space. Larger teams that are mostly virtual do better with
predictive but can scale up adaptive approaches.
2.3.5 Life Cycle and Phase Definitions
 The type and number of project phases in life cycle depend on many variables, mostly delivery cadence and
development approach. Examples of phasis in lifecycle include:
o Feasibility – determines if business case is valid and if organization has capability to deliver outcome;
o Design – planning and analysis to design deliverable that will be developed;
o Build – construction with integrated quality assurance activities;
o Test – final quality review and inspection before transition, go-live or
customer acceptance;
o Deploy – deliverables put into use and transitional activities required for
sustainment, benefits realization and organizational change
management;
o Close – project is closed, knowledge and artifacts are archived, team
members released, contracts closed.
 Phase gate review (stage gate) checks that desired outcomes or exit criteria for
phase have been achieved before proceeding to the next phase. Exit criteria may
tie to acceptance criteria for deliverables, contractual obligations, meeting
specific performance targets or other tangible measures.
 Life cycles where one phases finishes before the next one begins fits well with
predictive development since each phase is only performed once (first image).
There are situations like adding scope, change in requirements or change in
market that causes phases to be repeated.
 Life cycles with incremental development has three iterations of plan, design
and build where each subsequent build would add functionality to the initial
build (second image).
 Lifecycles with adaptive have “sprints” at the end of each iteration where the
customer reviews a functional deliverable and key stakeholders provide
feedback, team updates project backlog of features and functions to prioritize
for next iteration. Can be modified for use in continuous delivery situations
(third image).
 Other adaptive methodologies, like agile, use flow based scheduling which
does not use lifecycle or phases. Goals are to: (1) optimize flow of deliveries
based on resource capacity, materials and other inputs; (2) minimize time and

24
 waste while optimizing efficiency of processes. This is usually adopted through Kanban and just-in-time
scheduling approaches.
2.3.6 Aligning of Delivery Cadence, Development Approach and Life Cycle
 Example: four products/services – the building, community action patrol (CAP) training, senior services, and
the website.
 Potential life cycle might be:
o Start Up – business case approved, charter
authorized, high-level roadmap developed,
funding established, team and resources defined,
milestone schedule created, & procurement
strategy defined. Must be complete to exit this
phase which is reviewed at phase gate review;
o Plan – creation of detailed plan, design document for CAP training, analysis of senior services and
gap analysis, & outline of website. Must be complete to exit phase- reviewed at phase gate review;
o Development – overlap with test and deploy since different delivery cadences/approaches. Website
has early deliveries, some senior services and CAP
training may begin. Each deliverable may have
separate review before test phase;
o Test – overlap with development and deploy, test
depends on deliverable. Includes building inspection,
CAP beta delivery, small scale senior service trials,
website test environment. Each goes through
applicable testing before next phase;
o Deploy – overlap with development and test phases.
Activities in this phase iterate as more deliverables
become available. Final deployment will be opening
community center. Ongoing operations to website and
senior services part of operations after opening;
o Close – takes place periodically as deliverables are
completed. When entire project is done, information
from various phase gates and overall project
performance evaluation compared to baselines will be
conducted. Before final closeout, charter and business
case reviewed to see if deliverables were achieved.
2.3.7 Interactions with Other Performance Domains
 Development Approach and Life Cycle Performance Domain interacts with Stakeholder, Planning,
Uncertainty, Delivery, Project Work, and Team Performance Domains. The life cycle selected impacts the way
in which planning is undertaken.
 The development approach and delivery cadence is one way to reduce uncertainty on projects:
o Deliverable with risk to meet regulatory requirements may choose predictive;
o One with risk associated with stakeholder acceptable may choose iterative to get feedback.
 Development Approach and Life Cycle Performance Domain overall with Delivery Performance Domain:
o Delivery cadence is one of main drivers of delivering value in alignment with business case and
benefits realization plans;
o Meeting quality requirements as described in performance domain influences development approach.
 Team performance domain and development approach and life cycle interact when comes to project team
capabilities and leadership skills:
o Predictive entails more emphasis on up-front planning, measurement, control;
o Adaptive (agile) requires more servant leadership and self-managing teams.

25
2.3.8 Measuring Outcomes
 Refer to image for outcomes and ways of checking them.

2.4 Planning Performance Domain

 Estimate: quantitative assessment of likely amount or outcome of
variable, such as project costs, resources, effort or durations.
 Accuracy: assessment of correctness within quality management system.
 Precision: assessment of exactness within quality management system.
 Crashing: method used to shorten the schedule duration for least incremental cost by adding resources.
 Fast Tracking: schedule compression method where activities or phases normally done in sequence are
performed in parallel for portion of their duration;
 Budget: approved estimate for project or WBS component or schedule activity.
2.4.1 Planning Overview
 Purpose is to proactively develop an approach to create the project deliverables. High-level planning may
begin prior to project authorization through initial documents like vision statement, charter, business case.
 More common for initial planning to consider social and environmental impacts in addition to financial
impacts (referred to as triple bottom line), considering impacts of materials and processes with regards to
sustainability, toxicity and the environment.
 Amount of time spent planning up front and throughout project should be determine by circumstances – do
not need to spend more time planning than needed.
 Teams use planning artifacts to confirm stakeholder expectations and provide them with information needed
to make decisions, take action and maintain alignment between project and stakeholders.
2.4.2 Planning Variables
 Variables that influence how project planning is conducted include:
o Development Approach – can influence how, how much and when planning is conducted. E.g., a
specific phase for planning or organizing early in the life cycle, high level planning up front, followed
by design phase where prototyping is used, or team conducts iterations;
o Project Deliverables – the deliverables specific to projects require planning in specific way (e.g.,
construction requires significant up-front planning whereas product development use
continuous/adaptive planning to allow for evolution);
o Organizational Requirements – governance, policies, procedures, processes and culture may require
project managers to produce specific planning artifacts;
o Market Conditions – in highly competitive markets, teams undertake minimum amount of up-front
planning as emphasis is on speed to market. Cost of delay exceeds risk of potential rework;
o Legal or Regulatory Restrictions – regulatory agencies or statues may require specific planning
documents before granting authorization to proceed or secure approval to release deliverable.
2.3.2.1 Delivery
 Product scope is features/functions that characterize a product, service, result.

26
 Project scope is work performed to delivery product, service, or result with specific features/functions.
 Predictive planning starts with high-level project deliverables up front and decompose into more detail, using
a scope statement or WBS to break scope into lower levels of detail.
 Iterative/incremental can have high-level themes broken into features, then further broken down into use
stories and other backlog items:
o Unique, significant, novel or risky work can be prioritized to reduce uncertainty at the start;
o Teams plan routine work based on last responsible moment which defers decision to allow
consideration of multiple options until cost of further delay exceeds benefit;
o This reduces waste by not using time in developing plans for work that may change/not needed.
2.4.2.2 Estimating
 Are quantitative assessment of likely amount or outcome of variable (i.e., costs,
resources, effort or duration), and can change based on information and circumstances
as project evolves.
 Project’s phase in life cycle impacts four aspects associated with estimating:
o Range – estimates have broad range at start when there is not much information
(e.g., -25 to + 75% at start of exploring project opportunity whereas -5 to +10%
well along in life cycle);
o Accuracy – linked to range in that lower the accuracy, the larger the potential
range of values. Estimates at the start will have less accuracy than one
developed halfway through the project;
o Precision – degree of exactness associated with the estimate. Precision of
estimates should be compatible with the desired accuracy;
o Confidence – increases with experience (i.e., working on previous, similar
project). Whereas for new and evolving technology components, confidence in
estimates expected to be low.
 Different ways of presenting and/or adjusting estimates:
o Deterministic and Probabilistic Estimating –
 Deterministic also known as point estimates present a single number or
amount (e.g., 36 months);
 Probabilistic includes a range of estimates along with associated
probabilities within the range:
 Developed manually through: (a) weighted average based on multiple likely
outcomes, (b) running simulation to develop probability analysis of particular
outcome usually for cost or schedule;
 From computer has three factors: (1) point estimate with range, i.e., 36 months
+3months/-1 month; (2) statement of confidence, i.e., 95% confidence level; (3)
probability distribution describing dispersion of data within/around range;
o Absolute and Relative Estimating –
 Absolute are specific information and use actual numbers (i.e., for effort might be shown as
120 hours of work, 15 workdays assuming 8 hours of productivity;
 Relative only have meaning within a given context (e.g., planning poker, new work is
estimated using amount of estimated work compared to points assigned to previous work);
o Flow-Based Estimating – determining the cycle time and throughput to provide an estimate to
complete a specified quantity of work:
 Cycle time is the total elapsed time it takes one unit to get through a process;
 Throughput is the number of items that can complete a process in given amount of time;
o Adjusting Estimates for Uncertainty – key deliverable dates or budget estimates may be adjusted, or
contingency time or funds added, based on outcomes of simulation to establish range of uncertainty.
2.4.2.3 Schedules

27
 A Schedule is a model for executing project’s activities, including durations, dependencies and other planning
information.
 Predictive scheduling follow stepwise process:
o (1) Decompose project scope into activities; (2) Sequence related activities; (3) Estimate effort,
duration, people and physical resources required; (4) Allocate people and resources based on
availability; (5) Adjust sequence, estimates and resources until schedule is agreed upon.
 Crashing is a schedule compression method that seeks to shorten duration for least incremental cost. It can
include adding people to activities, working overtime or paying to expedite deliveries.
 Fast tracking is a compression method where activities or tasks normally done in sequence are performed in
parallel for at least a portion of duration. It often entails applying leads and lags along network path:
o Lead – where the work of a successor activity is accelerated, e.g.,
starting a successor activity before the predecessor has finished;
o Lag – a delay of a successor activity, i.e., changing the type of
relationship between activities and then applying a lag. E.g.,
instead of waiting for activity to finish before next one starts
(finish-to-start relationship), change relationship to have end of
successor activity finish a determine amount of time after the end
of predecessor (finish-to-finish relationship). This would show a
lag between finish of the predecessor and finish of successor
activities.
 When compressing a schedule, need to know the nature of the
dependencies between activities as some cannot be fast tracked due to
nature of the work. Four types of dependencies are:
o Mandatory – contractually required or inherent in the nature of the work, cannot be modified;
o Discretionary – based on best practices or preferences, may be modifiable;
o External – between activities and non-project activities, usually cannot be modified;
o Internal – between one or more project activities, may be
modifiable.
 Adaptive schedule planning uses incremental planning based on
iterations and releases where a high-level release plan is developed
that indicates basic features and functionality for each release. Within
each release, there are two or more iterations which adds
business/stakeholder value like features, risk reduction,
experimentation, etc.
 Adaptive often uses timeboxes where the work in each box is based on
prioritized backlog and the team determines amount of work to be
done in each box. At the end, team demonstrates work completed and
the backlog/estimates of work available may be updated/reprioritized
for the next timebox.
 Determining the schedule involves using the information in estimating
to determine overall duration and effort estimates. Regardless of scheduling
approach, relationship between effort and duration needs to be addressed.
2.4.2.4 Budget
 Project budgets evolve from agreed estimates where information on estimating is
applied to costs to develop cost estimates which are then aggregated to develop
cost baseline.
 The cost baseline is allocated across the project schedule to reflect when the
costs will be incurred which allows project managers to balance the funds
approved in a specific budget period with the schedule work.

28
 Project budget should include contingency reserve funds to allow for uncertainty which are set aside to
implement a risk response if events occur.
 Management reserves are set aside for unexpected activities related to in-scope work. May be managed by the
project, sponsor, product owner or PMO.
2.4.3 Project Team Composition and Structure
 Begins with identifying the skill sets required to accomplish project work which entails evaluating skills but
also level of proficiency and years or experience in similar projects.
 Different cost structures associated with using internal project team members vs. securing from outside the
organization. Benefit that outside skills bring are weighed against costs that will be incurred.
 Project manager considers ability and necessity for project team to work in same location. Small teams
working in the same room take advantage of osmotic communication and solve problems as they arise. On
teams that work virtually, more time spent connect people through technology.
2.4.4 Communication
 Overlaps with stakeholder identification, analysis, prioritization and engagement.
 Planning communication entails considering:
o (1) Who needs information?; (2) What information do they need; (3) Why should information be
shared with stakeholders?; (4) What’s the best way to provide information?; (5) When and how often
is it needed?; (6) Who has the information needed?
 Different categories of information such as internal and external, sensitive and public, or general and detailed.
 Analyzing stakeholders, information needs and categories provides foundation.
2.4.5 Physical Resources
 Any resource that is not a person, and can include materials, equipment, software, testing environments,
licenses, etc.
 Planning for physical resource requires estimating, supply chain, logistics and management. Large projects
will require planning for procurement activities.
 Takes into account lead time for delivery, movement, storage and disposition of materials, and a means to
track material inventory from arrival on site to delivery of product.
 Strategic planning when requiring significant physical materials includes evaluation of bulk ordering vs cost
of storage, global logistics, sustainability, integrating management of physical assets with rest of project.
2.4.6 Procurement
 Happens any time during a project but up-front planning helps set expectations that ensure process is smooth.
 Once high-level scope is known, teams conduct make-or-buy analysis including identifying deliverables and
services that will be developed in-house and those purchased from external sources.
 Will impact project team and schedule, i.e., contracting professionals needs advance information on type of
goods needed, when needed and any technical specifications.
2.4.7 Changes
 Some changes are a result of a risk event occurring or project environment change, some are based on
developing deeper understanding of requirements, and others due to customer requests or other reasons.
 Must prepare a process for adapting plans throughout the project, which may take form of change control
process, reprioritizing backlog, or rebaselining the project.
 Projects with contractual element may need to follow defined process for contract changes.
2.4.8 Metrics
 Establishing metrics includes setting thresholds that indicate whether work performance is as expected,
trending positively or negatively away from expected performance, or unacceptable.
 Metrics associated with the product are specific to the deliverables being developed.
 Metrics associated with schedule and budget performance are driven by organizational standards and are
related to a baseline or approved version of the schedule or budget against which results are compared.

29
 The metrics, baselines and thresholds are established and any test and evaluation processes and procedures
that will be used to measure performance for specific project deliverable. These are used as basis to evaluate
variance of actual performance as part of Measurement Performance Domain.
2.4.9 Alignment
 Planning for performance of scope and quality requirements aligns with delivery commitments, allocated
funds, type and availability of resources, the uncertainty inherent in the project, and stakeholder needs.
 Work on one project often occurs with other projects. The time of the work of a single project should align
with needs of work on related projects.
 Large projects may combine planning artifacts into integrated project management plan. For smaller projects,
detailed PM plan will be inefficient.
2.4.10 Interactions With Other Performance Domains
 Planning occurs throughout the project and integrates with each performance domain.
 Planning guides project work, delivery of outcomes, and business value. Teams and stakeholders establish
measures of progress and success, and performance is compared to plans.
 Uncertainty and planning interact as teams plan for how to address uncertainty and risks.
 Plans may need to be revised or new plans developed to account for events that emerge.
 Team members, environment and project details influence plans for working effectively with the team and
engaged with stakeholders.
2.4.11 Checking Results
 Refer to image for outcomes and ways of checking them.

2.5 Project Work Performance Domain

 Project work is associated with establishing the processes
and performing the work to enable to project team to
deliver the expected deliverables and outcomes.
 Bid Documents: all documents used to solicit information,
quotes or proposals from prospective sellers.
 Bidder (Contractor/Vendor/Pre-Bid) Conference: meetings
with prospective sellers prior to the prep of a bid or
proposal to ensure all prospective vendors have clear and
common understanding of procurement.
 Explicit Knowledge: can be codified using symbols such
as words, numbers and pictures.

30
 Tacit Knowledge: personal knowledge that can be difficult to articulate and share (i.e., beliefs, experience,
insights).
 Project work keeps team focused and activities running smoothly, including:
o (1) Managing flow of existing, new and changes to work; (2) Keeping team focused; (3) Establishing
efficient systems and processes; (4) Communicating with stakeholders; (5) Managing material,
equipment, supplies and logistics; (6) Working with contracting professionals and vendors to plan and
manage procurements/contracts; (7) Monitoring changes that can affect the project; (8) Enable project
learning and knowledge transfer.
2.5.1 Project Processes
 Project manager and team periodically review processes used to conduct work (i.e., review task boards to
determine any bottlenecks, work flowing at expected rate, any impediments blocking progress).
 Process tailoring used to optimize process for the needs of the project, taking into consideration the demands
of the environment. Ways of optimizing processes for environment include:
o Lean Production Methods – value stream mapping measures ratio of value and non-value adding
activities. Metrics calculated form basis and measurement system for identifying and removing waste;
o Retrospectives or Lessons Learned – opportunity for team to review way in which things work and
suggest changes to improve process and efficiency;
o Where is the Next Best Funding Spent? – help teams determine if should continue with current task or
move onto next activity to optimize value delivery.
 Reviewing processes helps determine if they are efficient or if there is waste. Teams utilize just enough time
to review to maximize benefits delivered from the review while still delivering on the outcomes.
 Processes should also be effective and comply with quality requirements, regulations, standards and
organizational policies. Process evaluation can include audits and quality assurance work.
2.5.2 Balancing Competing Constraints
 Constraints can take form of fixed delivery dates, compliance to regulatory codes, predetermined budget,
quality policies, considerations of triple bottom line, etc.
 Balancing shifting constraints while maintaining stakeholder satisfaction is ongoing activity. May include
meeting with customer, sponsor, product owner to present alternatives and implications or decisions may be
within team’s authority to make trade-offs to deliver on end result.
2.5.3 Maintaining Project Team Focus
 Leading project team includes balancing workload and assessing if team members are satisfied with their
work so they remain motivated.
 Leading with goal of maximizing overall delivered value involves focusing on production (delivering value)
and protecting team’s production capability (team health and satisfaction).
 Goal is to keep team focused on delivering value and maintaining awareness of when potential issues, delays
and cost overruns enter the project.
2.5.4 Project Communications and Engagement
 Much of project work is associated with communication and engagement, especially work associated with
maintaining team and stakeholder engagement.
 Refer to Stakeholder Performance domain section regarding communication types.
 Day-to-day there are ad-hoc requests for information, presentations, reports, etc. An abundance of ad hoc
requests may indicate that communication planning was not sufficient to meet stakeholder needs.
2.5.5 Managing Physical Resources
 Large amounts of physical resources require integrated logistics system.
 A logistics plan describes how the company policy will be implemented on the project.
 Supporting documentation includes estimates for type of material, basis of estimates, expected usage of time,
specifications for grade, and time/location for deliveries.
 Objectives of physical resources are to:

31
 o (1) Reduce/eliminate material handling and storage on site; (2) Eliminate wait times for materials; (3)
Minimize scrap and waste; (4) Facilitate safe work environment.
2.5.6 Working With Procurements
 In most organizations, project managers do not have contracting authority so they work with contracting
officers or other people with expertise in contracts, laws and regulations.
 Organizations usually have rigorous policies and procedures for procurement, identifying who has authority
to enter into a contract, limits of authority, processes/procedures that should be followed.
 Project manager and qualified team members work with contracting professional to develop request for
proposals (RFP), statement of work (SOW), terms and conditions, and other necessary documents for bid.
2.5.6.1 The Bid Process
 Developing and publicizing bid documents, bidder conferences, and selecting a bidder. Documents include:
o Request for Information – gathers more information from the market prior to sending out bid
documents to set of selected vendors;
o Request for Proposal – document used for complex/complicated scope where buyer is looking for
vendor to provide a solution;
o Request for Quote – document is used when price is the main deciding factor, and proposed solution
is readily available.
 Once bid documents are distributed, buyer generally has bidder conference to respond to bidder questions and
provide clarifying information. Bidders develop their responses and deliver them to the buyer by the date
specified in bid documents.
 Choosing the best vendor, known as source selection, based on criteria such as experience, references, price
and timely delivery. Variables may be weighed to reflect relative importance of each.
 Buyer evaluates vendor bids against criteria and terms and conditions are negotiated.
2.5.6.2 Contracting
 Type of contract depends on size of the purchase, stability of the scope of work and risk tolerance of
organization.
 For projects using adaptive and predictive approach for deliverables, a master agreement may be used for the
overall contract, where adaptive may be placed in appendix to allow changes to occur to the scope without
impacting the overall contract.
 Once vendor is selected, project plans/documents updated to include vendor dates, resources, costs, quality
requirements, risks, etc. The vendor is now a project stakeholder.
 Procurements take place at any point during the project and all activities are integrated into project operations.
2.5.7 Monitoring New Work and Changes
 In adaptive projects, if more work is being added than completed, or if same amount of work is added that is
completed, the project will continue without end.
o Project manager works with product owner to manage expectations around adding scope,
implications to the budget, and availability of project team members.
o Product owner prioritizes project backlog so that high-priority items are completed. If schedule or
budget is constrained, may consider project done when highest priority items are delivered.
 In predictive projects, project team manages changes to work to ensure only approved changes are included in
scope baseline. Any other changes to scope result in changes to people, resources, schedule and budget.
o Any scope change requests require evaluation of new risks introduced. Work with the change control
board and change requestor to guide change requests through process.
o Approved changes are integrated into project planning documents, product backlog and project scope,
and communicated to stakeholders.
2.5.8 Learning Throughout the Project
 Team may meet to determine what can be done better in the future (lessons learned) and how they can
improve and challenge the process in upcoming iterations (retrospectives).
2.5.8.1 Knowledge Management

32
 Most learning takes place during projects, where some is project specific and some can be shared with other
project teams to improve outcomes. Other learning can be shared throughout the organization.
2.5.8.2 Explicit and Tacit Knowledge
 Explicit knowledge can be readily codified using words, pictures or numbers. It can be distributed using
information management tools to connect people to information.
 Tacit knowledge is comprised of experience, insights, and practical knowledge or skill. Is shared by
connecting the people who need the knowledge with those that have the knowledge.
 Because projects are temporary, much of the knowledge is lost once the project is completed therefore being
attentive to knowledge transfer serves the organization through value from the project, but also gaining
knowledge from experience of running projects.
2.5.9 Interactions with Other Performance Domains
 Enables and supports efficient and effective planning, delivery and measurement.
 Provides environment for team meetings, interactions, and stakeholder engagement to be effective.
 Supports navigating uncertainty, ambiguity and complexity, and balance impacts with other constraints.
2.5.10 Checking Results
 Refer to image for outcomes and ways of checking them.

2.6 Delivery Performance Domain

 Project delivery focuses on meeting requirements, scope and quality expectations to produce expected
deliverables that will drive intended outcomes.
 Requirement: condition or capability that is necessary to
be present in a product, service or result to satisfy a
business need.
 Work Breakdown Structure (WBS): hierarchical
decomposition of total scope of work to be carried out by
team to accomplish objectives and required deliverables.
 Definition of Done (DoD): checklist of all criteria
required to be met so that deliverable can be considered
ready for customer use.
 Quality: degree to which set of inherent characteristics
fulfills requirements.

33
 Cost of Quality (COQ): costs incurred over life of product by investment in preventing nonconformance to
requirements, appraisal of product or service for conformance to requirements and failure to meet them.
 Projects provide business value by developing new products/services, solving problems, fixing features that
were defective/suboptimal. They offer multiple outcomes that stakeholders may value differently.
2.6.1 Delivery of Value
 Projects that use development approach that supports releasing deliverables throughout life cycle can start
delivering value to business, customer, or other stakeholders during the project.
 Those that deliver bulk of deliverable at the end of life cycle generate value after the initial deployment.
 Business value often continues to be captured long after project has ended. Longer product/program life
cycles are used to measure benefits/value contributed by earlier projects.
 Business case document provides business justification and projection of anticipated business value from a
project and demonstrate how project outcome (e.g., detailed estimates of ROI or lean start-up canvas with
high-level elements like problem, solution, revenue streams and cost structures).
 Project-authorizing documents quantify desired outcomes to allow for periodic measurement. Can provide an
overview of life cycle, major releases, key deliverables, reviews ad other top-level information.
2.6.2 Deliverables
 Is the interim or final product, service, or results from the project and reflect stakeholder requirements, scope,
quality and long-term impacts to profit, people and the planet.
2.6.2.1 Requirements
 Can be high level, i.e., found in business case, or can be very detailed, i.e., in acceptance criteria for a
component of a system.
 Projects with well-defined scope work with stakeholders to elicit and document requirements during up-front
planning. If requirements are high-level at the start, they may evolve over time where some discover
requirements during project work:
o Requirements Elicitation – requirements can be drawn out by analyzing data, observing processes,
reviewing defect logs, etc. Part of eliciting requirements is documenting and gaining stakeholder
agreement and show meet the following criteria:
 Clear: only one way to be interpreted;
 Concise: stated in as few words as possible;
 Verifiable: way to verify requirement has been met;
 Consistent: no contradictory requirements;
 Complete: set of requirements represents entirety of project or product needs;
 Traceable: can be recognized by a unique identified.
o Evolving and Discovering Requirements – if requirements are not clearly defined, prototypes,
demonstrations, storyboards, and mock-ups used to evolve requirements. Is common in projects using
iterative, incremental or adaptive approaches, or new opportunities arise changing requirements;
o Managing Requirements – poor management leads to rework, scope creep and project failure. Have
one accountable person for management who serves as business analyst, product owner, value
engineer. May use special software (e.g., backlogs, index cards, traceability matrices) to balance
between requirement flexibility and stability and that all new/changes are agreed to by stakeholders.
2.6.2.2 Scope Definition
 Is the sum of products, services and results to be provided. As scope is defined, creates need for more
requirement identification. So can be well defined up front but can evolve over time/be discovered:
o Scope Decomposition – can be elaborated various ways:
 Scope statement: to identify major deliverables and acceptance criteria;
 Decomposing: into lower levels of detail using a WBS where each level down in the
hierarchy represents a greater level of detail of deliverable and work required;
 Identifying Themes: in agile charter, roadmap or as part of hierarchy.
 Themes represent large groups of customer value reflected as user stories associated
by a common factor (i.e., functionality, data source, security);

34
  To accomplish themes, team develops epics which are logical containers for large
user story that is too big to complete within iteration;
 Epics can be decomposed into features, set of related requirements which represent
specific behaviours of a product;
 Each feature has multiple user stories which is a brief description of an outcome for
specific user. Team defines story details at last moment to avoid wasteful planning
should the scope change;
 Story is clear/concise representation of requirement from end user perspective.
o Completion of Deliverables – different ways to describe component or completion:
 Acceptance or Completion Criteria: must be met before customer accepts deliverable or
before project considered complete, often documented in scope statement;
 Technical Performance Measures: technical specs documented in specifications document or
as extension to WBS (known as WBS dictionary), which elaborates the information for each
deliverable (work package) in the WBS;
 Definition of Done: used with adaptive, is a checklist of all criteria required to be met so that
deliverable can be considered ready for customer use.
2.6.2.3 Moving Targets of Completion
 Projects that operate in uncertain or rapidly changing environments face “good enough for release” or “done”
goal but are subject to change (i.e., markets where competitors are releasing new products, new technology
trends, etc.).
 Definition of project goal being delivered or done is constantly moving. Teams track planned rate of project
goal achievement relative to rate of progress toward completion. The longer the project takes to complete, the
further the goal of “done” is to likely move – referred to as “done drift”.
 Projects operating in stable environment face “scope creep”, when additional scope/requirements are accepted
without adjust the schedule, budget or resource needs.
 To combat scope creep, team uses a change control system where all changes are evaluated for potential value
they bring to the project and resources, time and budget needed to realize value. Team presents changes to the
governance body, product owner or executive sponsor for formal approval.
2.6.3 Quality
 Focuses on performance levels required to be met. Requirements may be reflected in completion criteria,
definition of done, statement of work or requirements documentation.
 Much of the costs associated with quality are born by sponsoring organization and are reflected in policies,
procedures and work processes.
 Constant act of balancing quality of needs of processes/products with costs associated with meeting needs.
2.6.3.1 Cost of Quality (COQ)
 COQ used to find appropriate balance for investing in quality prevention and appraisal to avoid defect or
product failures. Four categories of costs associated with quality: (1) Prevention & (2) Appraisal associated
with cost of compliance to quality requirements; (3) Internal & (4) External Failure costs associated with cost
of noncompliance:
o Prevention – costs incurred to keep defects/failures out of product, avoid quality problems, associated
with design, implementation and maintenance of quality management, planning and incurred before
actual operation (e.g., quality assurance, training, quality planning, product/service requirements);
o Appraisal – determine degree of conformance to quality requirements, associated with measuring and
monitoring activities related to quality, associated with evaluation of purchased materials, processes,
products and services so that they conform to specs (e.g., verification, quality audits, supplier rating);
o Internal Failure – associated with finding and correcting defects before customer receives the
product. Are costs incurred when results of work fail to reach design quality standards (e.g., waste,
scrap, rework or rectification, failure analysis);

35
 o External Failure – found after customer has the product and with remediation. Occur when products
or services that fail to reach design quality standards are not detected until after reached the customer
(e.g., repairs and servicing, warranty claims, complaints, returns, reputation).
 To optimize delivered value, early inspection and review work focused on finding quality issues ASAP are
good investments. “Testing-quality-in” late live cycle are
likely to fail due to high rates of scrap and rework and is
time/cost prohibitive.
2.6.3.2 Cost of Change
 The later a defect is found, the more expensive it is to
correct since design and development have typically already
occurred based on flawed component. Activities are also
more costly to modify as life cycle progresses since more
stakeholders are impacted.
 To counter this, design project processes to build in quality.
Can include quality analysts working with designers to
determine how best to achieve quality during each lifecycle
step.
2.6.4 Suboptimal Outcomes
 All projects attempt to deliver outcomes, though some may fail to do so or may produce suboptimal
outcomes. This potential exists in every project.
 Effective project management can minimize negative outcomes, but different possibilities are part of the
uncertainty of attempting to produce a unique deliverable.
2.6.5 Interactions With Other Performance Domains
 Is the cumulative work done in the Planning Performance Domain and is based on the way work is structured
in the Development Approach and Life Cycle Domain.
 Project teams perform the work in this performance domain for stakeholders.
 Nature of the work to create deliveries influences how team navigates uncertainty that impacts the project.
2.6.6 Checking Results
 Refer to image for outcomes and ways of checking them.

2.7 Measurement Performance Domain

 Measurement involves assessing performance and implementing responses to maintain optimal performance.
 Metric: a description of a project/product attribute and how to
measure it.
 Baseline: approved version of a work product used as basis for
comparison to actual results.
 Dashboard: set of charts and graphs showing progress or
performance against important measures of project.

36
 Evaluates the degree to which work done in Delivery Domain is meeting the metrics identified in the
Planning Domain.
 Measures are used for multiple reasons, including:
o (1) Evaluating performance compared to plan; (2) Tracking utilization of resources, work completed,
budget use, etc.; (3) Demonstrate accountability; (4) Provide information to stakeholders; (5) Assess
whether deliverables are on track to deliver planned benefits; (6) Focus on trade-off, threats,
opportunities and options; (7) Ensure deliverables meet customer acceptance criteria.
 Value of measurements not in collection and dissemination of data, but in conversations on how to use the
data to take appropriate action.
 Use of the measures occurs within context of activities in other performance domains, such as team and
stakeholder discussions, coordinating project work, etc.
 This performance domain focuses on measures for active projects. Leaders may want to include measures that
address success or the project after it’s completed (e.g., increased customer satisfaction, decreased cost per
unit, increase in market share, increase in profit).
2.7.1 Establishing Effective Measures
 Effective measures allow for tracking, evaluating and reporting information that can communicate project
status, improve performance and reduce likelihood of performance deterioration.
2.7.1.1 Key Performance Indicators (KPIs)
 Are quantifiable measures used to evaluate the success of a project. Two types:
o Leading Indicators – predict changes or trends in the project. Can reduce performance risk on a
project by identifying potential performance variances before crossing the tolerance threshold:
 May be quantifiable but sometimes more difficult to quantify but provide early warning signs
of potential problems;
o Lagging Indicators – measure project deliverables or events by providing information after the fact
by reflecting on past performance or conditions. Are easier to measure than leading indicators (e.g.,
number of deliverables completed, schedule or cost variance, resources consumed):
 Can also be used to find correlations between outcomes and environmental variables;
 Can assist team in addressing a root cause that may not have been obvious.
2.7.1.2 Effective Metrics
 Should only measure what is relevant and ensure metrics are useful. Characteristics of effective/SMART
criteria include:
o Specific – measurements are specific as to what to measure (e.g., number of defects, fixed defects);
o Meaningful (Measurable) – should be tied to business case, baselines or requirements. Not efficient to
measure attributes that do not lead to meeting objective or improving performance;
o Achievable(Agree to) – target is achievable given the people, technology and environment;
o Relevant (Realistic/Reasonable) – information provided by measure provides value and allows for
actionable information;
o Timely (Time Bound) – forward-looking information, such as emerging trends, helps teams change
direction and make better decisions. Old information is not as useful as fresh information.
2.7.2 What to Measure
 What is measured, parameters and measurement method depend on objectives, intended outcomes and
environment. Common categories of metrics include:
o (1) Deliverable metrics; (2) Delivery; (3) Baseline performance; (4) Resources; (5) Business value;
(6) Stakeholders; (7) Forecasts.
 Balanced set of metrics provides holistic picture of project, performance and outcomes.
2.7.2.1 Deliverable Metrics
 Customary measures include:
o Information on Errors or Defects – source of defects, number of defects and resolved;

37
 o Measures of Performance – characterize physical or functional attributes relating to system operation
(e.g., size, weight, capacity, accuracy, reliability, efficiency);
o Technical Performance Measures – used to ensure system components meet technical requirements
by providing insights into progress in achieving technical solution.
2.7.2.2 Delivery
 Associated with work in progress and are frequently used in projects using adaptive approaches:
o Work in Progress – indicates number of work items being worked on at a given time. Used to help
team limit number of items in progress to manageable size;
o Lead Time – indicates amount of elapsed time from story or chunk of work entering backlog to end of
iteration or release. Lower lead time indicates more effective process/productive team;
o Cycle Time – indicates amount of time it takes team to complete a task. Shorter times indicate more
productive team and consistent time predicts future work rate;
o Queue Size – tracks number of items in a queue, compared to work in progress limit. Little’s Law
states queue size is proportional to both rate of arrival in queue and rate of completion of items from
queue. Gain insights into completion time by measuring work in progress and developing forecast;
o Batch Size – measures estimated amount of work (level of effort, story points, etc.) expected to be
completed in an iteration;
o Process Efficiency – ratio used in lean systems to optimize flow of work. Calculates ratio between
value-add (VA) and non value-add (NVA) activities. Tasks waiting increase NVA, tasks in
development or verification are VA. Higher ratios indicate more efficient process.
2.7.2.3 Baseline Performance
 Most common baselines are cost and schedule. Most schedule measures track actual to planned performance
related to:
o Start and Finish Dates – measures extent to which work is accomplished as planned. Late start and
finish dates indicate project is not performing to plan;
o Effort and Duration – actual to planned effort and duration indicates whether estimates for amount of
work and time the work takes are valid;
o Schedule Variance (SV) – simple SV determined by looking at performance on critical path. When
used with earned value management, it is the difference between earned and planned value;
o Schedule Performance Index (SPI) – is an earned value management measure indicating how
efficiently schedule work is being performed;
o Feature Completion Rates – examine rate of feature acceptance during frequent reviews to assess
progress and estimate completion dates and costs.
 Common cost measures include:
o Actual Cost Compared to Planned Cost – compares actual cost for labour or resources to estimated
cost, may be referred to as burn rate;
o Cost Variance (CV) – determined by comparing actual cost of a deliverable to the estimated cost.
When used with earned value management, it is the difference between earned value and actual cost;
o Cost Performance Index (CPI) – earned value management measure that indicates how efficiently
work is being performed with regard to budgeted cost of the work.
2.7.2.4 Resources
 May be a subset of cost measurements since resource variances frequently lead to cost variances. Teo
measures evaluate price and usage variance. Measures include:
o Planned Compared to Actual Resource Utilization – a usage variance is calculated by subtracting
planned usage from actual usage;
o Planned Compared to Actual Resource Cost – price variance is calculated by subtracting estimated
cost from actual cost.
2.7.2.5 Business Value

38
 Are used to ensure project deliverable stays aligned to business case and benefit realization plans. Has many
financial and nonfinancial aspects.
 Metrics that measure financial business value include:
o Cost-Benefit Ratio – measure of expected present value of an investment with the initial cost. Used to
determine if costs outweigh its benefits. If costs are greater than benefits, the result will be greater
than 1.0 and the project should not be considered unless there are regulatory, social good, etc. reasons.
 A similar measure is the benefit-cost ratio where the benefits are in the numerator and costs in
the denominator. If the ratio is greater than 1.0, project should be considered;
o Planned Compared to Actual Benefits Delivery – in business cases, value may be identified as the
benefit that will be delivered as a result of doing the project. For projects expecting to deliver benefits
during life cycle, measuring the benefits delivered and value of those benefits, then comparing the
information to the business case, provides justification of continuation or cancellation of the project;
o Return on Investment (ROI) – amount of financial return compared to cost. Is generally an input in the
decision to undertake a project. There may be estimates of ROI at different points in time across the
life cycle. By measuring ROI throughout the project, can determine if it makes sense to continue;
o Net Present Value (NPV) – difference between present value of inflows and outflows of capital over a
period of time. NPV is generally developed when deciding to undertake a project. Measuring NPV
throughout the project helps determine if makes sense to continue.
2.7.2.6 Stakeholders
 Stakeholder satisfaction measured with surveys or by inferring satisfaction or lack thereof by looking at
metrics such as:
o Net Promoter Score (NPS) – measures the degree to which a stakeholder is willing to recommend a
product/service to others.
 Measures a range from -100 to +100. High NPS measures satisfaction with a brand/product/
service and is an indicator of customer loyalty;
o Mood Chart – tracks mood/reactions of the project team, but is subjective. At the end of the day the
team uses colours, numbers or emojis to indicate their frame of mind. Tracking this can help identify
potential issues and areas for improvement;
o Morale – can be done by surveys, asking team members to rate their agreement on scale of 1-5 to
statements like: (1) I feel my work contributes to overall outcomes; (2) Feel appreciated; (3) Am
satisfied with way my team works together;
o Turnover – looking at unplanned team turnover. High rates may indicate low morale.
2.7.2.7 Forecasts
 Used to consider what might happen in the future so can discuss whether to adapt plans and work.
 Can be qualitative, e.g., using expert judgement about what the future will hold.
 Can be casual when seeking to understand impact of specific event/condition on future events.
 Quantitative forecasts seek to use past info to estimate what will happen in the future. They include:
o Estimate to Complete (ETC) – an earned value management
measure that forecasts expected cost to finish all of
remaining work. Assuming past performance is indicative of
future performance, common measurement is calculating
budget at completion minus earned value, then dividing by
cost performance index;
o Estimate at Completion (EAC) – forecasts expected total cost
of completing all work. A common measurement is budget at
completion divided by cost performance index;
o Variance at Completion (VAC) – forecasts amount of budget
deficit or surplus. It is expressed as the difference between
budget at completion (BAC) and EAC;

39
 o To-Complete Performance Index (TCPI) – estimates cost performance required to meet a specific
management goal. Is expressed as a ratio of cost to finish outstanding work to remaining budget;
o Regression Analysis – analytical method where series of input variables are examined in relation to
their corresponding output results in order to develop relationship which is used to infer future
performance;
o Throughput Analysis – analytical method assesses number of items being completed in fixed time
frame. Teams that use adaptive practices use these metrics like features complete vs. remaining,
velocity, story points to evaluate progress and estimate completion dates. Using duration estimates
and burn rates help verify and update cost estimates.
2.7.3 Presenting Information
 What is done with information after collected is just as important. To be useful, it must be timely, accessible,
easy to absorb/digest and presented to correctly convey degree of uncertainty.
 Visual displays with graphics can help stakeholders absorb and make sense of info.
2.7.3.1 Dashboards
 Collect information electronically and generate charts that depict status.
 Offer high level summaries of data and allow drill-down analysis into contributing data.
 Include information displayed as stoplight charts (RAG – red-amber-green), bar charts, pie charts, and control
charts. Text explanations used for measures outside of established thresholds.
2.7.3.2 Information Radiators
 Also known as big visible charts (BVCs) are visible, physical displays that provide information to the rest of
the organization, enabling timely knowledge sharing.
 Are posted in a place where people can see information easily.
Should be easy to update and should be updated frequently.
 Are “low tech and high touch” in that they are manually
maintained rather than electronically generated.
2.7.3.3 Visual Controls
 In lean environments, information radiators are known as visual
controls. They illustrate processes to easily compare actual
against expected performance.
 Visual controls can be present for all levels of information from
business value delivered to tasks that are started and should be
highly visible for anyone to see:
o Task Boards – visual representation of planned work
allowing everyone to see status of tasks, showing work
that is ready to be started, in progress and is completed:
 Flow-based projects, like use of Kanban boards, use
these charts to limit amount of work in progress;
o Burn Charts – shows project team velocity which measures
productivity rate at which deliverables are produced,
validated and accepted within predefined interval:
 Burnup Chart: track amount of work done
compared to expected work that should be done;
 Burndown Chart : shows the number of story points
remaining or amount of risk exposure that has been
reduced;
o Other Types of Charts – include other information such as
impediment list showing description of impediment to
getting work done, severity and actions being taken to resolve impediment.
2.7.4 Measurement Pitfalls
 Measures help team meet objectives but there are some pitfalls associated with measurement:

40
 o Hawthorne Effect – the very act of measuring something influences behaviour so take care in
establishing metrics;
o Vanity Metric – measure that shows data but does not provide useful information for making
decisions;
o Demoralization – if measures and goals are set that are not achievable, team morale may fall as they
continuously fail to meet targets. Unrealistic or unachievable goals can be counterproductive;
o Misusing the Metrics – there is opportunity for people to distort measurements or focus on wrong
thing (e.g., focus on less important metrics, focus on performing well for short-term at expense of
long-term metrics, work on out of sequence activities that are easy to accomplish to improve
performance indicators);
o Confirmation Bias – humans tend to look for and see information that supports our preexisting point
of view which can lead us to false interpretations of data;
o Correlation vs Causation – common mistake is confusing correlation of two variables with idea that
one causes the other.
2.7.5 Troubleshooting Performance
 Part of measurement is having agreed to plans for measures that are outside threshold ranges. These can be
established for metrics such as schedule, budget, velocity, etc. Degree of variance depends on risk tolerances.
 Teams should not wait until threshold has been breached before taking action. Breaches should be forecasted
to be proactive in addressing expected variance.
 Exception plan is agreed-upon set of actions to be taken if a threshold is crossed or forecast. They do not have
to be formal. Importance is to discuss the issue and develop a plan for what needs to be done, then follow
through to make sure it is implemented and determine if it is working.
2.7.6 Growing and Improving
 Intent in measuring and displaying data is to learn and improve. In optimizing project performance and
efficiency, measure and report information that will:
o (1) Allow team to learn; (2) Facilitate a decision; (3) Improve some aspect of product/project
performance; (4) Help avoid an issue; (5) Prevent performance deterioration.
 Measurements facilitate ability to generate business value and achieve objectives and performance targets.
2.7.7 Interactions With Other Performance Domains
 Interacts with Planning Project Work and Delivery Performance Domains as plans form basis for comparing
the deliveries to the plan.
 Support activities part of Planning Domain by presenting up-to-date information so lessons learned reflect
favourable or unfavourable information for updating plans.
 Team and Stakeholder Domains interact as team members develop plans and create deliverables measured.
 Activities in Uncertainty Domain, such as identifying risks and opportunities, can be initiated based on
performance measurements.
2.7.8 Checking Results
 Refer to image for outcomes and ways of checking them.

41
2.8 Uncertainty Performance Domain
 Uncertainty presents threats and opportunities that teams
explore, assess and decide how to handle.
 Uncertainty: lack of understanding and awareness of issues,
events, paths to follow, or solutions.
 Ambiguity: state of being unclear, having difficulty in
identifying cause of events, or having multiple options from
which to choose.
 Complexity: characteristic of a program/project or its
environment that is difficult to manage due to human and
system behaviour, and ambiguity.
 Volatility: possibility for rapid and unpredictable change.
 Risk: uncertain event or condition that has a positive or
negative effect on one or more project objectives.
 Many nuances to uncertainty such as:
o (1) Risk associated with not knowing future events; (2) Ambiguity associated with not being aware of
current or future conditions; (3) Complexity of dynamic systems having unpredictable outcomes.
 Navigating uncertainty means understanding larger environment the project is operating in. Aspects of the
environment that contribute to project uncertainty include:
o Economic factors (e.g., volatility in prices, resource availability, inflation/deflation, fund borrowing);
o Technical considerations (e.g., new/emerging technology, system complexity, interfaces);
o Legal or legislative constraints/requirements;
o Physical environment (e.g., safety, weather, working conditions);
o Ambiguity of current or future conditions;
o Social and market influences (e.g., opinion, media);
o Political influences internal or external to the organization.
2.8.1 General Uncertainty
 Is inherent in all projects so effects cannot be predicted precisely and range of outcomes can occur.
 Outcomes that benefit objectives are opportunities, while negative effects on objectives are threats. Together
these comprise the set of project risks.
 Several options to respond to uncertainty:
o Gather Information – uncertainty can be reduced by finding out more information (e.g., conducting
research, engaging experts, performing market analysis);
o Prepare for Multiple Outcomes – preparing means having a primary solution available, and backup or
contingency plans in case the initial solution is not viable or effective. If there are a lot of potential
outcomes, team can categorize and assess potential causes to estimate likelihood of occurrence to
narrow down focus;
o Set-Based Design – multiple designs or alternatives investigated early in the project to reduce
uncertainty with intention to explore options so the team can learn from working with various
alternatives with ineffective alternatives discarded throughout;
o Build In Resilience – ability to adapt and respond quickly to unexpected changes.
2.8.2 Ambiguity
 Conceptual ambiguity is the lack of effective understanding which occurs when people use similar terms or
arguments in different ways. Can be reduced by formally establishing common rules and definitions of terms.
 Situational ambiguity is when more than one outcome is possible. Solutions include:
o Progressive Elaboration – iterative process of increasing level of detail in project management plan
as greater amounts of information and more accurate estimates become available;
o Experiments – help identify cause-and-effect relationships or can reduce amount of ambiguity;
o Prototypes – help distinguish relationships between different variables.

42
2.8.3 Complexity
 Exists when there are many interconnected influences that behave and interact in diverse ways.
 Effect of complexity is that there is no way of making accurate predictions about likelihood of potential
outcome or even of knowing what outcomes might emerge.
 Ways to work with complexity are systems-based, reframing and process.
2.8.3.1 Systems-Based
 Working with complexity that is systems based include:
o Decoupling – disconnecting parts of the system to both simplify and reduce the number of connected
variables. Determine how a piece of the system works on its own to reduce the overall problem;
o Simulation – there may be similar though unrelated scenarios that can be used to simulate
components of a system.
2.8.3.2 Reframing
 Working with complexity that entail reframing are:
o Diversity – require viewing system from diverse perspectives (i.e., brainstorming with team to open
divergent ways of seeing the system, moving divergent to convergent thinking);
o Balance – balancing type of data used rather than only using forecasting data or data that report on
past or lagging indicators provides broader perspective. Use elements whose variations are likely to
counteract each other’s potential negative effects.
2.8.3.3 Process-Based
 Working with complexity that is process based includes:
o Iterate – build iteratively or incrementally, adding features one at a time. After each iteration, identify
what worked, what didn’t work, customer reaction and what team has learned;
o Engage – build in opportunities to get stakeholder engagement to reduce the number of assumptions
and builds learning and engagement into the process;
o Fail Safe – for elements that are critical, build in redundancy or elements that can provide
degradation of functionality in event of critical component failure.
2.8.4 Volatility
 Exists in environment that is subject to rapid and unpredictable change, occurs when ongoing fluctuations in
available skill sets/materials, impacts cost and schedule.
 To address volatility:
o Alternative Analysis – finding and evaluating alternatives which may include identifying variables to
be considered in evaluating options, and relative importance or weight of each variable;
o Reserve – cost reserve used to cover budget overruns due to price volatility. Schedule reserve can be
used to address delays due to volatility associated with resource availability.
2.8.5 Risk
 Team members should proactively identify risks throughout project to avoid/minimize impacts of threats and
maximize impacts of opportunities. There are strategies that can be planned for should the risk occur.
 To navigate risk, team needs to know what level of
risk exposure is acceptable to reach objectives. This is
defined by measurable risk thresholds that reflect risk
appetite and organization/stakeholder attitude.
 Thresholds are stated and communicated to team and
reflected in risk impact level definitions for project.
 If the overall risk on the project is too high, the
organization may cancel the project.
2.8.5.1 Threats
 An event or condition that has a negative impact on
objectives. Five strategies considered for threats:

43
 o Avoid – team acts to eliminate threat or protect project from its impacts;
o Escalate – when team or sponsor agree that threat is outside project scope or proposed response
would exceed project manager’s authority;
o Transfer – shifting ownership of threat to third party to manage and bear the impact;
o Mitigate – action is taken to reduce probability of occurrence and/or impact of threat. Earlier
mitigation is more effective than repairing damage;
o Accept – acknowledges existence of threat but no proactive action is planned. Includes developing
contingency plan if event occurs, or passive acceptance, which means doing nothing.
 A response to a threat might include multiple strategies.
 Goal of implementing threat responses is to reduce amount of negative risk. Risks that are accepted
sometimes are reduced by the passage of time or because risk event does not occur.
2.8.5.2 Opportunities
 Event or condition that has a positive impact on objectives. Five strategies for opportunities:
o Exploit – response strategy where team acts to ensure opportunity occurs;
o Escalate – same as for threats but for opportunities;
o Share – allocating ownership of opportunity to third party to best capture benefit;
o Enhance – team acts to increase probability of occurrence or impact. Early enhancement is more
effective than trying to improve opportunity after it’s
already occurred;
o Accept – acknowledge its existence but no proactive
action is planned.
 Once risk responses are developed, should be reviewed to see
whether planned responses add secondary risks. Should also
assess residual risk that will remain after response actions are
carried out.
 Response planning should be repeated until risk is compatible
with risk appetite.
 Economic view of risk looks at Expected Monetary Value
(EMV) compared to anticipated ROI of deliverable or feature.
Project manager has conversations to determine where/when to
incorporate risk responses.
2.8.5.3 Management and Contingency Reserve
 Reserve is amount of time or budget set aside to account for handling risks.
 Contingency reserve is set aside to address identified risks should they occur.
 Management is budget category used for unknown events (i.e., unplanned, in-scope work).
2.8.5.4 Risk Review
 Establishing rhythm or cadence of review and feedback sessions is helpful for navigating risk and being
proactive with risk responses.
 Examples include daily stand-up meetings, reports of progress and breakthroughs, frequent demonstrations of
increments of product/service, interim designs, proof of concepts, addressing risk at weekly status meetings,
and retrospectives and lessons learned meetings.
2.8.6 Interactions With Other Performance Domains
 Interacts with Planning, Project Work, Delivery and Measurement Performance Domains from
product/deliverable perspective.
 As planning is conducted, activities to reduce risks are built into plan which is carried out in Delivery
Domain, while Measurements indicate if risk level changes over time.
 Team members and stakeholders are main sources of information regarding uncertainty.
 Choice of lifecycle and development approach impact addressing uncertainty:
o On predictive projects, reserve in the schedule and budget can be used to respond to risks;

44
 o On adaptive projects, team can adjust plans to reflect evolving understanding or use reserves to offset
impacts of realized risks.
2.8.7 Checking Results
 Refer to image for outcomes and ways of checking them.

3 – Tailoring
3.1 Overview
 Tailoring is the deliberate adaptation of project management approach, governance and processes to make
them more suitable for given environment and work at hand.
 Considers the development approach, processes, project life cycle, deliverables, and people to engage.
 Entails the mindful selection and adjustment of multiple project factors, regardless of whether the label
“tailoring” is used.
 Alternative to tailoring is using unmodified framework or methodology that provide descriptions of processes,
phases, methods, artifacts and templates to be used in projects but are not customized to organization.
 Tailoring requires understanding project context, goals, and operating environment. Projects operate in
complex environments that need to balance competing demands, including:
o (1) Delivering as quickly as possible; (2) Minimizing project costs; (3) Optimizing value delivered;
(4) Creating high-quality deliverables and outcomes; (4) Providing compliance with regulatory
standards; (5) Satisfying diverse stakeholder expectations; (6) Adapting to change.
3.2 Why Tailor?
 Structure used to deliver projects can be extensive or minimal, rigorous or lightweight, robust or simple.
There is no single approach that can be applied to all projects all the time.
 Tailoring should reflect the size, duration and complexity of each individual project and should be adapted to
industry, organizational culture and level of project management maturity of organization.
 Tailoring produces direct and indirect benefits to the organization:
o (1) Commitment from team who helped tailor approach; (2) Customer-oriented focus since they are
influencing factor in its development; (3) More efficient use of project resources.
3.3 What to Tailor
3.3.1 Life Cycle and Development Approach Selection
 Deciding on a life cycle and the phases is an example of tailoring.
 Additional tailoring can be done when selecting development and delivery approach for the project. Larger
projects may use a combination of development and delivery approaches simultaneously.
3.3.2 Processes
 Process tailoring for selected life cycle and development approach includes determining which portions or
elements should be:

45
 o Added – to bring required rigor, coverage or address unique product/operating environment
conditions (e.g., adding independent inspections);
o Modified – to better suit project or team requirements (e.g., modify project document formats to
accommodate team member vision limitations);
o Removed – to reduce cost or effort that is no longer required or not economical (e.g., remove meeting
minutes for small team with good communication);
o Blended – bring additional benefits/value by mixing/combining elements (e.g., add appreciative
inquiry methods to foster better collaboration);
o Aligned – harmonize elements for consistent definition, understanding and application (e.g., different
disciplines have standards for risk management different from each other and needs to be aligned).
3.3.3 Engagement
 Tailor engagement for people involved in the project, this includes:
o People – evaluating skills and capability of leadership and team, then selecting who should be
involved and in what capacities based on project type and operating conditions;
o Empowerment – choosing which responsibilities and forms of local decision making should be
deferred to project team;
o Integration – teams can include contributors from contracted entities, channel partners and other
external entities in addition to staff from inside sponsoring organization. Tailoring considers how to
create one team from this diverse collection of contributors.
3.3.4 Tools
 Selecting tools (e.g., software or equipment) team will use for project is form of tailoring.
 Often, team has best insight into most suitable tools for the situation, but choices might need tempering based
on associated costs.
 Organizational leaders can also impose constraints that team cannot change.
3.3.5 Methods and Artifacts
 Tailoring means that will be used to achieve project outcomes is performed so that methods are suited for
environment and culture.
 Tailoring documents, templates and other artifacts that will be used on project helps make sure artifacts are
appropriate for project and organization.
3.4 The Tailoring Process
 Tailoring typically begins by selecting a development and delivery approach, tailoring it for the organization,
for the project and then implementing its ongoing improvement.
3.4.1 Select Initial Development Approach
 Determines the development approach that will be used for the project.
 Teams apply their knowledge of the product, delivery cadence and awareness of the available options to select
the most appropriate development approach for the situation.
 Suitability filter tool can help teams consider if project leans towards predictive, hybrid, or adaptive approach.
It is an informational tool that combines assessment with other decision making activities so that approach is
appropriate for each project (e.g., evaluate criteria on culture, team and project factors).
3.4.2 Tailor For The Organization
 Many organizations have a project methodology, general management or development approach that is used
as starting point for their projects.
 Organizations that have established process governance need to ensure tailoring is aligned to policy and teams
may need to justify using a tailored approach.
 Additional constraints for tailoring include large safety-critical or contract projects. Large safety may require
additional oversight/approval to prevent errors. Contracts may have terms that specify use of approach.

46
 Tailoring uses factors such as project size, criticality,
organizational maturity and other considerations to add,
remove and reconfigure elements to make it more suitable
for the individual organization.
 Organizations with PMO or Value Delivery Office (VDO)
may play a role in reviewing and approving tailored
delivery approaches.
 Tailoring internal projects requires less oversight than
tailoring that impacts external groups.
 VDO found in adaptive approaches. It serves as enabling
role, rather than management or oversight. Focuses on
coaching teams, building adaptive skills and mentoring sponsors/product owners to be more effective.
3.4.3 Tailor For The Project
3.4.3.1 Product/Deliverable
 Attributes associated with product/deliverable include:
o Compliance/Criticality – how much process rigor and QA is appropriate;
o Type of Product/Deliverable – is product well known/physical or intangible, i.e., building or software;
o Industry Market – what market, is it regulated, fast moving or slow to evolve? Competitors?;
o Technology – is technology stable and established or rapidly evolving and risk of obsolescence?;
o Time Frame – time frame short or long, i.e., weeks/months or years;
o Stability of Requirements – likelihood of changes to core requirements?;
o Security – elements of product business confidential or classified?;
o Incremental Delivery – something the team can develop and get stakeholder feedback on
incrementally, or something that is hard to evaluate until completion?
3.4.3.2 Project Team
 Team considerations include:
o Project Team Size – how many full and part-time people will be working on project?
o Team Geography – where are team members located? Remote or co-located?
o Organizational Distribution – where are team’s supporting groups/stakeholders located?
o Team Experience – team experience in industry, organization or working with each other? Skills,
tools, and technology required for project?
o Access to Customer – practical to get frequent/timely feedback from customers/representatives?
3.4.3.3 Culture
 Evaluating culture includes considering:
o Buy-In – acceptance, support, and enthusiasm for proposed delivery approach?
o Trust – high levels of trust in team that capable and
committed to delivering outcome?
o Empowerment – team trusted, supported and
encouraged to own and develop working
environment, agreements and decisions?
o Organizational Culture – organization values and
culture align with approach? Includes empowering
vs. specifying and checking, trusting decision making
vs. requesting external decision making, etc.
3.4.3.4 Implement Ongoing Improvement
 Process of tailoring is not a single, one-time exercise.
 Review points, phase gates and retrospectives all provide
opportunities to inspect and adapt the process, development
approach and delivery frequency as necessary.

47
 Keeping team engaged with improving process fosters ownership and commitment to ongoing improvements
and quality. Also demonstrates trust in their skills and empowerment.
 How organizations tailor can itself be tailored, but most follow the main four steps (refer to image).
3.5 Tailoring the Performance Domains
 Work associated with each performance domain can be tailored based on uniqueness of project.
 Principles of project management provide guidance for behaviour of project practitioners as they tailor
performance domains to meet needs of project context and environment.
 There are tailoring considerations for each performance domain below.
3.5.1 Stakeholders
 Is there collaborative environment for stakeholders/suppliers?
 Are stakeholders internal/external to organization, or both?
 What technologies are most appropriate/cost effective for stakeholder communication? What communication
technology is available?
 What language is used? Allowances made to adjust to stakeholders from diverse language groups?
 How many stakeholders are there? How diverse is the culture among stakeholder community?
 What are the relationships within the stakeholder community? The more networks, the more complex are
networks of information and misinformation stakeholders may receive.
3.5.2 Project Team
 Physical location of members? Is the team co-located, in same geographical area, or multiple time zones?
 Does the team reflect diverse viewpoints and cultural perspectives?
 How will members be identified for the project? Are they fulltime or parttime on the project? Are there
contractors capable of performing the work?
 Does the team have an existing culture? How will tailoring be influenced by this and vice versa.
 How is team development managed? Are there organizational tools to manage team development or will
new ones need to be established?
 Are there team members who have special needs? Will team need special training to manage diversity?
3.5.3 Development Approach and Life Cycle
 Which development approach is appropriate for product/service/result?
o If adaptive, should project be developed incrementally or iteratively?
o Is hybrid approach best?
 What is appropriate life cycle for specific project? What phases should comprise the life cycle?
 Does the organization have formal/informal audit/governance policies, procedures and guidelines?
3.5.4 Planning
 How will internal and external environment factors influence project and its deliverable?
 What factors are influencing durations (available resources and productivity)?
 Does organization have formal or informal policies, procedures, guidelines for cost estimating and budgeting?
 How does the organization estimate cost when using adaptive approach?
 Is there one main procurement or are there multiple procurements?
 Are local laws/regulations regarding procurement integrated with policies? Will this affect contract auditing?
3.5.5 Project Work
 What is most effective management process based on culture, complexity and other project factors?
 How will knowledge by managed to foster collaborative working environment?
 What information should be collected throughout and at the end of the project? How will the information be
collected/managed? What technology used to develop, record, send, retrieve, store information/artifacts?
 Will historical information and lessons learned be available for future projects?
 Does organization have formal knowledge management repository that team must use and can access?
3.5.6 Delivery
 Does organization have formal/informal requirements management systems?

48
 Does organization have existing formal/informal validation and controlled policies/procedures/guidelines?
 What quality policies already exist? What quality tools, techniques, templates are used?
 Are there specific quality standards in industry that need to be applied? Any governmental, legal or regulatory
constraints that need to be taken into consideration?
 Areas of project with unstable requirements? What is best approach for addressing this?
 How does sustainability factor into management and development?
3.5.7 Uncertainty
 What is risk appetite and tolerance for current endeavor?
 How are threats and opportunities best identified and addressed within development approach?
 Project complexity, technological uncertainty, product novelty, cadence or progress tracking impact project?
 Does project size for budget, duration, scope, team size require more detailed approach to risk management?
Is project small enough to justify simplified risk management process?
 Is robust risk management demanded by high levels of innovation, new technology, commercial
arrangements, interfaces or external dependencies? Or is project simple enough for reduced risk management?
 How strategically important is the project? Is level of risk increased due to breakthrough opportunities,
address significant blocks to organization performance or involve major product innovation?
3.5.8 Measurement
 How is value measured?
 Measures for financial and nonfinancial value?
 How project enables data capture/reporting for benefits realization, both during and after project completed?
 What are project status reporting requirements?
3.6 Diagnostics
 Periodic reviews such as retrospectives or lessons learned are
effective to determine if approaches are working well ad if
improvements can be made by tailoring.
 Teams that don’t use retrospectives can look to issues, threats,
QA stats and stakeholder feedback for signs that further tailoring
or adaptation might be required/useful.
 The image includes common situations and suggested tailoring.
3.7 Summary
 Tailoring involves considered adaptation of approach,
governance, and process to make them more suitable for given
environment and project.
 Involves analysis, design and deliberate modification of people
elements, processes employed and tools used.
 When tailoring is undertaken, bounds and approach usually governed by organizational guidelines to ensure
external interfaces between teams mesh correctly and provides guidance in form of tailoring considerations.

4 – Models, Methods, and Artifacts

4.1 Overview
 Model: is a thinking strategy to explain a process, framework or phenomenon.
 Method: means for achieving an outcome, output, result or project deliverable.
 Artifact: can be a template, document, output or project deliverable.
 As teams consider tailoring questions and decide on specific responses, they start to build a framework for
structuring their efforts to deliver project outcomes.
 Tailoring includes the models and methods used to perform work in project performance domain.
 Use of models, methods and artifacts has associated costs related to time, level of expertise/proficiency in use,
impact on productivity, etc.

49
 Teams should avoid using anything that:
o (1) Duplicates/adds unnecessary effort; (2) Is not useful to team and stakeholders; (3) Produces
incorrect/misleading information; (4) Caters to individual needs vs. project team.
4.2 Commonly Used Models
 Models reflect small-scale, simplified views of reality and present scenarios, strategies or approaches for
optimizing work processes and efforts.
 Can shape behavior and point to approaches for solving problems or meeting needs.
4.2.1 Situational Leadership Models
 Are a subset of a vast array of leadership models.
 Situational leadership models describe ways to tailor one’s leadership style to meet needs of the individual
and project team.
4.2.1.1 Situational Leadership II
 Ken Blanchard’s Situational Leadership II measures project team member development using competence and
commitment as two main variables.
o Competence is combination of ability, knowledge and skill;
o Commitment speaks to confidence and motivation an individual has.
 As both evolve, leadership styles evolve from directing to coaching to supporting to delegating.
4.2.1.2 OSCAR Model
 This coaching and mentoring model, developed by Karen Whittleworth/Andrew Gilbert, helps people adapt
their coaching/leadership styles to support those who have action plans for personal development.
 Five contributing factors:
o Outcome – identified long-term goals of person and desired result from each conversation;
o Situation – enables conversation about current skills, abilities and knowledge level of team member,
why person is at that level and how it impacts their performance and relationships;
o Choices/Consequences – identify all potential avenues for attaining desired outcome and
consequences of each choice so can choose viable avenues for reaching long-term goals;
o Actions – commits to specific improvements by focusing on immediate and attainable targets that
individual can work toward within specified time frame;
o Review – hold regular meetings to support and ensure individuals remain motivated and on track.
4.2.2 Communication Models
 Communication models are concepts associated with how sender and receiver frames of reference impact
effectiveness of communication, how communication medium influences effectiveness of communication,
and types of disconnects between end-user expectations and reality.
4.2.2.1 Cross-Cultural Communication
 Model developed by Browaeys and Price incorporates idea that message itself and how it is transmitted is
influenced by sender’s current knowledge, experience, language, thinking and communication styles, as well
as stereotypes and relationship to the receiver.
 Similarly the same concepts on the receiver side to the sender will influence how message is interpreted.
4.2.2.2 Effectiveness of Communication Channels
 Developed by Alistair Cockburn, a model that describes communication channels along axes of effectiveness
and richness.
 Definition of Richard Daft and Robert Lengel, richness related to amount of learning that can be transmitted
through a medium. Media richness is a function of characteristics, including ability to:
o (1) Handle multiple information cues simultaneously; (2) Facilitate rapid feedback; (3) Establish
personal focus; (4) Utilize natural language.
 Richness in communication allows broad spectrum of information conveyed rapidly.
 Situations with complex/complicated/personal information benefit from richer communication (i.e., face-to-
face). Situations with simple/factual information use less rich channels (i.e., note or text message).
4.2.2.3 Gulf of Execution and Evaluation

50
 Donald Norman described gulf of execution as degree to which item corresponds with expectation of it or the
difference between intention of a user and what the item allows them to do or supports them in doing.
 The gulf of evaluation is the degree to which an item supports the user in discovering how to interpret the
item and interact with it effectively.
4.2.3 Motivation Models
 Understanding what motivates team members and other stakeholders helps to tailor rewards to the individual,
thereby electing more effective engagement.
4.2.3.1 Hygiene and Motivational Factors
 Studied by Frederick Herzberg, job satisfaction and dissatisfaction stem from conditions called motivational
factors which include matters related to content of work, i.e., achievement, growth and advancement.
 Insufficient and sufficient motivational factors lead to dissatisfaction and satisfaction, respectively.
 Identified hygiene factors related to work such as company policies, salary and physical environment. If these
factors are insufficient, they cause dissatisfaction. If they are sufficient though, do not lead to satisfaction.
4.2.3.2 Intrinsic Versus Extrinsic Motivation
 Daniel Pink stated that while extrinsic rewards (i.e., salary) are motivators to a certain extent, once a person is
paid fairly for their work, motivational power of extrinsic rewards ceases to exist.
 For complicated/challenging work, intrinsic motivators are longer lasting and more effective. Identified three
types of intrinsic motivators:
o Autonomy – desire to direct one’s own life, aligned with being able to determine how, where and
when to accomplish work (e.g., flexible hours, WFH, self-selecting/self-managing teams);
o Mastery – being able to improve and excel (e.g., desire for excellent work, learn, achieve goals);
o Purpose – need to make a difference, knowing project vision and how work contributes to achieving
that vision, allowing people to feel like they are making a difference.
4.2.3.3 Theory of Needs
 David McClellan’s model states all people are driven by needs of achievement, power and affiliation. Relative
strength of each need depends on individual’s experiences and culture:
o Achievement – people are motivated by activities and work that is challenging but reasonable;
o Power – people like to organize, motivate and lead other, motivated by increased responsibility;
o Affiliation – people seek acceptance and belonging, motivated by being part of a team.
4.2.3.4 Theory X, Y and Z
 Douglas McGregor devised Theory X and Y models, which represent spectrum of employees motivation and
corresponding management styles, and later expanded to include Theory Z:
o Theory X – assumed individuals work for sole purpose of income, they are not ambitious or goal
oriented. Corresponding management style to motivate is hands-on, top-down approach and often
seen in production or labour-intensive environment with many layers of management;
o Theory Y – individuals are intrinsically motivated to do good work. Management style has personal
coaching feel where manager encourages creativity and discussion. Often seen in creative and
knowledge worker environments;
o Theory Z – transcendent dimension to work where individuals are motivated by self-realization values
and higher calling. Optimal management is one that cultivates insight and meaning. Motivate
employees by creating a job for life where focus is on well-being of employees/families. Promotes
high productivity, morale and satisfaction.
4.2.4 Change Models
 Many projects contain aspect of changing systems, behaviours, activities and sometimes cultures. Managing
this requires thinking about how to transition from current to future desired state.
4.2.4.1 Managing Change in Organizations
 Iterative model based on common elements across range of change management models. Has 5 associated
elements interconnected through series of feedback loops:

51
 o Formulate Change – building rational to help people understand why change is needed and how the
future state will be better;
o Plan Change – identification of activities helps to prepare for transition from current to future state;
o Implement Change – focuses on demonstrating future state capabilities, checking to ensure intended
impact is happening and making necessary improvements or adaptations in response;
o Manage Transition – considers how to address needs related to change that surface in future state;
o Sustain Change – ensure new capabilities continue and previous processes/behaviours cease.
4.2.4.2 ADKAR Model
 Developed by Jeff Hiatt, which focuses on 5 sequential steps that individuals undergo when adapting:
o Step 1: Awareness – identifies why the change is necessary;
o Step 2: Desire – needs to be a desire to be part of and support the change;
o Step 3: Knowledge – need to understand how to change, includes understanding new processes and
systems in addition to new roles and responsibilities. Knowledge gained through training/education;
o Step 4: Ability – knowledge supported through hands-on practice and access to expertise/help;
o Step 5: Reinforcement – change sustainment (e.g., rewards, recognition, feedback, measurement).
4.2.4.3 The 8-Step Process for Leading Change
 John Kotter introduced the process for transforming organizations, a top down approach where the need for
and approach to change originates at top levels of organization and promoted down through layers of
management. The eight steps are:
o Step 1: Create Urgency – identify potential threats and opportunities that drive need for change;
o Step 2: Form A Powerful Coalition – identify change leaders, should be influential people from a
variety of roles, expertise, social and political importance;
o Step 3: Create a Vision For Change – identify values that are central to the change then create brief
vision statement that summarizes change and identify strategy to realize vision;
o Step 4: Communicate the Vision – happens throughout change process, apply vision throughout all
aspects of organization. Senior management and change coalition must communicate vision and
demonstrate urgency and benefits of change;
o Step 5: Remove Obstacles – all change comes with obstacles (e.g., outdated processes, organizational
structure, people resistant to change), but need to be addressed;
o Step 6: Create Short-Term Wins – identify quick/easy wins to build momentum/support for change;
o Step 7: Build On The Change – once short-term wins are complete, set goals for continued
improvement;
o Step 8: Anchor The Changes in Corporate Culture – ensure change becomes ingrained into the
culture, continue to communicate vision, tell success stories, recognize people in organization who
embody and empower change, continue to support change coalition.
4.2.4.4 Virginia Satir Change Model
 Developed a model of how people experience and cope with change to help project team members understand
what they are feeling and enable them to move more efficiently through change:
o Late Status Quo – when everything feels familiar and is “business as usual”. For some, this is good
because they know what to expect. For others, status may feel stale or boring;
o The Foreign Element – shift status quo (i.e., initiating project for change in people’s usual way of
working). Period of resistance/reduction in performance, may ignore change or dismiss its relevance;
o Chaos – people in unfamiliar territory, no longer comfortable and performance drops to lowest levels
where feelings, actions, behaviours are unpredictable (e.g., anxious, may shut down, excited). Chaos
makes people creative, trying to find ways to make sense of situation and have positive outcome;
o The Transforming Idea – come to a point where come up with an idea that helps makes sense of the
situation, begin seeing how can find a way out of chaos and cope with new reality and performance
begins to increase;

52
 o Practice and Integration – implement new ideas or behaviours, may be setbacks and period of trial
and error but eventually learn what works and what doesn’t. Leads to improved performance at a
higher level than before;
o New Status Quo – get used to new environment, performance stabilizes and new status quo becomes
normal way of working.
4.2.4.5 Transition Model
 William Bridges’ Transition Model provides understanding of what occurs to people psychologically when
change takes place and differentiates between change and transition:
o Change is situational and happens whether or not people transition through it;
o Transition is a psychological process where people gradually accept details of new situation and
changes that come with it.
 Three stages of transition associated with change:
o Ending, Losing and Letting Go – change introduced, often associated with fear, anger, upset,
uncertainty, denial and resistance to change;
o The Neutral Zone – change is happening, people feel frustration, resentment, confusion and anxiety.
Productivity drops or people become creative, innovative and passionate about new ways;
o The New Beginning – accept and embrace change, more adept at new skills and ways of working.
People are open to learning and energized by the change.
4.2.5 Complexity Models
 Projects exist in state of ambiguity and require interactions among multiple systems, with uncertain outcomes.
 Complexity is a challenge to work with. Frameworks help determine decision making in this environment.
4.2.5.1 Cynefin Framework
 Created by Dave Snowden, is a conceptual framework used to diagnose cause-and-effect relationships as a
decision-making aid. Offers 5 problem and decision-making contexts:
o Where obvious cause-and-effect relationship, best practices used to make decisions;
o Complicated relationships exist when set of known unknowns or range of correct answers. Best to
assess facts, analyze situation and apply good practices;
o Also include unknown unknowns with no apparent cause and effect or right answers. Should probe
environment, sense situation and respond with action. Style uses emergent practices that allow for
repeated cycles of probe-sense-respond as things change;
o In chaotic environments, cause and effects are unclear. First step is to action to stabilize situation,
then sense when there is stability, respond by taking steps to get chaotic to complex situation;
o Disordered relationships lack clarity and require breaking into smaller parts whose context links with
one of other four contexts.
 Cynefin framework helps identify behaviours like probing, sensing, responding, acting and categorizing,
which impacts relationships between variables and guide actions.
4.2.5.2 Stacey Matrix
 Developed by Ralph Stacey, similar to Cynefin, but looks at two dimensions to determine relative project
complexity:
o (1) Relative uncertainty of requirements for deliverable; (2) Relative uncertainty of technology that
will be used to create the deliverable.
 Based on relative uncertainty of dimensions, project is considered simple, complicated, complex or chaotic.
 Degree of complexity is one factor influencing tailoring methods and practices for the project.
4.2.6 Project Team Development Models
 Project teams move through different stages of development. Understanding team development stage helps
project managers support team and its growth.
4.2.6.1 Tuckman Ladder
 Bruce Tuckman developed stages as forming, storming, norming and performing. New addition adjourning:

53
 o Forming – team first comes together, get to know each other’s position, skills, etc. Might be a formal
kickoff meeting where this happens;
o Storming – stage where personalities, strengths and weaknesses come out. Might be some conflict or
struggle when figuring out how to work together. Might be quick or go on for some time;
o Norming – team starts functioning collectively. Members know their places and how to relate
to/interface with other members. Starting to work together but might be some challenges as work
progresses. Issues resolved quickly and team moves into action;
o Performing – team becomes operationally efficient (mature team stage). Teams can develop a synergy
and accomplish more and produce high-quality product by working together;
o Adjourning – team completes the work and disperses to work on other things. If team has good
relations, some team members might feel sad leaving the team.
 While this shows a linear progression, teams can move back and forth between stages, and not all teams
achieve the performing or norming stages.
4.2.6.2 Drexler/Sibbet Team Performance Model
 Allan Drexler and David Sibbet developed performance model with 7 steps, where steps 1-4 describe stages
in creating project team and 5-7 cover team sustainability and performance:
o Step 1: Orientation – answers question of why. Team learns purpose and mission for project, usually
occurs after kickoff meeting or documented in business case, charger or lean start-up canvas;
o Step 2: Trust Building – answers question of who, sheds light on who is on the team and skills and
abilities each person brings. Includes information about influential key stakeholders;
o Step 3: Goal Clarification – answers what, team elaborates the high-level project information (i.e.,
finding out more stakeholder expectations, requirements, assumptions and deliverable criteria);
o Step 4: Commitment – addresses question of how, team starts to define plans to achieve goals (i.e.,
milestone schedules, release plans, high-level budgets, resource needs, etc.);
o Step 5: Implementation – high-level plans decomposed into greater detail (i.e., detailed schedule,
backlog), team works together to produce deliverables;
o Step 6: High Performance – after working together for some time, teams reach high level of
performance (i.e., work well together, don’t need oversight, experience synergies within team);
o Step 7: Renewal – stage of working through changes on team or project (i.e., deliverables,
stakeholders, environment, leadership or membership may change). Teams consider if past actions are
still sufficient or if need to reset expectations and ways of working together.
4.2.7 Other Models
4.2.7.1 Conflict Model
 Conflict can be healthy and productive when handled well. However, it can be unhealthy and addressing
inappropriately can lead to dissatisfaction, lack of trust, and reduced morale/motivation.
 Model from Ken Thomas and Ralph Kilmann describes 6 ways of addressing conflict by focusing on relative
power between individuals and desire to maintain good relationship:
o Confronting/Problem Solving – confronting conflict treats it as a problem to be solved. Used when
relationship between two parties is important and when there is confidence to problem-solve;
o Collaborating – incorporating multiple views about the conflict with objective to learn about various
views and see things from multiple perspectives. Works when there is trust among participants;
o Compromising – allows all parties to get something they want and avoids escalating conflict. Often
used when parties involved have equal “power”;
o Smoothing/Accommodating – useful when reaching overall goal is more important than disagreement.
Maintains harmony in relationship and creates good will between parties. Also used when there is a
difference in relative authority or power of individuals (e.g., sponsor outranking project manager);
o Forcing – used when there is not enough time to collaborate or problem-solve, so one party with more
power forces their will on the other (e.g., health and safety conflict);

54
 o Withdrawal/Avoiding – sometimes problems go away on their own or people need cooling-off period.
Withdrawing is appropriate in these situations and also no-win scenarios (e.g., complying with
regulatory agency requirement).
4.2.7.2 Negotiation
 Steven Covey’s principle of “Think Win-Win” applies to all interactions, not just negotiations. In
negotiations, there are different possible outcomes:
o Win-Win – optimal outcome, where each person is satisfied with the outcome;
o Win-Lose/Lose-Win – competition perspective where in order to win, someone else loses. From
martyr perspective, someone chooses to lose so others can win;
o Lose-Lose – occurs when win-win may have been possible, but competition overwhelms
collaboration and everyone ends up worse off.
 A win-win perspective is found when the following aspects are present:
o Character – parties involves are mature, have integrity and share perspective that there is enough
value for everyone;
o Trust – parties trust each other, establish agreements on how to operate, are accountable;
o Approach – each part willingly looks at the situation from other’s POV and work together to identify
key issues/concerns. They identify an acceptable solution and options to achieve this.
4.2.7.3 Planning
 Barry Boehm developed model comparing time and effort invested in developing plans to reduce risk,
including delay and other costs associated with overplanning.
 Intent is to help identify optimum amount of planning, “the sweet spot”, which is different for every project
so there is no correct answer for the right amount of planning overall.
 Demonstrates that there is appoint where additional planning becomes counterproductive.
4.2.7.4 Process Groups
 Project management processes can be organized into logical groupings of inputs, tools and techniques, and
outputs tailored to meet the needs of organization, stakeholders and the project.
 Groups of processes are not project phases. The Process Groups interact within each phase of a project life
cycle and it’s possible that all processes could occur within a single phase.
 Processes may be iterated within a phase or life cycle. The number of iterations and interactions between
processes varies based on needs of the project.
 Projects following a process-based approach may use the five process groupings as organizing structure:
o Initiating – processes performed to define a new project or new phase of existing project by obtaining
authorization to start the project/phase;
o Planning – to establish scope of the project, refine the objectives, and define the course of action
required to attain objectives that project was undertaken to achieve;
o Executing – to complete work defined in the project management plan to satisfy project requirements;
o Monitoring and Controlling – to track, review and regulate progress and performance of project,
identify areas where plan changes are required and initiate the changes;
o Closing – processes performed to formally complete or close project/phase or contract.
 Process Groups are independent of delivery approach, application areas or industry (e.g., marketing, IS,
accounting, construction, etc.). In process based approach, output of one process generally becomes input to
another or is a deliverable of the project or phase.
4.2.7.5 Salience Model
 Is about stakeholders. Salience means prominent, noticeable or perceived as important.
 Proposed by Ronald K. Mitchell, Bradley R. Agle and Donne J. Wood.
 Stakeholder identification is based on three variables:

55
 o (1) Power to influence; (2) Legitimacy of the stakeholders’ relationships
with the project; (3) Urgency of stakeholders’ claim on project for
stakeholder engagement.
4.3 Models Applied Across Performance Domains
 While the needs of the project, stakeholders and organizational environment will
determine which models are most applicable for a specific project, there are
some performance domains that are more likely to make use of each model.
 Project manager and team have the ultimate responsibility for selecting the right
models for their project.
4.4 Commonly Used Methods
 A method is a means for achieving an outcome, output, result or project
deliverable.
4.4.1 Data Gathering and Analysis
 Used to collect, assess and evaluate data and information to gain a deeper
understanding of a situation. Methods below, coupled with artifacts are used to inform decisions:
o Alternative Analysis – evaluate identified options in order to select the options or approaches to
perform the work of the project;
o Assumption and Constraint Analysis – assumption is factor considered true, real or certain without
proof. Constraint is limiting factor affecting project/program/process/portfolio execution. Analysis
ensures both are integrated into plans/documents with consistency;
o Benchmarking – comparison of processes/practices to those of comparable organizations to identify
best practices, ideas for improvement and basis for performance measurement;
o Business Justification Analysis Methods – outcomes of analysis are used in a business case to justify
undertaking the project:
 Payback Period – time needed to recover investment in months/years;
 Internal Rate of Return (IRR) – projected annual yield of project investment, incorporating
initial and ongoing costs into estimated percentage growth rate of a project;
 Return on Investment (ROI) – percent return on initial investment, by taking projected
average of all net benefits and dividing them by the initial cost;
 Net Present Value (NPV) – future value of expected benefits, expressed in value benefits have
at the time of investment. Considers current and future costs, benefits and inflation;
 Cost-Benefit Analysis – financial analysis tool used to determine benefits provided by a
project against its costs;
o Check Sheet – tally sheet used as checklist when gathering data, used to collect and segregate data
into categories, or create histograms and matrices;
o Cost of Quality – all costs incurred over life of product by investment in preventing nonconformance
to requirements, appraisal of product/service for conformance, and failure to meet requirements;
o Decision Tree Analysis – diagram and calculation method for evaluating implications of a chain of
multiple options in uncertainty. Can use information generated from expected monetary value
analysis to populate branches of the tree;
o Earned Value Analysis – utilizes set of measures associated with scope, schedule and cost to
determine cost and schedule performance of a project;
o Expected Monetary Value (EMV) – estimated value of outcomes expressed in monetary terms. Is used
to quantify value of uncertainty (risk), or compare the value of alternatives that are not equivalent.
Multiply probability that an event will occur and economic impact event would have if it occurred;
o Forecast – estimate/prediction of conditions and events in future, based on information and
knowledge available at time of forecast. Qualitative use opinions and judgements of SMEs.
Quantitative uses models where past information is used. Casual or econometric forecasting
(regression analysis) identifies variables that have significant impact on future outcomes;

56
 o Influence Diagram – graph of situations showing casual influences, time ordering of events and other
relationships among variables and outcomes;
o Life Cycle Assessment – tool used to evaluate total environmental impact of product/process/system.
Includes all aspects of producing deliverable, from origin of materials to distribution and disposal;
o Make-Or-Buy Analysis – process of gathering and organizing data about product requirement and
analyzing against alternatives;
o Probability and Impact Matrix – grid for mapping probability of occurrence of each risk and impact
on objectives if risk occurs;
o Process Analysis – systematic review of steps and procedures to perform activity;
o Regression Analysis – analytical technique where series of input variables are examined in relation to
corresponding output results to develop mathematical or statistical relationship;
o Reserve Analysis – evaluate amount of risk on project and amount of schedule and budget reserve to
determine whether reserve is sufficient for remaining risk. Reserve reduces risk to acceptable level;
o Root Cause Analysis – determine basic underlying cause of variance, defect, risk and may underlie
more than one of each;
o Sensitivity Analysis – determine which individual risks or other uncertainty heave potential impact on
outcomes by correlating variations in outcomes with elements of quantitative risk analysis model;
o Simulations – uses models to show combined effect of uncertainties to evaluate potential impact on
objectives. Monte Carlo simulation is method identifying impacts of risk and uncertainty using
multiple iterations of computer model to develop probability distribution of range of outcomes that
result from decision or course of action;
o Stakeholder Analysis – gather and analyze quantitative and qualitative information about stakeholders
to determine interests to be taken into account throughout project;
o SWOT Analysis – assess strength, weakness, opportunities and threats of organization/project/ option;
o Trend Analysis – uses mathematical models to forecast future outcomes based on historical results;
o Value Stream Mapping – lean method used to document, analyze and improve flow of information or
materials required to produce product or service for a customer;
o Variance Analysis – determines cause/degree of difference between baseline and actual performance;
o What-If Scenario Analysis – evaluates scenarios to predict effect on project objectives.
4.4.2 Estimating
 Estimating methods used to develop approximation of work, time or cost on project:
o Affinity Grouping – classify items into similar categories based on their likeness (e.g., size);
o Analogous Estimating – assesses duration or cost of activity or project using historical data from
similar activity/project;
o Function Point – estimate of amount of business functionality in information system. Are used to
calculate functional size measurement (FSM) of software system;
o Multipoint Estimating – assesses cost or duration by applying average or weighted average of
optimistic, pessimistic, and most likely estimates when uncertainty in estimates;
o Parametric Estimating – uses algorithm to calculate cost or duration based on historical data and
project parameters;
o Relative Estimating – used to create estimates derived from performing a comparison against similar
body of work, taking effort, complexity and uncertainty into consideration. Not based on absolute
units of cost or time. Story points are common unitless measures used;
o Single-Point Estimating – use data to calculate single value that reflects best guess estimate, opposite
of range estimate (includes best and worst case scenarios);
o Story Point Estimating – involves team members assigning abstract (relative) points of effort required
to implement user story, tells team about difficulty of story considering complexity, risks and effort;
o Wideband Delphi – variation of Delphi method where SMEs complete multiple rounds of producing
estimates individually and with a team discussion until consensus is achieved. For Wideband Delphi,

57
 those who created highest and lowest estimates explain their rationale, following with everyone re-
estimating and process repeats until convergence is achieved (e.g., planning poker).
4.4.3 Meetings and Events
 Meetings are primary means of communication throughout project:
o Backlog Refinement – backlog is progressively elaborated and (re)prioritized to identify the work that
can be accomplished in an upcoming iteration;
o Bidder Conference – meetings with prospective sellers prior to preparation of a bid or proposal to
ensure all prospective vendors have clear and common understanding of procurement. Also known as
contractor, vendor or pre-bid conferences;
o Change Control Board – includes group of people accountable for reviewing, evaluating, approving,
delaying or rejecting changes to the project. Decisions made are recorded and communicated to
stakeholders. Also referred to as Change Control Meeting;
o Daily Standup – brief collaboration where the team reviews it progress from the previous day,
declares intentions for current day and any obstacles encountered or anticipated. Also referred to as
Daily Scrum;
o Iteration Planning – clarify details of backlog items, acceptance criteria and work-effort require to
meet upcoming iteration commitment. Also referred to as Sprint Planning Meeting;
o Iteration Review – held at the end of an iteration to demonstrate work accomplished during the
iteration. Also referred to as Sprint Review;
o Kickoff – gathering of team members and stakeholders at outset of project to formally set
expectations, common understanding and commence work. Establishes the start.
o Lessons Learned Meeting – used to identify and share knowledge gained during a project, phase or
iteration, focusing on improving team performance. Address situations to handle better, good
practices and situations producing favourable outcomes;
o Planning Meeting – create, elaborate or review a plan or plans and secure commitment for plan(s);
o Project Closeout – obtain final acceptance of delivered scope from sponsor, product owner or client.
Meeting indicates that product delivery is complete;
o Project Review – event at the end of a phase or project to assess status, evaluate value delivered, and
determine if project is ready to move to next phase or transition to operations;
o Release Planning – identify high-level plan for releasing or transitioning a product, deliverable or
increment of value;
o Retrospective – regularly occurring workshop where people explore their work and results to improve
process and product. Are a form of lessons learned;
o Risk Review – analyze status of existing risks and identify new ones. Determine if risk is still active or
changes to risk attributes. Responses are evaluated for continued effectiveness. New risks identified
and non-active risks closed. Part of risk reassessment.
o Status Meeting – regularly scheduled event to exchange and analyze information about current project
progress and performance;
o Steering Committee – senior stakeholders provide direction and support to team and make decisions
outside of team’s authority.
4.4.4 Other Methods
 Common other methods used for a variety of purposes on projects:
o Impact Mapping – strategic planning method, serves as a visual roadmap for organization during
product development;
o Modeling – process of creating simplified representations of systems, solutions or deliverables (e.g.,
prototypes, diagrams, storyboards). Can help facilitate further analysis;
o Net Promoter Score (NPS) – measures willingness of customers to recommend organizations products
or services to others. Score used as proxy to gauge satisfaction and loyalty;

58
 o Prioritization Schema – methods used to prioritize portfolio, program or project components, and
requirements, risks, features or other product information;
o Timebox – short, fixed period of time where work is completed (i.e., 1 or 2 weeks, 1 month).
4.5 Methods Applied Across Performance Domains
 Different methods are more likely to be useful in each performance domain, where needs of delivery
approach, product and organizational environment will determine which methods are most applicable.

4.6 Commonly Used Artifacts

 An artifact is a template, document, output or project deliverable. Project managers are expected to tailor the
use of artifacts to meet the needs of their particular project.
4.6.1 Strategy Artifacts
 Documents created prior to or at the start of the project that address strategic, business or high-level
information about the project.
 Developed at the start of the project and don’t normally change, but reviewed throughout project:
o Business Case – value proposition for proposed project, may include financial and nonfinancial
benefits;
o Business Model Canvas – one-page visual summary describing value proposition, infrastructure,
customers and finances. Used in lean start-up situations;
o Project Brief – provides high level overview of goals, deliverables and processes for project;
o Project Charter – document issued by project initiator or sponsor, formally authorizing existence of
project and provides project manager with authority to apply organizational resources to project;
o Project Vision Statement – concise, high-level description of project that states purpose and inspires
team to contribute to the project;
o Roadmap – high level timeline of milestones, significant events, reviews and decision points.
4.6.2 Logs and Registers
 Are used to record continuously evolving aspects of the project and are updated throughout the project. Also
termed risk register or risk log:
o Assumption Log – records all assumptions and constraints throughout the project (i.e., factors
considered to be true, real or certain without proof; factor limiting options for project);
o Backlog – ordered list of work to be done. Items in a backlog are prioritized which is scheduled for
upcoming iterations (e.g., product, requirements, impediments backlogs, etc.);

59
 o Change Log – a comprehensive list of changes submitted during project and their current status (i.e.,
modification to formally controlled deliverable, PM plan component, or document);
o Issue Log – used to record and monitor information on active issues and are assigned to responsible
party for follow-up and resolution;
o Lessons Learned Register – records knowledge gained during project, phase or iteration so it can be
used to improve future performance for team and/or organization;
o Risk-Adjusted Backlog – includes work and actions to address threats and opportunities;
o Risk Register – repository where outputs of risk management processes are recorded (e.g., person
responsible for risk management, probability, impact, risk score, planned responses, etc.);
o Stakeholder Register – records information about project stakeholders, including an assessment and
classification of stakeholders.
4.6.3 Plans
 Plans are developed for individual aspects of a project and/or combined into overarching plan. Are generally
written documents but may also be visual/virtual whiteboards:
o Change Control Plan – component of PM plan that establishes change control board, documents that
have authority over, and describes how change control system will be implemented;
o Communications Management – component of project/program/portfolio management plan
describing how, when and by whom information about the project will be administered/disseminated;
o Cost Management – part of project/program plan describing how costs will be planned, structured and
controlled;
o Iteration Plan – detailed plan for current iteration;
o Procurement Management – component of program/program plan describing how team will acquire
goods and services from outside of the organization;
o Project Management Plan – document describing how the project will be executed, monitored and
controlled, and closed;
o Quality Management – part of project/program plan that describes how applicable policies,
procedures and guidelines will be implemented to achieve quality objectives;
o Release Plan – sets expectations for dates, features and outcomes expected to be delivered over
course of multiple iterations;
o Requirements Management – part of project/program plan describing how requirements will be
analyzed, documented and managed;
o Resource Management – part of PM plan that describes how project resources are acquired, allocated,
monitored and controlled;
o Risk Management – part of project/program/portfolio plan describing how risk management activities
will be structured and performed;
o Scope Management – part of project/program plan describing how scope will be defined, developed,
monitored, controlled and validated;
o Schedule Management – part of project/program plan establishing criteria and activities for
developing, monitoring and controlling the schedule;
o Stakeholder Engagement – part of PM plan identifying strategies and actions required to promote
productive involvement of stakeholders in project or program decision making and execution;
o Test Plan – document describes deliverables to be tested, tests to be conducted and processes to be
used in testing, forming the basis for formally testing components and deliverables.
4.6.4 Hierarchy Charts
 Begin with high-level information progressively decomposed into greater levels of detail. Are often
progressively elaborated into greater levels of detail as more project information is known:
o Organizational Breakdown Structure – hierarchical representation of project organization, illustrating
relationship between project activities and organizational units performing the activities;
o Product Breakdown Structure – reflects products components and deliverables;

60
 o Resource Breakdown Structure – resources by category and type;
o Risk Breakdown Structure – potential sources of risks;
o Work Breakdown Structure – decomposition of total scope of work to be carried out by the team to
accomplish project objectives and create required deliverables.
4.6.5 Baselines
 Are approved versions of work product or plan where actual performance is compared to baselines to identify
variances. Baselines include:
o Budget – approved estimate for project or any WBS component or any schedule activity;
o Milestone Schedule – schedule presenting milestones with planned dates;
o Performance Measurement Baseline – integrated scope, schedule and cost baselines used for
comparison to manage, measure and control project execution;
o Project Schedule – output of schedule model that presents linked activities with planned dates,
durations, milestones and resources;
o Scope Baseline – approved version of scope statement, WBS and associated WBS dictionary that can
be changed using formal change control procedures and is basis for comparison to actual results.
4.6.6 Visual Data and Information
 Are artifacts that organize and present data/information visually (e.g., charts, graphs, matrices, diagrams), as
visualizing data is easier to absorb.
 These artifacts are often produced after data has been collected and analyzed and aid in decision making and
prioritization:
o Affinity Diagram – shows large numbers of ideas classified into groups for review and analysis;
o Burndown/Burnup Chart – graphical representation of work remaining in a timebox or work
completed toward the release of a product/project deliverable;
o Cause-and-Effect Diagram – visualization that helps trace undesirable effect back to root cause;
o Cumulative Flow Diagram (CFD) – indicates features completed over time, in development and those
in backlog. May also include features at intermediate states, in QA or in testing;
o Cycle Time Chart – shows average cycle time of work items completed over time. May be shown as a
scatter diagram or bar chart;
o Dashboards – set of charts and graphs showing progress or performance against important measures
of the project;
o Flowchart – depicts inputs, process actions and outputs of one or more processes within a system;
o Gantt Chart – bar chart that provides schedule information where activities are listed on vertical axis,
dates are shown on horizontal axis, and activity durations show as horizonal bars, placed according to
start and finish dates;
o Histogram – bar chart showing graphical representation of numerical data;
o Information Radiator – is a visible, physical display that provides information to organization,
enabling timely knowledge sharing;
o Lead Time Chart – shows trend over time of average lead time of items completed in work. May be
shown as scatter diagram or bar chart;
o Prioritization Matrix – is a scatter diagram where effect is shown on horizontal axis and value on
vertical, divided into four quadrants to classify items by priority;
o Project Schedule Network Diagram – graphical representation showing logical relationships among
project schedule activities;
o Requirements Traceability Matrix – links product requirements from their origin to the deliverables
that satisfy them;
o Responsibility Assignment Matrix (RAM) – is a grid that shows project resources assigned to each
work package. A RACI is a common way of showing stakeholders responsible, accountable,
consulted or informed and are associated with project activities, decisions and deliverables;
o Scatter Diagram – graph showing relationship between two variables;

61
 o S-Curve – graph displaying cumulative costs over specific period of time;
o Stakeholder Engagement Assessment Matrix – compares current and desired stakeholder engagement
levels;
o Story Map – a visual model of all features and functionality desired for given product, created to give
project team holistic view of what they are building and why;
o Throughput Chart – shows accepted deliverables over time. May be scatter diagram or bar chart;
o Use Case – describes and explores how user interacts with a system to achieve a specific goal;
o Value Stream Map – lean enterprise method used to document, analyze and improve the flow of
information or materials required to produce a product or service. Can be used to identify waste;
o Velocity Chart – tracks the rate at which deliverables are produced, validated and accepted within a
predefined interval.
4.6.7 Reports
 Are formal records or summaries of information that communicate relevant summary level information to
stakeholders interested in project status (i.e., sponsors, business owners or PMOs):
o Quality Report – includes quality management issues, recommendations for corrective actions and
summary of findings from quality control activities. May include recommendations for process,
project and product improvements;
o Risk Report – developed progressively throughout risk management and summarizes information on
individual project risks and level of overall project risk;
o Status Report – report on current status of project, may include information on progress since last
report and forecasts for cost and schedule performance.
4.6.8 Agreements and Contracts
 An agreement is any document or communication defining intentions of the parties (e.g., contracts, etc.).
 Contracts are mutually binding agreements that obligates seller to provide specific product, service or result
and obligates buyer to pay for it. There are different types of contracts:
o Fixed-Price Contracts – set fixed price for well-defined product, service or result. Includes firm fixed
price (FFP), fixed-price inventive fee (FPIF), fixed price with economic price adjustment (FP-EPA);
o Cost-Reimbursable – payments to seller for actual costs incurred for completing the work plus a fee
representing seller profit. Often used when project scope is not well defined or is subject to frequent
change. Include cost plus (+) award fee (CPAF), cost + fixed fee (CPFF), cost + inventive fee (CPIF);
o Time and Materials (T&M) – established fixed rate, but not precise statement of work. Used for staff
augmentation, subject matter expertise or other outside support;
o Indefinite Delivery Indefinite Quality (IDIQ) – provides for indefinite quantity of goods/services, with
stated lower and upper limit, and within a fixed time period. Can be used for architectural,
engineering or information technology engagements;
o Other Agreements – others include memorandum of understanding (MOU), memorandum of
agreement (MOA), service level agreement (SLA), basic ordering agreement (BOA), etc.
4.6.9 Other Artifacts
 The remainder do not fit into a specific category:
o Activity List – provides tabulation of schedule activities that shows activity description, identifier and
detailed scope of work description so project team understands what work is to be performed;
o Bid Documents – used to request proposals from prospective sellers. Depending on goods/services
needed, can include:
 Request for information (RFI), Request for quote (RFQ), Request for proposal (RFP);
o Metrics – describe an attribute and how to measure it;
o Project Calendar – identifies working days and shifts available for scheduled activities;
o Requirements Documentation – is a record of product requirements and relevant information needed
to manage requirements, including associated category, priority and acceptance criteria;

62
 o Project Team Charter – records project team values, agreements and operating guidelines, and
establishes clear expectations regarding acceptable behaviour by team members;
o User Story – is a brief description of an outcome for a specific user, which is a promise of a
conversation to clarify details.
4.7 Artifacts Applied Across Performance Domains
 Different artifacts are likely to be useful in different performance domains.
 Delivery approach, product and organizational environment determine most applicable artifacts for a project.

APPENDIX
Appendix X1 – Contributors and Reviewers of The Standard for
Project Management and A Guide to The Project Management Body of Knowledge

Appendix X2 – Sponsor
X2.1 Introduction
 An active project sponsor is a critical success factor in achieving positive outcomes from projects.
X2.2 The Sponsor Role
 The sponsor provides decision leadership that is outside of the authority and position power of project
manager and team.
 Active engagement and oversight by sponsor supports the project manager, team and drives project outcomes.
 The sponsor links the team with the strategy and big-picture view at executive level of the organization.
 Sponsors perform the following functions:
o (1) Communicate vision goals, expectations to the team; (2) Advocate for project and team; (3)
Facilitate executive-level decisions; (4) Help secure resources; (5) Keep projects aligned to business
objectives; (6) Remove obstacles; (7) Address issues outside team’s authority; (8) Bring opportunities
that arise within project to senior management; (9) Monitor outcomes after closure to ensure intended
business benefits are realized.
 Sponsor’s position and perspective in organization enable them to provide support in following areas:
o Vision – establish and/or communicate vision and project direction;
o Business Value – work with team to maintain alignment with strategic and business objectives. May
require frequent interactions to adjust project to meet evolving direction in volatile markets;
o Customer Focus – balance various stakeholder needs and priorities;
o Decisions – make or direct decisions to appropriate group when outside team’s authority. Sponsors
can mediate conflict and facilitate decision-making process;
o Motivation – source of motivation for team by actively engaging and supporting them;

63
 o Accountability – often accountable for project outcomes, may accept or reject deliverables for project;
X2.3 Lack of Engagement
 When sponsor is not engaged or missing, there may be negative impacts on project effectiveness:
o Performance suffers due to longer decision time frames and conflicting priorities;
o If resources not secured, the gap impacts access to necessary personnel or physical resources;
o If no support, members may be removed or switched out causing negative impacts to scope, quality,
schedule, budget and diminish ability to achieve intended outcomes and stakeholder satisfaction.
X2.4 Sponsor Behaviours
 Certain sponsor behaviours that help teams perform effectively and improve project outcomes:
o Resource – liaise with organization ensuring team has skill sets and resources to deliver on project;
o Guide – provide motivating vision that team can rally;
o Align – align with organization’s strategic goals and project outcomes, pivoting the team when
necessary to meet market or organization changes/shifts;
o Tailor – work with team to tailor structure, culture, processes, roles, work to optimize outcomes;
o Influence – enable needed changes for adoption to post-project operations, including leadership,
engagement and collaboration with stakeholders throughout organization;
o Communicate – ongoing exchange of information from organization to team and vice versa;
o Partner – with team in achieving success, includes coaching, mentoring and demonstrating personal
commitment to project goal;
o Check – engage team to stimulate critical thinking by asking questions, challenging assumptions and
foster innovation;
o Unblock – remove barriers, resolve issues outside team’s authority or ability to address.
X2.5 Conclusion
X2.6 Suggested Resources

Appendix X3 – The Project Management Office

X3.1 Introduction
 PMO refers to portfolio, program or project management office. The PMO represents a management structure
that standardizes project-related governance processes and facilitates sharing of resources, tools,
methodologies and techniques.
 Character and function of a PMO varies between and within organizations.
X3.2 The PMO Value Proposition – Why Have One?
 Core benefit to PMO is improved project management in terms of schedule, cost, quality, risk, etc.
 PMOs have many roles in aligning work with strategic goals, engaging and collaborating with stakeholders,
developing talent and realizing value from investments in projects.
 Benefits PMOs offer are:
o Provide guidance supporting consistency in how projects are delivered. May provide guidelines,
templates and examples of good practices with training and coaching. Standardization promotes
common business picture across projects and facilitate decisions. Often exists in organizations
starting to improve PM capabilities;
o Support for planning activities, risk management, performance tracking, etc. Shared services model
exists in independent or diverse business units (BU) that want support with delivery while
maintaining direct control over projects;
o Part of department/BU overseeing portfolio of projects with oversight including business case to
initiate project, resource allocation, approving requests for scope/activity changes. Provides
centralized management and exists where departments have multiple projects and deliver strategically
important results;

64
 o Enterprise-level PMO linking organizational strategy with portfolio-level investments in
programs/projects that deliver specific results, changes or products. Exists where there are well
established PM capabilities directly linked to achieving organizational strategy/business objectives;
o Organizations with flatter structured, customer centered initiatives, and more adaptive delivery
approaches may adopt Agile Center of Excellence (ACoE) or Value Delivery Office (VDO). These
serve as enabling roles (rather than management/oversight), focusing on coaching teams, building
agile skills and capabilities throughout organization, and mentoring sponsors/product owners to be
more effective. Emerging within organizations adopting more decentralized structures.
 PMOs may be layered (e.g., EPMO with subordinate PMOs and VDOs residing in specific departments) to
support strategic alignment at executive level and specific capabilities within department level.
 Any PMO or VDO is based on organizational needs, with influences being types of projects being delivered,
size of organization, its structure(s), degree of centralized/decentralized decision making, corporate culture.
X3.3 Key PMO Capabilities
 Effective PMOs make three key contributions that support value delivery:
o Fostering Delivery and Outcomes-Oriented Capabilities – ensure employees, contractors, partners,
etc. within and outside PMO understand, develop, apply and value range of PM skills/competencies.
Focus on right-sizing processes/governance to unique project to produce high-quality results;
o Keeping The “Big Picture” Perspective – staying true to goals of project is key element of success.
Strong PMOs evaluate performance focusing on continuous improvement, evaluating work in context
of overall success rather than maximizing specific project’s results. Provide guidance to teams, senior
management/business leaders for aiding in decision making;
o Continuous Improvement, Knowledge Transfer and Change Management – regularly share results
across organization. Learning and sharing activities inform strategic and business objectives while
improving activities that strengthen future projects. Effective change management builds/sustains
alignment with process updates, capability enhancements and new skills that support PM.
X3.4 Evolving for Stronger Benefits Realization
 Greater uncertainty, accelerated pace of change, increased competition and more empowered customers exert
pressure on PMOs to demonstrate contributions to benefits realization/value creation. PMOs meet this by:
o Focusing On Critical Initiatives – shift from watchdogs to organizing conversations between senior
leaders, BU heads, product owners, and project teams. These provide insights into performance,
threats and opportunities that affect strategic initiatives;
o Instituting Smart and Simple Processes – establish just enough process/practice discipline to enable
effective communication, collaboration, and continuous improvement without adding wasteful steps
or overriding processes adding value;
o Fostering Talent and Capabilities – PMOs developing and nurturing technical, strategic, management
and leadership skills within teams and across organization;
o Encouraging and Enabling Culture of Change – change leaders by actively building support for and
commitment to outcomes and benefits-focused performance and organization change management.
X3.5 Learn More about PMOs
X3.6 Suggested Resources

Appendix X4 – Product
X4.1 Introduction
 Defining success as meeting scope, schedule and budget objectives have transitioned to measuring value and
outcomes (not outputs) of the project.
Product management is aligned with this
value view and adds longer time frame
perspective.

65
 Product: an artifact that is produced, is quantifiable and can be an end item or component item;
 Product Management: integration of people, data, processes, and business systems to create, maintain and
evolve a product/service throughout its lifecycle.
 Product Life Cycle: a series of phases that represents the evolution of a product, from concept through
delivery, growth, maturity and retirement.
 Products extend beyond a project life cycle and operate like long-running programs focusing on maximizing
benefits realization (e.g., Apple iPhone, buildings and homes).
 Continuous development has impacts on funding, staffing models, development
and sustainment.
X4.2 Global Market Shifts
 Three global trends are disrupting traditional business models and transforming
products/services:
o Customer Centricity – inverts traditional model of developing products
and pushing them out. Instead, organizations are better understanding,
serving and maintaining customer loyalty through collecting
customer data/requirements to use for product enhancements,
cross-selling, new ideas, etc.;
o Software-Enhanced Value – software and it’s capabilities have
become key differentiators in range of products/services today.
Most organizations conduct some portion of their business
electronically through websites and applications. Ongoing
upgrades and maintenance of systems means these are only
finished development when product/service is retired;
o Ongoing Provision and Payment – single-transaction services are
being replaced with continuous provision and payment:
 Publishing – self-publishing, direct distribution, e-books allow ongoing
refinement/development after publication;
 Finance – shift from local branches to microlending with funding in smaller batches based on
evaluation of value delivered;
 Start-Ups – work is more distributed, fragmented and fluid than with traditional models;
 Media – rise in subscription services with ongoing funding and delivery of benefits.
X4.3 Impact on Project Delivery Practices
 Organizations are looking to move from delivering single product to delivery constructs that have strong
customer focus, recognize rapid technology evolution and align with services for loyal customers.
 Has increased interest in and shift toward product management life cycles for value delivery.
 Product management takes longer life cycle view that encompasses support, sustainment and ongoing
evolution with the same team.
 Stable teams are especially valuable in complex and unique domains.
X4.4 Organizational Considerations for Product Management
 Organizations shifting to long-running, product-based environments
utilize three strategies:
o Establish Stable Teams – use team to sustain and evolve
product with designated product owner, removing need of
knowledge transfer. Long-standing teams develop better
market awareness, customer insights and empathy. Quality,
maintainability often improve with long-serving teams.
Teams that develop initial products include change
management to ensure customers have capabilities to
maintain product once it is transitioned;

66
 o Use Incremental Guidance and Funding – instead of predefined durations/budgets, more frequent
reviews (quarterly) and funding allows business to be in closer control of overall progress, direction
and decision making. Similar to venture capital, regular reviews of delivered value direct funding
towards products with value and reduce investment in underperforming initiatives.
o Utilize Program Management Structures – with stable teams that support customer-centric products,
program management used to manage
long-running initiatives where programs
align with adjusting to market changes
and focusing on customer benefits, are
also longer running than single project.
 Acceptance of up-front
uncertainty, need for adaptation,
focus on benefits and longer time
frames make programs a better fit
than projects for organizations
managing product delivery (e.g.,
infrastructure, aerospace and
automotive industries use
program management).
 When program structures already
exist, shifting to that for product
management does not require reorienting everyone to a new way of thinking/working.
X4.5 Summary
X4.6 Suggested Resources
Appendix X5 – Research and Development for The Standard for Project Management
Glossary
1. Inclusions and Exclusions
2. Common Acronyms
3. Definitions

67