SUP.10 Change Request Management#
The purpose of the Change Request Management Process is to ensure that change requests are recorded, analyzed, tracked, approved, and implemented.
Process outcomes#
Requests for changes are recorded and identified.
Change requests are analyzed, dependencies and relationships to other change requests are identified, and the impact is estimated.
Change requests are approved before implementation and prioritized accordingly.
Bidirectional traceability is established between change requests and affected work products.
Implementation of change requests is confirmed.
Change requests are tracked to closure and status of change requests is communicated to affected parties.
Base practices#
SUP.10.BP1: Identify and record the change requests
|
status: valid
|
||||
The scope for application of change requests is identified. Each change request is uniquely identified, described, and recorded, including the initiator and reason of the change request. A status is assigned to each change request to facilitate tracking. Note Change requests may be used for changes related to e.g., product, process, methods. Note Example values for the change request status are “open”, “under investigation”, “implemented”, etc. Note The change request handling may differ across the product life cycle e.g., during prototype |
|||||
SUP.10.BP2: Analyze and assess change requests
|
status: valid
|
||||
Change requests are analyzed by relevant parties according to analysis criteria. Work products affected by the change request and dependencies to other change requests are determined. The impact of the change requests is assessed. Note Examples for analysis criteria are: resource requirements, scheduling issues, risks, benefits, etc. |
|||||
SUP.10.BP3: Approve change requests before implementation
|
status: valid
|
||||
Change requests are prioritized and approved for implementation based on analysis results and availability of resources. Note A Change Control Board (CCB) is an example mechanism used to approve change requests. Note Prioritization of change requests may be done by allocation to releases. |
|||||
SUP.10.BP4: Establish bidirectional traceability
|
status: valid
|
||||
Establish bidirectional traceability between change requests and work products affected by the change requests. In case that the change request is initiated by a problem, establish bidirectional traceability between change requests and the corresponding problem reports. |
|||||
SUP.10.BP5: Confirm the implementation of change requests
|
status: valid
|
||||
The implementation of change requests is confirmed before closure by relevant stakeholders. |
|||||
SUP.10.BP6: Track change requests to closure
|
status: valid
|
||||
Change requests are tracked to closure. The status of change requests is communicated to all affected parties.
|
|||||