How do I explain the effect of a proposed change on work that is already in progress?

Organize the summary around commitments, not just a description of the new request. Start by naming the proposed change and its status: proposed, under review, or approved. Then identify work already in progress that may be affected. Include only commitments or dependencies you can identify—for example, a deliverable currently being drafted or a review that must happen before another task can proceed.

For each item, separate what is confirmed from what is still possible. A confirmed effect is supported by information you have, such as a task that must be revised if the change is accepted. A possible effect is a concern that still needs checking, such as whether a review date would move. Do not turn “may affect” into “will delay” unless that outcome is established.

A useful opening might be: “The proposed change adds [requested change] to [work area]. It may affect [known in-progress commitment]. We have confirmed [known effect]. We have not yet confirmed [uncertainty].”

Make a short impact list and label the basis for each entry. Include an item when you know it is active and can explain its connection to the proposed change. If the connection is only suspected, label it as something to verify rather than presenting it as a definite dependency.

For example, imagine a team is considering adding an approval section to a draft guide. The guide is being edited, and a review of its current version is scheduled. The draft is directly affected if the new section changes its text. But do not state that the review will be late unless someone has confirmed that the added work changes the review plan.

You can write entries like these:

1. Confirmed: [in-progress item] needs [specific change] if the proposal is approved.
2. Possible: [related task or dependency] may need adjustment; [person or team] needs to confirm.
3. Not assessed: Other effects have not been checked yet.

If you do not know who owns a dependency, say that it needs an owner or confirmation. A clear gap is more useful than a guessed answer.

Say explicitly that timing or effort has not yet been assessed, then name what must be checked before anyone can estimate it. Avoid a replacement date, effort figure, or reassurance that existing commitments will stay unchanged unless you have evidence for that statement.

A copyable example might read:

“Proposed change: Add [new requirement] to [work item]. In progress: [current deliverable] is being prepared for [existing milestone, if confirmed]. Confirmed effect: If approved, [specific part] will need to be revised. Possible effect: The change may affect [review, dependent task, or commitment]; this has not been confirmed. Unknowns: [effort, timing, dependency, or scope] have not been assessed. Next questions: Who can confirm [dependency]? What scope should be included? Once those are answered, [owner or team] can review the effect on the existing plan.”

Replace each bracket with information you can verify. If a field is unknown, keep it marked as unknown rather than filling it with an assumption. Distinguish a decision needed now—such as whether to proceed—from an estimate that depends on that decision.

Put the decision and its consequences where the reader can find them quickly. State what is proposed, which in-progress commitments are known to be affected, and which concerns still need verification. Then ask focused questions that would resolve uncertainties—for example, whether a named dependency is real, which scope is intended, or who should assess the plan.

Keep observations separate from recommendations. If you recommend pausing, sequencing, or proceeding, label it as a recommendation and give its basis; do not present it as an established consequence. If there is not enough information to recommend an option, say so and identify the missing input. Before sending, check that every definite statement is supported, every uncertain effect is labeled, and no date or effort promise has slipped in without evidence.