Change Mgmt study materials
Change Mgmt study resources

Change Mgmt: Change Management Knowledge (SFIA Level 3)

Change Mgmt · Work through your exam, one topic at a time.

All guide sections

Change Management Knowledge (SFIA Level 3)

What this domain tests

Domain 1 checks whether you can describe and apply the mechanics of change management at SFIA level 3 - the 'apply' level. You need the vocabulary and the end-to-end control path for a change, not just a list of approval meetings. Expect questions on change types, assessment, authorization, scheduling, implementation and review, plus the artefacts and roles that make an audit trail.

The change lifecycle

Every change, whether to a service, application, process or configuration item, should follow a controlled path:

  • Request and record: capture the request (often an RFC) with requester, description, reason and desired outcome; log it in the change record.
  • Assess: impact, risk, urgency, benefit, cost, dependencies, security and compliance, capacity and rollback. ITIL's '7 Rs' give a useful prompt: raised, reason, return, risks, resources, responsible, relationship.
  • Authorize: route to the correct change authority; record the decision and any conditions.
  • Plan and schedule: assign implementation tasks, test/validation, communications, contingency and a change window.
  • Implement and verify: deploy, test, confirm outcome and update configuration records.
  • Review and close: post-implementation review (PIR), compare actual vs planned, capture lessons and close.

Change types and roles

Three common types are standard (pre-authorized, repeatable, low risk, defined trigger), normal (assessed and approved, often through a CAB or delegated authority; can be minor or major) and emergency (expedited path for urgent risk or service restoration, with retrospective review). A CAB is advisory: it recommends, while the change authority decides. Other roles include change manager, change owner and implementer; separation of duties matters.

Worked example

A payroll team raises a change to a payroll calculation rule three days before payday. It is not standard: the rule affects pay accuracy and compliance. It is urgent, so classify it as an emergency change only if delay would cause greater harm. Assessment shows high impact, a dependency on the bank file and a need for a tested rollback. The emergency authority approves a limited change window after the current pay run, with validation by payroll and finance and a PIR within five days. The reasoning is explicit: classify by risk and timing, not by who is asking; document the expedited justification; protect the pay run.

Traps

  • Confusing change with release or deployment: change is the addition, modification or removal; release makes a version available; deployment installs it.
  • Treating every urgent request as an emergency and eroding control.
  • Using a standard change for something that is not pre-authorized or repeatable.
  • Skipping the PIR, so lessons and effectiveness are never checked.
  • Forgetting configuration baselines, so impact assessment is guesswork.