In this blog, we will cover the Assess and Implement Changes process.

Changes are inevitable, whether we are working in a predictive or agile environment. The plans we create and the requirements we define may evolve over time. In such situations, we need a structured and professional way to incorporate changes into the project—without impacting project objectives and while keeping the process transparent and traceable. That is why this process exists.

First, let’s look at the key output of this process, which is the Approved Change Request. We will understand the inputs, tools, and techniques required to produce this output.

As we learned in the Monitor and Control Project Performance process, change requests are raised to address project variances and issues. To resolve these issues, we often need to modify the project plan—for example, increasing budget or time, changing requirements, reducing scope, or adjusting resources.

These change requests are processed in this process, where a decision is made on whether they should be approved or rejected. If approved, they become Approved Change Requests, which can then be implemented.

Now, let’s look at the tools and techniques used to convert change requests into approved change requests.

We use Expert Judgment to evaluate whether a change is necessary. Changes often require technical, business, legal, or financial expertise to assess feasibility and impact.

Next, we use Change Control Tools—these are software systems used to raise, track, and document change requests, along with decisions made by the governing body. They ensure transparency, traceability, and auditability of the entire process.

We also use Data Analysis techniques to support decision-making with facts and evidence.

One key technique is Alternative Analysis, where we evaluate multiple ways of implementing a change and select the most efficient option in terms of cost, time, and value. For example, instead of replacing an entire CRM system, a smaller integration change combined with training might achieve the same outcome.

Another important technique is Cost-Benefit Analysis, where we compare the cost of implementing a change with the expected benefits. This helps ensure that resources are used effectively and only valuable changes are approved.

Next is Decision-Making.

In many cases, we use Consensus-Based Decision-Making, such as voting. Typically, a group of stakeholders forms a Change Control Board (CCB), which reviews change requests and decides whether to approve them. If the majority supports the change, it is approved.

However, some decisions require Autocratic Decision-Making, where a single authority makes the decision. For example, only the sponsor can approve budget increases, and only the product owner can decide on changes to the product backlog in an agile environment.

In some cases, we use Data-Driven Decision-Making, where decisions are based on quantitative analysis. One such technique is Multi-Criteria Decision Analysis (MCDA), where multiple factors are evaluated and weighted to arrive at a decision. 

Finally, Expert Judgment is also used to determine which decision-making approach—consensus, autocratic, or data-driven—is most appropriate in a given situation.

Next meetings – Meetings (especially CCB meetings) allow stakeholders and experts to discuss change requests, clarify impacts, and reach decisions.

Integrated Change Control – Integrated change control ensures each approved change is evaluated and implemented in a way that considers all project aspects (scope, schedule, cost, quality, resources, risk).

It prevents optimizing one area (e.g., scope) at the expense of others (e.g., cost and risk) and keeps the project coherent.

A scope change is only approved once the team also updates the schedule, cost, and risk baselines, ensuring everything stays consistent.

Backlog Management

In adaptive/agile approaches, many change requests manifest as new or modified backlog items. Backlog management is how changes are assessed and implemented iteratively.

It allows continuous reprioritization and incorporation of change without heavy formal change requests for each item.

Let’s see the other inputs we missed the cover.

Work performance reports

Work performance reports summarize performance data (scope, schedule, cost, quality, etc.). They show current status and trends at the time a change is requested.

They allow you to assess whether a change will help correct variances, worsen them, or is even needed at all.

Enterprise Environmental Factors (EEFs)

EEFs (laws, regulations, market conditions, corporate culture) influence which changes are acceptable or required.

They ensure change decisions comply with external and internal constraints and take advantage of relevant opportunities.

Organizational Process Assets (OPAs)

OPAs (change request forms, CCB charters, templates, historical records) guide how to document, analyze, and decide on changes.

They standardize change assessment, speed up evaluation, and allow you to learn from past similar changes.

Project Management Plan

Change Management Plan – The change management plan defines how changes are requested, documented, assessed, approved, and communicated. Without it, change handling becomes ad hoc and inconsistent.

It gives a clear, agreed workflow for changes (forms, boards, thresholds, approval levels), which reduces confusion and politics and speeds decisions.

For example – The plan states that any change impacting the cost baseline by more than 5% must be reviewed by the Change Control Board (CCB). A major design change request triggers this path automatically.

Configuration Management Plan

The configuration management plan defines which artifacts are under configuration control and how versions and baselines are managed when changes are approved.

It prevents situations where different team members use different versions of scope, designs, or requirements after a change, reducing rework and defects.

Example
After a requirement change is approved, the configuration plan ensures the updated requirements document is versioned, the old version is archived, and only the new version is used by design and test teams.

Scope Baseline

The scope baseline (scope statement, WBS, WBS dictionary) is the reference to see whether a requested change alters the agreed scope.

It allows you to quantify and explain exactly how a change will affect deliverables and work packages, enabling a fact-based approval decision.

Schedule Baseline

The schedule baseline is used to assess schedule impact of a proposed change and to update the schedule if the change is approved.

It helps determine whether the change will delay key milestones or require more schedule contingency, supporting realistic commitments.

Cost Baseline

The cost baseline is required to determine the cost impact of a change and to update the budget if the change is approved.

It ensures cost implications of changes are transparent and that funding decisions can be made consciously.

Next let’s cover the project documents which act as the inputs to this process.

Basis of Estimates

The basis of estimates documents how original time and cost estimates were built. It helps you understand and adjust underlying assumptions when evaluating changes. It allows more accurate, credible re-estimation when a change request affects previously estimated work.

Change Log

The change log contains all past and current change requests and their status. It provides context and history when assessing new changes.

It helps avoid contradictions with previous decisions, manage cumulative impact of changes, and track patterns (e.g., repeated change requests from a single stakeholder).

Requirements Traceability Matrix

The requirements traceability matrix (RTM) links requirements to design, development, and test artifacts. It is needed to see all items impacted by a requirement-related change.

It ensures you identify full downstream impact of a change, reducing missed updates to design, code, or tests.

Now let’s focus on the Outputs we yet to cover. We have already covered Approved Change request.

Project Management Plan Updates –

Change Management Plan – Frequent issues in change handling or large changes might reveal the need to refine thresholds, workflows, or CCB membership. For example – After repeated delays due to too many items needing full CCB review, the plan is updated to allow the PM to approve low-impact changes under defined limits.

Configuration Management Plan

New types of configuration items may emerge, or existing control levels may prove insufficient as changes are implemented. APIs become critical as more integrations are added, so the configuration plan is updated to include API specifications as controlled items.

Scope Baseline – Approved scope changes require updating the scope statement, WBS, and WBS dictionary.

Schedule Baseline – Approved changes that affect schedule (tasks added/removed, duration changes) require updating the schedule baseline.

Cost Baseline – Approved changes that affect cost must be reflected in the cost baseline and possibly funding requirements.

Project Documents updates

Change Log – Each decision (approved, rejected, deferred) and key rationale for a change request must be recorded. It provides traceability, supports audits, and helps resolve future disputes about what was decided and why.

Basis of Estimates – When a change leads to re-estimation, the reasoning and assumptions behind new estimates should be documented. It preserves transparency and supports future re-estimation if changes occur again.

Requirements Traceability Matrix – Approved requirement-related changes must be reflected in the RTM, updating relationships and affected items. It maintains end-to-end traceability and ensures design/test artifacts stay aligned with updated requirements.

Risk Report – Each approved change can alter the project’s risk profile and may introduce new risks or change existing ones.

That’s it! With that, we have completed all the inputs, tools and techniques, and outputs associated with the Assess and Implement Changes process. I hope you found this process clear and the concepts easy to understand.