Change Management Process Itil

Document Sample
Change Management Process Itil Powered By Docstoc
					              Process, Policy and Procedure
                     Documentation




                            Change Management


                                           Version 1.3




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc      Page 1 of 65
Preamble
This document outlines examples of the policies, processes and procedures you need to have in
place to implement Change Management in your organisation. It not only covers the process as
recommended by ITIL but information your support system provider will need and information
your people will need.

It is the combination of people, processes and technology that will get you over the line in the
end not just processes alone!

To make this document complete in terms of how work would flow into and out of Change
Management we have covered some areas of other ITIL processes. Mainly:

                       Problem
                       Release & Deployment
                       Service Level Management


The idea behind the document is that you take the work commenced here and amend it to suit the
unique requirements of your organisation. ITIL is a framework and open to interpretation so if it
makes sense for you to do something differently to what we have outlined here then feel free to
do so.

Once you have updated the document, your support system provider can use it to configure the
system to underpin your processes. Your staff can also use it to understand how the process will
work in your environment and how it will be monitored and reported against - it defines the
goalposts. Why not involve staff in the job of amending this document to suit your environment -
after all, involvement breeds acceptance.

Good luck on the journey and don‟t forget that if you want buy in from your people you need to
communicate, communicate, communicate, every step of the way!




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc       Page 2 of 65
                 Implementing Change Management
Steps to Implementation
Step 1
Gain Senior Management approval/buy in for the implementation. If this is not forthcoming, it is
going to be extremely hard (almost to the point of not worth trying) to implement.
Step 2
Appoint a Process Owner, Process Manager & CAB Members. These may or may not be full
time positions depending on the size of the organisation. Sample role statements for these
positions may be found in the documentation.
Step 3
Commence a staff awareness campaign (remember – communicate, communicate,
communicate). Ensure all IT staff are ITIL trained and knowledgeable. A big enabler in
implementing ITIL processes is having a common understanding amongst staff of the
terminology used and the relationships between processes.

ITIL Foundation certification has advantages but is not mandatory – there are many ITIL
awareness programmes available that would suffice.
Step 4
Document your policies, processes & procedures – use this document as a template.
Step 5
Define the roles and responsibilities for all parties involved so they are clear on what it is they
need to do. Sample Role Statements are included in this document.
Step 6
Workshop the documentation with the Change Management Team and the CAB until consensus
is reached.
Step 7
Configure your support system to underpin the processes as outlined in your documentation and
define your reports.
Step 8
Decide on a launch strategy – should it be overt or covert
Step 9
If overt, communicate to the stakeholders
         awareness campaigns
         email
         newsletters
         through team meetings
         focus on individual teams needs
Step 10
Go live!



668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc      Page 3 of 65
Document Control
Document Versions
             Date             Version             Person                Brief Summary of Change
                                                 Changing
          26/05/08                1.0           Iain Maitland               Document Commenced
          29/11/08                1.1           Iain Maitland                  Update to ITIL v3
          02/02/09                1.2           Iain Maitland              CAB Agenda & Steps to
                                                                           Implementation Added
          13/02/09                1.3           Iain Maitland          Final read - slight adjustments and
                                                                            amendments throughout




Document Location
The document is located at: H:\ITIL Process Docs


Document Approval
  Authorising Officer                         Name                       Signature/s                 Date
       Process Owner                       Iain Maitland


      Change Manager                        Dave Tice


     Document Owner                     Adam McMahon




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc                Page 4 of 65
Table of Contents
Document Control ............................................................................................................... 4
Table of Contents ................................................................................................................. 5
Change Management Scope ................................................................................................ 6
 Basic Change Management Process as Defined by ITIL ................................................... 8
 Change Management at HDAA ......................................................................................... 9
 Change Management Process Description (HDAA) .......................................................... 10
Inputs & Outputs of Change Management ....................................................................... 11
Change Management Policies ............................................................................................. 12
 Policy Statements ............................................................................................................... 13
Change Risk Assessment ..................................................................................................... 20
Change Categorisation Matrix ........................................................................................... 22
Pre-approved Standard Changes ....................................................................................... 23
Minor Changes – Authorised by Change Manager .......................................................... 24
CAB Membership ................................................................................................................ 25
Emergency CAB Membership ............................................................................................ 26
CAB Approvals .................................................................................................................... 27
Change Status....................................................................................................................... 28
Change Resolution Codes.................................................................................................... 29
Change Procedural Documentation ................................................................................... 30
 Change Procedures Flowchart ............................................................................................ 31
 Change Procedures Flowchart Description ........................................................................ 32
 1.0 Raise and Record an RFC ............................................................................................ 33
 2.0 Change Assessment Procedure ..................................................................................... 36
 3.0 Standard Change Procedure ......................................................................................... 37
 4.0 Urgent Change Procedure ............................................................................................ 38
 5.0 Change Approval .......................................................................................................... 41
 6.0 Change Development ................................................................................................... 43
 7.0 Change Review............................................................................................................. 45
 8.0 Change Closure ............................................................................................................ 47
 Change Management Responsibilities - RACI Matrix....................................................... 48
Change Management: Critical Success Factors & Key Performance Indicators .......... 49
 Change Management - Critical Success Factors (CSF‟s) .................................................. 50
 Change Management - Key Performance Indicators (KPI‟s) ............................................ 51
Change Management Reporting ........................................................................................ 54
Change Management Roles ................................................................................................ 56
 Process Owner (IT Director) .............................................................................................. 57
 Change Advisory Board (CAB) Member ........................................................................... 59
 Change Manager (IT Manager) .......................................................................................... 60
 Change Initiator .................................................................................................................. 62
 Change Implementer .......................................................................................................... 63
Change Management - Customer Satisfaction Measurement ......................................... 64
Change Advisory Board Agenda ........................................................................................ 64

668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc                         Page 5 of 65
Change Management Scope
This document seeks to provide standardised methods and procedures to meet the change
management requirements supporting HDAA‟s operations. The business processes outlined in
this document meet industry best practice as defined by the IT Infrastructure Library (ITIL) as
customised to comply with HDAA‟s unique circumstances.
‘Change’ can be broadly defined as the process of requesting, analysing, approving, developing,
implementing and reviewing a planned or unplanned change within the IT infrastructure. The
process begins with the completion of a Request for Change (RFC) either manually or through
the Support System. It ends with the satisfactory implementation of the change and the
communication of that change to all interested parties.
Some Changes arise as a result of Problems, but many Changes can come from proactively
seeking business benefits such as reducing costs or improving services. The goal of the Change
Management process is to ensure that standardised methods and procedures are used for efficient
and prompt handling of all Changes, in order to minimise the impact of Change-related Incidents
upon service quality, and consequently to improve the day-to-day operations of the organisation.
The purpose of Change Management is to ensure that all changes are controlled, including the
submission, analysis, decision-making, approval, implementation and post implementation of the
change.
At HDAA, Changes that arise as a result of a problem will primarily be initiated by a support
specialist while Changes that are requested by the HDAA business units will be reported to the
Service Desk for an RFC to be raised through the support system. Alternatively, business driven
change can be requested through the support system web portal.
This document covers the daily operational aspects of Change Management. It defines process
flow, policy, KPI‟s and work procedures. It also identifies reporting requirements and the HDAA
roles and responsibilities for the process.

Related Processes
                       Problem Management
                       Configuration Management
                       Release Management
Ownership
                       The IT Director is the Process Owner
                       The IT Operations Manager is the Change Manager
                       All IT Team Leaders are responsible for ensuring the Change Management
                        Process is followed in their respective areas of responsibility.

Distribution
                       All IT staff members
                       Business System Owners
                       CAB Members




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc         Page 6 of 65
In this document we have used the term “Service Desk Analyst” to represent the first level
support staff and the term “Support Specialist” to represent staff providing higher levels of
support outside of the Service Desk (2nd level, 3rd level etc.)


Value to the Business of Change Management

Reliability and business continuity are essential for the success and survival of any organisation.
Service and infrastructure changes can have a negative impact on the business through service
disruption and delay in identifying business requirements, but Change Management enables the
service provider to add value to the business by:

           Prioritising and responding to business and customer change proposals
           Implementing changes that meet the customers‟ agreed service requirements while
            optimising costs
           Contributing to meet governance, legal, contractual and regulatory requirements
           Reducing failed changes and therefore service disruption, defects and re-work
           Delivering change promptly to meet business timescales
           Tracking changes through the service lifecycle and to the assets of its customers
           Contributing to better estimations of the quality, time and cost of change
           Assessing the risks associated with the transition of services (introduction or disposal)
           Aiding productivity of staff through minimising disruptions due to high levels of
            unplanned or „emergency‟ change and hence maximising service availability
           Reducing the Mean Time to Restore Service (MTRS), via quicker and more successful
            implementation of corrective changes
           Liaising with the business change process to identify opportunities for business
            improvement.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc       Page 7 of 65
Basic Change Management Process as Defined by ITIL




                                               Change
                                               Required




                                            Raise & Record
                                            Change Request




                                            Assess Change




                                            Approve/Reject
                                               Change




                                           Coordinate Change
                                            Implementation




                                            Review Change




                                             Close Change




                                                 End




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc         Page 8 of 65
Change Management at HDAA



                                                              A Change is
                                                               Required




                                                        1.0 Raise & Record RFC


                                                       A change is initiated when a
                                                      Request For Change (RFC) is
                                                      logged in the Support System




                                                        2.0 Change Assessment


                                                         The RFC is filtered and if
                                                       approved then prioritised and
                                                              categorised




                                                                                               3.0 Standard Change
                                                            Is it a Standard
                                                                                        Yes     These changes have prior
                                                                Change?
                                                                                                   approval and can be
                                                                                              implemented without invoking
                                                                                                 the full Change process

                                                                   No
                   4.0 Urgent Change

                 The ECAB will approve an
                   Urgent Change in most
                                                             Is it an Urgent
                  instances. Where this is      Yes
                 impractical, the IT Director                   Change?
                 (or Change Manager in his
                 absence) can authorise the
                          change
                                                                   No

                                                          5.0 Change Approval
                                                          The appropriate CAB
                                                        members will review and
                                                      approve the change. However,
                                                          minor changes can be
                                                        approved by the relevant
                                                           Change Manager.




                                                       6.0 Change Implementation


                                                        The change is built and then
                                                       implemented through release
                                                       and deployment according to
                                                                the RFC




                                                        7.0 Post Implementation
                                                                 Review


                                                      All Changes will undergo a Post
                                                       Implementation Review by the
                                                             relevant authority




                                                           8.0 Change Closure


                                                       Update the Change Record
                                                      within the support system, file
                                                      supporting documentation and
                                                                   close




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc                         Page 9 of 65
Change Management Process Description (HDAA)
       Activity                                                    Description
1.0 Raise and                 Change Management is initiated when a Request For Change (RFC) is
Record RFC                    logged in the Support system. The RFC may be logged by the customer
                              through the web portal or may be raised by an IT staff member.

2.0 Change                    The RFC is filtered (accepted yes/no), assessed for risk, prioritised
Assessment                    (Emergency, High, Medium, Low) and categorised (Standard, Minor,
                              Significant, Major or Urgent) by the applicable Change Facilitator. The
                              RFC may need to be referred to the Business representative or an IT staff
                              member for more information before progressing.

3.0 Standard Change Standard Change Procedures are procedures that have the official, prior
                    approval of the Change Advisory Board (CAB). They may therefore be
                    implemented immediately, without the need for any further assessment or
                    approval. See Standard Change Table

4.0 Urgent Change             Follow the Urgent Change Procedure. The Emergency Change Advisory
                              Board (ECAB) will approve urgent Changes.

5.0 Change                    All changes require the appropriate level of approval (based on the
Approval                      priority and category) before they are entered into the Forward Schedule
                              Of Change (FSC). The CAB is the primary body charged with
                              responsibility for change control, however the Change Manager is
                              authorised to approve Minor Changes without reference to the CAB.

                              Standard changes are changes that have prior approval from the CAB and
                              can be implemented without further approval.

                              The relevant CAB members will approve all changes categorised as
                              significant or major:
                              Change approval will be automated through the Support System.

6.0 Change                    The change is built and then moves for implementation to the Release and
Implementation                Deployment process in accordance with the RFC and any special
                              instructions applicable to the change.

7.0 Change Review             Prior to closure, the relevant authorised officers will review all Changes.

8.0 Change Closure            Update the Change Record within the Support System, file all supporting
                              documentation and close the RFC.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc           Page 10 of 65
Inputs & Outputs of Change Management

Scope
This section lists all the relevant inputs and outputs to the process.


Inputs
                                                 Process Inputs
           Requests for Change (RFC‟s)
           CMDB Information (Change impact analysis on CI‟s)



Outputs
            Output Objective                                         Description
           Closed Changes                  These are the Changes that have been formally closed
                                           following implementation & review.

           Forward Schedule of             Information on when changes are to be implemented
           Changes (FSC)                   will be held in the FSC

           CAB minutes and                 Documented outcomes from CAB meetings
           actions

           Change Management               Regular reports outlining performance for Change
           Reports                         Management

           Failed Changes                  Should a failed change require further analysis and
                                           investigation; a new Request For Change will be raised
                                           in the Support System so the work can be recorded and
                                           allocated




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc             Page 11 of 65
Change Management Policies

Scope
This section contains all the policy statements that form the foundation of the Change
Management Process.
Each policy is described in terms of:
                       Policy statement
                       Reason for policy




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc    Page 12 of 65
Policy Statements

Change Management Process Policy
                       Title                                           Policy
               Policy Statement             One IT Change Management Process will be utilised
                                                          throughout HDAA.
                                                   The IT Change Management Process will seek to
                                                     implement best practice as defined by the IT
                                                    Infrastructure Library (ITIL) as customised to
                                                               HDAA‟s circumstances.
               Reason for Policy              To ensure consistency and quality of IT services
                                             delivered to customers, while minimising change-
                                           related incidents/problems and change related service
                                                               unavailability.




Process Owner Authority Policy

                      Title                                            Policy
               Policy Statement                The Change Management Process Owner (IT
                                           Director) will be accountable for the entire IT Change
                                              Management Process within HDAA and has the
                                                                authority to:
                                                  Develop policies and procedures pertaining to the
                                                                       process
                                                   Appoint staff to any position within the process
                                                   In conjunction with the CAB members, hold the
                                                        right to veto any decisions made by other
                                                                 participants in the process
                                                          Enforce compliance with the process
              Reason for Policy             Provides a single point of accountability for the IT
                                              Change Management Process across HDAA.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc              Page 13 of 65
Change Compliance Policy
                       Title                                                 Policy
                Policy Statement                All employees will comply with the policies and
                                               procedures developed by the Change Management
                                                     Process as contained in this document.
                                                Any exceptions require approval by the Change
                                                              Advisory Board.
               Reason for Policy           Provides a consistent set of processes and procedures
                                            required to minimise the impact of change-related
                                              incidents and improve day-to-day operations.

Urgent Change Policy
                       Title                                                 Policy
                Policy Statement                       A change is categorised as „Urgent‟ if:
                                                                It is prioritised as an emergency
                                                                   Is unplanned and unforseen
                                                   Is necessary to resolve or prevent a Priority 1 or
                                                                  2 incident/problem; or
                                                    Is necessary to prevent disruption (or further
                                                    disruption) to the production environment; or
                                                   Has been previously deemed as „Urgent‟ by the
                                                          Change Advisory Board (CAB)
               Reason for Policy           To enable Change Management to deal with Urgent
                                           Changes quickly without having to sacrifice normal
                                                        management controls.

Standard Pre-approved Change Policy
                       Title                                                 Policy
                Policy Statement                                      Standard Changes are:
                                                    documented, common changes that follow an
                                                               established path; and
                                                               have prior approval from the CAB
                                            RFC‟s are required to be logged and assigned, and
                                              can then be carried out in accordance with the
                                           approved Standard Change Procedure (see Approved
                                                           Standard Changes)
               Reason for Policy            To prevent the Change Management Process from
                                              being bogged down in common or reoccurring
                                           changes, without having to sacrifice change controls.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc              Page 14 of 65
Change Advisory Board Policy
                      Title                                                        Policy
              Policy Statement              The ‘Change Advisory Board (CAB)’ members are
                                             charged with the primary responsibility to approve
                                                                 changes.
                                            Change approval can be granted electronically via the
                                           Support System thus allowing formal face-to-face CAB
                                           meetings to be kept to a minimum. CAB meetings will
                                                           be scheduled monthly.
                                                       CAB members will be appointed by the various
                                                       Business Owners and the Process Owner (IT
                                                         Director). Core members will consist of:
                                                                     Business System Representatives
                                                                          IT Director (process owner)
                                                                         IT Manager (process manager)
                                                                         Business Unit Representatives
                                                           IT Team Leader as required (normally the
                                                                   Technical System Owner)
                                                            The CAB‟s core responsibilities are to:
                                                       Assess RFC‟s referred to the CAB for approval
                                                      Review and document Standard Change types for
                                                                       pre-approval
                                                  Periodically review the effectiveness of the Change
                                                   Management Process and identify opportunities for
                                                                      improvement
                                                      All CAB meetings are to be minuted and records
                                                         maintained for a minimum period of 3 years
             Reason for Policy                         Provides the standards required for the Change
                                                             Advisory Board (CAB) function.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc                    Page 15 of 65
Change Prioritisation Policy
                      Title                                         Policy
               Policy Statement                  Every RFC will be allocated a priority that will
                                                  determine the speed at which it is approved and
                                                 deployed. The criteria used will be the urgency of
                                                   the need for a solution along with the business
                                                      impact of not implementing the change.
                                            The Change Requestor may choose an initial priority
                                           but Change Management is ultimately responsible for
                                           assigning this priority. The priority of the RFC ideally
                                             should be decided in collaboration with the initiator
                                             and, if necessary, with the Change Advisory Board
                                            (CAB); but it should not be left to the initiator alone,
                                            as a higher priority than is really justified may result.
                                            All RFC‟s submitted at HDAA will have a priority
                                             assigned in accordance with the Change Priority
                                                                 Matrix.

              Reason for Policy            To establish common guidelines and standards for the
                                             prioritisation of any Request for Change (RFC).

Change Categorisation Policy
                       Title                                         Policy
               Policy Statement               Every RFC will be categorised according to the
                                            change complexity and resources required, including
                                              people, money and time to complete the change.
                                                 The change category will determine the level of
                                                      authorisation required for a change.
                                            All RFC‟s submitted at HDAA will have a category
                                                 assigned in accordance with the Change
                                                         Categorisation Matrix.
               Reason for Policy           To establish common guidelines and standards for the
                                             categorisation of any Request for Change (RFC).

Change Approval Policy
                       Title                                        Policy
               Policy Statement                All Changes will be approved by the relevant
                                            approval officer/s electronically through the Support
                                              System. Change approval is based on the change
                                                            category as follows:
                                            Standard Changes – are documented changes that
                                                     are pre-approved by the CAB.
                                            Minor Changes - may be approved by the Change
                                                             Manager.


668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc            Page 16 of 65
                       Title                                              Policy
                                               Significant and Major Changes - under normal
                                             circumstances, these will be approved electronically
                                                by the relevant Change Advisory Board (CAB)
                                                                  member/s.
                                                        Urgent Changes – authorised by the ECAB
                                                                       members
              Reason for Policy                     Ensures that the authority required to perform a
                                                     change is understood by the relevant parties.

Change Communication Policy
                      Title                                               Policy
              Policy Statement                Changes that are under the control of Change
                                            Management will be communicated to the necessary
                                                       customers as appropriate.
             Reason for Policy                To ensure that all planned changes have been
                                           communicated to the customers that may be impacted
                                                              by the change

Failed Change Policy
                      Title                                               Policy
              Policy Statement              Failure of a Change is deemed as such if the results of
                                           the change are not successful and the Change Manager
                                               determines it has failed after consulting with the
                                                Change Initiator and the Change Implementer.
                                           A failed change may result from any of the following:
                                                   One or more incidents reported subsequent to the
                                                                        change
                                                       The change must be backed out for any reason
                                                       The change was not implemented according to
                                                                         schedule
             Reason for Policy             To minimise failed changes and any related impacts to
                                                               the business

Change Testing Policy
                      Title                                               Policy
              Policy Statement              Any Request For Change (RFC) requires successful
                                             completion of testing before being released to the
                                                        production environment.
             Reason for Policy               Ensures that any changes are tested prior to being
                                                                 released.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc                  Page 17 of 65
Testing Exceptions in Urgent Change Process Policy
                       Title                                      Policy
               Policy Statement            Any Request For Change (RFC) requires successful
                                            completion of testing before being released to the
                                           production environment. The exception to this is an
                                           Urgent change, where the nature of the change is so
                                             critical that testing will delay the process. In this
                                             instance the ECAB can approve an exception to
                                                                 normal testing
               Reason for Policy             Ensures that any Urgent change not tested has the
                                                            required approval.




Forward Schedule of Changes Policy
                       Title                                      Policy
               Policy Statement               A Forward Schedule of Changes (FSC) will be
                                             maintained within the Support System at HDAA.
                                           The FSC contains details of all the Changes approved
                                                 for implementation and their proposed
                                                         implementation dates.
                                             The implementation date will be agreed with the
                                           customer and their business unit. Once agreed, the IT
                                                Service Desk will communicate to the user
                                           community at large any planned additional downtime
                                            arising from implementing the Changes, using the
                                                     most effective methods available.
               Reason for Policy            Communicate planned changes, identify potential
                                              change conflicts, impact and risk analysis.




Reporting Policy
                       Title                                       Policy
                Policy Statement                Change Management metrics and management
                                              reports will be regularly reviewed and provided to
                                            the CAB, Management and Customers in accordance
                                                  with outlined procedures and agreements.
               Reason for Policy              Assessing the efficiency and effectiveness of the
                                                       Change Management process




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc         Page 18 of 65
Post Implementation Review (PIR) Policy
                       Title                                      Policy
                Policy Statement              A Post Implementation Review (PIR) will be
                                            conducted for each change undertaken at HDAA.
                                           The PIR process is designed to collect and utilise the
                                               knowledge learned throughout the change to
                                           optimise the delivery and outputs of future changes.
                                           The review will be conducted at the weekly IT Team
                                           Leaders meeting and the content will vary depending
                                                 on the success factor for the change, any
                                           incidents/problems that may have been encountered
                                              because of the change, and the category of the
                                                                  change.
               Reason for Policy            To gain information and understanding with which
                                                to improve based on reviewing changes. A
                                           successfully completed Post Implementation Review
                                               (PIR) will be used in process evaluation and
                                                     continuous process improvement.




Change Management Policy – Process Review Policy
                       Title                                      Policy
                Policy Statement            At the Process Owner‟s discretion, regular reviews
                                             will be conducted. The reviews will focus on the
                                           process consistency and repeatability as well as Key
                                                      Performance Indicators (KPI‟s).
                                             Results are communicated with the Change
                                           Managers, Change Coordinators, Change Advisory
                                             Board (CAB) members, and management as
                                                            appropriate
               Reason for Policy               Maximise process benefits and reduce costs.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc        Page 19 of 65
Change Risk Assessment

All change requests should undergo a risk assessment before being submitted. The focus should
be on identifying the factors that may disrupt the business, impede the delivery of service
warranties or impact corporate objectives and policies. The relevant risk is the risk to the
business service. Changes require thorough assessment, wide communication and appropriate
authorisation by the person accountable for that business service.

Each change should be assessed in terms of:
            the likelihood that the risk(s) will occur (probability)
            the consequence to HDAA should the risk(s) occur (impact)


The following matrix will be used to enable requesters to determine a risk category when raising
a Request for Change (RFC).




                                               Change Impact/Risk Categorisation Matrix
                                           High Impact               High Impact
                                           Low Probability                High Probability
                                           Risk Category: 2               Risk Category: 1
                  Change Impact            Low Impact                     Low Impact
                                           Low Probability                High Probability
                                           Risk Category: 4               Risk Category: 3

                                                                  Probability




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc              Page 20 of 65
Change Priority Matrix
In the change management process, the priority (or urgency) is determined by how quickly a
change is required.
One of the following priority codes will be allocated within the support system to every RFC -
the priority field will be a mandatory field within the system:


                                                Change Priorities

             Priority                                         Priority Definition

             Emergency                     A change that, if not implemented immediately, may
                                              put life at risk or may leave HDAA open to an
                                           unacceptable risk - for example, applying a security
                                                 patch or urgent virus definition upgrade.

             High                          A change that is important and must be implemented
                                             asap - for example, an upgrade in line with new
                                                         legislation requirements.

             Medium                         A change that should be implemented soon to gain
                                              benefit from a changed service - for example,
                                                 between version upgrades to a service.

             Low                                A change that is not pressing but would be
                                           advantageous - for example, a “nice to have” addition
                                                          to a system or service.

Change Service Levels
The following table sets out the service level targets applicable for each change priority type:


                                                  Service Level

                      Priority                     Target                      Target
                                               Implementation              Implementation
                                                Time (Hours)              Success Rate (%)
                   Emergency                             8                          90
                        High                            16                          90
                      Medium                            80                          80
                         Low                           120                          80




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc              Page 21 of 65
Change Categorisation Matrix

Scope
The change priority (see priority matrix) indicates how quickly a change should be implemented.
The change category is a measure of the size of the change‟s impact on users, the business, or the
IT infrastructure. For example, does the change affect one user, a department, or every user
within the organisation? Does the change involve updating a single switch, or is it a complete
overhaul of the network? The answers to such questions determine the category of the change.
Categorisation will be used to determine the level of authorisation required for a change.
The Change category field within the Support System will be mandatory and all Changes will be
categorised as one of the following:



                                             Change Categories

    Category                           Category Definition                      Approval

   Urgent             To be used in conjunction with a change that has   Emergency Change
                      an Emergency priority only and will follow the     Advisory Board (ECAB).
                      urgent change procedure.

   Major              Will have impact on a very high percentage of      Change Advisory Board or
                      HDAA users or a business-critical system. The      HDAA Board of Directors
                      change may be new technology or a
                      configuration change and would likely involve
                      downtime of the network or a service.

   Significant        Affects a relatively high percentage of users. The Change Advisory Board
                      change is a non-standard change, such as a new
                      product or network changes, and may involve
                      downtime of the network or a service.

   Minor              Affects a small percentage of users and risk is    Change Manager
                      less because of IT‟s experience level with the
                      proposed change.

   Standard           Affects the smallest percentage of users and has   Pre Approved by CAB
                      a set release process.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc          Page 22 of 65
Pre-approved Standard Changes

Scope
Changes that are categorised as „Standard‟ are pre approved by the Change Advisory Board.
The following table outlines those changes that have been pre-approved for inclusion as a
standard change:




                        Standard Change Category (Changes Pre-Approved)

        Service Area                          Device                       Type of Change

   LAN                             Patch Panel                    Port patching for configuring devices
                                                                  to relevant LAN outlets.

   LAN                             Hub / Switch                   Port Changes

   Hardware                        PC                             Replace monitor, mouse, keyboard,
                                                                  cd, dvd.

   Server Support                  Server                         Replace hot swappable drive

   Applications Support Software                                  Reinstall on PC

   Telephony                       Telephone System               Voice Mail Messages

   On-line Services                Internet                       Reboot modem




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc          Page 23 of 65
Minor Changes – Authorised by Change Manager

Scope
The Change Manager within IT Services can approve changes that are categorised as „Minor‟.
The following table outlines those changes that are included in this category.



                        Minor Change Category (Change Manager Approved)

        Service Area                          Device                       Type of Change

   LAN                             Patch Panel                    Replace Patch Panel

   LAN                             Hub / Switch                   Replace Hub or Switch

   Server Support                  Server                         Increase memory, Increase disk
                                                                  capacity

   Applications Support Software                                  Update Virus Definitions

   Telephony                       Telephone System               Move extension

   On-line Services                Internet                       Replace modem

   Hardware                        PC                             Upgrade Memory




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc          Page 24 of 65
CAB Membership

Scope
The Change Advisory Board (CAB) is a body that exists to approve Changes. CAB members
should be chosen who are capable of ensuring that all Changes affecting their area of
responsibility are adequately assessed from both a business and a technical viewpoint. To
achieve this mix, the CAB needs to include people with a clear understanding of the business
needs, as well as the technical development and support functions.
At HDAA it is not necessary to hold face-to-face CAB meetings for each change request. Most
of the assessment referral process will be handled electronically via the Support System. Only in
very complex, high-risk or high-impact cases will a formal CAB meeting be necessary.
Otherwise, meetings will be held once per month. These meetings will be used to provide a
formal review and sign-off for pre-approved Standard Changes, a review of any outstanding
Changes, and to discuss any impending major Changes. A standard agenda will be used for these
meetings (see standard CAB agenda).
The following table outlines the CAB members at HDAA:



CAB Members

  Business Unit                        Member                   Contact       Email Address
                                                                Number

Executive                              Alan Hull               9986 1988    alanh@hdaa.com.au
                                                                            davidb@hdaa.com.au
Finance                              David Byron               9986 1987
                                                                            christ@hdaa.com.au
HR                                Chris Thompson               9986 1983
                                                                            davidg@hdaa.com.au
Enquiries                          David Gilmour               9986 1982
                                                                            annew@hdaa.com.au
Sales                                Anne Wilson               9986 1976
                                                                             rond@hdaa.com.au
Business Unit 1                       Ronald Dio               9986 1943
                                                                            stevien@hdaa.com.au
Business Unit 2                    Stephanie Nicks             9986 1966
                                                                           janderson@hdaa.com.au
Business Unit 3                     Jon Anderson               9986 1944
                                                                            iainm@hdaa.com.au
Information                         Iain Maitland              9986 1932
Technology Services
                                                                            davet@hdaa.com.au
Information                           Dave Tice                9986 1933
Technology Services




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc             Page 25 of 65
Emergency CAB Membership

Scope
When major Problems arise that require an urgent change, there may not be time to gain full
CAB approval. It is therefore necessary to identify a smaller group with authority to make
emergency decisions. Such a body is known as the Emergency Change Advisory Board (ECAB).
This is intended to ensure that the composition of the CAB will be flexible; in order to act
quickly when urgent changes are proposed. It will also ensure that the composition of the ECAB
will provide the ability to make appropriate decisions in any conceivable eventuality.




ECAB Members

   Business Unit                     Member            Contact Number       Email Address
                                                                           alanh@hdaa.com.au
Executive                            Alan Hull            W: 9986 1988
                                                         M: 0415 666 037
                                                                           davidb@hdaa.com.au
Finance                            David Byron            W: 9986 1987
                                                         M: 0415 666 034
                                                                           annew@hdaa.com.au
Sales                              Anne Wilson            W: 9986 1976
                                                         M: 0415 666 036
                                                                           iainm@hdaa.com.au
Information                        Iain Maitland         W: 9986 1932
Technology Services                                     M: 0415 666 038
                                                                           davet@hdaa.com.au
Information                          Dave Tice           W: 9986 1933
Technology Services                                     M: 0415 666 039




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc           Page 26 of 65
CAB Approvals

Scope
All changes categorised as „Significant‟ or „Major‟ require approval from the relevant CAB
authorised officer/s.
If more than one Business Unit is affected by a change then approval is required from the
authorised officer (or the nominated secondary officer) from each Business Unit. The IT
Manager is also required to authorise „significant‟ and „major‟ changes. Change approval will be
undertaken electronically through the support system.
The following officers are authorised to approve changes for their respective Business Areas:



   Significant & Major Change Approval – Authorised Officers

          Business Unit                    Authorised Officer       Secondary Officer

   Executive                                   Alan Hull              Richard Davies

   Finance                                    David Byron             Justin Hayward

   HR                                        Chris Thompson            Paul Rodgers

   Enquiries                                 David Gilmour               Ian Gillan

   Sales                                      Anne Wilson               Don Henley

   Business Unit 1                             Ronald Dio               Cass Elliott

   Business Unit 2                           Stephanie Nicks          Denny Doherty

   Business Unit 3                            Jon Anderson            Nancy Wilson

   Information Technology                      Dave Tice             Christine McVie
   Services




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc            Page 27 of 65
Change Status

Scope
The status of a change reflects the current position in its lifecycle.
All Change Requests logged in the Support System will have the relevant status applied at each
stage of its progression toward closure. The „Status‟ field in the Support System will be a
mandatory field.

Status Codes
The following status codes will be used for changes logged at HDAA:



     Status Codes
       Change Status Category                                    Explanation
     Open                                  This is the system default when a RFC has been
                                           logged but no action has yet been taken.
     With Customer                         This status is applied when awaiting some further
                                           information from the customer to complete the RFC
     Awaiting Authorisation                Set when the RFC is fully completed, prioritised and
                                           categorised and is awaiting approval from relevant
                                           authorised officer/s.
     Authorised                            Where RFC is approved and build or preparation
                                           action is underway. The proposed implementation date
                                           will appear in the FSC
     Backed Out                            Where the change has been unsuccessful at release and
                                           has been backed out.
     Resolved                              Where the change has been implemented through
                                           release and is awaiting review. A resolution code will
                                           be applied at this stage.
     Closed                                Indicates that the change has been implemented and
                                           reviewed. Where applicable the appended problem and
                                           any related incident/s would also be closed. The
                                           resolution code will flow through to the closure code.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc         Page 28 of 65
Change Resolution Codes

Scope
To facilitate reporting against completed changes, a change resolution code will be applied in the
support system when the change record is resolved.



Resolution Codes
The following change resolution codes will be used at HDAA:



        Resolution
             Resolution Code                                       Explanation
        Cancelled                          Implementation not completed for policy/initial
                                           approval reasons or where the requestor cancels the
                                           change.
        Rejected                           Where a significant or major change was not approved
                                           by the relevant CAB member/s and a decision was
                                           made not to proceed with the change.
        Failed                             Implementation not completed, or backed out, due to
                                           technical failure.
        Implemented with                   A change related „problem‟ has been formally
        problems                           identified and is currently unresolved.
        Implemented                        No outstanding change related „problems‟ have been
                                           formally identified.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc           Page 29 of 65
Change Procedural Documentation

Scope
This section documents the relevant procedures to be followed in managing changes to the
HDAA computing infrastructure.
The workflow involved is graphically presented in the following flow chart which identifies the
activities required in order to ensure that changes are being handled in the correct manner and
within the timescales relevant to the business:




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc   Page 30 of 65
Change Procedures Flowchart



                                                       Change
                                                       Required




                                                 1.0 Raise & Record RFC




                                                      2.0 Change
                                                      Assessment




                                                       Standard
                                                                          Yes   3.0 Standard Change
                                                       Change?




                                                          No




                   4.0 Urgent Change                    Urgent
                                           Yes
                                                       Change?




                                                          No




                                                      5.0 Change
                                                       Approval




                                                       6.0 Change
                                                     Implementation




                                                        7.0 Post
                                                     Implementation
                                                      Review (PIR)




                                                      8.0 Change
                                                        Closure




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc                Page 31 of 65
Change Procedures Flowchart Description
       Activity                                                     Description
1.0 Raise & Record            Change Management is initiated when a Request For Change (RFC) is
RFC                           logged in the Support system.

2.0 Change                    The RFC is filtered (accepted yes/no), prioritised (Emergency, High,
Assessment                    Medium, Low), risk assessed and categorised (Standard, Minor,
                              Significant, Major or Urgent) by the applicable Change Facilitator. The
                              RFC may need to be referred to the Business Unit representative or an IT
                              staff member for more information before progressing.

3.0 Standard Change Standard Change Procedures are for Changes that have the official, prior
Procedure           approval of the Change Advisory Board (CAB). They may therefore be
                    implemented immediately, without the need for any further assessment or
                    approval. See Standard Change Table

4.0 Urgent Change             Urgent changes are those that have a priority classification of
Procedure                     „Emergency‟ and will be authorised by the ECAB. Urgent changes will be
                              fast-tracked through the Change Management process.

5.0 Change                    All changes require the appropriate level of approval, which is based on
Approval                      the priority and categorisation, before they are entered into the Forward
                              Schedule Of Change (FSC). The CAB is the primary body charged with
                              responsibility for change control, however the Change Manager is
                              authorised to approve Minor Changes without reference to the CAB.

                              CAB approval is determined by the specific change under consideration.
                              It is composed of:
                                          Business System Owner/s applicable to the change
                                          IT Change Manager
                                          IT Team Leaders (the Technical System Owners)

                              Change approval will be automated through the Support System.

6.0 Change                    The change is built and then implemented through the release &
Development                   deployment process in accordance with the RFC and any special
                              instructions applicable to the change.

7.0 Change Review             Prior to closure, the relevant authorised officers will review all Changes.

8.0 Change Closure            Update the Change Record within the Support System, file all
                              documentation and close the RFC




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc            Page 32 of 65
1.0 Raise and Record an RFC

Scope
The procedure begins by raising a RFC within the Support System. This can be done either by an
IT officer directly within the Support System or by a Business Unit representative through the
Support System‟s Web Portal.
All RFC‟s requested through the web portal will be forwarded to the Service Desk in the first
instance, the Service Desk will perform an advisory function for business driven change,
assisting requestors to adequately plan, document and support the change request.

Procedures

  Activity            Sub                                            Description
                     Activity

1.1               1.1.1                The need for a change may be initiated as a result of a problem or
Raise RFC         Business or          to satisfy a business need which would be initiated by a Business
                  Problem              Unit representative or by the Board of Directors.
                  related
                  Change?              If related to a problem go to 1.1.2

                                       If related to a business need go to 1.1.3


                  1.1.2                Where identified as the result of a problem the relevant support
                  Problem              specialist will log the RFC in the Support System.
                  Related
                  Change               The status field will default to „open‟ and a unique change request
                                       number will be allocated to enable future tracking.

                                       Append the problem ticket to the RFC along with any electronic
                                       documentation relating to the change and go to 2.0 Change
                                       Assessment




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc             Page 33 of 65
  Activity            Sub                                           Description
                     Activity

                  1.1.3                Where a business unit representative initiates the change, the
                  Business             initial request will be communicated to the Service Desk via the
                  Related              Support System web portal utilising an on line RFC form.
                  Change
                                       The status field will default to „open‟ and a unique change request
                                       number will be allocated to enable future tracking. The change
                                       request number will be automatically sent via email to the change
                                       requestor through the Support System.

                                       Once received at the Service Desk, the Service Desk Analyst will
                                       filter the request and decide whether there is enough information
                                       to proceed or not. This screening process is not concerned with the
                                       validity or approval of the change request, but determines whether
                                       a decision to authorise or deny the change can be made based on
                                       the information at hand and any references made by the initiator.

                                       This screening process should include:

                                       A reality check to ensure that the RFC is appropriate. Because any
                                       user can request a change, it means that requests might be
                                       generated that are:
                                        Not relevant to the IT change management process.
                                        Not detailed enough.
                                        Not fully understood as to their implications.
                                        Not completed correctly due to the change initiator‟s lack of
                                          knowledge of the change management process.

                                       In summary, the process for requesting a business related change
                                       consists of the following steps:

                                        The change initiator creates and submits an account of the
                                         change needed.
                                        A screener (Service Desk Analyst) determines whether there is
                                         sufficient information present in the RFC for it to proceed.
                                        If sufficient information is not present, the screener calls or
                                         returns the request to the initiator with an explanation or
                                         request for further information
                                        This cyclical process results in an authorised, screened request
                                         ready for entry into the change assessment procedure or a
                                         request that is deemed inappropriate and is unauthorised.

                                       If authorised to proceed, go to 1.1.4
                                       If not authorised, confirm decision with the Change Manager and
                                       go to 1.1.5




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc            Page 34 of 65
  Activity            Sub                                           Description
                     Activity

                  1.1.4                The Service Desk Analyst will append any electronic data
                  Ensure all           supporting the RFC within the Support System.
                  required
                  information is       If a “standard change” which is pre-approved go to 3.0 Standard
                  present              Change

                                       If other than a “standard change” The Service Desk analyst will
                                       then escalate the RFC to the Change Manager for further
                                       processing. Go to 2.0 Change Assessment.


                  1.1.5          If the Change is not accepted, the reasons will be explained to the
                  Communicate change initiator. If the representative accepts these reasons then
                  with initiator this will be documented within the support system and no further
                                 action will be taken. Resolve the change - set the status to
                                 „Resolved‟ and set the resolution code to „Cancelled‟ - go to 7.0
                                 Review Change

                                       If the business unit representative does not accept the reason for
                                       rejection, then the request will be escalated to the Change
                                       Manager for a decision. The Change Manager may discuss the
                                       request with CAB members or convene a CAB meeting for final
                                       determination.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc            Page 35 of 65
2.0 Change Assessment Procedure

Scope
This procedure covers the initial assessment including setting the risk, priority and category of
the Request for Change.

Procedures

   Activity          Sub Activity                                      Description

2.1           2.1.1                        The RFC should arrive with the risk assessment determined by
Risk/Priority Set Risk &                   the business unit representative (see Impact/Risk matrix).
              Priority
                                           The Change Manager then determines the initial priority of the
                                           RFC in regards to its urgency.

                                           With the organisation‟s best interest in mind and taking into
                                           consideration any policies and/or service level agreements the
                                           Change Manager will assess the RFC and apply the most
                                           appropriate priority code (see change priority matrix).

                                           Go to 2.2


2.2                  2.2.1                 The Change Manager determines the category of the RFC in
Category             Set Category          regards to its impact on IT or the business (see change category
                                           matrix). The category that is applied will determine the
                                           appropriate approval process to be taken.

                                           If any further information is required at this stage, contact the
                                           change initiator. If information is not forthcoming immediately,
                                           set the status code to „With Customer‟ until the information is
                                           received. If documented in an electronic format append the
                                           information to the RFC within the Support System.

                                           Once all information is present, set the status code in the
                                           Support System to „Awaiting Authorisation‟

                                           Go to 2.2.2


                     2.2.2                 If it is determined to be a Standard Change that has been
                     Determine             miscategorised at the Service Desk go to 3.0 Standard Change
                     relevant              Procedure
                     approval
                     procedure             If an Urgent Change go to 4.0 Urgent Change Approval

                                           Otherwise go to 5.0 Change Approval




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc               Page 36 of 65
3.0 Standard Change Procedure

Scope
A standard change is a change to the infrastructure that follows an established path, is relatively
common, and is the accepted solution to a specific requirement or set of requirements. The
crucial elements of a standard change are:
                      The tasks are well known and proven.
                      Authority is given in advance by the CAB.
                      The change process can usually be initiated by the Service Desk.
                      Budgetary approval is typically preordained or within the control of the
                       initiator.
Standard changes are automatically approved and move straight to the change implementation
phase of the change management process. Because the types of changes that have been pre
approved as standard changes are known to have a low impact on the environment and are a low
risk to it, they do not need to be reviewed again by the CAB or even the Change Manager. This,
however, means that care must be taken during the initial screening to ensure that a change
request that has been categorised as standard is, indeed, one of the pre approved change types.
See “Pre-approved Standard Changes” for a list of standard changes in use at HDAA.

Procedures

  Activity        Sub Activity                                         Description

3.1               3.1.1                    Once the initial category is determined to be standard then verify
Check and         Is change                that the change is included on the Pre-approved Standard
Authorise         listed as                Changes list.
                  standard?
                                           If included select “standard” for the category from the drop down
                                           list in the Support System and go to 3.1.2

                                           If not included go to 2.2.1 and reassess the change category or
                                           request that this change type be added to the standard change list
                                           through the Change Manager and CAB.



                  3.1.2                    The change is approved within the Support System and the status
                  Authorise                is changed to „Authorised”.

                                           Go to 6.0 Change Development




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc               Page 37 of 65
4.0 Urgent Change Procedure

Scope
Urgent changes are those that have a priority classification of “Emergency”. The urgent change
procedure is an accelerated process that follows normal Change Management to the extent that
time constraints permit. Urgent changes need to be implemented quickly - for example, to
prevent a potential security breach or fix a business-critical application.
Time constraints allow only limited testing and require that normal processes, controls and
approval be bypassed. Urgent changes must be approved through the Emergency Change
Advisory Board (ECAB).
The ECAB is smaller than the regular CAB, and is able to meet or be available at short notice.
The ECAB must be empowered to make quick decisions and must have the full authority to
approve or deny urgent changes.
See „Emergency CAB Membership‟ table for ECAB members.


Procedures

   Activity           Sub Activity                                  Description

4.1                  4.1.1                 When a change is given a priority of “Emergency‟ it is
Approval             Convene               immediately categorised as an Urgent Change.
                     ECAB
                                           In this instance, a meeting of the ECAB will be convened
                                           with the purpose of reviewing the change to ensure that an
                                           emergency situation exists.

                                           If a meeting is unrealistic at short notice then approval
                                           through phone hook-up or through other electronic means
                                           may be sought.


                                           Go to 4.1.2


                     4.1.2                 If Urgent category is endorsed go to 4.1.3
                     Category              If Urgent category is not endorsed go to 2.2.1
                     endorsed?


                     4.1.3         When an Urgent Change is endorsed, the ECAB will
                     Planning &    authorise the change in the Support System and determine the
                     Communication best implementation plan. Status code is changed to
                                   “Authorised”

                                           All IT staff will be notified of the Urgent Change.

                                           The Service Desk team leader (in conjunction with the IT
                                           Manager) will be responsible for regular communication (both
                                           within IT and with the affected business unit/s) regarding the

668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc            Page 38 of 65
   Activity           Sub Activity                                  Description

                                           on-going status of the change. Communication is very
                                           important in an emergency situation.

                                           Go to 4.2


4.2                  4.2.1                 The change is added to the Forward Schedule of Change
Develop              Build change          (FSC).

                                           Development work will commence immediately with the
                                           urgent change given priority over all other change requests in
                                           the system.

                                           The Change Manager will be responsible for coordinating the
                                           build and applying the relevant level of resources to ensure
                                           the change is ready for release asap.

                                           A suitable back-out plan will be developed and agreed with
                                           the ECAB.

                                           Go to 4.3



4.3                  4.3.1             Best practice suggests that all changes be tested unless there is
Test                 Is there time for no time to do so. The level of testing to be undertaken for the
                     testing?          urgent change (if any) will be determined by the ECAB.

                                           If testing is approved go to 4.3.2
                                           If it is decided to proceed without testing go to 4.4


                     4.3.2                 If testing successful go to 4.4
                     Undertake             If testing unsuccessful go to 4.3.3
                     Testing
                     4.3.3                 Inform ECAB and, if approved, rebuild the change.

                                           Go to 4.3.1


4.4                  4.4.1                 Once built the urgent change will be scheduled for release at
Release              Implement             the most suitable time. The ECAB will have final approval for
                     Urgent Change         the implementation timing.

                                           Go to 4.4.2




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc            Page 39 of 65
   Activity           Sub Activity                                  Description

                     4.4.2                 If the change worked, change the status to „Resolved‟ and
                     Did change            apply resolution code - go to 7.0 Change Review
                     work?
                                           If the change did not work, go to 4.4.3


                     4.4.3 Back-out        ECAB is notified and back-out plans are implemented – status
                     change                is changed to „Backed Out”. If ECAB agrees a more thorough
                                           approach is taken with the change build.

                                           Rebuild change and go to 4.3.1




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc            Page 40 of 65
5.0 Change Approval

Scope
The change approval procedure is determined by the change category. Minor changes are
approved by the relevant IT Change Manager and are listed in the “Minor Changes – Authorised
by Change Manager” section of this document.
Significant and Major changes will require approval from the relevant approval officers listed in
the “CAB Approvals” section of this document.



Procedures

  Activity        Sub Activity                                          Description

5.1               5.1.1                    If categorised as minor go to 5.1.2
Change            Is the change
Category          categorised as           If categorised as significant or major go to 5.1.3
                  minor,
                  significant or
                  major?
                  5.1.2        The Change Manager will approve and change status in the
                  Minor Change Support System to “Authorised”

                                           Go to 5.2


                  5.1.3                    Escalate the fully completed RFC to CAB members according to
                  Significant              the “CAB Approval matrix”. The RFC will be sent to the relevant
                  and Major                approval officers through the Support System which will
                  Change                   determine the required approvers by a combination of the
                                           „category field‟ and „business units affected‟ field. The Change
                                           Manager and the IT Director will be included in the approval
                                           process.

                                           The RFC will be monitored for approval/rejection on a regular
                                           basis. If a response is not forthcoming in a timely manner or it is
                                           known that the CAB member is not in the office, the RFC will be
                                           sent to the secondary approval officer as listed in the „CAB
                                           Approvals‟ section of this document.

                                           Go to 5.2
5.2               5.2.1                    If no go to 5.2.2
Approval          Is the RFC
                  Authorised?              If yes go to 5.2.3


                  5.2.2                    The requestor will be notified that the Change has been rejected
                  RFC Rejected             by the CAB. Update the status code in the Support System to
                                           „Resolved‟ and the resolution code to „Rejected‟.

668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc                Page 41 of 65
  Activity        Sub Activity                                        Description


                                           Go to 7.0 Change Review


                  5.2.3                    Once the RFC is authorised by the relevant CAB members,
                  RFC                      change the status code within the Support System to
                  Authorised               „Authorised‟.

                                           Go to 6.0 Change Development




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc              Page 42 of 65
6.0 Change Development

Scope
After an RFC has been approved (using the appropriate approval body based on its priority and
category), it moves into the change development phase. This phase is concerned with the steps
necessary to plan the change, develop the deliverables of the change (for example, developing
new code or configuring new hardware), and the handover to the Release & Deployment
Management process for the deployment of the change into the production environment.
The speed with which the steps in this process are executed can vary greatly. A small, emergency
change may be planned, developed, and implemented in minutes. A change involving
deployment of a new software package to all of HDAA may take months in the development and
deployment phases.



  Activity         Sub Activity                                        Description

6.1               6.1.1                    The forward schedule of change within the Support System will
Schedule          Enter in FSC             contain only minor, significant, major, and emergency changes.
                                           Standard changes are not considered to have an impact on other
                                           types of change and therefore will not be included.

                                           The Change Manager enters the proposed date and time for the
                                           change implementation into the FSC once the RFC is approved.

                                           In some cases, it may only be possible to enter a tentative date
                                           for the change. This is the case for large changes that require a
                                           long development phase. As the development project progresses
                                           and the development project plan is drawn up and tracked, the
                                           date when the change will be implemented in the production
                                           environment becomes more definite and the FSC can be updated
                                           at this stage.

                                           Go to 6.2


6.2               6.2.1                    After the change has been scheduled, the change manager needs
Ownership         Appoint                  to identify and appoint a change owner to manage the change
                  Change Owner             through the development and release process and into the
                                           production environment. The change owner may in some cases
                                           be the change initiator.

                                           The RFC will be assigned within the Support System to the
                                           appointed IT Group who will take ownership of the change
                                           request.

                                           Go to 6.3


6.3               6.3.1                    Development work will commence on the requested change.
Develop           Build change
                                           The change owner will be responsible for coordinating the build

668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc               Page 43 of 65
  Activity         Sub Activity                                          Description

                                           in line with the timeframe set out in the FSC. Should delays
                                           occur these will be discussed with the Change Manager and the
                                           FSC updated if required.

                                           Commence building change.

                                           Prior to testing, a suitable back-out plan will be developed and
                                           agreed with the Change Manager.

                                           Go to 6.4



6.4               6.4.1                    All changes will be tested unless there is no time to do so
Test              Undertake                (Urgent Changes only). The level of testing to be undertaken will
                  Testing                  depend on the type of change.

                                           Test Change.

                                           Go to 6.4.2


                  6.4.2                    If testing successful go to 6.5
                  Was testing              If testing unsuccessful go to 6.4.3
                  successful?


                  6.4.3                    Inform Change Manager and, if approved, rebuild the change.
                  Testing
                  Unsuccessful             Go to 6.3.1


6.5               6.5.1                    Once built, the change will be released through the Release &
Release           Implement                Deployment Management process. Check FSC date is still
                  Change                   applicable, set status code to „Scheduled‟.

                                           Go to 6.5.2


                  6.5.2                    If yes, change status to „Resolved‟ and apply resolution code
                  Was release              within the Support System. - go to 7.0 Change Review
                  successful
                                           If no go to 6.5.3


                  6.5.3 Back-out           The Change Manager is notified and the back-out plan is
                  change                   implemented – status is changed to „Backed Out”. If Change
                                           Manager agrees the change will be rebuilt.

                                           Amend FSC, rebuild change and go to 6.3.1




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc                 Page 44 of 65
7.0 Change Review

Scope
Following release and deployment into the production environment or, as in the case of a
standard change, just a deployment into production, a review should be conducted to establish
whether the change has had the desired effect and has met the requirements of the original
Request for Change (RFC).
In most cases, this review process will be brief. For a standard change, e.g. where the effect has
been small and the results relatively predictable, the review process may be limited to checking
that the user has the desired functionality from the change.
All changes within the system will be reviewed at the weekly IT Team Leader meeting.



     Activity                 Sub                                  Description
                             Activity

7.1                       7.1.1            In order to determine whether the deployed change has been
Monitor                   Monitor          effective and has achieved the desired results, it is necessary
                          Change in        to monitor the change in the production environment. For a
                          Production       small change, this may consist of checking on the desired
                                           functionality (e.g. for a change in Group Policy allowing a
                                           desktop setting to be changed). For larger changes, it might
                                           require the monitoring of network and server information,
                                           performance data, event logs, or response times.

                                           Go to 7.2



7.2                       7.2.1            A Post Implementation Review for all changes with a status
Post                      PIR Meetings     of „Resolved‟ will be conducted at the weekly IT Team
Implementation                             Leader meeting.
Review
                                           Where sufficient monitoring has been completed and the
                                           change meets objectives then it will be approved for closure
                                           at the meeting. Following the meeting, the Service Desk
                                           will set the resolution code to „Implemented‟ and then close
                                           all changes that are approved (see 8.0 Change Closure).

                                           Some changes may have an immediate adverse effect on
                                           users or the network, as evidenced by a large increase in
                                           incidents reported to the Service Desk. In these cases, an IT
                                           Team Leader meeting will be called immediately in order to
                                           decide whether to back out the change or to make other
                                           changes to resolve the situation.

                                           If a decision is made to back out go to 7.2.2 Back Out

                                           If an implemented change has not fully met the objectives
                                           desired for the change, the PIR may determine that backing

668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc          Page 45 of 65
     Activity                 Sub                                  Description
                             Activity

                                           out the change is too costly or too risky, or the desired effect
                                           can be achieved (with less expense) by making additional
                                           changes. For example, a service pack or hot fix may be
                                           required to fully implement the functionality of the original
                                           change to the level desired.

                                           In this case, a new RFC should be raised to keep the
                                           production environment running and to achieve the results
                                           originally desired.

                                           The priority of such an RFC needs to be set appropriately:
                                           an emergency change might be required to minimise the
                                           time during which the adverse effects of the original change
                                           are experienced.

                                           If decided to raise additional change/s - go to 7.2.3
                                           “Additional Change Required”



                          7.2.2            The back-out plan associated with the change is
                          Back Out         implemented – set resolution code to „Fail‟. Go to 8.0
                                           Change Closure

                                           If it is determined that the change is still required a new
                                           RFC will be raised and the failed change will be appended
                                           within the Support System.


                          7.2.3            Set resolution code to „Implemented With Problems‟ and
                          Additional       close RFC (see 8.0 Change Closure).
                          Change
                          Required         Raise new RFC and append existing RFC within the
                                           Support System.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc          Page 46 of 65
8.0 Change Closure

Scope
The Service Desk will close all RFC‟s.
This procedure checks that the change record is fully updated and a resolution/closure code is
assigned.


  Activity            Sub                                            Description
                     Activity

8.1                                    Set the status of the RFC to „Closed‟ within the Support System.
Close the
Change                                 The Support System captures the time and date of closure and the
                                       resolution code automatically populates into the Closure Code
                                       field.

                                       When a change is closed there will be an email notification sent to
                                       the initiator informing them that their change has been closed and
                                       the closure code applied. Any appended problems/incidents will
                                       also be closed at this time. For significant, major and urgent
                                       change categories the relevant CAB members will be advised
                                       automatically through email that the change is now closed. Closed
                                       changes will be discussed at the monthly CAB meetings.

                                       All relevant electronically held documentation will be appended to
                                       the RFC within the Support System (if not already appended).
                                       Any hard copy documentation will be filed using the unique RFC
                                       record number from the Support System as the reference guide.

                                           Note: As part of the quality assurance function, the Support
                                           system will auto email 20% of business driven change
                                           requestors with a quick satisfaction survey. See Customer
                                           Satisfaction for details of questions and rating system.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc             Page 47 of 65
Change Management Responsibilities - RACI Matrix

Scope
RACI is an accountability and communication matrix that is designed to help eliminate
confusion over roles and responsibilities.
The acronym „RACI‟ stands for Responsible, Accountable, Consulted and Informed.
This section contains the RACI matrix for the HDAA Change Management Process.

Change Management RACI Matrix
                       Process      Service    Service       Support      IT Team   Change    Initiator   CAB   ECAB
     Procedure         Owner       Desk Team    Desk         Specialist   Leaders
                                    Leader     Analyst                              Manager

CM Process i.e.           A            R          I              I          R         R          I        C      C
planning, design,
roles,
communication,
training, adoption,
compliance,
reporting,
continuous
improvement
1.0 Change                            C/R       C/R             C/R        R/C        A          R
Initiation
2.0 Change                             I          I              R         R/C        A          C
Assessment
3.0 Standard                         A/C/I      R/I             R/I        R/C
Change Procedure
4.0 Urgent                I            C          I              R         R/C       A/C         I         I     C
Change Procedure
5.0 Change                             I          I              C         R/C        A          I
Approval (Minor)
5.0 Change                             I          I              C          C        A/I                  R
Approval
(Significant &
Major)
6.0 Change                             I          I             R/C        R/C       A/I
Development
7.0 Change                             C          I              I         R/C       A/C
Review
8.0 Change                            A/R        R               I           I         I         I         I
Closure


Legend
R = Responsible: executes the task
A = Accountable: accountable for final result
C = Consulted: consulted about the task to provide additional information
I = Informed: needs to be kept up-to-date on activities/tasks



668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc                 Page 48 of 65
Change Management: Critical Success Factors & Key
Performance Indicators

Scope
Critical Success Factors (CSF‟s) are the small number of things that need to be done right within
each ITIL process. Key Performance Indicators (KPI‟s) are a set of clearly defined objectives
that have measurable targets and are used to judge the performance against the critical success
factors of an area or a process. Reports against Change Management KPI‟s will be produced for
discussion at IT Team Leader weekly meetings but will be measured monthly.


KPI targets (or a sub-set) will be made available to customers via Service Level Agreements
(SLA‟s) and performance against KPI‟s included in regular customer reports.




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc    Page 49 of 65
Change Management - Critical Success Factors (CSF’s)

The critical success factors for Change Management within HDAA will be:
               HDAA has a repeatable process for making changes
               Changes are made quickly and accurately
               Existing services are protected when Changes are being made
               Process efficiency and effectiveness benefits are delivered




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc       Page 50 of 65
Change Management - Key Performance Indicators (KPI’s)


                              1. Repeatable Process for Making Changes

        KPI Name                           Definition               Data Source        Target

 Percentage reduction            As process matures and             Support       Gradual reduction
 in rejected RFC‟s               historical data is collected,      System        over time as
                                 fewer changes should be                          process matures.
                                 rejected – especially for                        Measured
                                 insufficient detail or                           monthly.
                                 information supplied.

 Percentage increase in Changes implemented within                  Support       Gradual
 Business Change        timeframe documented in the                 System        percentage
 Requests implemented Forward Schedule of Changes.                                increase over time
 on time                                                                          as process
                                                                                  matures.

 No unauthorised                 If the approval process is well    Support       No unauthorised
 changes detected in             defined and repeatable, there      System        changes within
 system                          should be no unauthorised                        Support
                                 changes entering or within the
                                 system

 Reduction in time to            As process matures and staff       Support       Percentage
 make Standard                   become familiar with pre           System        decrease in
 Changes                         approved standard changes                        average time taken
                                 average implementation time                      to process a
                                 will reduce                                      Standard Change

 Reports produced on             Reports will be produced for       Support       Reports available
 schedule                        weekly team leader meetings        System        for meetings 99%
                                 and monthly CAB meetings                         of time.




                                 2. Make Changes Quickly & Accurately

        KPI Name                           Definition               Data Source        Target

 Percentage reduction    If overall process is working              Support       Gradual reduction
 in changes resulting in quickly and accurately                     System        over time as
 incidents               (including sufficient testing)                           process matures.
                         then approved changes should                             Measured monthly
                         not cause change related
                         incidents.



668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc            Page 51 of 65
                                 2. Make Changes Quickly & Accurately

        KPI Name                           Definition              Data Source        Target

 Percentage reduction            Accurate, sufficiently tested     Support       Gradual reduction
 in Changes requiring            changes should not lead to a      System        over time as
 back-out                        back-out being required                         process matures.
                                                                                 Measured monthly

 Reduction in the                If process is running smoothly    Support       Number of
 number of urgent                with changes implemented          System        reported urgent
 changes                         within agreed timeframes then                   changes reducing
                                 requests for urgent changes
                                 should reduce



                              3. Protect Services When Making Changes

        KPI Name                           Definition              Data Source        Target

 Percentage reduction    Successful change should not              Support       Gradual reduction
 in changes resulting in lead to associated incidents or           System        over time as
 incidents to existing   problems.                                               process matures.
 services                                                                        Measured monthly

 Reduction in both the           If changes are implemented to     Support       Service
 scheduled and                   schedule then there should be     System        availability
 unscheduled service             a reduction in service                          measures
 unavailability caused           unavailability                                  gradually improve
 by changes

 Percentage increase in          Day to day services will be       Support       Gradual increase
 Changes activated               protected the more changes        System        in changes
 (released) outside core         are released outside of core                    released outside
 service hours                   business hours                                  core business
                                                                                 hours



                     4. Deliver Process Efficiency & Effectiveness Benefits

        KPI Name                           Definition              Data Source        Target

 Improvement in                  This is the overall rating from   Survey        Gradual increase
 Customer Satisfaction           customer surveys conducted        Database      on overall
 Survey feedback on              on change closure.                              customer
 change                                                                          satisfaction each
                                                                                 year as process
                                                                                 matures



668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc           Page 52 of 65
                     4. Deliver Process Efficiency & Effectiveness Benefits

        KPI Name                           Definition              Data Source        Target

 Reduction in                    The more efficient and            Support       Gradual reduction
 percentage of failed            effective the process the less    System        over time as
 changes                         failures                                        process matures.
                                                                                 Measured monthly

 Increased percentage            Performance against Service       Support       Performance
 of Changes                      Levels as documented should       System        targets are met on
 implemented on time             improve as process becomes                      an increasing basis
                                 more efficient




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc           Page 53 of 65
Change Management Reporting

Scope
This section describes the main reporting requirements of Change Management. These reports
will be used as the basis for management of the process.
By maintaining historical information on infrastructure changes, it is possible to derive measures
that are indicative of the quality of service and the performance of the process.
Reports will be produced for each of the Key Performance Indicators listed above. Other more
detailed reports will be required by team leaders and managers – these reports are listed below.

Summary Of Changes
These reports provide a convenient „snapshot‟ of the performance of a Support Group or overall
performance of the Process.

Reports

                       Summary of Urgent Changes – provides a list of all changes categorised as
                        „Urgent‟ for review at weekly team leaders meeting.
                       Summary of Changes by category: Provides a list of all changes by
                        category i.e. urgent, major, significant, minor and standard.
                       Summary of Changes by status for all Support Groups: Provides a list of
                        all changes and their current status for each Support Group.
                       Summary of Changes by Support Group: Provides a list of changes
                        allocated to the change owners in each Support Group.
                       Summary of Changes by Configuration Item: Provides a list of changes
                        applied to individual Configuration Item (CI) for month.
                       Summary of Changes by Priority: Provides a list of changes for each of the
                        four possible priorities in use (Emergency, High, Medium and Low).
                       Summary of Changes by Business Unit: Provides a list of changes for each
                        Business Unit within HDAA.

Measurements in the Reports
Against each item listed in the selected report will be the following metrics:
                       Number of new changes
                       Number of changes resolved
                       Number of changes in breach of SLA (by business unit)
                       Total time and Average time spent until change is implanted and RFC is
                        resolved



668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc        Page 54 of 65
Summary of Effectiveness
These reports are intended to provide an overall view of the effectiveness of Change
Management in a specified period (monthly) by providing aggregates of key metrics against four
perspectives (performance, efficiency, quality & customer satisfaction).

Reports

                       Summary of Effectiveness of Change Management
                       Summary of Effectiveness by Support Group
                       Summary of Effectiveness by Change Owner
Measurement

                       Performance:
                            Total number of changes unresolved by status
                            Total number of new changes logged
                            Total number of changes resolved
                            Total number of changes closed

                       Efficiency:
                            Total hours spent on change from approval to resolution
                            Average hours per change from approval to resolution

                       Quality:
                            Total changes resolved within SLA by Business Unit
                            Total changes in breach of SLA

                       Customer satisfaction:
                            Percentage satisfaction rating from customer survey on 20% of changes
                             closed




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc         Page 55 of 65
Change Management Roles

Scope
Roles associated with the Change Management Process are defined in the context of the function
and are not intended to correspond with organisational job titles. Specific roles have been defined
according to industry best practice. In some cases, many persons might share a single role; and in
other cases, a single person may assume many roles, or at least more than one role. It is
especially likely that a person will assume different roles with respect to different processes. For
example, the change owner for change management may be the release manager for release
management.
This document provides detailed descriptions of the key roles in the Change Management
Process as implemented at HDAA.
The key roles are:
                       Process Owner (IT Director)
                       Change Manager (IT Manager)
                       Change Initiator (Business Unit staff member or any IT staff member)
                       Change Implementers (Potentially any IT staff member or 3rd Party)
This document describes each role referred in terms of:
                       Role profile
                       Objectives
                       Responsibilities & Activities
                       Authority




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc        Page 56 of 65
Process Owner (IT Director)

Profile
The person fulfilling this role has the overall responsibility for the integrity of the end-to-end
Change Management Process, for the way in which it functions and develops, and is the Support
System owner. The main role of the Process Owner is to ensure that the design of the change
management process and the underpinning support systems are efficient, effective, and fit-for-
purpose.
The Process Owner will work to ensure integration between the ITIL disciplines and their
process-flows.
In general, the Change Management Process Owner:
                       Operates with a bird‟s eye view
                       Has strong process competencies
                       Can coach and mentor the other participants (Particular the Change Manager
                        and CAB Members) in the Change Management Process
                       Understands the business priorities
                       Possesses at least an ITIL Foundation certificate and preferably an ITIL
                        Practioners certificate in Release and Control or the ITIL Service
                        Management certificate

Objectives

                       Take ownership of the Process to establish process flow, accountabilities &
                        responsibilities
                       Quality manage the Process ensuring compliance and continuous
                        improvement
                       Ensure there is a balance between the key components of a good Service
                        Management environment: People, Process, Product & Partners

Responsibilities

                       Ensuring the Change Management process is fit-for-purpose
                       Ensuring the Process is followed (eg ensuring CAB meetings are held
                        regularly and all change activities are reviewed)
                       Defining the Business Case for the Change Management Process
                       Ensuring there is optimal fit between people, process, product & partners
                       Ensure Key Performance Indicators are met
                       Reporting to upper management
                       Integration/communication of the process with the HDAA Business Units
                       Any changes to the Change Management Process

668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc        Page 57 of 65
Authority
The Process Owner has authority to:
                       Recruit/appoint staff to positions in the Process
                       Approve training requests for participants in the Process
                       Approve changes to the Process or Technology, in particular to integrate ITIL
                        processes and to resolve conflicts in processes
                       Enforce compliance with the Process by all participants.
                       In conjunction with the CAB overrule any change that does not have business
                        approval, is an incorrect application of the Process or that will have negative
                        consequences for HDAA‟s services




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc         Page 58 of 65
Change Advisory Board (CAB) Member

Profile
The Change Advisory Board (CAB) is the group of people who have the primary accountability
and responsibility for the approval and review of change related activities.
Activities delegated to other participants, such as Standard Change Procedures and approval of
minor RFC‟s by the Change Manager, will be initially approved and regularly reviewed by the
CAB.

Membership
The core members of the CAB are in general:
                       IT Director (Process Owner)
                       IT Manager (Change Manager)
                       Business Unit representatives (one per Business Unit)

Objectives
                       Assess, control, approve and review all change related activities so as to
                        minimise the occurrence of incidents and failures and maximise service
                        availability
                       Quality assurance and continuous improvement of the change process

Responsibilities & Activities
                       Assess and approve/reject all significant and major RFC‟s referred by the
                        Change Manager
                       Ensure a Forward Schedule (FSC) of Change is maintained.
                       Advise on project plans and implementations
                       Periodically meet to review change reports, update Standard and Minor
                        Change tables and to ratify urgent change procedures
                       Review the effectiveness of the Change Process in general, identifying and
                        recommending opportunities for improvement to the Process Owner.

Authority
                   The CAB has the authority to:
                       Approve or reject all urgent (ECAB), major and significant change requests
                       Be informed of any urgent change requests raised
                       Enforce the Change Management Process
                       Recommend changes to improve the Process
                       Review any change related activity

668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc         Page 59 of 65
Change Manager (IT Manager)

Profile of the Role
The Change Manager reports to the Change Advisory Board (CAB) in regards to the change
management process but ultimately reports to the Process Owner.
The Change Manager is the key coordinator of the change management process. This role
provides input to the filtering of the initial RFC‟s and to the classification of RFC‟s. Minor
requests may be approved and scheduled by the Change Manager, while significant or major
RFC‟s must be referred to the CAB. The Change Manager ensures that an ECAB meeting is
called when a change is categorised as urgent.
Following approval of a change, the Change Manager is responsible for monitoring progress and
ensuring compliance with the change process. The Change Manager also responsible for
identifying post-implementation issues, such as change related incidents, and ensuring changes
are reviewed.
In general, the Change Manager:
                       Is the key coordinator of the change management process
                       Has strong process and management skills
                       Understands both the business side and the technical side of proposed
                        changes and is able to clearly present this information to the CAB
                       Ideally, Possesses an ITIL Foundation Certificate and is moving forward to
                        achieve the Practitioners Certificate for the Change Management process.

Objectives of the Role

                       Responsible for ensuring the day to day filtering & classification of RFC‟s is
                        undertaken
                       Responsible for day-to-day monitoring and management of the change
                        process
                       Establish an environment of quality assurance and continuous process
                        improvement

Responsibilities & Activities

                       Responsible for ensuring that the Change Management process is being
                        followed correctly
                       Filters and classifies all RFC‟s in collaboration with IT staff and returns
                        incomplete or incorrect RFC‟s to initiator.
                       Approves/rejects “minor” RFC‟s.
                       Ensures “significant” and “major” changes are referred to the CAB for
                        assessment and approval and “urgent” changes are referred to the ECAB.
                       Ensures that sufficient technical guidance is provided to the CAB to enable its
                        decision-making.

668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc         Page 60 of 65
                       Participates fully in the CAB meetings and carries out delegated tasks.
                       Liaises with all necessary individuals to coordinate the building, testing and
                        implementation of changes as per the Forward Schedule of Changes (FSC)·
                       Assigns change related tasks to appropriate individuals
                       Is vigilant in the monitoring of all changes from build to testing.
                       Ensures an adequate Post Implementation Review (PIR) takes place.
                       Provides any reporting as requested by the CAB or Process Owner

Authority
The Change Manager has authority to:
                       Enforce compliance with the change process by all initiators, builders, testers
                        & implementers
                       Assign approved, change related tasks to appropriate individuals
                       Report on Key Performance Indicators that have been established.
                       Escalate any breaches in the process to the CAB and the Process Owner
                       Recommend improvements to the process and the related technology
                       Communicate/educate customers and users




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc         Page 61 of 65
Change Initiator

Profile

                       Can be any staff member either in an HDAA business unit or in the IT
                        Department.
                       Must possess the technical or business competence to identify the need for
                        change and to satisfactorily complete an RFC – otherwise should seek
                        assistance from an IT staff member (the Service Desk can help).

Responsibilities & Activities

                       Initiating change requests
                       Satisfactorily completing an RFC, and
                       Providing all necessary supporting documentation

Provides Input To

                       Project plan
                       Assessment and planning of the change
                       Building, testing and implementing the change
                       Assessing and reviewing the change
                       Identifying and resolving change related incidents

Authority

                       Log and implement Standard Change Procedures




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc         Page 62 of 65
Change Implementer

Role Profile
“Change Implementer” is a generic term that refers to anyone assigned by the Change Manager
(with approval of the CAB if required) to carry out a change related activity.
A Change Implementer may be assigned responsibility for one or more aspects of a project plan
such as:
                       Designing
                       Building
                       Testing
                       Transferring to Production
In general, the Change Implementer:
                       Must possess the necessary technical skills to carry out the assigned task
                       Must understand the Change Management Process

Responsibilities and Activities

                       Complies with the Change Management Process and required authorisations
                       Carries out the approved and assigned task, in accordance with the project
                        plan, procedures or specifications
                       Keeps the Change Manager informed of progress
                       Updates the Change Record as required
                       Provides feedback on the implementation in the Post Implementation Review
                        (PIR) when required

Provides Input To

                       Project plan
                       Assessment and planning of the change
                       Building, testing and implementing the change
                       Assessing and reviewing the change
                       Identifying and resolving change related incidents

Authority

                       Log and implement Standard Change Procedures




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc         Page 63 of 65
Change Management - Customer Satisfaction
Measurement

Scope
Since customer satisfaction on changes arising from problem tickets will be measured within the
problem management process, customer satisfaction within the change process will be
undertaken by sampling 20% of customers who have requested a business change.
This will be automated through the Support system.

Questions
When surveying customers, the five questions to be asked are:

How satisfied were you with:
                       The courtesy of the IT staff?
                       The technical skills/knowledge of the change builder/s?
                       The timeliness of the service provided?
                       The change release?
                       The overall service experience?


Rating Scale
The rating scale will be based on a 5 point scale:
                       Very Dissatisfied
                       Satisfied
                       Indifferent
                       Satisfied
                       Very Satisfied


Reporting
The KPI for customer satisfaction against Change Management will be „90% of staff surveyed
are satisfied or above with the services provided‟. Reports will be produced on a monthly basis
showing the percentage of staff responding „satisfied‟ or „very satisfied‟ to the questions listed
above. Individual reports will be produced for each question and a cumulative report against all
questions will also be produced for KPI reporting.



                                              End Process



668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc         Page 64 of 65
Change Advisory Board Agenda

Date: xx/xx/xx
The most viable approach for CAB meetings is a combination of regular meetings combined with
electronic automation. If this format is viable then monthly meetings held on a regular basis (e.g.
first Tuesday of each month) would be appropriate. A standard agenda should be used – for
example:

    1)     Opening of the meeting

    2)     Apologies

    3)     Minutes from previous meetings

    4)     Actions points from last meeting

    5)     Urgent Changes that may have arisen between this and the previous meeting

    6)     Failed Changes i.e. where the back-out plan needed to be invoked

    7)     Status of current Changes (does the status, priority or category need to change?)

    8)     Status of testing for current changes (verification and validation)

    9)     Status of release planning activities for current changes, such as training, documentation
           readiness and rollback procedures

    10) New Requests For Change to be assessed in structured and priority order

    11) Changes being implemented without approval from Change Management

    12) Any changes to pre-approved schedules i.e. standard or minor changes

    13) Post Implementation Review of closed Changes

    14) Action points (assign to members)

    15) Wins/accomplishments for this period

    16) Comments and questions (also on the process for possible process improvement)

    17) Closure of the meeting




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc       Page 65 of 65
tion Review of closed Changes

    14) Action points (assign to members)

    15) Wins/accomplishments for this period

    16) Comments and questions (also on the process for possible process improvement)

    17) Closure of the meeting




668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc       Page 65 of 65

				
DOCUMENT INFO
Description: Change Management Process Itil document sample