Change Management Operations Flashcards

Question 1

What is change management in an IT operations context?

Accepted Answer

Change management is the set of processes used to control the lifecycle of changes to IT services and their supporting components. Its purpose is to ensure changes are documented, assessed for risk, authorized, and communicated, so disruption to live services is minimized. It balances improvement against stability.

Question 2

What counts as a change in IT service management?

Accepted Answer

A change is any addition, modification, or removal of a configuration item that could affect IT services. The broad definition matters because small edits, such as a firewall rule or a server patch, can cause outages just as large projects can. Recognizing every change lets the organization control it consistently.

Question 3

What is the difference between a standard, normal, and emergency change?

Accepted Answer

A standard change is a pre-approved, low-risk change that follows an established procedure. A normal change follows the full assessment and approval path because its risk or impact requires review. An emergency change is urgent, needed to restore service or prevent serious harm, and goes through an expedited approval path.

Question 4

Why do change records need to be tracked in a central repository?

Accepted Answer

A central repository gives everyone one authoritative view of planned, active, and completed changes. It prevents conflicting changes from being scheduled at the same time, supports audit and compliance reviews, and lets teams trace an incident back to the change that caused it. Without it, changes happen in silos.

Question 5

What does a change manager do in the change process?

Accepted Answer

The change manager owns the change management process rather than performing every technical task. This person reviews change requests for completeness, ensures risk assessments and back-out plans are present, chairs or coordinates the review board, and monitors outcomes. The role focuses on governance, coordination, and communication across teams that build and run systems.

Question 6

What is a request for change, and what core details should it contain?

Accepted Answer

A request for change, or RFC, is the formal document that proposes a change to a service or configuration item. A solid request states the reason for the change, the systems affected, the planned implementation steps, the schedule, and the back-out plan. Complete details let reviewers judge risk and approve or reject the proposal.

Question 7

Why is a back-out plan required for most changes?

Accepted Answer

A back-out plan describes how to return a system to its previous working state if a change fails or causes unexpected problems. It must be written before implementation and tested where practical. Having one reduces the time a service stays degraded and gives reviewers confidence that the team has considered what could go wrong.

Question 8

What is a change freeze, and why do organizations use one?

Accepted Answer

A change freeze is a defined period during which most or all changes to production systems are prohibited. Organizations use freezes to protect high-stakes periods, such as financial closing, peak sales events, or major holidays, when even small disruptions would be costly. Exceptions usually require explicit approval from a senior authority.

Question 9

How does a change move from idea to formal request?

Accepted Answer

A requester first identifies a need, such as a defect fix, a capacity upgrade, or a new feature. They then document the need in a formal request and submit it for triage. Intake checks that the request is complete and that it is assigned to the right owner before any assessment begins.

Question 10

Why should change requests be validated for completeness at intake?

Accepted Answer

Validating requests at intake prevents incomplete proposals from consuming the time of reviewers, who would otherwise have to send them back repeatedly. A complete intake check confirms that the description, business justification, affected services, schedule, and back-out plan are present.

Question 11

What information should a requester provide about the business justification?

Accepted Answer

The requester should explain the problem or opportunity, the business outcome sought, and the consequence of doing nothing. Clear justification lets the change authority compare the proposal against other priorities and budget. Vague statements such as the system needs updating give reviewers no basis for deciding whether the risk is worth taking.

Question 12

What is the difference between a change request and a change record?

Accepted Answer

A change request is the initial proposal submitted for consideration, while a change record is the tracked entry that follows the change through its full lifecycle. The record starts when the request is logged and continues through assessment, approval, implementation, and closure. Recording every stage keeps status visible and creates an audit trail.

Question 13

Why do organizations require a business owner to sponsor a change?

Accepted Answer

A business owner sponsors a change to confirm that the outcome matters to the organization and that the cost, disruption, and risk are accepted by someone with authority over the affected service. Technical teams can design and deliver the change, but they should not decide alone whether the business should accept its impact.

Question 14

How should duplicate or overlapping change requests be handled?

Accepted Answer

Duplicate requests should be identified and merged or linked to a single primary record so that work is not repeated and status stays accurate. Overlapping requests that touch the same configuration item should be reviewed together, because their combined effect may create risk that neither shows alone. Coordinators should notify both requesters.

Question 15

How do requesters identify the affected configuration items?

Accepted Answer

Requesters identify affected configuration items by consulting the configuration management database, which records components and their relationships to services. Starting from the service being changed, they follow dependency links to find servers, applications, databases, and network elements that could be impacted. Accurate lists show reviewers the full scope.

Question 16

Why should requests be prioritized, and what factors guide that priority?

Accepted Answer

Prioritization ensures limited review capacity and implementation windows go to the changes with the greatest business value or the most urgent need. Common factors include the severity of the problem being solved, regulatory or contractual deadlines, and dependencies on other planned work. Priority is a judgment, so it should be recorded with its rationale.

Question 17

What does a change risk assessment try to determine?

Accepted Answer

A change risk assessment estimates the likelihood that a change will cause a failure and the impact that failure would have on users, services, and data. Teams often rate each factor as low, medium, or high. The result informs the level of review, testing, and approval the change needs.

Question 18

What factors are commonly used to classify a change?

Accepted Answer

Classification commonly considers the scope of the change, the number of users or services affected, the complexity of the work, and the level of risk. These factors place the change into categories such as standard, minor, significant, or major. Consistent classification determines how much governance the change receives.

Question 19

What is the difference between impact and urgency when assigning priority?

Accepted Answer

Impact describes how many people or business functions would be affected by a change or its failure, and how severely. Urgency describes how quickly the change needs to be made. A change can be high impact but low urgency, or the reverse, so both dimensions should be considered separately before setting priority.

Question 20

What makes a change eligible to be pre-approved as a standard change?

Accepted Answer

A change qualifies for standard status when its risk is well understood and low, its steps are documented and repeatable, and its outcome is predictable. Typical examples include routine password resets or adding a user to an existing group. Eligibility should be reviewed, since routine changes can become risky over time.

Question 21

What is a risk matrix, and how is it used?

Accepted Answer

A risk matrix is a grid that plots likelihood against impact, often with three to five levels, to place a change in a risk category. The category then determines the approval path and the amount of testing required. Matrices make assessments consistent across reviewers, though they simplify reality and should be applied with judgment.

Question 22

Why is it important to consider dependencies when assessing a change?

Accepted Answer

A system rarely operates alone, so a change to one component can break others that rely on it, such as an interface, shared database, or scheduled batch job. Dependency analysis reveals these hidden links and shows which teams need to test or be notified. Ignoring dependencies often causes unexpected outages.

Question 23

How should a reviewer assess a change that has never been performed before?

Accepted Answer

Without operational history, a reviewer should rely more heavily on design review, peer input, and comparison with similar changes performed elsewhere. Testing in a non-production environment becomes more important, and the back-out plan deserves extra scrutiny. Unfamiliar changes are often classified at a higher risk level until evidence supports a lower rating.

Question 24

How does a change's risk rating influence the required testing?

Accepted Answer

Higher risk ratings typically call for more extensive testing, including functional, performance, and security checks, along with testing in a staging environment that mirrors production. Lower risk changes may need only a basic verification step. The testing expectation should be written into the change record so the implementer and reviewers share the same standard.

Question 25

What is a change advisory board, and what does it do?

Accepted Answer

A change advisory board, or CAB, is a group of stakeholders who review proposed changes, assess their risk and business impact, and recommend approval, rejection, or rework. Members usually include representatives from operations, development, security, and the business. The CAB advises the change authority and does not replace individual accountability for the outcome.

Question 26

Who has the authority to approve a normal change?

Accepted Answer

Approval authority depends on the organization's delegation matrix, which assigns sign-off rights according to change category, risk level, and affected services. A low-risk normal change may be approved by a team lead, while a high-impact change may require a service owner or the CAB. Approvers should hold enough authority to accept the consequences.

Question 27

What is a change schedule, and why must it avoid conflicts?

Accepted Answer

A change schedule lists the planned start and end times of approved changes and the systems they affect. Conflicts arise when two changes touch the same service at overlapping times, making it hard to tell which change caused an incident. Scheduling changes into separate windows keeps cause and effect clear.

Question 28

What is a freeze exception, and who should approve one?

Accepted Answer

A freeze exception is a documented, time-limited permission to make a change during a freeze period, usually because the change is urgent or the freeze itself would cause harm. Exceptions should be approved by a senior authority with knowledge of the business risk. The record should state the justification, scope, and end time.

Question 29

How should a change window be chosen for a production change?

Accepted Answer

The window should fall when user demand and business activity are lowest, while leaving enough time for implementation, verification, and rollback if needed. Teams also consider support staffing, vendor availability, and dependencies on other scheduled work. Windows are usually documented in advance so stakeholders can plan around them.

Question 30

Why should approvals be recorded with a clear decision and rationale?

Accepted Answer

A recorded decision creates an audit trail showing who approved or rejected a change, when they did so, and on what basis. Rationale helps future reviewers learn from similar proposals and supports investigations if the change later causes a problem. Approvals without reasons are hard to defend during audits or post-incident reviews.

Question 31

What should happen when an approved change is postponed or cancelled?

Accepted Answer

The change record should be updated to reflect the new status, and the schedule should be adjusted so that the reserved window is released or reassigned. Stakeholders and implementers must be notified, and any approval conditions should be reconfirmed before the rescheduled date. Resubmission may be required if the risk profile has changed.

Question 32

How does a conflict between two proposed changes get resolved?

Accepted Answer

The conflict is usually escalated to the change manager, who compares the business priority, risk, and dependencies of each proposal. The options include sequencing one change after the other, combining the work into one change, or rejecting one. The decision and its rationale should be recorded so both requesters understand the outcome.

Question 33

What happens during the implementation phase of a change?

Accepted Answer

During implementation, the assigned team carries out the steps documented in the approved change record, following the agreed schedule and any conditions set by approvers. They record actual times, deviations from the plan, and any problems encountered. Staying within the approved scope is essential, since unplanned extra work is itself a source of risk.

Question 34

Why is verification needed after a change is implemented?

Accepted Answer

Verification confirms that the change achieved its intended outcome and that the service is working as expected. Checks may include functional tests, monitoring review, and confirmation from users or business owners. A change is not complete just because the work was carried out, since it may still fail to deliver value.

Question 35

What is a post-implementation review, and when should it happen?

Accepted Answer

A post-implementation review examines whether a change met its objectives, caused any incidents, and followed the process. It usually takes place after the change has run long enough to show stable results, often within a set number of days. Findings feed back into improving future assessments and approvals.

Question 36

What is a back-out decision point, and who makes the call to roll back?

Accepted Answer

A back-out decision point is a predefined time or condition, such as an error threshold, at which the team must decide whether to continue or roll back. The implementer makes this call under the criteria in the change record. Setting the trigger in advance avoids prolonged debate during an outage.

Question 37

How should lessons learned from failed changes be used?

Accepted Answer

Lessons from failed changes should be turned into concrete updates, such as clearer templates, improved testing checklists, better dependency records, or revised standard change procedures. Each update should have an owner and a due date. Tracking whether these improvements reduce failure rates shows whether the process is actually getting better.

Question 38

What is the purpose of a change closure step?

Accepted Answer

Closure formally ends the change lifecycle once verification is complete and the outcome is recorded. It confirms that the change record has accurate actual times, the final status, any incidents linked to the change, and the verification results. Closing records promptly keeps the change history reliable for audits and future planning.

Question 39

How are emergency changes handled differently during implementation and review?

Accepted Answer

Emergency changes may be implemented before full approval, so the record is often completed afterward with the authorization and evidence that normally precede the work. A retrospective review should follow after, to confirm the fix worked and decide whether a permanent change is needed. Teams should watch for emergency changes becoming a routine shortcut.

Question 40

Why is it valuable to measure change success rates over time?

Accepted Answer

Tracking metrics such as the percentage of changes that succeed without incident, the number of emergency changes, and the rate of rollbacks reveals trends in process health. Trends show whether improvements in testing, assessment, or scheduling are working. Metrics should support learning and improvement, not be used to punish teams for taking reasonable risks.

Change Management Operations Flashcards

1Foundations of Change Management

2Intake and Change Requests

3Classification and Risk Assessment

4Approval and Scheduling

5Implementation, Verification, and Review

Learning Resources