Assess and Implement Changes in PMBOK 8 — Complete Guide

Article updated in March 2026 for the PMBOK® Guide — Eighth Edition.

Assess and Implement Changes in PMBOK 8 — Complete Guide

Formerly known as: Perform Integrated Change Control (PMBOK 6)

The developer was talented, experienced, and genuinely trying to improve the product. When the client mentioned during a status call that it “would be nice” to have a quick-filter feature on the search results page, the developer built it over the weekend and deployed it to production by Monday morning. No change request. No impact analysis. No documentation. The feature was clean, functional, and completely undocumented in the project’s scope baseline. Six weeks later, the QA engineer found that the quick-filter interacted with a caching module in a way that produced intermittent data inconsistencies. The defect fix took four days. The re-testing of related modules took two additional days. The client escalation meeting took three hours. Total cost of an unapproved, undocumented, well-intentioned change: twelve days of team effort and a stakeholder trust incident. The original weekend build: fourteen hours.

In PMBOK 8, Assess and Implement Changes is Process 8 of the Governance Domain. It is the process that manages project changes — from the moment a change is proposed through impact assessment, decision, and implementation — ensuring that every change affecting the project baseline is evaluated, documented, decided upon by the appropriate authority, and implemented in a controlled and traceable manner. It is the governance instrument that separates organizations that manage change from organizations that are managed by change.

This complete guide covers everything a project manager or PMP candidate needs to understand, apply, and tailor this process:

• What it is — definition, position in PMBOK 8, and what changed from PMBOK 6
• Why use it — direct benefits and the cost of skipping it
• Full ITTO — every input, tool, technique, and output explained
• Step-by-step application guide — from change request receipt to implementation
• When to apply it — triggers and mandatory vs. recommended scenarios
• Two real-world examples — Project Phoenix (website launch) and Project ProjectAdm (SaaS PM platform)
• Templates and tools — with free downloads
• Five common errors — and how to avoid each one
• Tailoring — predictive, agile, and hybrid approaches
• Process interactions — what feeds into change management and what depends on it
• Quick-application checklist — 10 items you can use today

1. What Is the Assess and Implement Changes Process

Assess and Implement Changes is the process of managing project changes that may impact various aspects of the project and adjusting plans based on stakeholder recommendations throughout the project life cycle. According to PMBOK 8, change requests can affect project scope, product scope, project management plan components, and project documents. Such changes can be proposed by any stakeholder and may occur at any point in the project life cycle.

In PMBOK 8, this is Process 8 of the Governance Domain (Process 8 of 9). It operates throughout the entire project lifecycle — from the moment baselines are established until project closure. The process spans from change request receipt through impact analysis, decision, and implementation, and it is the governance mechanism that maintains the integrity of the project management plan in the face of the inevitable pressure to change it.

Types of changes managed by this process

PMBOK 8 identifies four types of change requests that flow through this process:

What changed from PMBOK 6 to PMBOK 8

2. Why Use the Assess and Implement Changes Process

Direct benefits

• Baseline integrity: The project management plan is the authoritative reference for all project decisions. Without a formal change control process, the baseline gradually diverges from reality as informal changes accumulate — each one individually minor, collectively catastrophic. A project with controlled baselines has a clear reference for every decision. A project with drifted baselines has no reliable reference at all.
• Impact visibility: Formal change assessment ensures that every proposed change’s full impact — on scope, schedule, cost, quality, resources, risk, and stakeholder expectations — is evaluated before a decision is made. A change that appears simple in isolation (adding a feature, shifting a deadline) may have cascading effects that are invisible without structured analysis.
• Accountability: The change log creates an auditable record of every change proposed, assessed, and decided upon. When a stakeholder later asks “why did the project cost more than originally budgeted?” or “why is the feature X different from what was agreed?”, the change log provides the answer.
• Stakeholder alignment: Formal change requests require the approval of the designated decision-maker (project manager, sponsor, or change control board) before implementation. This ensures that the people who are accountable for the project’s outcomes have explicitly agreed to every significant modification of the plan — preventing the scenario where a change was made by someone without the authority to approve it.
• Controlled implementation: Approved changes are incorporated into the project management plan and communicated to all affected team members. Implementation is coordinated, not ad hoc. The scenario in the opening story — a well-intentioned developer implementing an unapproved change that caused a defect six weeks later — is prevented by this process.

The cost of skipping or bypassing change control

• Scope creep becomes invisible: Scope creep — the gradual, undocumented expansion of project scope — is the direct consequence of informal change management. Without a change log, no one can answer the question “what changed from the original plan?” because no record was kept.
• Budget overruns without traceable cause: When unauthorized changes accumulate, budget overruns appear to come from nowhere. The actual cause — twelve small, undocumented scope additions over four months — is invisible because it was never recorded.
• Schedule compression without authorization: Unauthorized changes consume schedule buffer without formal acknowledgment, exposing the project to deadline failures that could have been avoided with explicit trade-off decisions.
• Technical debt and defect accumulation: Unauthorized changes typically bypass quality review processes, creating technical debt and defects that are discovered late and are expensive to fix.

3. Inputs, Tools & Techniques, and Outputs (ITTO)

Inputs explained

Project management plan — change management plan and configuration management plan: The change management plan defines the process for managing changes: who can propose a change, what information is required in a change request, how changes are assessed, who has authority to approve or reject changes, and how approved changes are communicated and implemented. The configuration management plan defines which project artifacts are subject to configuration control and what level of formality is required for changes to those artifacts. Together, these two plan components are the governance rules that the Assess and Implement Changes process enforces.

Project management plan — scope, schedule, and cost baselines: The three primary baselines against which change impacts are assessed. A proposed scope addition is evaluated against the scope baseline to determine its size. A proposed schedule extension is evaluated against the schedule baseline to determine its downstream impact on dependent milestones. A proposed cost addition is evaluated against the cost baseline to determine whether the project budget envelope can absorb it or whether a budget amendment is required.

Work performance reports: The outputs of Monitor and Control Project Performance — the evidence base for change requests that originate from performance monitoring. A corrective action change request is supported by work performance report data showing that the project is deviating from baseline. A preventive action change request is supported by trend analysis data showing that a risk is approaching a trigger threshold.

Change requests: Formal documented proposals to modify any element of the project management plan, its baselines, or its associated documents. In PMBOK 8, change requests may be formally documented even in verbal initial form — any change that is initiated verbally should be documented in writing before being entered into the change management system. A change request should include: a description of the proposed change; the reason for the change; the category (corrective action, preventive action, defect repair, or update); the requester; the date; and the estimated impacts on schedule, cost, scope, quality, resources, and risk.

Tools & Techniques explained

Expert judgment: Applied throughout the change assessment process to evaluate technical feasibility, estimate cost and schedule impacts, assess risk implications, and determine whether the proposed change is consistent with the project’s strategic objectives. Expert judgment may be provided by technical specialists (is this technically feasible within the current architecture?), domain experts (does this change comply with regulatory requirements?), or experienced project managers (what is the realistic schedule impact of this change given the team’s current velocity?).

Change control tools: The systems and platforms used to manage change requests through the assessment and decision cycle. In formal change management contexts, this may include dedicated change management modules within the project management information system. In less formal contexts, it may be a structured spreadsheet or a Jira/Azure DevOps change ticket workflow. The tool matters less than the discipline: every change request must be formally entered into the system, tracked through assessment, and updated with the decision and implementation status.

Integrated change control: The formal process used in predictive project approaches for evaluating change requests holistically — assessing the change’s impact across all project baselines and plan components before a decision is made, and ensuring that the decision and its implementation are reflected consistently across all affected documents. PMBOK 8 uses “integrated change control” as both a concept and a specific technique within this process.

Backlog management: The technique used in adaptive project approaches to manage changes continuously through prioritization and iterative delivery. In agile contexts, changes are not processed through a formal CCB review — they are added to the product backlog as new backlog items and prioritized relative to the existing backlog by the product owner. Higher-priority changes displace lower-priority items in the sprint plan; lower-priority changes are deferred (effectively rejected or put on hold) until their priority rises sufficiently to warrant inclusion in a sprint.

Decision-making — voting, autocratic decision-making, multicriteria decision analysis: Voting aggregates the judgments of multiple stakeholders (CCB members, technical specialists, business representatives) into a collective decision. Autocratic decision-making concentrates the change decision in a single designated authority (the project manager for changes within their authority; the sponsor for changes requiring budget amendment; the CCB for changes to baselines). Multicriteria decision analysis evaluates competing change options against multiple dimensions — cost, schedule, risk, strategic alignment — to support changes where multiple alternatives exist.

Outputs explained

Approved change requests: Change requests that have been assessed, decided upon, and formally authorized for implementation. Approved change requests are the primary input to the Manage Project Execution process, which incorporates the approved changes into the live work stream. The approval must be documented — a verbal approval from the sponsor in a status call is not an approved change request; a documented approval with a timestamp, the decision-maker’s identity, and the approved scope of the change is.

Project management plan updates: Every approved change that modifies a baseline or a plan component requires a corresponding update to the project management plan. A scope addition must be reflected in the scope baseline. A schedule extension must be reflected in the schedule baseline. A budget amendment must be reflected in the cost baseline. Failure to update the project management plan after approving a change creates a document that no longer accurately represents the project’s authorized scope, schedule, and budget — which undermines all subsequent monitoring and control activities.

Project document updates — change log: The change log records every change request processed through this process: its ID, description, requester, date submitted, category, impact assessment, decision (approved, rejected, or deferred), decision date, decision authority, and implementation status. The change log is the definitive audit trail of the project’s change history — the document that answers “what changed from the original plan, and why?”

4. How to Apply the Process Step by Step

Step 1 — Establish the change management process before baselines are set

Document the change management approach in the change management plan before execution begins: define the change request format, the assessment criteria, the decision-making authority at each level (PM, sponsor, CCB), the response timeframes, and the communication protocol for approved and rejected changes. In adaptive contexts, document the backlog prioritization process and the product owner’s authority to approve changes through backlog management. Without a documented process, change management defaults to informal negotiation — which is not governance.

Step 2 — Receive and document all change requests formally

Every change request — whether received in writing, verbally, via email, or in a meeting — must be entered into the change management system with a unique ID, requester name, date, and description. No exception. A change that is requested and not documented is indistinguishable from an unauthorized scope addition. The five minutes required to document a verbal change request is the minimum viable change governance investment.

Step 3 — Conduct impact analysis before assessment

Before scheduling a change for CCB review or product owner decision, conduct a structured impact analysis covering: scope (what will be added, removed, or modified?); schedule (how many days will the change add to the affected work packages and to the overall project timeline?); cost (what additional resources, materials, or services will the change require?); quality (will the change create new quality risks or require additional quality activities?); risk (what new risks does the change introduce?); resources (will the change require skills or availability not currently in the plan?). The impact analysis should be completed before the decision is presented to avoid decisions based on incomplete information.

Step 4 — Submit for decision to the appropriate authority

Present the change request and impact analysis to the designated decision-maker: the project manager for changes within their authority; the sponsor for changes requiring budget or schedule amendment beyond the PM’s authority; the CCB for changes to baselines. Present the decision with at least two alternatives where possible (accept the change with the full impact, accept a reduced version of the change, or reject the change) to ensure the decision-maker has genuine options rather than a take-it-or-leave-it proposal.

Step 5 — Document the decision and update the change log

Record the decision in the change log: approved, rejected, or deferred. Include the decision date, the decision authority, and the rationale. For approved changes, document the approved scope of the change, the authorized budget and schedule impact, and the implementation priority. For rejected changes, document the reason for rejection. For deferred changes, document the conditions under which the change will be reconsidered.

Step 6 — Update the project management plan and communicate

For every approved change, update all affected plan components (scope baseline, schedule baseline, cost baseline, and any relevant subsidiary plans), communicate the change to all affected team members, and submit the approved change request to Manage Project Execution for implementation. Document the date the change was communicated and who received the communication.

Step 7 — Monitor the results of implemented changes

After an approved change has been implemented, monitor whether it produced the intended results. PMBOK 8 explicitly notes that the results of changes should be monitored to ensure they yield the desired results. A corrective action that does not resolve the performance variance it was designed to address requires a follow-up change request, not passive acceptance of continued deviation.

5. When to Apply the Process

Mandatory scenarios

• Any time a change to a project baseline is proposed: Once baselines (scope, schedule, cost) are established, every proposed modification to them requires formal change control. No exceptions, regardless of how minor the change appears.
• Any time a corrective or preventive action is required: Actions to restore performance to plan or prevent future deviations are changes to the project management plan and must be processed through this process.
• Any time a defect repair is required: A decision to repair a defect in a project deliverable is a formal change that requires documentation, assessment, authorization, and tracking.

Recommended scenarios

• Any time a stakeholder informally requests a modification: Verbal requests, email suggestions, and “while we’re at it” comments in meetings are all potential change requests. Every such request should prompt the PM to ask: “Do you want me to log this as a formal change request?” This question establishes the norm that all scope discussions are formal governance conversations, not casual agreements.

Warning signs that change control is not functioning

• Stakeholders are making direct requests to team members without going through the PM
• Developers are implementing “improvements” that were not in the approved backlog or work plan
• The change log has fewer entries than the number of identified issues or scope-affecting conversations in the same period
• The project management plan baselines do not reflect the actual current scope, schedule, and cost
• No one can answer the question “what is the current authorized project scope?”

6. Practical Examples

Example 1 — Website Launch: Project Phoenix

Context: Alex Morgan, PMP, is managing Project Phoenix — a 90-day website redesign for TechCorp, led by CEO Sarah Chen. Budget: $72,250. 2-week sprints.

How Assess and Implement Changes was applied:

Project Phoenix received six change requests during its 90-day execution. Three were approved, two were rejected, and one was deferred.

The most significant was the chatbot feature request raised by Sarah Chen’s CEO at the Sprint 3 review. Alex immediately logged it as Change Request #003: “Add AI chatbot for lead qualification to the website scope.” The impact analysis, completed within 48 hours, documented: scope addition (new integration with a chatbot platform, not currently in the technology stack), schedule impact (+14 calendar days to Sprint 5 and 6), cost impact (+$8,250 for chatbot platform license, development, and testing), quality risk (new integration introduces a dependency not covered by existing test protocols), and resource requirement (one developer redirected from Sprint 5 planned features). Alex presented the impact analysis to Sarah Chen in the next steering committee call with two options: approve the full scope addition with the documented impact, or defer the chatbot to a Phase 2 post-launch project. Sarah Chen selected option one. The change request was formally approved, the charter was amended, the budget was authorized, and the chatbot was added to the Sprint 5 backlog. The entire process — from verbal request to formal approval — took five business days.

Change Request #004 — a request from the developer to refactor the homepage load sequence using a new lazy-loading library “while we’re already working in that module” — was assessed and rejected. The impact analysis showed a +4-day schedule impact with no corresponding business value increase for the client, as the current load time already met the sub-2-second target defined in the charter. The rejection was documented in the change log with the rationale: “Feature-level technical optimization with no measurable business impact; out of scope for Phase 1; deferred to Phase 2 backlog.”

Example 2 — SaaS PM Platform: Project ProjectAdm

Context: Eduardo Montes leads ProjectAdm development. Team: 8 developers + 2 designers + 1 QA. Duration: 18 months. Hybrid approach.

How Assess and Implement Changes was applied:

ProjectAdm’s hybrid approach required a dual change management structure. On the predictive track (compliance milestones, infrastructure decisions, architectural choices), formal change control applied: a documented CCB process with Eduardo and co-sponsor Henry Douglas as the two CCB members. On the agile track (product features), backlog management applied: the product owner (Eduardo) continuously prioritized the product backlog, with any new feature requests assessed against the backlog priority and added, deferred, or rejected based on comparative value and sprint capacity.

The most consequential change request on the predictive track was submitted at month 8: a request from the lead developer to replace the initially chosen third-party authentication library with an in-house implementation, citing security audit findings that identified a CVE (Common Vulnerability and Exposure) in the library’s current version. The impact analysis documented: security risk reduction (critical, estimated at eliminating a known CVE that would have blocked GDPR compliance certification), schedule impact (+11 days to the compliance milestone), cost impact (+$3,400 in developer time), and architecture benefit (reduced third-party dependency in a security-critical module). The CCB approved the change within 24 hours, citing the security and compliance benefit as clearly justifying the time and cost impact. The change was implemented in a two-sprint effort, and the GDPR compliance certification was obtained at month 10 as planned.

Over 18 months, 23 formal change requests were processed on the predictive track: 17 approved, 4 rejected, and 2 deferred. On the agile track, 84 backlog refinement decisions were documented (changes approved via backlog prioritization) and 31 feature requests were deferred to a future product version. The complete change log was presented to the compliance auditor as evidence of controlled project governance — a requirement for the GDPR certification.

7. Free and Recommended Templates

Recommended digital tools

• Jira / Azure DevOps: Change request tracking integrated with the project’s task management workflow; change tickets linked to affected work packages; approval workflow configured for the project’s authority levels.
• Confluence / SharePoint: Change management plan documentation, change log archiving, and approval records with version history and access control.
• ServiceNow / Jira Service Management: For enterprise-scale change management in organizations with formal CCB governance and compliance requirements.
• Google Sheets / Excel: For lightweight change logs in smaller projects — structured template with ID, description, impact, decision, and status columns, shared with the PM and sponsor.

8. Five Common Errors — and How to Avoid Each One

Error 1 — Informal scope additions that bypass the change management process

Why it happens: Client requests made directly to developers, “quick improvements” decided in team meetings, and verbal sponsor approvals that are never documented. The change management process exists theoretically but is bypassed in practice whenever the change feels small or urgent.

How to avoid it: Establish a cultural norm: any modification to the project scope, schedule, cost, or quality baseline requires a documented change request, regardless of size or source. Empower team members to respond to direct client change requests with: “That sounds like a great idea. Let me log it as a formal change request so we can assess the impact and get the appropriate approval before we start work on it.” This response is professional, client-friendly, and governance-compliant.

Error 2 — Impact analysis that covers scope but not schedule, cost, and risk

Why it happens: Scope impact is the most visible dimension of a change. Schedule, cost, quality, and risk impacts require more analysis effort and are often underestimated or omitted from the change request to avoid complicating the approval.

How to avoid it: Use a structured change request template that requires assessment of all impact dimensions before the request is submitted for decision. A change request that has no schedule or cost impact assessment is incomplete and should not be approved until those fields are populated. Make the template non-negotiable.

Error 3 — Approving changes without updating the project management plan baselines

Why it happens: The change is approved in a meeting, communicated to the team verbally, and implemented. The project management plan baselines are not updated. The next monitoring cycle produces a false variance — the approved change is not reflected in the baseline, so the monitoring system reports the approved additional cost as a budget overrun.

How to avoid it: Establish as a process rule: no change is considered implemented until the project management plan baselines have been updated to reflect the approved change. The PMIS should be configured to prevent task creation for approved changes until the relevant baseline has been updated. Include “baseline update” as a mandatory step in the change implementation protocol.

Error 4 — CCB decisions made without quorum or appropriate authority

Why it happens: The CCB meeting is scheduled for Friday; the sponsor is unavailable; the PM approves the change alone to avoid delay. The change is significant enough to require sponsor authority, but the approval is recorded as a PM decision.

How to avoid it: Define quorum requirements and decision authorities in the change management plan before execution begins. If the sponsor is unavailable, the options are: defer the decision to the next CCB meeting, request an asynchronous approval via documented email or approval system, or escalate to a defined backup authority. A change approved by the wrong authority is not properly approved — it is a governance failure waiting to surface at a contractual or compliance audit.

Error 5 — Not monitoring the results of implemented changes

Why it happens: Once a change is approved and implemented, the PM moves on to the next issue. Whether the corrective action resolved the performance variance it was designed to address is never verified.

How to avoid it: For every approved corrective or preventive action, define a specific success metric before implementation: “This corrective action (reallocating the developer to 100% capacity) should restore sprint velocity to ≥ 85% of planned within two sprints.” Monitor that metric at the next two reporting intervals. If the corrective action did not achieve the intended result, generate a follow-up change request with a different corrective approach. Implemented changes that do not resolve the underlying problem continue to consume resources while the actual problem persists.

9. Tailoring: Predictive, Agile, and Hybrid

PMBOK 8 provides explicit, distinct guidance for predictive and adaptive approaches to change management, recognizing that the degree of change request management applied depends on the scope of the project, its complexity, contract requirements, and the development approach used.

Predictive approach

• Formal change control from baseline establishment: Changes are not formally controlled until baselines are established. Once established, all changes to baselines require a formal change request with documented impact analysis and CCB review.
• Change Control Board (CCB): A formally established group responsible for reviewing, evaluating, approving, deferring, or rejecting changes — and for documenting and communicating these decisions. CCB membership is defined in the change management plan; quorum and voting rules are documented.
• Configuration management: The configuration management plan specifies which project artifacts are subject to configuration control. Changes to these artifacts require a formal change request, regardless of their apparent magnitude.
• Best suited for: Projects with contractually defined scope, regulated industries requiring audit trails, and long-duration projects where baseline integrity is essential to investment management.

Adaptive approach

• Backlog management as change control: In adaptive approaches, changes are managed through the product backlog. A proposed change is added to the backlog as a new item. The product owner assesses its value and priority relative to existing backlog items. High-priority changes displace lower-priority items in sprint planning. Low-priority changes are deferred — effectively treated as “put on hold” rather than “rejected.”
• No formal approval process: Any stakeholder can propose a change by adding a backlog item. The approval mechanism is priority — a change assigned high priority by the product owner is “approved” for implementation when its sprint arrives. A change that is never assigned sufficient priority is effectively rejected or deferred indefinitely.
• Continuous change assessment: In adaptive contexts, change assessment is continuous and iterative, embedded in backlog refinement sessions rather than concentrated in discrete CCB meetings.

Hybrid approach (ProjectAdm model)

• Formal CCB for predictive track: Changes to compliance milestones, infrastructure baselines, and architectural decisions are processed through formal change control, with documented CCB approval required for all baseline changes.
• Backlog management for agile track: Feature-level changes are managed through backlog prioritization. The product owner (Eduardo) has full authority to accept, defer, or reject feature changes without CCB review, within the bounds defined in the project management plan.
• Integration point: Changes on the agile track that affect the predictive track (e.g., a feature change that has security implications requiring compliance review) escalate from backlog management to formal change control. This escalation criterion is documented in the change management plan.

10. Interactions with Other Processes and Domains

11. Quick-Application Checklist

1. Is a change management plan documented that defines who can propose changes, how changes are assessed, who approves changes at each level, and how approved changes are communicated?
2. Is the change management process active from the moment project baselines are established?
3. Is every proposed change — regardless of source or perceived size — formally documented in the change log with a unique ID?
4. Does every change request include an impact analysis covering scope, schedule, cost, quality, and risk?
5. Are change decisions (approved, rejected, or deferred) made by the appropriate authority as defined in the change management plan?
6. Are approved change decisions formally documented with the decision date, decision authority, and rationale?
7. Are project management plan baselines updated to reflect every approved change before implementation begins?
8. Is the change log actively maintained and available as an audit trail for all project governance reviews?
9. Are the results of implemented corrective and preventive actions monitored to verify that they achieved their intended effect?
10. In adaptive contexts, is the backlog prioritization process serving as a disciplined, documented change management mechanism with a product owner who has clear and exercised prioritization authority?

Conclusion and Next Steps

Assess and Implement Changes is the governance process that determines whether your project’s scope, schedule, and cost baselines remain meaningful throughout execution — or gradually drift into irrelevance as informal changes accumulate without documentation, assessment, or authorization. Project Phoenix’s chatbot change request — from verbal request to formal approval, impact assessment, charter amendment, and sprint backlog addition in five business days — demonstrates what controlled change management looks like in a fast-moving agile project. ProjectAdm’s security library change, assessed and approved within 24 hours when a CVE was identified, demonstrates what controlled change management looks like when speed is essential and governance is non-negotiable.

Three takeaways for immediate application:

• All changes require documentation, regardless of size: The perception that small changes do not need formal change control is the primary cause of scope creep. There is no such thing as a change too small to document. There are only changes that are documented and changes that are not. Undocumented changes accumulate into uncontrolled scope drift.
• Impact analysis must cover all baselines, not just scope: A change request that has only a scope impact assessment is incomplete. Schedule, cost, quality, and risk impacts must be assessed before any decision is made. Decisions based on partial impact analysis produce surprises that are more expensive than the original change.
• Approved changes must be reflected in updated baselines: A change that is approved but not reflected in the project management plan baselines creates a gap between the documented project and the real project. Every approved change requires a baseline update. Without this discipline, monitoring and control lose their reference point and project governance becomes performative rather than effective.

Your concrete next step: Open your change log. Count the entries since execution began. If the number of formal change requests is lower than the number of scope discussions, stakeholder requests, or “quick improvements” you can remember from the past four weeks, there are undocumented changes in your project. Identify them. Log them retroactively. Assess their impact. And establish the norm — starting today — that every future change goes through the formal process before it goes into the work stream.

See all PMBOK 8 articles in the Complete Index

🇧🇷 Leia este artigo em português

Call to Action:

References

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

PMBOK Guide 8: The New Era of Value-Based Project Management. Available at: https://projectmanagement.com.br/pmbok-guide-8/

Disclaimer

This article is an independent educational interpretation of the PMBOK® Guide – Eighth Edition, developed for informational purposes by ProjectManagement.com.br. It does not reproduce or redistribute proprietary PMI content. All trademarks, including PMI, PMBOK, and Project Management Institute, are the property of the Project Management Institute, Inc. For access to the complete and official content, purchase the guide from Amazon or download it for free at https://www.pmi.org/standards/pmbok if you are a PMI member.