Change Request Template

---
title: "Change Request Template"
methodology: "traditional"
complexity: "advanced"
owner: "mirichard"
updated: "2026-09-19"
primary_principles: ["adaptability", "risk-optimization"]
secondary_principles: ["evidence-based-decisions"]
principle_rationale: "Compares change alternatives and baseline impacts so the change authority can approve a proportionate response with recorded evidence."
---

# PROJECT CHANGE REQUEST FORM

## When to Use

- During execution when a proposed change affects approved scope, schedule, cost, or controls.
- When the change authority needs alternatives, impact analysis, and a recorded decision.

## When NOT to Use

- To replace the original baseline with the requested change before approval.
- Do not overwrite the original baseline to remove an unfavorable variance. See [Rebaseline to green](../../../../../../docs/principles/anti-patterns.md#baseline-green).

## Pairs Well With

- [Raid Log Template](../../../../../../domains/delivery/templates/traditional/Traditional/Templates/raid_log_template.md).
- [Project Schedule Template](../../../../../../domains/delivery/templates/traditional/Traditional/Process_Groups/Planning/project_schedule_template.md).

Selection context: Delivery domain; traditional methodology; advanced complexity. Match the situations above to project phase, risk, team size, and industry using the [decision-engine context model](../../../../../../meta/architecture-research/800-801-context-assessment-model.md).

## Document Control Information
**Project/Program Name:** *[Enterprise Resource Planning Implementation]*  
**Change Request ID:** *[CR-001]*  
**Prepared By:** *[Jane Smith, Project Management Professional]*  
**Preparation Date:** *[YYYY-MM-DD]*  
**Last Updated By:** *[Jane Smith, Project Management Professional]*  
**Last Revision Date:** *[YYYY-MM-DD]*  
**Status:** *[Submitted/Under Review/Approved/Rejected/Deferred/Implemented/Closed]*

---

## Instructions for Using This Template

*This Change Request Form is used to document proposed changes to project scope, schedule, budget, quality, or other baselined project elements. Follow these steps to use this template:*

1. *The Change Requestor should complete Sections 1, 2, and 3*
2. *The Project Manager should complete Sections 4, 5, and 6*
3. *The Change Control Board reviews Sections 1-6 and completes Section 7*
4. *If approved, the Project Manager completes Sections 8 and 9 during implementation*
5. *After implementation, the Project Manager completes Section 10*
6. *The Change Control Board should review the completed change and sign off in Section 11*

*All completed Change Requests should be stored in the project repository and logged in the Change Log.*

---

## 1. Change Request Identification

### 1.1 Change Requestor Information
**Name:** *[Full Name]*  
**Role/Title:** *[Role or Title]*  
**Department/Organization:** *[Department or Organization]*  
**Email:** *[Email Address]*  
**Phone:** *[Phone Number]*  
**Date Submitted:** *[YYYY-MM-DD]*  

### 1.2 Change Request Type
*Select all that apply:*

- [ ] Scope Change
- [ ] Schedule Change
- [ ] Budget Change
- [ ] Quality/Requirements Change
- [ ] Resource Change
- [ ] Contract Change
- [ ] Process Change
- [ ] Technology Change
- [ ] Documentation Change
- [ ] Other: *[Specify]*

### 1.3 Change Request Priority
*Select one:*

- [ ] Critical (Must implement immediately)
- [ ] High (Required for project success)
- [ ] Medium (Enhances project outcomes)
- [ ] Low (Desirable but not essential)

---

## 2. Change Description and Justification

### 2.1 Change Description
*Provide a clear, concise description of the proposed change. Be specific about what is changing from the current baseline.*

*Example: Add a mobile-responsive user interface to the customer portal module. The current approved scope includes only desktop browser compatibility, but this change would add full functionality for mobile devices (iOS and Android).*

### 2.2 Change Justification
*Explain why this change is needed. Reference business requirements, issues, or opportunities that this change addresses.*

*Example: Customer analytics show that 45% of users attempt to access the portal via mobile devices, but the current design doesn't support mobile browsers. This change would improve customer satisfaction and increase portal usage, directly supporting our strategic goal of improving digital customer engagement.*

### 2.3 Business Case
*Provide a business case for the change, including benefits, costs, and return on investment.*

**Benefits:**  
*Example:*
* *Increase customer engagement by estimated 30%*
* *Reduce customer support calls related to mobile access by estimated 25%*
* *Generate additional revenue of approximately $100,000 per year through increased mobile transactions*
* *Improve customer satisfaction ratings by estimated 15%*

**Costs:**  
*Example:*
* *Additional development effort: 120 person-hours at $75/hour = $9,000*
* *Additional testing effort: 40 person-hours at $60/hour = $2,400*
* *Additional documentation updates: 20 person-hours at $50/hour = $1,000*
* *Total estimated cost: $12,400*

**Return on Investment:**  
*Example: Estimated ROI of 706% in first year ($100,000 benefit vs. $12,400 cost), with ongoing benefits in subsequent years.*

### 2.4 Consequences of Not Implementing
*Describe what will happen if this change is not implemented.*

*Example: Without mobile compatibility, we will continue to see low engagement from mobile users, resulting in continued customer dissatisfaction and lost revenue opportunities. Competitors who offer mobile access will have a competitive advantage, potentially leading to customer attrition.*

---

## 3. Supporting Documentation

### 3.1 Attachments
*List any supporting documents attached to this change request.*

*Example:*
1. *Mobile usage analytics report*
2. *Competitor analysis*
3. *Customer feedback survey results*
4. *Technical feasibility assessment*
5. *Detailed cost estimates*

### 3.2 Related Project Documents
*Reference any project documents related to this change request.*

*Example:*
* *Requirements Document v2.1, Section 3.4 - User Interface Requirements*
* *Project Management Plan v1.2, Section 4.3 - Scope Management Approach*
* *Risk Register, Risk #R-005 - Customer Adoption Risk*
* *Architecture Design Document v1.0, Section 5.2 - Technical Architecture*

---

## 4. Impact Analysis

### 4.1 Scope Impact
*Describe how this change impacts the project scope. Reference specific WBS elements or deliverables affected.*

*Example: This change affects WBS element 2.3 (Customer Portal Development) and will require modifications to deliverables 2.3.2 (User Interface Design) and 2.3.4 (Portal Testing). The functional requirements document will need to be updated to include mobile-specific requirements.*

### 4.2 Schedule Impact
*Describe how this change impacts the project schedule. Include specific activities affected, duration changes, and impact on milestones or critical path.*

*Example: This change will add an estimated 3 weeks to the development phase. The following activities will be affected:*
* *Activity 2.3.2.1 (UI Design): +5 days*
* *Activity 2.3.3.2 (UI Development): +10 days*
* *Activity 2.3.4.1 (Portal Testing): +6 days*

*Critical path will be affected, delaying the "Portal Ready for UAT" milestone by 3 weeks (from YYYY-MM-DD to YYYY-MM-DD).*

### 4.3 Cost Impact
*Describe how this change impacts the project budget. Include detailed cost breakdown.*

*Example: This change will increase the project budget by $12,400 (3.1% of total project budget), broken down as follows:*
* *Additional development labor: $9,000*
* *Additional testing labor: $2,400*
* *Additional documentation updates: $1,000*

*Current approved budget: $400,000*
*New budget if change approved: $412,400*

### 4.4 Quality Impact
*Describe how this change impacts product or project quality. Include any changes to quality requirements, standards, or testing processes.*

*Example: This change requires:*
* *Additional quality standards for mobile interface compliance*
* *Cross-browser and cross-device compatibility testing*
* *Performance testing on mobile networks*
* *Updates to quality metrics to include mobile-specific measures*

*Quality will be enhanced as the final product will meet a broader range of user needs.*

### 4.5 Resource Impact
*Describe how this change impacts project resources. Include changes to resource requirements, availability, or allocation.*

*Example: This change requires:*
* *UI/UX Designer: 40 additional hours over 2 weeks*
* *Front-end Developer: 80 additional hours over 4 weeks*
* *QA Tester with mobile testing experience: 40 additional hours over 2 weeks*

*Current team members can accommodate these additional hours, but it will limit their availability for other planned work.*

### 4.6 Risk Impact
*Describe new risks introduced by this change and impacts on existing risk assessments.*

*Example: New risks introduced:*
1. *Mobile framework compatibility issues could cause additional delays (Medium probability, Medium impact)*
2. *Mobile security requirements may be more complex than anticipated (Low probability, High impact)*

*Existing risks affected:*
1. *R-007 (Schedule Risk): Probability increased from Medium to High due to added complexity*
2. *R-012 (Resource Risk): Probability increased from Low to Medium due to specialized skill requirements*

### 4.7 Contract Impact
*Describe any impacts on vendor contracts or agreements.*

*Example: The current contract with the UI development vendor will need to be amended to include mobile development. Estimated contract change value: $5,000 (included in the cost impact above).*

### 4.8 Stakeholder Impact
*Describe how this change affects project stakeholders.*

*Example:*
* *Marketing team: Positive impact as they can promote new mobile capabilities*
* *Customer Support team: Initially increased training needed, but ultimately fewer support calls expected*
* *Executive Sponsor: Positive impact as change aligns with digital strategy*
* *End users: Positive impact with improved accessibility*

---

## 5. Change Evaluation

### 5.1 Change Alternatives
*Describe alternatives to the proposed change, including doing nothing.*

*Example:*
1. *Do nothing: Continue with desktop-only interface (no cost, but missed opportunity)*
2. *Simplified mobile version with reduced functionality ($7,000, but limited user experience)*
3. **Recommended** *Full mobile-responsive implementation ($12,400, comprehensive solution)*
4. *Native mobile app development ($45,000, highest quality but exceeds budget constraints)*

### 5.2 Project Manager Recommendation
*The Project Manager's recommendation regarding this change request.*

*Example: I recommend approval of this change request. The business case is strong with positive ROI, and the impact on schedule and budget can be managed within existing contingency reserves. The change aligns with project objectives and organizational strategic goals.*

### 5.3 Technical Feasibility Assessment
*Assessment of the technical feasibility of implementing the change.*

*Example: The technical team has assessed this change as feasible with moderate complexity. The current architecture can accommodate the mobile-responsive design without major restructuring. Some additional frameworks will need to be incorporated, but these are well-established and team members have relevant experience.*

---

## 6. Change Classification (For Project Manager Use)

### 6.1 Change Control Level
*Indicate the appropriate approval level based on project governance.*

- [ ] Project Manager Approval (Minor change within approved tolerances)
- [ ] Change Control Board Approval (Moderate change exceeding PM tolerances)
- [ ] Sponsor/Steering Committee Approval (Significant change to baselined elements)
- [ ] Contract Amendment Required (Change affecting contractual agreements)

### 6.2 Funding Source
*Indicate the funding source for this change if approved.*

- [ ] Project Contingency Reserve
- [ ] Management Reserve
- [ ] Additional Funding Required
- [ ] Offset by Reduction in Other Scope: *[Specify]*
- [ ] Other: *[Specify]*

---

## 7. Approval Decision (For Change Control Board Use)

### 7.1 Decision
*Select one:*

- [ ] Approved as Submitted
- [ ] Approved with Modifications (specify below)
- [ ] Rejected (provide reason below)
- [ ] Deferred (provide explanation and timeframe below)
- [ ] More Information Required (specify below)

### 7.2 Decision Notes
*Provide explanation for decision, especially if modified, rejected, deferred, or more information is required.*

*Example: Change request approved as submitted. The business case demonstrates strong ROI and strategic alignment. The Project Manager is authorized to implement this change using the project contingency reserve for the additional costs.*

### 7.3 Approval Signatures

| Name | Role | Signature | Date |
|------|------|-----------|------|
| *[John Doe]* | *[CCB Chair/Project Sponsor]* | ______________ | *[YYYY-MM-DD]* |
| *[Jane Smith]* | *[Project Manager]* | ______________ | *[YYYY-MM-DD]* |
| *[Michael Johnson]* | *[Technical Lead]* | ______________ | *[YYYY-MM-DD]* |
| *[Sarah Williams]* | *[Business Owner]* | ______________ | *[YYYY-MM-DD]* |
| *[Robert Brown]* | *[Financial Representative]* | ______________ | *[YYYY-MM-DD]* |

---

## 8. Implementation Planning (For Approved Changes)

### 8.1 Implementation Approach
*Describe how the change will be implemented, including phases or stages if applicable.*

*Example: The mobile-responsive interface will be implemented in two phases:*
1. *Phase 1: Core functionality (login, account view, basic transactions) - 2 weeks*
2. *Phase 2: Advanced features (reporting, personalization, notifications) - 1 week*

*Implementation will be integrated into the existing development sprint schedule, with dedicated resources assigned to this feature.*

### 8.2 Implementation Schedule
*Provide the schedule for implementing the change.*

*Example:*
* *Design Updates: YYYY-MM-DD to YYYY-MM-DD*
* *Development - Phase 1: YYYY-MM-DD to YYYY-MM-DD*
* *Development - Phase 2: YYYY-MM-DD to YYYY-MM-DD*
* *Testing: YYYY-MM-DD to YYYY-MM-DD*
* *Documentation Updates: YYYY-MM-DD to YYYY-MM-DD*
* *Implementation Complete: YYYY-MM-DD*

### 8.3 Implementation Resources
*List the resources needed to implement the change.*

*Example:*
* *Jane Doe - UI/UX Designer - 40 hours*
* *John Smith - Front-end Developer - 80 hours*
* *Sarah Jones - QA Tester - 40 hours*
* *Mike Johnson - Technical Writer - 20 hours*
* *Development Environment - 6 weeks*
* *Mobile Testing Devices - 2 weeks*

### 8.4 Communication Plan
*Describe how the change and its impacts will be communicated to stakeholders.*

*Example:*
* *Project Team: Detailed implementation plan shared at next team meeting (YYYY-MM-DD)*
* *Steering Committee: Change approval and impact summary at next steering committee meeting (YYYY-MM-DD)*
* *End Users: Announcement of upcoming new feature in monthly newsletter (YYYY-MM-DD)*
* *Support Team: Training session on new features (YYYY-MM-DD)*

---

## 9. Baseline Updates

### 9.1 Documents to be Updated
*List all baseline documents that require updates due to this change.*

*Example:*
* *Project Management Plan v1.2 → v1.3*
* *Project Schedule v2.4 → v2.5*
* *Project Budget v1.1 → v1.2*
* *Requirements Document v2.1 → v2.2*
* *Architecture Design Document v1.0 → v1.1*
* *Test Plan v1.0 → v1.1*

### 9.2 Update Responsibility
*Assign responsibility for each document update.*

*Example:*
* *Project Management Plan: Jane Smith (Project Manager)*
* *Project Schedule: Jane Smith (Project Manager)*
* *Project Budget: Robert Brown (Financial Analyst)*
* *Requirements Document: Michael Johnson (Business Analyst)*
* *Architecture Design Document: Sarah Williams (Technical Lead)*
* *Test Plan: David Lee (QA Lead)*

### 9.3 Update Status
*Track the status of required baseline updates.*

*Example:*
* *Project Management Plan: Completed YYYY-MM-DD*
* *Project Schedule: Completed YYYY-MM-DD*
* *Project Budget: In Progress, Due YYYY-MM-DD*
* *Requirements Document: Not Started, Due YYYY-MM-DD*
* *Architecture Design Document: Not Started, Due YYYY-MM-DD*
* *Test Plan: Not Started, Due YYYY-MM-DD*

---

## 10. Implementation Results

### 10.1 Implementation Status
*Describe the results of the change implementation.*

*Example: The mobile-responsive interface was successfully implemented according to plan. All functionality was delivered as specified, and testing confirmed compatibility across target devices and browsers. The implementation was completed on YYYY-MM-DD, which was 2 days ahead of the revised schedule. All test cases passed, and the solution has been deployed to the production environment.*

### 10.2 Implementation Metrics
*Provide metrics related to the implementation performance.*

*Example:*
* *Schedule performance: Completed 2 days ahead of schedule*
* *Budget performance: $11,500 actual cost vs. $12,400 estimated cost ($900 under budget)*
* *Quality metrics: 100% test case pass rate, 0 critical defects, 3 minor defects (all resolved)*
* *Resource utilization: Actual hours - UI/UX Designer (36 hours), Front-end Developer (78 hours), QA Tester (42 hours), Technical Writer (18 hours)*

### 10.3 Implementation Issues
*Describe any issues encountered during implementation and how they were addressed.*

*Example: Two minor implementation issues were encountered:*
1. *Mobile menu rendering inconsistently on older Android devices: Resolved by adding additional CSS fallbacks for older browsers.*
2. *Performance slowdown on initial page load: Resolved by implementing lazy loading for non-critical elements and optimizing image sizes.*

*Both issues were resolved during the implementation phase and validated in final testing.*

### 10.4 Lessons Learned
*Document lessons learned from implementing this change.*

*Example:*
* *Positive: Early involvement of mobile UX specialists resulted in a better design with fewer revisions*
* *Positive: Cross-functional implementation team improved communication and reduced handoff issues*
* *Improvement opportunity: Additional time for cross-browser testing should be included in future mobile implementations*
* *Improvement opportunity: Mobile design requirements should be considered earlier in future projects*

---

## 11. Change Closure

### 11.1 Closure Verification
*Verify that all aspects of the change have been properly completed and closed.*

*Example:*

| Closure Item | Status | Verified By | Verification Date |
|--------------|--------|-------------|-------------------|
| Implementation complete | Complete | Sarah Williams | YYYY-MM-DD |
| Testing complete | Complete | David Lee | YYYY-MM-DD |
| Documentation updated | Complete | Mike Johnson | YYYY-MM-DD |
| Baseline documents updated | Complete | Jane Smith | YYYY-MM-DD |
| Stakeholders notified | Complete | Jane Smith | YYYY-MM-DD |
| Training completed | Complete | Training Team | YYYY-MM-DD |
| Post-implementation review | Complete | Project Sponsor | YYYY-MM-DD |

### 11.2 Business Outcome Assessment
*Assess whether the change has achieved or is on track to achieve its intended business outcomes.*

*Example: Initial metrics indicate that the change has achieved its primary business objectives:*
* *Mobile user engagement increased by 35% in the first week post-implementation (exceeded target of 30%)*
* *Customer support calls related to mobile access have decreased by 20% (on track to meet target of 25%)*
* *Mobile transactions totaling $15,000 were processed in the first week (projecting to exceed annual target of $100,000)*
* *User satisfaction survey results show 4.2/5 rating for mobile functionality (exceeding target of 3.5/5)*

*Full business impact assessment will be conducted after 3 months of operation as part of the benefits realization plan.*

### 11.3 Closure Approval
*Final approval that the change has been successfully implemented and can be formally closed.*

*Example: Based on the successful implementation and initial business outcomes, this change request can be formally closed. All deliverables have been completed, tested, and accepted by the business owner. All documentation has been updated, and the change has been integrated into normal operations.*

### 11.4 Closure Signatures

| Name | Role | Signature | Date |
|------|------|-----------|------|
| *[John Doe]* | *[Project Sponsor]* | ______________ | *[YYYY-MM-DD]* |
| *[Jane Smith]* | *[Project Manager]* | ______________ | *[YYYY-MM-DD]* |
| *[Sarah Williams]* | *[Business Owner]* | ______________ | *[YYYY-MM-DD]* |
| *[Robert Brown]* | *[CCB Representative]* | ______________ | *[YYYY-MM-DD]* |

---

## 12. Change Log Entry

*This section documents the entry in the project Change Log for tracking purposes.*

| Log Date | Change ID | Description | Type | Priority | Status | Requestor | Impact Summary |
|----------|-----------|-------------|------|----------|--------|-----------|----------------|
| *YYYY-MM-DD* | *CR-001* | *Add mobile-responsive interface to customer portal* | *Scope, Schedule, Budget* | *High* | *Closed* | *Sarah Williams* | *Schedule +3 weeks, Budget +$11,500* |

---

*Tailor this worksheet to the selected organizational methodology and approval process.*