How do I record a project requirement change without losing the original agreement?
Quick answer
Keep the original requirement intact and add a separate, dated entry for each proposed change. Record who requested it, what would change, who decided, when the decision was made, and which work is affected. Do not mark the earlier requirement as superseded until the change is approved. Link the relevant drafts or decisions, and clearly identify the current version so readers can distinguish history from instructions to follow now.
The question, the details, the next step.
How do I record a project requirement change without losing the original agreement?
Keep a change log beside the requirements document rather than editing the original requirement until its history disappears. Give each proposed change a separate entry with a date, description, status, decision, and affected work. When the change is approved, update the current requirements and mark the earlier wording as superseded—not deleted. This preserves what was agreed first while showing what people should follow now. Keep the log concise: capture the request and decision, not every conversation.
What should I put in each entry? I want it useful, but not a long meeting transcript.
Use fields that make the request, decision, and impact easy to understand:
- Change ID and date raised.
- Request and requester, using a name or role as appropriate.
- Original requirement, copied exactly or linked to its version.
- Proposed change and the reason given.
- Decision, decision-maker, and date decided.
- Status, such as proposed, approved, declined, or deferred.
- Affected work, its owner, and the next action.
- Current requirement or version after the decision.
If the decision is pending, say so. A request does not become an approved requirement just because it appears in the log. Keep the reason separate from the decision, and do not add an explanation that nobody agreed to.
Can you show how that works for a small project?
Suppose the agreed requirement is that a monthly report includes three summary charts, and someone requests a fourth. This copyable example uses placeholders:
Change ID: CR-01 Raised: [date] Requested by: [name or role] Original requirement: “The monthly report includes three summary charts.” [link or version] Proposed change: Add a fourth chart showing [measure]. Reason: [brief reason given] Decision: Approved by [decision-maker] on [date]. Affected work: Report layout and chart preparation; [owner] to update them by [date]. Current requirement: “The monthly report includes four summary charts, including [measure].” Status: Approved; original wording retained as superseded.
If approval has not happened, label the entry “Proposed” and leave the current requirement unchanged. That makes it clear the new wording is not yet an instruction to follow.
How do I keep people from mistaking an old draft for the current agreement, especially if the request changes again or is declined?
Make the active version easy to identify: label it with a version or “current as of [date],” and agree where that version and the official change log are kept. In each entry, point to the exact section or version affected and link to the approved update. Keep old wording visible as historical, marked superseded with the change ID and decision date; do not overwrite it.
For another change, add a new entry that refers to the earlier change ID rather than rewriting the first one. If a request is declined or deferred, record that outcome and any next step, but leave the active requirement unchanged. If approval is verbal or the decision-maker is unclear, record what needs confirmation and label the entry pending until the relevant person verifies it.
A practical checklist
Keep the original requirement and identify its version or location.
Give each proposed change a unique ID and date raised.
Record the request, reason, decision, decision-maker, and decision date.
Name affected work, its owner, and the next action.
Label the status clearly and update the active requirement only after approval.
Link later changes to earlier entries instead of rewriting history.
A few more useful answers
Should I delete a requirement after it is replaced?
Keep the original wording in the history and mark it superseded, with a link to the approved replacement. That preserves the earlier agreement without presenting it as current.
What if the change was agreed verbally?
Record the date and the decision as you understand it, then ask the relevant decision-maker to verify the written entry. Mark it pending confirmation until they do.
How much detail should the reason include?
Use a brief, plain-language explanation of the stated reason for the request. Keep it separate from the decision, and avoid adding an explanation that nobody agreed to.