Client Delivery
Part of Project documentation and decisions
Keeping a change log inside a project workspace
Track proposed project changes, their impact, decisions and implementation in a log connected to the current plan.
A project change log should show each proposed change, its assessed effect, the authorised decision and any work needed to apply it. Keep it near the current plan and reference earlier plan versions. Readers should be able to tell pending requests from approved changes.
Project Management Standards Reference
- Source: APM
- Association for Project Management
- Focus Areas
- Change control, information management, configuration management
Set the threshold for an entry
Log a request when it may change an agreed deliverable, acceptance rule, date, cost or another controlled part of the plan. An ordinary task update or spelling correction may need edit history without becoming a change request. Make the local threshold clear to contributors.
Give each request an ID, requester, date, description, reason, affected plan version and decision owner. Preserve the request as submitted, then add the assessment and outcome separately. Rejected and deferred requests remain useful records.
Stage / What the entry should show
- Proposed
- What is requested and why
- Assessing
- Affected work, options and likely consequences
- Awaiting decision
- Who can decide and what information is missing
- Decided
- The outcome, decision-maker and date
- Implementing
- Updates required after approval
- Resolved
- Evidence of implementation, rejection or another recorded outcome
These states are suggested. A deferred request needs a review trigger rather than disappearing into a closed queue.
Assess before changing the plan
Compare the request with the approved baseline. Consider the effects on scope, quality, time, resources, cost and risk where relevant. Record important uncertainty and options. An estimate in the log is not yet an authorised commitment.
For example, an additional review round might affect a deliverable, reviewer availability and a later milestone. The decision-maker can approve, reject or defer it after seeing those effects. A client engagement may also require a separate contractual or client-authorisation step.
Connect the log to the workspace
Keep the log in a project area that authorised people can reach. Name its maintainer and reference the relevant plan version, deliverable and affected tasks. After approval, assign updates and check that the changed records match the decision.
Activity or version history may show that a field changed without explaining why the change was authorised or what else it affects. Use the log for that decision trail. If the workspace has no structured register, a maintained table with stable IDs can serve the same purpose.
Review open requests
At project reviews, check requests awaiting assessment or decision, approved changes still being applied and deferred requests whose review trigger has arrived. Give each a decision owner or next-action owner. For an implemented change, retain references to the previous and resulting plan versions so a later reader can understand what changed.
