HKSM

A change log is a living register that records all change requests and tracks their status, decisions, and key details throughout the project. It supports governance, traceability, and communication across the life cycle.

Key Points

• Captures every change request from submission through closure, including decisions and rationale.
• Acts as a single source of truth for change history, traceability, and audit readiness.
• Used by the project manager and change authority to manage impacts to scope, schedule, cost, and risk.
• Updated at key moments: on intake, after impact analysis, after decision, and during implementation.
• Access should be controlled but visible to stakeholders who need to track decisions and status.
• Enables reporting on change trends, throughput, and cycle time to improve decision quality.

Purpose

The change log ensures transparency and control over proposed changes by documenting requests, impacts, decisions, and implementation status. It helps prevent scope creep, supports integrated planning updates, and provides an auditable record of why and how the project evolved.

Field Definitions

• Change ID: Unique identifier for the request.
• Title: Short, descriptive name of the change.
• Date Submitted: When the request was logged.
• Requester/Source: Person or group that raised the change.
• Category: Scope, schedule, cost, quality, risk, procurement, or other.
• Priority/Severity: Urgency or business criticality of the change.
• Description and Reason: What is changing and why.
• Affected Items/Baselines: Deliverables, documents, or baselines impacted.
• Impact Summary: Concise statement of cost, schedule, quality, and risk effects and key assumptions.
• Cost Impact: Estimated monetary impact or range.
• Schedule Impact: Estimated time impact or range.
• Risk Impact: New or changed risks resulting from the change.
• Alternatives Considered: Options evaluated and their trade-offs.
• Recommendation: Analysis team or PM recommendation prior to decision.
• Decision: Approved, rejected, deferred, or more information required.
• Decision Date: Date the authority made the decision.
• Approver/Authority: CCB, sponsor, or designated authority.
• Implementation Owner: Person accountable for execution.
• Implementation Reference: Task or work item IDs and plan links.
• Target Release/Iteration: When the change will be delivered.
• Status: New, under review, approved, in implementation, closed.
• Communications/Notifications: Who was informed and when.
• Attachments/Links: Business case, analysis, and supporting documents.
• Closure Criteria and Verification Date: How closure is confirmed and when.

How to Create

• Select a tool that fits team needs (spreadsheet, register in PPM tool, or tracker) and set access controls.
• Define standard fields, data types, and picklists to ensure consistent entries.
• Establish a unique ID format (for example, CHG-001) and numbering rules.
• Configure a simple workflow with clear statuses and transitions.
• Create an intake form template and guidance for requesters.
• Agree on analysis guidelines for estimating cost, schedule, and risk impacts.
• Set up reporting views and filters for CCB meetings and stakeholder updates.

How to Use

• Log new requests promptly with initial details and assign an ID and owner.
• Screen for completeness, then assign impact analysis to appropriate SMEs.
• Record impact results, assumptions, and a recommendation before routing for a decision.
• Route to the authorized decision-maker or CCB per the change control plan.
• Immediately record the decision, date, and approver in the change log.
• If approved, update plans and baselines as needed, create implementation tasks, and communicate per the communication plan.
• Track implementation progress, manage dependencies, and update status until closure.
• Verify outcomes against acceptance or closure criteria and archive the record.

Ownership & Update Cadence

• Owner: Project manager or change manager maintains the log; the CCB or sponsor provides decisions.
• Update Timing: Real-time on intake, after analysis, immediately after decisions, and during implementation.
• Review Frequency: At every CCB session and at least weekly in project status reviews.
• Governance: Maintain version history and audit trail; do not delete requests, close them with rationale.
• Visibility: Provide read access or dashboards to stakeholders who need insight into change status.

Example Rows

• CHG-001 - Add compliance requirement; Category: Scope; Requester: QA lead; Impact: +$8,000, +10 days; Decision: Approved on 2025-02-10 by CCB; Implementation owner: Team A; Status: In implementation.
• CHG-002 - Replace vendor due to performance; Category: Procurement; Requester: PM; Impact: -$5,000, +3 days, risk reduced; Decision: Rejected on 2025-02-15; Rationale: Out of scope for this phase; Status: Closed.
• CHG-003 - Extend testing window; Category: Schedule; Requester: Product owner; Impact: +0 cost, +5 days; Decision: Deferred pending impact analysis; Status: Under review.

PMP Example Question

During a change control meeting, a change request is approved with a minor schedule impact. What should the project manager do next?

1. Update the schedule baseline immediately and inform the team.
2. Record the decision and key details in the change log, then update plans and communicate per the plan.
3. Implement the change and update the change log after implementation.
4. Escalate the decision to the sponsor for confirmation.

Correct Answer: B - Record the decision and key details in the change log, then update plans and communicate per the plan.

Explanation: After approval, the decision should be documented in the change log and then integrated into plans and communications. This maintains traceability and ensures controlled implementation.