Change enablement and the three types of change

What change enablement covers and what it does not, the three types of change, and why the classification is about the authorisation route rather than about how big or how risky the change is.

Lesson 5 of 12 in objective 7. Seven ITIL practices in detail, part of ITIL 4 Foundation.

Three change types, sorted by how authorisation is obtained. Standard — Authorised when: Once, when the procedure was written; Risk range: Low, and assessed in advance; On the schedule when raised?: Usually as a known recurring activity. Normal — Authorised when: Each time, by the defined route; Risk range: The whole range, low to high; On the schedule when raised?: Yes — that is where it is planned. Emergency — Authorised when: Each time, but compressed; Risk range: Usually high, and urgent; On the schedule when raised?: No, typically added afterwards Standard Normal Emergency Authorised when Once, when the procedure was written Each time, by the defined route Each time, but compressed Risk range Low, and assessed in advance The whole range, low to high Usually high, and urgent On the schedule when raised? Usually as a known recurring activity Yes — that is where it is planned No, typically added afterwards
Three change types, sorted by how authorisation is obtained.

What change enablement is about, and what it is not

Change enablement covers changes to products and services and to the components that support them. The trap is a familiar-sounding neighbour: preparing PEOPLE for a new way of working — communications, training, dealing with resistance — is organisational change management, a different practice with a confusingly similar name in ordinary English.

So a programme manager who assumes change enablement will run the training and the communications plan has the wrong practice. Change enablement is about the changes themselves being assessed, authorised and scheduled; getting the organisation ready to adopt them is somebody else's job.

Two practices with similar names, split by what is being changed. Change enablement — Its subject: The changes themselves; The work it runs: Assessed, authorised, scheduled; The stem that names it: A change to a product, service or component. Organisational change management — Its subject: The people adopting them; The work it runs: Training, communications, resistance; The stem that names it: Getting people ready for a new way of working Change enablement Organisational change management Its subject The changes themselves The people adopting them The work it runs Assessed, authorised, scheduled Training, communications, resistance The stem that names it A change to a product, service or component Getting people ready for a new way of working
Two practices with similar names, split by what is being changed.

The definition of a change, which is wider than expected

A change is anything added, altered or taken away that could affect services — and it counts whether the effect is DIRECT OR INDIRECT. That reach is the examinable part. It is not limited to code and hardware; documentation, processes and supplier arrangements are all in scope when they could affect a service.

Candidates under-answer this because the everyday use of the word is narrower. If an option restricts changes to technical components, or to things that directly affect a live service, it is too narrow.

What decides whether something added, altered or taken away is a change. One test, and exactly one way out of it. The test is: Could it affect a service? (a document, a process or a supplier arrangement is as much in scope as code). It could, and the effect is direct leads to It counts as a change (the case candidates already recognise); It could, but only indirectly leads to It counts just the same (an option that demands a direct effect is too narrow); It could not affect any service leads to Not a change (the possible effect is the test, not what was touched). Could it affect a service? a document, a process or a supplier arrangement is as much in scope as code It could, and the effect is direct It could, but only indirectly It could not affect any service It counts as a change the case candidates already recognise It counts just the same an option that demands a direct effect is too narrow Not a change the possible effect is the test, not what was touched
What decides whether something added, altered or taken away is a change.

Standard, normal, emergency

A standard change is pre-authorised. The risk assessment happened once, when the procedure was written, and individual instances are carried out under that existing authorisation with no fresh approval. Provisioning a laptop for a joiner using a fully documented, well-rehearsed procedure is the textbook case: re-approving each one would defeat the entire point of the category.

A normal change is scheduled, then assessed and authorised by following a defined process, with the applicable change model determining who assesses and who authorises. The mistake to avoid is thinking normal means low-risk or medium-sized: normal changes span the whole risk range, and the model is what varies the route.

An emergency change must be implemented as soon as possible — typically to resolve an incident or apply a security fix. It is expedited, often through a smaller or separately named change authority, and it is NEVER unauthorised. Assessment and authorisation are compressed, not skipped, and an option saying an emergency change bypasses authorisation is always wrong.

Worth carrying in

Change enablement
Changes to products, services and their components. Not people-readiness.
Organizational change management
Preparing people to adopt a new way of working. A different practice.
Change
Anything added, altered or taken away that could affect services, directly or indirectly.
Standard change
Pre-authorised via the documented procedure. No separate approval per instance.
Normal change
Assessed and authorised each time by the route the change model defines. Any risk level.
Emergency change
Expedited and compressed authorisation. Never skipped.

What the exam does with this

Objective
7. Seven ITIL practices in detail
Share of the exam
47.5% (the whole objective)
Questions in this lesson
5
Signed for by a person
0

Partly checked. None of the 5 questions here has been read against the cited source by a person. 5 questions have been checked against their cited clause by an automated pass — which is not the same thing, and is not a signature.

Only questions a person has signed for are used in mock exams here. That is the whole difference between the two kinds of checking above.

How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.

Drill this lesson

A lesson is one sitting: the trainer draws a short run from these questions alone and spaces the ones you get wrong.

Practise Change enablement and the three types of change

Questions in this lesson

Practise Change enablement and the three types of change

The rest of objective 7