You are here:
Change Manager Runs a Safe Change with Risk Scoring
Help a change manager assess risk, resolve scheduling conflicts and conflicts involving configuration items, and authorize a change with verifiable implementation and rollback plans.
Use Case at a Glance
Audience: Change managers responsible for evaluating, approving, scheduling, and closing IT changes
Goal: Determine whether a proposed change is safe to implement and apply controls that are proportional to its business and technical risk
Starting point: A documented change request with affected services or configuration items, an estimated implementation window, and an accountable owner
Successful outcome: The change is implemented in an appropriate window, meets its verification criteria, avoids or resolves known conflicts, and has a documented outcome and follow-up actions.
Use risk information to decide whether to proceed, revise, reschedule, or reject the request. Use the related Help topics for steps to complete the questionnaire, configure scoring, resolve conflicts, manage approvals, and close the request.
Establish a Reviewable Change
Begin with enough detail for a reviewer to evaluate the change. Confirm the purpose, scope, affected services and configuration items (CIs), implementation steps, test plan, rollback approach, owner, and estimated start and end times. Classify the request as standard, normal, or emergency according to your organization's process.
| Evidence | Change Manager Question | Decision It Supports |
|---|---|---|
| Business impact | Which service or business outcome is at risk if the implementation fails? | Set review depth, communication needs, and approval authority. |
| CI and dependency scope | Which systems, services, and users could be affected? | Identify the required reviewers, potential conflicts, and verification coverage. |
| Implementation plan | Are the steps sequenced, owned, and executable in the window? | Approve the plan or return it for revision. |
| Test plan | What evidence proves success after deployment? | Define the completion and monitoring criteria. |
| Rollback approach | Can the team restore service within the available window? | Proceed, add mitigation, or select a different implementation window. |
| Schedule | Does the proposed schedule avoid conflicts, moratoriums, and periods without adequate staffing? | Keep or reschedule the change. |
For details about change types and their intended use, see Change Request Management for IT Services. For steps to create, associate, schedule, and close change requests, see Work with Change Requests for IT Services.
Use Risk Information to Focus the Review
Two types of risk information can appear. The rules-based Change Risk Assessment uses the record attributes and questionnaire responses configured in the org. It produces a Risk Level of Low, Medium, High, or Critical and a normalized score from 1–100. Use the questions and weights configured by your admin.
Use the Risk Level and normalized score to focus the review, not to replace judgment. A higher Risk Level or score calls for stronger evidence, mitigation, review, and approval. A lower Risk Level or score doesn't make an incomplete plan or unresolved conflict safe. For details about the assessment and its workflow, see Change Risk Assessment for IT Services and Conduct Change Risk Assessment for IT Services.
For details about the calculation and thresholds, see How Risk Score Is Calculated for Change Requests. If your org uses customized assessment logic, confirm the configured behavior with your admin.
Keep the rules-based assessment separate from the optional machine learning prediction. The Change Risk Score predictive card estimates the likelihood of implementation failure on a 0–100 scale. It doesn't replace the rules-based Risk Level or write a new risk score to the change request. If both types of risk information appear, record which one informed the approval or Change Advisory Board decision.
Resolve Conflicts Before Approval
Review the affected CIs and their dependencies, and then compare the estimated implementation window with other scheduled work. If Change Request Conflict Detection is enabled, it creates conflict records when overlapping change requests affect the same configuration item during the same scheduled period. Conflict detection requires affected CIs to be associated with the change request. Separately, IT Service Calendar shows change requests, releases, and moratoriums so that the change manager can reschedule work around a freeze.
For each conflict, decide whether to reschedule the request, change its scope, coordinate the work, or document why the conflict doesn't apply. An empty conflict count doesn't mean that IT Service Calendar is clear, so review the calendar separately. Conflict detection doesn't automatically block implementation. For details about conflict criteria and available actions, see Review and Resolve Change Conflicts for IT Services.
Authorize and Run the Change
Match approval strength to the evidence and risk. Confirm that required reviewers understand the impact, mitigation, verification, rollback, and communications plan. For higher-risk work, route the request through the configured approval or Change Advisory Board process and record the decision before implementation.
During the implementation window, the change fulfiller executes the approved steps, records material deviations, tests the result, and monitors service health. If verification fails or risk exceeds the accepted boundary, stop or roll back according to the approved plan. Risk scoring doesn't automatically block implementation. The configured approval and change-management workflows enforce the decision.
For details about Change Advisory Board concepts and workflow, see Manage Change Advisory Boards for IT Services.
Verify, Learn, and Close
Before closure, compare results with the test plan, confirm service health, capture the implementation outcome, and identify remaining risk. Record the close code and summary, update related documentation, and assign corrective work when implementation was partial or unsuccessful.
Conduct a post-implementation review when the process or risk warrants it. Compare the expected impact and risk with the actual result, and use what you learn to improve templates, assessment responses, implementation practices, or rollback plans. This journey is successful when the decision and outcome are traceable, not merely when the risk questionnaire is complete.
Confirm That Change Controls Are Ready
Before using this journey to assess adoption, confirm that Change Request Management, risk assessment, stage management, Change Request Conflict Detection, IT Service Calendar access, and required approvals are configured for your change process. Confirm that affected CIs are associated with change requests when conflict detection is used, and verify that change managers, fulfillers, assessors, and approvers have the required permissions.
