# Change Request

Writes a formal change request document including the reason for the change, the scope of the change, and a structured impact analysis covering schedule, cost, and resources. Use it any time a proposed change to scope, schedule, or budget needs to go through a formal approval process.

## Prompt

## Context
You are a project management assistant helping [REQUESTOR NAME] draft a change request for [PROJECT NAME] at [ORGANIZATION NAME]. The change request is being submitted to [APPROVING AUTHORITY].

Change description (what is changing and why):
[CHANGE DESCRIPTION]

Change type: [CHANGE TYPE] (scope / schedule / budget / resource / technical / other)

Reason and justification:
[CHANGE JUSTIFICATION]

Alternatives considered before requesting this change:
[ALTERNATIVES CONSIDERED]

Proposed impacts on schedule:
[SCHEDULE IMPACT]

Proposed impacts on budget:
[BUDGET IMPACT]

Proposed impacts on resources:
[RESOURCE IMPACT]

Risks introduced or reduced by this change:
[CHANGE RISKS]

Requested effective date:
[REQUESTED EFFECTIVE DATE]

## Task
Draft a change request document with these sections:
1. Change Request Summary (one paragraph: what, why, and the requested effective date).
2. Change Description (detailed explanation of what is changing).
3. Justification (why this change is necessary or beneficial).
4. Alternatives Considered (what other options were evaluated and why they were rejected).
5. Impact Analysis (schedule, budget, resource impacts in table form).
6. Risks Introduced or Reduced.
7. Recommendation (one sentence: approve, deny, or defer, written as a blank for the approver to fill in).
8. Signature block with Requestor, Approver, and Date fields.

## Standards
- Use only the information the requestor provided. Do not invent schedule dates, cost figures, resource names, or risk ratings.
- Impact Analysis table: show baseline, proposed change, and net delta for each dimension. Use [BASELINE VALUE] as a placeholder where the requestor did not supply the current baseline.
- Tone: factual and neutral. This is a record, not a sales pitch.
- Note at the bottom: this document does not constitute a contract modification. Formal contract changes require review by the contracting authority.
- Length: 400 to 600 words of narrative, plus tables.
- If any required input is missing, ask before drafting.

## Variables

- REQUESTOR NAME
- PROJECT NAME
- ORGANIZATION NAME
- APPROVING AUTHORITY
- CHANGE DESCRIPTION
- CHANGE TYPE
- CHANGE JUSTIFICATION
- ALTERNATIVES CONSIDERED
- SCHEDULE IMPACT
- BUDGET IMPACT
- RESOURCE IMPACT
- CHANGE RISKS
- REQUESTED EFFECTIVE DATE

## Input checklist

- [ ] Clear description of what is changing, written by the person requesting the change
- [ ] The baseline values for schedule, budget, and resources before the change
- [ ] Specific impacts on schedule, cost, and resources with numbers from the project plan
- [ ] At least one alternative that was considered before the change was requested
- [ ] Risks introduced or reduced by the change, from the risk register or team discussion
- [ ] Confirm all baseline values, dates, and cost figures come from current project records, not estimated by the AI

## Verification checklist

- [ ] Confirm the Impact Analysis table shows your actual baseline values, not placeholders the AI invented
- [ ] Check that no cost figures, schedule dates, or resource counts were invented by the AI
- [ ] Verify the net delta in each impact row is correct by computing it yourself
- [ ] Confirm the alternatives section accurately reflects what the team actually evaluated
- [ ] Check the risks section against the project risk register before submitting
- [ ] Verify the contractual disclaimer is present and that no language in the document implies a contract modification has occurred
- [ ] Do not submit this document until the requestor has reviewed every field and confirmed its accuracy

## Sample output

Sample output. Generated by AI from sample inputs:

Change Request CR-007
Project: Atlas -- Northwind Logistics Warehouse Migration
Requestor: Operations Director, Northwind Logistics
Approving Authority: Steering Committee
Date Submitted: [INSERT DATE]
Requested Effective Date: [INSERT DATE]

**1. Change Request Summary**

This change request proposes to defer the Phase 2 go-live date by three weeks to allow completion of the legacy system data mapping audit, which identified a larger-than-expected number of unmapped fields. Without this extension, the migration would proceed with an incomplete data set, increasing the risk of inventory errors at go-live. The requested effective date is [INSERT DATE].

**2. Change Description**

The current Phase 2 go-live date will be extended by three weeks. All Phase 2 milestones shift proportionally. Phase 3 planning start date is also affected. No scope changes are proposed.

**3. Justification**

The Week 3 data mapping review found that 18 percent of legacy product fields do not have a direct equivalent in the new WMS. Mapping these fields manually requires an estimated three additional weeks of IT and operations effort. Proceeding on the original date would require going live with incomplete inventory records.

**4. Alternatives Considered**

- Proceed on the original date with a partial dataset and remediate post-go-live: rejected because inventory errors during the peak shipping period carry unacceptable operational risk.
- Reduce the scope to exclude the unmapped product categories: rejected because those categories represent core stock the warehouse cannot operate without.

**5. Impact Analysis**

| Dimension | Baseline | Proposed | Net Delta |
|---|---|---|---|
| Go-live Date | [BASELINE VALUE] | [BASELINE VALUE + 3 weeks] | +3 weeks |
| Phase 3 Start | [BASELINE VALUE] | [BASELINE VALUE + 3 weeks] | +3 weeks |
| Budget | [BASELINE VALUE] | [BASELINE VALUE + extended labor cost] | To be confirmed by PM |
| Resources | IT Lead + Ops SME assigned through go-live | Same, extended 3 weeks | +3 weeks of IT Lead and Ops SME time |

**6. Risks Introduced or Reduced**

- Reduced: R-002 (Data Mapping Failure) likelihood decreases from 4 to 2 if the extension is used to complete the audit.
- Introduced: Extended timeline increases exposure to R-001 (Vendor Delivery Delay) if the vendor's schedule is fixed.

**7. Recommendation**

This change request is: [ ] Approved  [ ] Denied  [ ] Deferred

Comments: _______________

Approver Signature: _______________ Date: _______________
Requestor Signature: _______________ Date: _______________

Note: This document does not constitute a contract modification. Formal contract changes require review and approval by the contracting authority.

## Customization notes

For government contracts and defense logistics programs, add a Contract Line Item Number field and note the requirement for a formal contract modification through the contracting officer. Larger programs should add a Change Control Board tracking number and link the change request to the project schedule baseline version. Adapt the impact table to match your organization's earned value or schedule performance reporting format if those baselines are tracked.

---

From The Logistics, Operations & Project Management Library at vetslearn.com/libraries/logistics-pm