Project Performance Domains

• Project management entails applying knowledge, skills, tools, and techniques for management activities as well as leadership activities.
• Management activities focus on the means of meeting project objectives, such as having effective processes, planning, coordinating, measuring, and monitoring work, among others.
• Leadership activities focus on people^① .
• Leadership includes influencing, motivating, listening, enabling, and other activities having to do with the project team.
• Both are important in delivering the intended outcomes.

• Centralized Management and Leadership
  • While leadership activities should be practiced by all project team members, management activities may be centralized or distributed.
  • In an environment where management activities are centralized, accountability (being answerable for an outcome)^①, is usually assigned to one individual, such as the project manager or similar role.
  • In these situations, a project charter^② (see example in notes below) or other authorizing document can provide approval for the project manager to form a project team to achieve the project outcomes.

• Distributed Management and Leadership
  • Sometimes project management activities are shared among a project management team, and project team members are responsible for completing the work.
  • There are also situations where a project team may self-organize to complete a project.
  • Rather than having a designated project manager, someone within the project team may serve as facilitator^① to enable communication, collaboration, and engagement.
  • This role may shift among project team members^②.

• Common Aspects of Team Development
  • Regardless of how the management activities are structured, there are common aspects of project team development that are relevant for most project teams.
  • These include:
    • Vision and objectives.
    • Roles and responsibilities.
    • Project team operations.
    • Guidance.
      • Guidance can be directed to the overall project team to keep everyone headed in the right direction.
      • Individual project team members may also provide guidance on a particular task or deliverable.
    • Growth.^①
      • Identifying areas where the project team is performing well and pointing out areas where the project team can improve helps the project team to grow.
      • Working collaboratively, the project team can identify goals for its improvement and take steps to meet those goals.

• Each project team develops its own team culture.
• The project team’s culture may be established deliberately by developing project team norms, or informally through the behaviors^① and actions of its project team members.
• The project team culture operates within the organization’s culture but reflects the project team’s individual ways of working and interacting.

• The project manager is key in establishing and maintaining a safe, respectful, nonjudgmental environment that allows the project team to communicate openly.
• One way to accomplish this is by modeling desired behaviors^①, such as:
  • Transparency
  • Integrity
  • Respect
  • Positive discourse
  • Support
  • Courage
  • Celebrating success

• The list below identifies some of the factors associated with high-performing project teams.
  • Open communication
  • Shared understanding
  • Shared ownership
  • Trust
  • Collaboration
  • Adaptability
  • Resilience
  • Empowerment
  • Recognition^①

• leadership styles (ex: autocratic, democratic, laisser-faire, transactional, servant, etc.) are tailored to meet the needs of the project, the environment, and the stakeholders.
• Some of the variables that influence tailoring of leadership styles include:
  • Experience with the type of project
  • Maturity of the project team members
  • Organizational governance structures
  • Distributed project teams^①

• The following definitions are relevant to the Development Approach and Life Cycle Performance Domain:
  • Deliverable
    • Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project.
  • Development Approach.
    • A method used to create and evolve the product, service, or result during the project life cycle, such as a predictive, iterative, incremental, adaptive, or hybrid method.
  • Cadence.
    • A rhythm of activities^① conducted throughout the project.
  • Project Phase.
    • A collection of logically related project activities that culminates in the completion of one or more deliverables.
  • Project Life Cycle.
    • The series of phases that a project passes through from its start to its completion.^②

• The type of project deliverable(s) determines how it can be developed.
• The type of deliverable(s) and the development approach influence the number and cadence for project deliveries.
• The deliverable approach and the desired delivery cadence determine the project life cycle and its phases.^①
• Delivery cadence refers to the timing and frequency^② of project deliverables.
• Projects can have a single delivery, multiple deliveries, or periodic deliveries.

• For digital products, another delivery option is called continuous delivery.
• Continuous delivery is the practice of delivering feature increments immediately to customers, often through the use of small batches of work and automation technology.
• From the product management perspective, the emphasis is on delivering benefits and value throughout the product life cycle.
• This allows the team to respond to market trends and stay focused on value delivery.
• This practice is included in several approaches such as DevOps^①, #noprojects and Continuous Digital, for example.

• Predictive approach
  • A predictive approach is useful when the project and product requirements can be defined, collected, and analyzed at the start of the project. (Waterfall approach)^①
  • May also be used when there is a significant investment involved and a high level of risk that may require frequent reviews, change control mechanisms, and replanning between development phases.
  • The scope, schedule, cost, resource needs, and risks can be well defined in the early phases of the project life cycle, and they are relatively stable.
  • This development approach allows the project team to reduce the level of uncertainty early in the project and do much of the planning upfront.^②

• Hybrid approach
  • A hybrid development approach is a combination of adaptive and predictive approaches.
  • This means that some elements from a predictive approach are used and some from an adaptive approach are used.
  • This development approach is useful when there is uncertainty or risk around the requirements.
  • Hybrid is also useful when deliverables can be modularized^①, or when there are deliverables that can be developed by different project teams.

• Adaptive approach
  • Adaptive approaches are useful when requirements are subject to a high level of uncertainty and volatility and are likely to change throughout the project.^①
  • A clear vision is established at the start of the project, and the initial known requirements are refined, detailed, changed, or replaced in accordance with user feedback, the environment, or unexpected events.
  • Adaptive approaches use iterative and incremental approaches. However, on the far side of the adaptive methods, the iterations tend to get shorter and the product is more likely to evolve based on stakeholder feedback.^②

• Adaptive approach
  • While agility is a wide mindset that is broader than a development framework, agile approaches can be considered adaptive. Some agile approaches entail iterations that are 1 to 2 weeks in duration with a demonstration of the accomplishments at the end of each iteration.^①
  • The project team is very engaged with the planning for each iteration.
  • The project team will determine the scope they can achieve based on a prioritized backlog^②, estimate the work involved, and work collaboratively throughout the iteration to develop the scope.

• There are many variables associated with the nature of the product or service that influence the development approach.
  • Degree of innovation
  • Requirements certainty
  • Scope stability
  • Ease of change
  • Delivery options
  • Risk
  • Safety requirements
  • Regulations^①

• Project variables that influence the development approach are centered around stakeholders, schedule constraints, and funding availability.
  • Stakeholders
    • Projects that use adaptive methods require significant stakeholder involvement throughout the process.
    • Certain stakeholders, such as the product owner, play a substantial role in establishing and prioritizing work.^①
  • Schedule constraints
    • If there is a need to deliver something early, even if it is not a finished product, an iterative or adaptive approach is beneficial.
  • Funding availability
    • Projects that work in an environment of funding uncertainty can benefit from an adaptive or iterative approach.
    • A minimum viable product^② can be released with less investment than an elaborate product.
    • This allows for market testing or market capture with minimum investment.

• The Organization
  • Organizational variables such as the structure, culture, capability, project team size, and location influence the development approach.
    • Organizational structure
    • Culture
    • Organizational capability
    • Project team size and location^①

• The following definitions are relevant to the Planning Performance Domain:
  • Estimate
    • A quantitative assessment of the likely amount or outcome of a variable, such as project costs, resources, effort, or durations.
  • Accuracy
    • Within the quality management system, accuracy is an assessment of correctness^①: Reflects how well your plan predicts reality (If you estimate a project will cost $100K and it ends up costing $102K, your estimate was accurate)
  • Precision
    • Within the quality management system, precision is an assessment of exactness^②: Reflects the level of detail and consistency in your planning assumptions (if your estimates are based on a precise breakdown of the costs): An estimate can be precise because all the details are taken into account but not accurate if the project ends up costing much more or much less.

• The purpose of planning is to proactively ( ) develop an approach to create the project deliverables.^①
• High-level planning may begin prior to project authorization.
• The project team progressively elaborates^② initial project documents, such as a vision statement, project charter, business case, or similar documents to identify or define a coordinated path to achieve the desired outcomes.
• It is becoming more common for initial planning to consider social and environmental impacts in addition to the financial. Such as a product life cycle assessment which evaluates the potential environmental impacts of a product, process, or system (impacts of materials and processes with regards to sustainability, toxicity, and the environment).^③

• Planning begins with understanding the business case, stakeholder requirements, and the project and product scope.
• Product scope^① defines the features and functions that characterize a product, service, or result.
• Project scope^② also defines the work performed to deliver a product, service, or result with the specified features and functions.

• In predictive planning approaches
  • start with the high-level project deliverables upfront and decompose them into more detail.
  • Employ a scope statement and/or a work breakdown structure (WBS)^① to decompose the scope into lower levels of detail.
• In Iterative and Incremental planning
  • can have high-level themes or epics that are decomposed into features, which are then further decomposed into user stories and other backlog items.^②
  • Work that is unique, significant, risky, or novel can be prioritized to reduce the uncertainty associated with project scope at the start of the project before significant investment has taken place.
  • Project teams plan routine work based on the concept of last responsible moment^③.
  • This approach defers a decision to allow the project team to consider multiple options until the cost of further delay would exceed the benefit.

• Planning entails developing estimates for work effort, duration, costs, people, and physical resources.
• Estimates are a quantitative assessment of the likely amount or outcome of a variable, such as project costs, resources, effort, or duration.
• As the project evolves, the estimates can change based on current information and circumstances.^①

• A schedule is a model for executing the project’s activities, including durations, dependencies, and other planning information.
• Schedule planning can use predictive or adaptive approaches.
• Predictive approaches follow a stepwise process as follows:
  • Step 1. Decompose the project scope into specific activities.
  • Step 2. Sequence related activities.
  • Step 3. Estimate the effort, duration, people, and physical resources required to complete the activities.
  • Step 4. Allocate people and resources to the activities based on availability.
  • Step 5. Adjust the sequence, estimates, and resources until an agreed-upon schedule is achieved.^①

• The four types of dependencies are:
  • Mandatory dependency^①
    • A relationship that is contractually required or inherent in the nature of the work. This type of dependency usually cannot be modified.
  • Discretionary dependency^②
    • A relationship that is based on best practices or project preferences. This type of dependency may be modifiable.
  • External dependency
    • A relationship between project activities and non-project activities. This type of dependency usually cannot be modified.
  • Internal dependency
    • A relationship between one or more project activities. This type of dependency may be modifiable.

• Adaptive schedule planning uses incremental planning.
• One such scheduling approach is based on iterations and releases.
• A high-level release plan is developed that indicates the basic features and functionality to be included in each release.
• Within each release, there will be two or more iterations^①.
• Each iteration adds business and/or stakeholder value.
• Value may include features, risk reduction, experimentation, or other ways of delivering or protecting value.
• The planning for the work in future releases is kept at a high level so the project team does not engage in planning that could change based on feedback from earlier releases.^②

• Adaptive approaches often use timeboxes^①.
• The work in each timebox is based on a prioritized backlog.
• The project team determines the amount of work they can do in each timebox, estimates the work, and self-manages to accomplish the work.
• At the end of the timebox, the project team demonstrates the work completed.
• At that point, the backlog and estimates of work available to be done may be updated or reprioritized for the next timebox.^②

• The project budget evolves from the agreed estimates for the project.
• Cost estimates are then aggregated to develop the cost baseline^①.
• The cost baseline (time-phased budget) is often allocated across the project schedule to reflect when the costs will be incurred.
• This practice allows project managers to balance the funds approved in a specific budget period with the scheduled work.
• If there are funding limitations for a budget period, the work may need to be rescheduled to meet those limitations.

• The project budget should include contingency reserve funds to allow for uncertainty.
• Contingency reserves are set aside to implement a risk response or to respond to risk events should they occur (for identified risks, controlled by PM^①).
• Management reserves are set aside for unexpected activities related to in-scope work (for unknown risks, usually controlled by upper management^②).
• Depending on the organization’s policies and organizational structure, management reserves may be managed by the project, the sponsor, product owner, or the PMO at the program and portfolio level.

• Physical resources apply to any resource that is not a person.
• It can include materials, equipment, software, testing environments, licenses, and so forth.
• Planning for physical resources entails estimating, as well as supply chain, logistics, and management.
• Projects with significant physical resources, such as engineering and construction projects, will need to plan for procurement activities to acquire the resources.
• Planning for physical resources includes taking into account lead time for delivery, movement, storage, and disposition of materials, as well as a means to track material inventory from arrival on site to delivery of an integrated product.^①

• Procurement can happen at any time during a project. However, upfront planning helps to set expectations that ensure the procurement process is performed smoothly.
• Once the high-level scope is known, project teams conduct a make-or-buy analysis^①.
• This includes identifying those deliverables and services that will be developed in-house, and those that will be purchased from external sources.
• This information impacts the project team and the schedule.

• There is a natural linkage between planning, delivering, and measuring work.
• That linkage is metrics.
• Establishing metrics includes setting the thresholds that indicate whether work performance is as expected, trending positively or negatively away from expected performance, or unacceptable.
• Deciding what to measure and “how often” is best informed by the phrase “only measure what matters.”^①

• The following definitions are relevant to the Project Work Performance Domain:
  • Bid Documents
    • All documents used to solicit information, quotations, or proposals from prospective sellers.
  • Bidder Conference
    • The meetings with prospective sellers prior to the preparation of a bid or proposal to ensure all prospective vendors have a clear and common understanding of the procurement. Also known as contractor conferences, vendor conferences, or pre-bid conferences.
  • Explicit Knowledge^①
    • Knowledge that can be codified using symbols such as words, numbers, and pictures.
  • Tacit Knowledge^②
    • Personal knowledge that can be difficult to articulate and share such as beliefs, experience, and insights.

• Project work keeps the project team focused and project activities running smoothly.
• This includes but is not limited to:
  • Managing the flow of existing work, new work, and changes to work;
  • Keeping the project team focused;
  • Establishing efficient project systems and processes;
  • Communicating with stakeholders;
  • Managing material, equipment, supplies, and logistics;
  • Working with contracting professionals and vendors to plan and manage procurements and contracts;
  • Monitoring changes that can affect the project; and
  • Enabling project learning and knowledge transfer.^①

• The project manager and the project team establish and periodically review the processes the project team is using to conduct the work.
• This can take the form of reviewing task boards to determine if there are bottlenecks in the process, if work is flowing at the expected rate, and if there are any impediments that are blocking progress.^①

• Process tailoring can be used to optimize the process for the needs of the project.
• In general, large projects have more process compared to small projects, and critical projects have more process than less significant projects.
• Tailoring takes into consideration the demands of the environment.
• Ways of optimizing the processes for the environment include:
  • Lean production methods.
  • Retrospectives or lessons learned.
  • Where is the next best funding spent?^①

• Reviewing processes can entail determining if processes are efficient, or if there is waste in the process that can be eliminated.
• Time spent tracking conformance to process is time the project team cannot spend on delivering the outcomes for which the project was commissioned.
• Therefore, project teams utilize just enough time reviewing process conformance to maximize the benefits delivered from the review while still satisfying the governance needs of process.^①

• Successfully leading a project includes understanding the constraints associated with the work.
• Constraints can take the form of fixed delivery dates, compliance to regulatory codes, a predetermined budget, quality policies, and so forth. The constraints may shift and change throughout the project.^①
• A new stakeholder requirement may entail expanding the schedule and budget.
• A reduction in budget may entail relaxing a quality requirement or reducing scope.^②

• Balancing these shifting constraints, while maintaining stakeholder satisfaction, is an ongoing project activity.
• At times, it may include meeting with the customer, sponsor, or product owner to present alternatives and implications.^①
• Other times, the decisions and potential variances may be within the project team’s authority to make trade-offs^② to deliver the end result.

• Many projects involve some form of contracting or procurement.
• Procurement can cover everything from material, capital equipment, and supplies to solutions, labor, and services.
• In most organizations, project managers do not have contracting authority^①.
• Rather, they work with contracting officers or other people with expertise in contracts, laws, and regulations.

• Organizations usually have rigorous policies and procedures associated with procurements. The policies identify who has authority to enter into a contract, the limits of authority, and the processes and procedures that should be followed.
• Prior to conducting a procurement, the project manager and technically qualified project team members work with contracting professionals to develop the request for proposals (RFP), statement of work (SOW), terms and conditions, and other necessary documents to go out to bid.^①

• The bid process includes developing and publicizing bid documents, bidder conferences, and selecting a bidder.
• Bid documents can include:
  • Request for information^① (Example: A company wants to build a new software platform but isn’t sure what technologies or vendors are out there. They issue an RFI to learn about different capabilities and approaches.)
  • Request for proposal (Example: After reviewing RFIs, the company decides on a specific type of software and issues an RFP to invite vendors to bid on building it.)
  • Request for quote^② (Example: A company needs 500 laptops with specific specs. They issue an RFQ to multiple vendors asking for their best price and delivery timeline.)

• Knowledge Management
• Explicit and Tacit Knowledge

• The following definitions are relevant to the Delivery Performance Domain:
  • Definition of Done (DoD)
    • A checklist of all the criteria required to be met so that a deliverable can be considered ready for customer use.^①
  • Quality
    • The degree to which a set of inherent characteristics fulfills requirements.
  • Cost of Quality (COQ)
    • All costs incurred over the life of the product by investment in preventing nonconformance to requirements, appraisal of the product or service for conformance to requirements, and failure to meet requirements.^②

h

• Projects that use a development approach that supports releasingdeliverables throughout the project life cycle can start delivering value to the business, customer, or other stakeholders during the project.^①
• Business value often continues to be captured long after the initial project has ended.
• A business case^② document often provides the business justification and a projection of anticipated business value from a project.
• The format of this business case varies based on the development approach and life cycle selected.

• Delivery is more than just scope and requirements.
• Scope and requirements focus on what needs to be delivered.
• Quality focuses on the performance levels^① that are required to be met.
• Quality requirements may be reflected in the completion criteria, definition of done, statement of work, or requirements documentation.

• Much of the costs associated with quality are born by the sponsoring organization and are reflected in policies, procedures, and work processes.
• For example, organizational policies that govern how work is performed and procedures that prescribe work processes are often part of the organization’s quality policy.
• The cost of overhead, training, and process audit are born by the organization, though they are employed by the project.
• Inherent in projects is balancing the quality needs of the processes and products with the costs associated with meeting those needs.
• The cost of quality methodology^① is used to find the appropriate balance for investing in quality prevention and appraisal to avoid defect or product failures.

• All projects attempt to deliver outcomes, though some may fail to do so or may produce suboptimal outcomes.
• The potential for suboptimal outcomes exists in every project.
• In the case of a fully experimental project, the organization is attempting to achieve a breakthrough, such as the creation of a completely new technology, for example.
• This requires deliberate investment in an uncertain outcome.
• Companies that produce new medicines or compounds may experience several failures before finding a successful formula.
• Some projects may fail to deliver outcomes because the market opportunity has passed^① or competitors were first to market with their offering.
• Effective project management can minimize negative outcomes, but such possibilities are part of the uncertainty of attempting to produce a unique deliverable.^②

• The following definitions are relevant to the Measurement Performance Domain:
  • Metric
    • A description of a project or product attribute and how to measure it (ex: work progress %).^①
  • Baseline
    • The approved version of a measure used as a basis for comparison to actual results (cost of a project, duration).^②
  • Dashboard
    • A set of charts and graphs showing progress or performance against important measures of the project.

• Measures are used for multiple reasons, including:
  • Evaluating performance compared to plan;
  • Tracking the utilization of resources, work completed, budget expended, etc.;
  • Demonstrating accountability;
  • Providing information to stakeholders;
  • Assessing whether project deliverables are on track to deliver planned benefits;
  • Focusing conversations about trade-offs, threats, opportunities, and options; and
  • Ensuring the project deliverables will meet customer acceptance criteria.^①

• The value of measurements is not in the collection and dissemination of the data, but rather in the conversations about how to use the data^① to take appropriate action.
• It helps to ensure the right things are measured and reported to stakeholders.
• Effective measures allow for tracking, evaluating, and reporting information that can communicate project status, help improve project performance, and reduce the likelihood of performance deterioration.

• Key Performance Indicators (KPIs)
  • Leading indicators^① ( proactive metrics)
    • predict changes or trends in the project
    • Ex:
      • Rate of scope change requests (frequent changes may hint at poor planning)
      • Team workload balance (overloaded teams may lead to burnout or missed deadlines)
  • Lagging indicators^② (reactive or Backward-looking)
    • measure project deliverables or events
    • They provide information after the fact
    • Ex:
      • Cost variance (budget overrun or underrun)
      • Number of deliverables completed
      • Customer satisfaction scores

• Effective Metrics
  • Measuring takes time and effort, which could otherwise be spent on other productive work; therefore, project teams should only measure what is relevant and should ensure that the metrics are useful.
  • Characteristics of effective metrics (or SMART criteria) include:
    • Specific
    • Meaningful
    • Achievable
    • Relevant
    • Timely^①

• What is measured, the parameters, and the measurement method depend on the project objectives, the intended outcomes, and the environment in which the project takes place.
• Common categories of metrics include:
  • Deliverable metrics,
  • Delivery,
  • Baseline performance,
  • Resources,
  • Business value,
  • Stakeholders, and
  • Forecasts.^①

• Deliverable metrics
  • Information on errors or defects, Measures of performance, Technical performance measures
• Delivery
  • Work in progress, Lead time^① (total elapsed time between the identification of a need and the delivery of the result), Cycle time, Process efficiency
• Baseline performance
  • Start and finish dates, Effort and duration, Schedule variance

• Resources
  • Planned resource utilization compared to actual resource utilization, Planned resource cost compared to actual resource cost
• Business value
  • Cost-benefit ratio, Return on investment (ROI), Net present value (NPV)^①
• Stakeholders
  • Net Promoter Score (NPS), Mood chart, Morale, Turnover
• Forecasts
  • Estimate to complete (ETC), Estimate at completion (EAC), Variance at completion (VAC)^②

• Dashboards
• Information Radiators
• Visual Controls^①

• The following definitions are relevant to the Uncertainty Performance Domain:
  • Uncertainty
    • A lack of understanding and awareness of issues, events, paths to follow, or solutions to pursue.
  • Ambiguity
    • A state of being unclear, having difficulty in identifying the cause of events, or having multiple options from which to choose.
  • Complexity
    • A characteristic of a program or project or its environment that is difficult to manage due to human behavior, system behavior, and ambiguity.
  • Volatility^①
    • The possibility for rapid and unpredictable change.
  • Risk
    • An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.^②

• Uncertainty in the broadest sense is a state of not knowing or unpredictability.
• There are many nuances to uncertainty, such as:
  • Risk associated with not knowing future events,
  • Ambiguity associated with not being aware of current or future conditions, and
  • Complexity associated with dynamic systems having unpredictable outcomes.^①

• Successfully navigating uncertainty begins with understanding the larger environment within which the project is operating.
• Aspects of the environment that contribute to project uncertainty include, but are not limited to:
  • Economic factors such as volatility in prices, availability of resources, ability to borrow funds, and inflation/deflation;
  • Technical considerations such as new or emerging technology, complexity associated with systems, and interfaces;
  • Legal or legislative constraints or requirements;
  • Physical environment as it pertains to safety, weather, and working conditions;
  • Ambiguity associated with current or future conditions;
  • Social and market influences shaped by opinion and media; and,
  • Political influences^①, either external or internal to the organization.

• There are two categories of ambiguity:
  • Conceptual ambiguity^①
    • The lack of effective understanding—occurs when people use similar terms or arguments in different ways.
    • For example, the statement, “The schedule was reported on track last week,” is not clear.
    • It isn’t clear whether the schedule was on track last week or whether it was reported on last week.
  • Situational ambiguity^②
    • Surfaces when more than one outcome is possible.
    • Having multiple options to solve a problem is a form of situational ambiguity.

• Complexity is a characteristic of a program, project, or its environment, which is difficult to manage due to human behavior, system behavior, or ambiguity.
• Complexity exists when there are many interconnected influences that behave and interact in diverse ways.^①

• In complex environments, it is not uncommon to see an aggregation of individual elements leading to unforeseen or unintended outcomes.
• The effect of complexity is that there is no way of making accurate predictions about the likelihood of any potential outcome or even of knowing what outcomes might emerge.
• There are numerous ways to work with complexity; some of them are systems-based, some entail reframing, and others are based on process.^①

• Examples of working with complexity that is systems based include:
  • Decoupling^①
    • Disconnecting parts of the system to both simplify the system and reduce the number of connected variables.
    • Determining how a piece of a system works on its own reduces the overall size of the problem.
  • Simulation^②
    • There may be similar though unrelated scenarios that can be used to simulate components of a system.
    • A project to build a new airport that includes an area with shopping and restaurants can learn about consumer buying habits by seeking out analogous information on shopping malls and entertainment establishments.

• Examples of working with complexity that entail reframing are:
  • Diversity^①
    • Complex systems require viewing the system from diverse perspectives.
    • This can include brainstorming with the project team to open up divergent ways of seeing the system.
    • It can also include Delphi-like processes to move from divergent to convergent thinking.
  • Balance^②
    • Balancing the type of data used rather than only using forecasting data or data that report on the past or lagging indicators provides a broader perspective.
    • This can include using elements whose variations are likely to counteract each other's potential negative effects.

• Examples of working with complexity that is process based include:
  • Iterate^①
    • Build iteratively or incrementally.
    • Add features one at a time. After each iteration, identify what worked, what did not work, customer reaction, and what the project team learned.
  • Engage
    • Build in opportunities to get stakeholder engagement.
    • This reduces the number of assumptions and builds learning and engagement into the process.
  • Fail safe^②
    • For elements of a system that are critical, build in redundancy or elements that can provide a graceful degradation of functionality in the event of a critical component failure.

• Volatility exists in an environment that is subject to rapid and unpredictable change.
• Volatility can occur when there are ongoing fluctuations in available skill sets or materials.
• Volatility usually impacts cost and schedule.^①

• Alternatives analysis^① and use of cost or schedule reserve address volatility.
  • Alternatives analysis
    • Finding and evaluating alternatives, such as looking at different ways to meet an objective, such as using a different mix of skills, resequencing work, or outsourcing work
  • Reserve
    • Cost reserve can be used to cover budget overruns due to price volatility.^②

• Risks are an aspect of uncertainty.
• A risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.
• Negative risks are called threats, and positive risks are called opportunities.^①
• All projects have risks since they are unique undertakings with varying degrees of uncertainty.

• Overall risk is often a function of complexity, ambiguity, and volatility. Responses to overall project risk are the same as for individual threats and opportunities, though responses are applied to the overall project rather than to a specific event.
• If the overall risk on the project is too high, the organization may choose to cancel the project.^①

• Reserve is an 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 reserve is a budget category used for unknown events such as unplanned, in-scope work.^②

• Establishing a frequent rhythm or cadence of review and feedback sessions from a broad selection of stakeholders is helpful for navigating project risk and being proactive with risk responses.
• Daily standup meetings^① can be used in any project and are a source for identifying potential threats and opportunities.
• Reports of blockers or impediments could become threats if they continue to delay progress.
• Likewise, reports of progress and breakthroughs might point toward opportunities to be further leveraged and shared.
• Frequent demonstrations of increments of the product or service, interim designs, or proof of concepts can surface threats and opportunities.^②