TCRM Technical Change Request Management

Linked Knowledge Nuggets:
arrow_forward "When and How to use supporting processes"

person Author: Process Fellows
Supporting processes like SUP.9 (Problem Resolution) or SUP.10 (Change Request Management) are often misunderstood as “back-office.” But they’re vital for delivering quality. Make sure your teams know when to invoke them — and how to record their outcomes. A 2-minute log of a problem review can save hours of debugging.

• O1 Technical change requests are analyzed, dependencies and relationships to other technical change requests are identified, and the impact is estimated
• O2 Implementation of technical change requests is confirmed
• O3 The status of all technical change requests is known, and technical change requests are tracked to closure

BP1 Analyze and assess technical change requests. ( O1 )

Technical change requests are analyzed by relevant parties according to analysis criteria. Work products affected by the change request and dependencies on other technical change requests are determined. The impact of the technical change requests is assessed.
Note 1: Examples for analysis criteria are: resource requirements, scheduling issues, risks (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.), benefits, etc.

Linked Knowledge Nuggets:
arrow_forward "Change Requests and affected work items"

person Author: Process Fellows
Traceability between a change request and the affected work item can be established through proper analysis of the change request. The reverse traceability — from an affected work item back to the originating change request — is typically established through a change comment in the version history. This comment should include the change request ID to ensure proper linkage.

BP3 Track technical change requests to closure. ( O3 )

The status of technical change requests is known, and they are tracked to closure.

Linked Knowledge Nuggets:
arrow_forward "ALM-based dashboard for monitoring Change Requests"

person Author: Process Fellows
Defining an ALM (Application Lifecycle Management) dashboard for tracking change requests involves identifying the right metrics, data sources, and visualizations to support transparency, traceability, and decision-making. The main steps are:

• Define stakeholders for tracking and reporting
• Identify stakeholders information needs, i.e. key metrics
• Define data sources
• Design dashboard layout
• Set up alerts and filters
• Regularly review dashboard usage and feedback
• Adjust metrics and visualization to match evolving stakeholder needs