A Request for Change (RFC) is a formal proposal to modify any aspect of a project that has been baselined or approved. In PRINCE2 7, the Issues Practice provides a structured approach to handling such requests throughout the project lifecycle.
When stakeholders identify a need to alter project del…A Request for Change (RFC) is a formal proposal to modify any aspect of a project that has been baselined or approved. In PRINCE2 7, the Issues Practice provides a structured approach to handling such requests throughout the project lifecycle.
When stakeholders identify a need to alter project deliverables, scope, timelines, or other controlled aspects, they submit a Request for Change. This differs from other issue types like off-specifications (which deal with deviations from agreed specifications) or problems and concerns (which address general project difficulties).
The RFC process begins when someone identifies a desired modification. This request is then captured, logged, and assessed for its potential impact on the project. The assessment examines how the proposed change would affect time, cost, quality, scope, benefits, and risks. This analysis provides decision-makers with the information needed to determine whether the change should be approved, rejected, or deferred.
Authority levels for approving changes are established during project initiation. Minor changes might be approved by the Project Manager within defined tolerances, while significant changes require escalation to the Project Board or even higher organizational levels. This hierarchy ensures appropriate governance while maintaining project momentum.
Once a decision is made, the outcome is communicated to relevant parties and documented in the Issue Register. Approved changes lead to updates in project plans, product descriptions, and other affected documentation. The change is then implemented and tracked to ensure successful integration.
Effective RFC management helps maintain project control by ensuring modifications are properly evaluated before implementation. It prevents scope creep, manages stakeholder expectations, and maintains alignment between project outputs and business needs. The formal process creates an audit trail demonstrating how and why project changes occurred, supporting transparency and accountability throughout the project journey.
Request for Change (RFC) in PRINCE2 Foundation v7 - Complete Guide
What is a Request for Change?
A Request for Change (RFC) is a formal proposal to modify any aspect of a project's baseline. It is one of the key issue types managed within the PRINCE2 Issues practice. An RFC is raised when someone wants to add, modify, or remove something that was originally agreed upon in the project, such as scope, products, timelines, or costs.
Why is Request for Change Important?
RFCs are crucial because they:
• Protect the project baseline - Changes cannot be made arbitrarily; they must go through a formal process • Enable controlled flexibility - Projects can adapt to new requirements while maintaining governance • Provide traceability - All requested changes are documented and tracked • Support informed decision-making - Impact analysis ensures stakeholders understand consequences before approving changes • Maintain accountability - Clear ownership and authorization levels are established
How Does the RFC Process Work?
The RFC process follows these steps:
1. Capture: The change request is formally recorded in the Issue Register with all relevant details including the proposed change, reasons, and who raised it.
2. Examine: The Project Manager assesses the impact of the change on time, cost, quality, scope, benefits, and risk. This analysis is documented.
3. Propose: Options are developed for how to handle the request, including implementing the change, rejecting it, or deferring it.
4. Decide: The appropriate authority makes a decision. This could be: • The Project Manager (within their change authority) • The Project Board (for larger changes) • A Change Authority (if delegated)
5. Implement: If approved, the change is incorporated into the project plans and baselines are updated accordingly.
Key Roles in Managing RFCs:
• Project Manager - Responsible for the day-to-day management of issues including RFCs • Project Board - Has ultimate authority over significant changes affecting tolerances • Change Authority - May be delegated authority to approve certain types of changes • Team Manager - May raise RFCs and implement approved changes
RFC vs Other Issue Types:
Understanding the difference is essential: • Request for Change - A proposal to change something in the baseline • Off-specification - Something that should be provided but currently is not, or will not be • Problem/Concern - Any other issue the Project Manager needs to resolve
Exam Tips: Answering Questions on Request for Change
Tip 1: Remember that RFCs are always about changes to what was originally agreed - the baseline. If a question describes something missing from the agreed specification, that is an off-specification, not an RFC.
Tip 2: Know the authorization hierarchy. The Project Board can delegate change authority, but they retain ultimate responsibility for changes that exceed tolerances.
Tip 3: Impact analysis is mandatory for RFCs. Questions may test whether you understand that all changes must be assessed before decisions are made.
Tip 4: The change budget concept is important. Organizations may set aside funds specifically for approved changes. Questions may reference this.
Tip 5: Pay attention to who raises the RFC in exam scenarios. Anyone can raise an RFC, but only authorized personnel can approve them.
Tip 6: Look for keywords in questions: 'add functionality,' 'extend scope,' 'modify requirements' typically indicate an RFC scenario.
Tip 7: Remember that approved changes update the baseline - this is a key principle that exam questions often test.
Tip 8: Configuration management links closely to RFCs. Approved changes must be reflected in configuration items and records.