Change Requests
A Change Request (CR) is a formal proposal to alter a product, system, or project. It is a key component of change management, ensuring that any proposed modifications are documented, assessed for impact, and properly approved before implementation. This process helps prevent scope creep and maintains project integrity.
Mid-20th Century
3
Definitions
Project Management Context
In the context of Project Management, a Change Request (CR) is a formal proposal to alter any aspect of a project that has been formally agreed upon and baselined. This can include changes to the project's scope, schedule, budget, or deliverables.
The primary purpose of a formal CR process is to prevent scope creep—the uncontrolled expansion of project requirements. It ensures that every proposed change is documented, analyzed for its impact on resources and timelines, and formally approved or rejected by a designated authority, often a Change Control Board (CCB).
Key Concepts:
- Project Baseline: The initial approved plan for a project (scope, schedule, cost) against which performance is measured. A CR seeks to modify this baseline.
- Impact Analysis: A critical step where the project team assesses the potential consequences of the proposed change on all aspects of the project.
- Change Control Board (CCB): A group of stakeholders who review and approve or deny change requests.
Example Process:
- A stakeholder identifies a need for a change.
- A formal Change Request form is filled out, detailing the proposed change, its justification, and expected benefits.
- The project manager and team conduct an impact analysis.
- The CR and analysis are presented to the CCB.
- The CCB approves or rejects the request. If approved, the project plan is updated, and the change is implemented.
Software Development Context
Within Software Development, a Change Request refers to a formal request for a modification to a software system. This could be a bug fix, a new feature, an enhancement to an existing feature, or a change in the underlying architecture.
The handling of CRs varies significantly between development methodologies:
-
Waterfall: In traditional Waterfall models, change is discouraged after the requirements phase. A CR is a highly formal document that goes through a rigid approval process, as any change can have a significant ripple effect on the sequential phases of the project.
-
Agile: Agile methodologies are designed to embrace change. While formal CRs might be used for significant contractual changes, most modifications are handled more fluidly. A new requirement or feature idea is simply added to the product backlog as a user story. It is then prioritized by the Product Owner and can be incorporated into a future sprint. This approach allows for continuous adaptation and feedback.
IT Service Management (ITIL) Context
In IT Service Management (ITSM), particularly within the ITIL (Information Technology Infrastructure Library) framework, a Change Request is commonly known as a Request for Change (RFC). An RFC is a formal proposal for a change to be made to any IT service, configuration item, or the IT infrastructure.
The focus here is on maintaining the stability and reliability of live IT services. The process is rigorous, emphasizing risk assessment to minimize the potential for service disruption.
Types of Changes in ITIL:
- Standard Change: A low-risk, pre-authorized change that is common and follows a defined procedure (e.g., installing pre-approved software on a user's laptop).
- Normal Change: A change that is not standard and must go through the full change management process, including assessment and authorization by a Change Advisory Board (the ITIL equivalent of a CCB).
- Emergency Change: A change that must be implemented as soon as possible to resolve a major incident (e.g., applying a critical security patch). These often have an expedited approval process.
Origin & History
Etymology
The term is a compound of 'change' (from Old French 'changier', meaning 'to alter') and 'request' (from Old French 'requeste', meaning 'a demand'). Its usage in a formal sense arose from the need in structured engineering and management disciplines to create a documented, auditable trail for modifications to an approved plan or design.
Historical Context
The concept of formal **Change Requests** grew out of the large-scale engineering, military, and aerospace projects of the mid-20th century. In these complex projects, undocumented or unapproved changes often led to catastrophic failures, massive cost overruns, and significant delays. This created a need for a structured process to manage any deviation from the original plan. Project management methodologies like the Waterfall model, which became popular in the 1970s, institutionalized strict change control. The philosophy was to define all requirements upfront and minimize changes thereafter. A **Change Request** was treated as a formal, and often cumbersome, exception. Later, with the rise of the software industry, frameworks like the Information Technology Infrastructure Library (ITIL) in the 1980s formalized the process within IT operations, coining the term **Request for Change (RFC)** to emphasize risk mitigation and service stability. In the late 1990s and early 2000s, Agile methodologies emerged as a response to the rigidity of traditional models. Agile principles acknowledged that change is inevitable, especially in software development. Instead of a heavy CR process for every alteration, change is managed through an iterative process of backlog refinement and prioritization, making the system more adaptable.
Usage Examples
Before we can add the new payment gateway, the client must submit a formal Change Request detailing the new requirements.
The Change Control Board is meeting this afternoon to review all pending Change Requests and assess their impact on the project's timeline and budget.
In our ITIL-compliant environment, every modification to the production server requires an approved Request for Change (RFC) to minimize service disruption.
The developer submitted a Modification Request to update the legacy library, which is now pending security review.
Frequently Asked Questions
What is the primary purpose of a formal Change Request process?
The primary purpose of a formal Change Request process is to provide a structured and controlled way to manage alterations to a project's scope, schedule, or budget. It ensures that all proposed changes are documented, reviewed, assessed for impact, and formally approved or rejected, thereby preventing uncontrolled changes, also known as scope creep.
How does the handling of Change Requests differ between Waterfall and Agile methodologies?
In Waterfall, Change Requests are typically seen as deviations from the initial plan and go through a rigid, formal approval process, often involving a Change Control Board. The goal is to minimize changes. In Agile, change is expected. While formal CRs might be used for contract-level changes, smaller adjustments are managed flexibly by adding, removing, or reprioritizing items in the product backlog during sprint planning or backlog grooming sessions.
What is a Change Control Board (CCB)?
A Change Control Board (CCB) is a formal group of stakeholders responsible for reviewing, evaluating, approving, delaying, or rejecting Change Requests to a project. Their primary function is to assess the impact of proposed changes on the project's scope, budget, timeline, and quality before a decision is made.