How to Write a Change Summary When a Project Plan Moves

A project plan changes in one meeting, but the people affected by it may be working from several different versions. One person remembers the original date. Another sees a revised task list. Someone else receives a message that says only, “The schedule moved.”

A change summary gives everyone the same current picture. It states what was approved, what the plan was before, what it is now, why it moved, which work is affected, what remains unchanged, and where the live source can be found. It is a communication record, not a substitute for the plan itself.

What is a project change summary?

A project change summary is a short, dated explanation of an approved change. It helps a reader update the right part of their work without reconstructing the entire discussion.

This guide covers ordinary changes to schedules, ownership, scope, sequence, and handoffs. Contractual, legal, safety, regulatory, privacy, security, and financial changes require the appropriate qualified review before they are communicated or implemented.

Confirm that the change is approved

Meeting notes often contain options, preferences, and provisional statements. None of those is automatically an approved change. Before writing, find the source that confirms the new plan and the person or process authorized to approve it.

“We could move the workshop to the afternoon” is an option. “The program lead approved the 14:00 start” is a decision. If the approval is unclear, record an open question rather than publishing a confident update.

If readers need to understand the reasoning and alternatives behind the approval, link to a decision log from the meeting notes. The change summary should stay focused on the current operational effect.

Use a simple before-and-after structure

Start with the field that changed. Showing both values prevents readers from comparing several documents themselves.

Changed field: Workshop start time
Previous plan: 10 October, 10:00
Current plan: 10 October, 14:00
Effective from: 22 September

Use exact labels and dates. Avoid “old time” and “new time” when the message may be forwarded or read later.

Answer seven questions

A useful change summary answers seven questions in this order:

1. What changed? Name the field, previous value, and current value.
2. When does it take effect? Give an effective date or version.
3. Why did it change? State the confirmed reason without adding motives that are not in the source.
4. What is affected? Identify the tasks, dates, owners, or audiences that need to adjust.
5. What stays the same? Protect stable parts of the plan from unnecessary rework.
6. What must the reader do? Give an owner and a date, or say that no action is required.
7. Where is the live source? Link to the current plan and the approving record.

These questions make the summary useful without turning it into a second project plan.

A worked example: a fictional workshop

Imagine a fictional team preparing a customer-research workshop. The permitted meeting notes record the following:

• the venue can no longer provide the main room before 13:30;
• the program lead approved moving the workshop from 10:00 to 14:00 on the same date;
• the venue, participant list, workshop goal, and session order are unchanged;
• the catering delivery needs to move from 09:15 to 13:15;
• the facilitator and note taker remain assigned;
• Rina will update the calendar and participant message by 23 September at 12:00;
• the team has not yet confirmed whether one remote participant can join at the later time.

The notes support an approved schedule change. They also contain one unresolved attendance question. The summary should keep those two facts separate.

Example change summary

Customer-research workshop — schedule change

Updated: 22 September, 18:30

What changed: The workshop on 10 October will begin at 14:00 instead of 10:00.

Why: The venue confirmed that the main room is unavailable before 13:30. The program lead approved the later start.

Impact: Catering delivery moves from 09:15 to 13:15. Rina will update the calendar invitation and participant message by 23 September at 12:00.

Unchanged: The date, venue, participant list, workshop goal, session order, facilitator, and note taker remain the same.

Open item: The team is confirming whether one remote participant can attend at the later time. This does not change the approved schedule.

Current source: Workshop plan, version dated 22 September; approval recorded in the 22 September planning notes.

The summary does not repeat the full meeting. It tells each reader which part of the plan to replace and which parts to leave alone.

Explain impact without guessing

Impact means the confirmed consequence of the change, not every possible downstream effect. If the catering time must move, say so. If the effect on remote attendance is still unknown, label it as an open item.

Avoid phrases such as “nothing else is affected” unless the source supports that claim. “No other changes were approved in this review” is narrower and easier to verify.

Say what stays the same

Unchanged elements are often the most valuable part of the message. They stop readers from reopening settled work. A date can stay fixed while the time moves. A delivery sequence can change while ownership stays fixed.

List only stable elements that a reasonable reader might otherwise question. There is no need to restate the entire plan.

Keep the live plan and the history connected

Update the authoritative project plan first or at the same time as the change summary. Then link the summary to that source. Mark outdated schedules as superseded where practical, but preserve the change history.

If an earlier note contains inaccurate information rather than a newly approved change, use a transparent correction that preserves the record. A correction fixes what was recorded incorrectly. A change summary communicates a plan that genuinely moved.

Choose recipients by impact

Send the summary to people whose work, attendance, deadline, or decision is affected. Do not copy a broad audience by default. For each recipient group, state the action required—or state clearly that the message is for awareness only.

Use a subject line that names the project and changed field, such as “Workshop start time changed to 14:00.” Avoid vague subjects such as “Important update.”

Copy this change-summary template

Project or event:
Updated at:
Approved by / approval source:

Changed field:
Previous plan:
Current plan:
Effective date or version:

Confirmed reason:
Affected work or audience:
What stays the same:
Action required, owner, and due date:
Open items or unknown effects:

Current plan link:
Decision or approval record:
Superseded source, if any:

Run a final source check

Before sending, compare the previous value, current value, reason, approval, affected work, stable elements, owner, and due date with the permitted source. Test every link. Make sure an option has not been rewritten as a decision and an unknown effect has not been presented as settled.

Choose one approved change from an ordinary project you are allowed to document. Write the previous plan, current plan, reason, impact, unchanged elements, action required, and current source. If any one of those fields cannot be verified, mark the gap before the summary is shared.