A project change request explains a proposed departure from the approved scope, timing, cost or other controlled arrangement. It gives the authorised decision-maker enough information to assess the consequences before the change is implemented.
Raising a request does not approve it. Keep the existing baseline and the proposed revision distinguishable until the proper decision has been made and communicated.
Establish what the proposal changes
Identify the current approved requirement and its reference. Describe the proposed difference in specific terms, including what remains uncertain. For a systems change, our IT roles and skills guide helps place coordination alongside technical delivery; confirm which role can assess the impact and which person can approve the change.
A clarification that does not alter the approved work may follow a different process from a change to scope or timing. Check the project’s governance arrangements rather than calling every question a formal change or treating every change as a harmless clarification.
The Queensland Transport and Main Roads project-management principles provide context for managing work against a project plan. The request structure below is an original general workplace example, not a delegation to approve a change.
Prepare a practical change-request brief
Include:
- Reference: identifier, requester and date.
- Baseline: the approved requirement, plan or version affected.
- Proposal: the specific change and reason.
- Options: feasible alternatives, including maintaining the current arrangement.
- Effects: scope, schedule, resources, cost, quality and other relevant consequences.
- Dependencies: decisions, commitments or information needed first.
- Recommendation: the preferred approach, if within the requester’s role.
- Decision: authorised approver, required timing and recorded outcome.
Label estimates and assumptions. Obtain input from the people responsible for affected work instead of assuming that a small change creates no additional effort.
A fictional request with a real trade-off
In this invented office project, the approved deliverable is a staff instruction guide. A requester proposes adding a separate supervisor checklist before rollout.
The change brief explains the intended use and asks the team to assess drafting, review and testing effort. It identifies that retaining the current rollout date may require another approved adjustment or a later release of the checklist.
The proposal does not state that the extra document is already part of the agreed scope. It presents the options and information needed for the manager’s decision.
Record the actual decision and conditions
Capture whether the request is approved, rejected, deferred or returned for more information. Record who decided, when and any conditions or limits.
If approval depends on a resource or another decision, make that condition visible before work begins. Do not mark a conditional approval as unrestricted permission to spend or change another team’s commitments.
Where the request affects contractual arrangements, use the applicable contract-change process and appropriate advice separately. An internal project log does not automatically vary an external agreement.
Implement the approved change consistently
Update the plan, task assignments and relevant documents through controlled processes. Tell affected people what has changed, which version applies and what they need to do.
Check whether related risks, issues or stakeholder communications need updating. Retain the decision and earlier baseline through the approved records process. A complete change request leaves a traceable path from proposal to authorised decision and implementation, with no confusion about what was actually approved.
