Change Management Policy

From IT frameworks

ITIL is used in order to achieve IT governance in the company. ITIL is an abbreviation for IT Infrastructure Library and is a best practice framework for organizing IT. ITIL version 3 is the most recent version.

The purpose of ITIL is to help IT deliver more efficient services to its customers and users. It helps bring more control into IT and makes it more predictable..

This policy covers all types of changes in IT in the company. Whenever anything is to be changed, this policy must be followed. There are no exceptions.

Contents 1 Priority 2 Change categories 3 Standard Change 4 Normal Change 5 Major Change 6 Emergency Change 7 Request for Change (RfC) 8 Change Advisory Board (CAB)

Priority

Changes are prioritized just like Incidents and Problems. Priority is found by adding Impact, Urgency and an SLA adjustment for the system (if applicable).

Impact scale
Value	Description
5	Critical impact on the whole company operation
4	Impact on the whole company operation or critical impact on a group
3	Mild impact on the whole company, impact on a group or critical impact on one user
2	Mild impact on a group or impact on a user
1	Mild impact on a user

Urgency scale
Value	Response time
5	Immediate (Emergency Change)
4	1 week
3	2 weeks
2	1 month
1	At convenience

Change categories

A Change may be any of four categories:

1. Standard Change
2. Normal Change
3. Major Change
4. Emergency Change

Standard Change

A Standard Change is a change that has been pre-approved by Change Management. There is an exact procedure for a Standard Change (and a Roll-Back if needed). The list of Standard Changes includes who is allowed to do the change and a reference to the procedure. A Standard Change requires no RfC (Request for Change) and thus no approval from the Change Manager or the CAB (Change Advisory Board).

The requirement for a Change to become Standard is:

• The Change is earlier approved through the normal Change Management Process
• The Change is well known and the solution is well tested
• The risk involved is small – Standard Changes are normally not made for Changes with impact 4 or 5
• If there is a real risk for the Change failing, there is also a defined Roll-Back plan
• The Change is found in the list of Standard Changes. This list may only be updated by the Change Manager. It grows as changes are done frequently and then added to the list.

Standard Changes normally have a fixed price.

Examples of Standard Changes:

• Hardware failure to be fixed by a vendor
• Adding a new user to a system
• Decommissioning of a user
• Resetting a password
• Any change that does not alter the specification of a Configuration Item (CI)
• Installation or upgrading of software (some deployments are Standard Changes, some will never enter the list due to high risk).

If a required Change is not found on the list of Standard Changes, an RfC must be submitted (unless it is an Emergency Change – see below).

Any change to a system with an impact of 3 or lower is a Standard Change, and can be executed by the System Responsible without Change authorization.

Any change to a process with an impact of 3 or lower is a Standard Change, and can be executed by the Process Owner with the authorization of the CSI Manager.

Any change to a policy with an impact of 3 or lower is a Standard Change, and can be executed by the CSI Manager without Change authorization.

All Standard Changes that are executed are notified and recorded.

Normal Change

A Normal Change is submitted to the Change Manager via an RfC. A Normal Change is defined as any Change with an impact of 3 or lower. It is approved by the Change Manager without the need of approval from the CAB.

Major Change

A Major Change is submitted as an RfC and is always taken up in the CAB. A Major Change has an impact of 4 or 5.

Emergency Change

An Emergency Change requires immediate action (Urgency = 5). It is a rush action that cannot wait for Change Manager or CAB approval. It is done there and then by the person identifying the need and who has the competence to handle the situation. After putting out the fire, a report is written detailing what was discovered and how it was handled. The report must minimally include:

• Who discovered the need for a Change
• Description of the need for Change and how it was discovered
• The justification for the Change made; Why it was classified as an Emergency Change
• What analysis was made to uncover the Impact and Urgency
• What was the possible Roll-Back
• How the Change was done
• What the Change accomplished (solution/positive effects)
• What was the negative consequences resulting from the Change

Request for Change (RfC)

An RfC minimally contains information about:

• Submitter
• Description of the required Change
• Proposed Priority (Impact + Urgency)
• Business Case for the Change, including:
  • The reason for the Change (all the good arguments for the change is to be included)
  • Estimated cost (time/money)
  • Estimated benefits (increased revenue, profit, reduced cost)
  • The budget covering the cost
  • Cost limit (discard the change if the implementation will cost more than Y money)
  • Time limit (discard the change if the implementation will take more than X time)
• Systems involved
• Potential risk and negative consequences from doing the Change
• Suggestions as to how the Change should best be done
• Roll back plan, or a reason why this is not needed
• Other information that will help the approver make a qualified decision

An RfC must in any case be approved by the system owner and the budget owner.

An incomplete RfC is always rejected with an explanation as to what is missing.

A rejection of a complete RfC must include a well formulated reply with the exact reason why it was rejected. Also include a recommendation to the user for his/her further action regarding the proposed change – i.e. there may be alternatives the submitter could explore.

Remember that the submitter (most probably) was sincere in his proposed change and that the rejection must take into account how it will be received by the submitter.

Change Advisory Board (CAB)

The CAB convenes every Wednesday after the IT Operations meeting. The permanent CAB members are:

• Change Manager (chair of the CAB)
• Continual Service Improvement Manager
• Transition Planning and Support Manager

Some CAB meetings require the attendance of other roles – such as the system owner (customer) of an upgrade to a service. Relevant system stakeholders are to attend the CAB. The Change Manager looks through the RfCs and decides who to call in for the CAB.