Managing Changes During a Project

Change is a normal part of project work. A client may revise a requirement, a supplier may become unavailable, a regulator may introduce a new condition, or the team may discover that an early assumption was wrong. The challenge is not to eliminate change, but to manage it deliberately so that one adjustment does not create avoidable problems elsewhere.

Effective change management connects decision-making with project control. It helps a project team understand what is changing, why it matters, what it will affect and who must approve it. Whether you are managing a construction project in Kisumu, a software implementation in Nairobi, a community programme in Uganda or an internal business improvement project, the principles are broadly similar.

What Counts as a Project Change?

A project change is an approved or proposed alteration to the project’s agreed baseline. The baseline normally includes the project scope, schedule, budget, quality expectations, resources, risks and deliverables. A change may affect one of these areas or several at the same time.

Examples include:

• Adding a new feature to a digital service.
• Removing a deliverable because it is no longer needed.
• Changing the materials, design or location of a construction activity.
• Moving a deadline because a critical supplier is delayed.
• Replacing a team member with different skills or availability.
• Introducing a new reporting, safety or compliance requirement.
• Changing the order in which activities are completed.

Not every adjustment requires the same level of control. A team member correcting a spelling error in an internal working document is different from a client requesting an additional service that requires two more weeks and a larger budget. The purpose of change management is to apply proportionate discipline: small changes should not be buried in unnecessary administration, while significant changes should never be handled casually.

Why Poorly Managed Changes Cause Problems

Many project difficulties begin with changes that are accepted informally. A manager may say, “We can add that later,” or a developer may begin work on a new request without recording it. Although the change may appear minor, its consequences can spread through the project.

For example, adding a reporting dashboard to a business system may require new data fields, additional design work, testing, user training and revised documentation. If the team only considers the dashboard itself, the schedule and budget may become unrealistic. This is sometimes called scope creep: the gradual expansion of project work without corresponding control over time, cost or resources.

Uncontrolled changes can lead to:

• Missed deadlines because new work is added to an unchanged schedule.
• Cost overruns caused by extra labour, materials or suppliers.
• Lower quality when the team rushes to absorb additional work.
• Conflicting expectations between the project team and stakeholders.
• Rework when changes are made without understanding dependencies.
• Reduced morale because priorities keep shifting.
• Disputes about who requested, approved or paid for the change.

Good change management protects the project from these effects while still allowing it to respond to genuine needs.

Understand the Difference Between Change, Risk and Issue

These terms are connected but not interchangeable.

• A change is a proposed or approved alteration to the project plan, requirements or deliverables.
• A risk is an uncertain event or condition that may affect the project in the future.
• An issue is a problem that has already occurred and requires action.

Suppose a supplier warns that imported equipment may arrive late. The possible delay is a risk. If the shipment actually misses the required date, it becomes an issue. If the team decides to replace the equipment with a locally available alternative, that decision may create a project change.

Making these distinctions helps the manager choose an appropriate response. A risk may require mitigation or contingency planning. An issue may require immediate resolution. A change normally requires assessment, approval and an update to the relevant project records.

A Practical Change Management Process

1. Identify and describe the change

Begin with a clear description of what is being requested or discovered. Avoid vague statements such as “The client wants improvements.” Record the specific change, its origin, the reason for it and the date it was raised.

A useful change request might state: “The client requests a mobile-friendly version of the customer booking page because many users access the service through smartphones. The requested outcome is a responsive page tested on commonly used mobile devices.” This description is more useful than simply writing “Improve mobile access”.

At this stage, do not assume that the requested solution is the only option. The underlying need may be met in another way. Asking what problem the stakeholder is trying to solve can prevent unnecessary work.

2. Check whether the change is necessary

Not every request should be accepted. Consider whether the change is required to meet the project’s purpose, respond to a genuine external condition or improve a clearly defined outcome. Some requests are preferences rather than necessities, and some can be postponed to a later phase.

Useful questions include:

• What problem or opportunity does the change address?
• What happens if the project does not make the change?
• Is the requested outcome already covered by the agreed scope?
• Could the need be met through a simpler alternative?
• Does the change support the project’s business or organisational objectives?

This step prevents the team from treating every new idea as an urgent requirement.

3. Assess the impact

Impact assessment is the heart of responsible change management. The project manager should consult the people who understand the affected work rather than estimating everything alone.

Assess the likely effect on:

• Scope: What additional or different work will be required? Which deliverables, requirements or acceptance criteria will change?
• Schedule: Will activities take longer? Are there dependencies, critical tasks or fixed external dates?
• Cost: Will the project need more labour, materials, software, transport, specialist advice or contingency funds?
• Quality: Could the change improve quality, reduce it or introduce new testing requirements?
• Resources: Are the necessary skills, equipment and staff available?
• Risk: What new risks will the change create, and which existing risks will it reduce?
• Stakeholders: Who will gain, lose, approve, use or be affected by the change?
• Contracts and compliance: Does the change affect a supplier agreement, permit, safety requirement, data responsibility or other obligation?

Consider both direct and indirect effects. If a community water project changes the location of a storage tank, the direct effect may be revised construction work. Indirect effects may include a longer pipe route, additional land discussions, altered maintenance access and a different delivery schedule.

4. Develop options and a recommendation

A strong assessment does not merely say that a change is expensive. It presents decision-makers with practical choices. Options might include accepting the change now, accepting it with a revised deadline, replacing another deliverable, postponing it to a later phase or rejecting it.

For each option, explain the trade-offs. For example:

1. Implement immediately: meets the new need but adds cost and delays another milestone.
2. Implement a limited version: addresses the most important requirement within the current schedule.
3. Defer to a later phase: protects the current launch but requires a future commitment.
4. Do not implement: preserves the baseline but leaves the identified need unresolved.

Recommendations should be based on evidence and project priorities, not on pressure from the loudest stakeholder. Where information is uncertain, state the assumptions clearly and identify what must be confirmed before a final decision.

5. Obtain the right approval

Approval authority should be clear before a change arises. A small operational adjustment may be approved by the project manager, while a change affecting the budget, contractual scope or launch date may require a sponsor, steering group, client or governance body.

Do not confuse consultation with approval. A team may discuss a change with several people, but only the authorised decision-maker can approve it. Likewise, a stakeholder’s request is not automatically an instruction to proceed.

Approval records should show the decision, the authority who made it, any conditions and the date. If the change is rejected, record that decision as well. A clear record reduces later confusion and helps the team explain why work was or was not undertaken.

6. Update the project baseline and records

Once a change is approved, update the relevant plans and documents before implementation begins. Depending on the project, this may include the scope statement, work breakdown structure, schedule, budget, risk register, procurement plan, quality plan, communications plan, requirements list and benefits measures.

Updating documents is not administrative decoration. It creates a shared version of the truth. If the schedule says completion is 30 June but an approved change moves it to 15 July, the revised date should appear wherever stakeholders rely on project information.

Maintain a change log containing at least the change reference, description, requester, reason, impact assessment, decision, approver, implementation status and date. A simple spreadsheet can be sufficient for a small project if it is kept accurate and accessible.

7. Communicate the decision and its consequences

Communication should explain more than whether the change was approved. People need to know what will happen, when it will happen, what is no longer included, and what they must do differently.

Tailor the message to the audience. A sponsor may need the effect on cost and benefits. A technical team may need revised requirements and acceptance criteria. A supplier may need a formal instruction. End users may need a new training date or explanation of changed functionality.

Be honest about trade-offs. If a project accepts an additional feature by removing a lower-priority feature, say so. Clear communication is more useful than promising that everything will remain unchanged.

8. Implement, monitor and close the change

Assign responsibility for implementation and define how completion will be checked. A change is not complete simply because someone began working on it. The revised deliverable must meet its agreed acceptance criteria, related documents must be updated and affected stakeholders must be informed.

Monitor the change for unintended consequences. A revised supplier may solve a delay but create a quality concern. A compressed schedule may protect the launch date but increase workload and testing risk. If new information changes the assessment, raise a further change or issue rather than quietly allowing the plan to drift.

Leading People Through Project Change

Change management is also a leadership responsibility. Team members may feel frustrated when priorities move, while stakeholders may resist changes that affect their work or expected benefits. The manager’s role is to create clarity without pretending that change is painless.

Explain the reason behind the decision, not only the instruction. Invite concerns from people closest to the work because they may identify practical consequences that were missed during planning. At the same time, avoid reopening every decision indefinitely. Once the authorised decision has been made, the team needs a clear direction.

Protect the team from conflicting requests by establishing a single route for changes. If a senior stakeholder approaches an individual team member directly, the request should still be recorded and assessed through the agreed process. This is not about slowing work; it is about preventing hidden commitments.

Prioritisation is particularly important when resources are limited. A useful approach is to distinguish between essential work, valuable work and work that can wait. When everything is labelled urgent, the project has no meaningful priority system.

Common Mistakes to Avoid

• Starting before approval: early work can create pressure to accept a change simply because resources have already been spent.
• Assessing only cost: time, quality, risk, staffing and stakeholder effects may be more important than the immediate financial impact.
• Ignoring rejected changes: without a record, the same request may return repeatedly and create confusion.
• Updating one document only: inconsistent plans produce inconsistent decisions.
• Assuming silence means agreement: approval should be explicit and come from the correct authority.
• Making every change a crisis: calm, proportionate handling improves judgement and reduces unnecessary disruption.
• Using change control as a barrier: the process should help good changes move forward, not discourage legitimate improvements.

Applying This in Practice

When a new request arrives, use the following short routine:

1. Write down exactly what is being requested and why.
2. Identify the project objective or user need connected to the request.
3. Ask the relevant team members to estimate effects on scope, time, cost, quality, resources and risk.
4. Compare practical options, including postponing or declining the change.
5. Send the recommendation to the authorised decision-maker.
6. Record the decision in the change log.
7. Update plans, requirements and dates before work begins.
8. Communicate the decision to everyone affected.
9. Monitor implementation and confirm that the revised outcome has been accepted.

For a small enterprise project, this routine may fit on a single-page form. For a major infrastructure, technology or development programme, it may be supported by a formal change control board and detailed governance documents. The scale can vary, but the reasoning remains the same: understand the request, examine its consequences, decide transparently and keep the project information current.

Key Takeaways

• Project change is normal, but it should be assessed and authorised rather than absorbed informally.
• Separate changes from risks and issues so that each receives the right response.
• Assess every significant change across scope, schedule, cost, quality, resources, risk and stakeholders.
• Present decision-makers with realistic options and explain the trade-offs of each one.
• After approval, update the baseline, change log and affected project documents.
• Communicate not only the decision, but also its practical consequences and responsibilities.
• Monitor implementation and confirm that the changed deliverable meets its acceptance criteria.