IFSM 301 - CIO Organizational Structure Memo

twinkletoes

IFSM-Week5ResourcesandCitations.pdf

Home >Information Systems homework help >IFSM 301 - CIO Organizational Structure Memo

IFSM 301 – Week 5 Citations

(Module_Business Case and Putting It All Together)

(Change Management - Sample Process Guide)

(Van Grembergen & De Haes, IT Governance and Its Mechanisms, 2004)

(Van Grembergen & De Haes, IT Governance Maturity Model, 2004)

(ITIL explained in 3 minutes, 2015)

(Schneider, 2020)

(White & Greiner, 2019)

Bibliography (n.d.). Change Management - Sample Process Guide. Sample Guide, University of Maryland

Global Campus. Retrieved February 3, 2021, from https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543080/View

ITIL explained in 3 minutes (2015). [Motion Picture]. YouTube. Retrieved February 6, 2021, from https://www.youtube.com/watch?v=vp2wfoVRMDE&feature=youtu.be

Module_Business Case and Putting It All Together. (n.d.). Retrieved February 3, 2021, from University of Maryland Global Campus: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543104/View

Schneider, L. (2020, January 29). Learn About Information Technology Infrastructure Library. Retrieved February 6, 2021, from Balance Career: https://www.thebalancecareers.com/information-technology-infrastructure-library- 2071503

Van Grembergen, W., & De Haes, S. (2004). IT Governance and Its Mechanisms. Information Systems Audit and Control Association, 1-71. Retrieved January 12, 2021, from https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543002/View

Van Grembergen, W., & De Haes, S. (2004). IT Governance Maturity Model. In IT Governance and Its Mechanism. Information Systems Audit and Control Association. Retrieved February 5, 2021, from https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543083/View

White, S. K., & Greiner, L. (2019, January 18). What is ITIL? Your guide to the IT Infrastructure Library. Retrieved February 6, 2021, from CIO: https://www.cio.com/article/2439501/infrastructure-it-infrastructure-library-itil- definition-and-solutions.html

2/3/2021 Module: Business Case & Putting It All Together - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543107/View 1/1

Putting It All Together With this module’s content, we will discuss building a business case—a tool used to justify the allocation of scarce company resources among competing corporate projects. We will focus on using a business case to justify IT projects. You will then have an opportunity, using a real-life case study, to put what you have learned into practice and demonstrate all of your new knowledge.

XXXXX (XX) IT Operational Process

Change Management Process Guide

XXXXX Information Technology

IT Change Management Procedure

XXXXX Page 2

Preface

The purpose of this document is to outline the procedures that govern the Change Management process in XXXXX (XX) Information Technology. This document describes how to use the procedures and provides a definition of the management controls required and some rationale for instituting those controls.

IT Change Management Procedure

XXXXX Page 3

Table of Contents

Preface ........................................................................................................................... 2 Table of Contents.......................................................................................................... 3 Objectives/Purpose....................................................................................................... 5

Scope Inclusion........................................................................................................................6 Scope Exclusion.......................................................................................................................6

Change Management Standards.................................................................................. 7 Status of Changes......................................................................................................... 8 Types of Changes ......................................................................................................... 9 Change Levels............................................................................................................. 11

Change Level Summary Table...............................................................................................17 Risk/Complexity Scoring ........................................................................................................18 Risk/Complexity Scoring Grid.................................................................................................19

Summary of the XX Change Management Procedures............................................ 20 Change Request Flows............................................................................................... 22

High Level Process Flow........................................................................................................22 1. Enter Change Request Flow .............................................................................................23 2. Assign Change Implementer Flow ....................................................................................26 3. Monitor Change Calendar Flow.........................................................................................28 4. Perform Assessments Flow...............................................................................................30 5. Approve Change Flow.......................................................................................................33 6. Commit Change Schedule Flow........................................................................................35 7. Deploy Change Flow.........................................................................................................37 8. Assure Change Quality Flow.............................................................................................39 9. Close Change Flow...........................................................................................................41

Change Request Form ................................................................................................ 43 Scheduled Change Windows ..................................................................................... 47 Lead Times for Changes............................................................................................. 48 Unsuccessful Changes............................................................................................... 49 Roles and Responsibilities......................................................................................... 51

Change Review Board ...........................................................................................................51 Change Coordinator ...............................................................................................................52

IT Change Management Procedure

XXXXX Page 4

Change Requester .................................................................................................................53 Change Implementer..............................................................................................................54 Change Management Process Owner ...................................................................................55 Service Center Administrator .................................................................................................56 Change Controller ..................................................................................................................57 Change Scheduler .................................................................................................................58

XX Change Review Board........................................................................................... 59 Change Review Definition ......................................................................................................59 Change Approver Table .........................................................................................................60 Meetings.................................................................................................................................61 XX Change Review Board Meeting Agenda ..........................................................................62

Measurements ............................................................................................................. 64 Glossary....................................................................................................................... 65

IT Change Management Procedure

XXXXX Page 5

Objectives/Purpose

Change Management is the process of planning, coordinating, implementing and monitoring changes affecting any production platform within Information Technology’s control. The objectives of the Change Management process are to:

Ensure that changes are made with minimum disruption to the services IT has committed to its users.

Support the efficient and prompt handling of all changes. Provide accurate and timely information about all changes. Ensure all changes are consistent with business and technical plans and

strategies. Ensure that a consistent approach is used. Provide additional functionality and performance enhancements to systems

while maintaining an acceptable level of user services. Reduce the ratio of changes that need to be backed out of the system due to

inadequate preparation. Ensure that the required level of technical and management accountability is

maintained for every change. Monitor the number, reason, type, and associated risk of the changes.

The Change Management procedure for the XX Information Technology Division defines how the change process is implemented in all of the IT platform environments. The objectives of the operating procedures, in addition to those detailed above are to:

Provide documentation that allows XX IT management to understand, at any point in time, the configuration of the IT environment.

Minimize the bureaucratic impact on the development community while maintaining control of the environment.

Activities of the Change Management Process at XXXXX include:

Receiving change requests from the Request for Service process Determining whether or not the change is in the best interests of XX Assigning the change to resources within IT for solution identification, sizing

and risk analysis Accepting or rejecting the requested change Assigning the change to solution development resources Reviewing the solution prior to implementation Scheduling the change Communicating change status as required to all interested parties Closing the change

IT Change Management Procedure

XXXXX Page 6

Scope Inclusion The management of any installation or alteration to hardware, network, system or application software, procedure or environmental facilities which adds to, deletes from or modifies the service delivery environment.

Scope Exclusion Activities required to develop, test and deploy the change.

IT Change Management Procedure

XXXXX Page 7

Change Management Standards

• All substantive changes to the IT Environment must adhere to the XX change Management process. A substantive change has the potential to affect the ability of users and systems to interact with each other.

• All changes must conform to the published guidelines that dictate the “look and feel” of the XX web environment.

• All web page content changes must have the approval of the web page owner prior to change implementation.

• All changes to the production systems within IT will have a corresponding set of documentation that describes the change, the business reason for the change and the disposition of the change. This includes emergency and exception changes.

• The risk and/or impact ratings of the requested change will determine which of the four phases of the change workflow (Analysis, Design, Testing and Implementation) will be required to promote the change into production. For “minor” changes only Analysis and Implementation will be required.

• Anyone with a valid XX Notes access will be able to enter a change into the Change Request process. Only authorized approvers will be able to accept a change request into the Change Management process.

IT Change Management Procedure

XXXXX Page 8

Status of Changes

The following status codes are used to reflect the status of a change request:

• Open – The change has been received and accepted but has not been assigned • In-Progress – The change has been received, acknowledged and assigned.

Work is in progress to fulfill the change request. • Approved – The business and technical assessments have been completed and

the change has been approved and committed to the change scheduler. • Rejected – The change has been rejected and will be routed back to the

Request for Service process and sent back to the customer with an explanation and a recommended course of action.

• Closed – The change request has been closed. • Canceled – The change request has been canceled.

IT Change Management Procedure

XXXXX Page 9

Types of Changes

The Change Management Procedure applies to all types of changes related to the XX IT environment. The following is a description of each of the types of changes that can take place and the rules that apply to each. Application Changes - Changes to any application code that is running on or linked

to by any hardware or software in the XX IT environment. These changes are typically made to enhance the function or performance of or to fix a known error in the IT application environment. These changes cannot be implemented without approval of the owner of the application and cannot be requested by any programmer other than the one assigned to the program. Assignment of Risk Category Level of the change is to be a joint effort of both the owner and the Change Implementer.

Hardware Changes - All XX IT and IT support equipment installations, discontinuances and relocations are controlled by the Change Management Procedure. This activity can be requested by anyone but must have the approval of the Operations Manager.

Visual Image Changes – Changes to the “artistic” presentation of web pages are not required to make entries into the Change Management system. Changes to “Active” areas of the web page are required to use the XX Change Management procedure.

Software Changes - The criteria for entering a software change into the Change process are based upon the effect that the changes may have on the IT support resources. If the changes affect the system, users or the support staff there is a requirement to enter it into the Change process. If the change is made for the exclusive benefit of the requester and if failure could not affect anyone else, that change would be exempt from the Change Process. For example, a change made by a programmer affecting a procedure or a program under development on a test application requires no entry. However, when stand-alone test time is required on a production system, a change request form is required.

o Typically, software changes would include changes to the Operating System, Vendor supplied Program Products, e.g., Visual Studio, Java, etc. or common application support modules. However, during the last two and first five workdays of each month changes are restricted to emergency and critical necessities as determined by the Director of Information Technology.

Network Changes - All installations, discontinuances and all relocations of equipment used for IT teleprocessing communications are entered into the change process. This includes all routers, switches and telephone lines as well as Personal Computers if they are connected to the network.

Environmental Changes - Environmental changes normally involve the facilities associated with the IT Installation. These facility changes include items such as air conditioning, chilled water, raised flooring, security, motor generators, electricity, plumbing and the telephony system for voice and data. For example, when there is

IT Change Management Procedure

XXXXX Page 10

a planned weekend power outage initiated by the local power company this information is submitted to the Change Management Process a minimum of two weeks prior to the scheduled outage and communicated to management, staff and the user community.

Documentation Changes - All procedural changes to the standard operating procedures will be implemented through the Change process. Also, all permanent deviations from the published schedule time for running of production applications will be communicated through the Change Management system.

IT Change Management Procedure

XXXXX Page 11

Change Levels

The following guidelines for definition of Change risk levels are provided for consideration during the planning cycle. It must be clearly understood that these requirements are the minimum for each of the defined levels. The Requester may wish to plan additional lead times, documentation or reviews to insure that targets can be met and planned implementation schedules can be achieved. All changes are tracked, correlated and used for management reporting, statistiXX, trending, etc., to identify when and where additional resources should be provided. For any change that fails, the Change Requester must enter an explanation in the comments section of the Change Record for that change and notify the Change Coordinator. The Change Coordinator will then close the change with the appropriate close status. If the change is to be attempted at a later time, the Change Requester should reenter the change with the new date. Changes that cause a Platform outage will be reviewed at a Quality Measurement Meeting.

Level E Changes Emergency changes are those changes that are vital in order to ensure that IT’s committed service levels are maintained. An Emergency change should not be used in order to bypass the appropriate lead-time for a change that has been entered into the system. Exception changes are those changes that are a result of a business need and must be installed prior to the required lead-time. These types of changes proceed to the implementation phase when the requester's manager and the Director of Information Technology acknowledge that an Emergency or an Exception situation exists and authorize the modification planned. These changes will be post-reviewed to assure successful implementation, along with identification of any external impacts or new requirements. Post-review will also evaluate the reason for the Level E change request and try to determine a way of eliminating this requirement in the future. The post-review will also evaluate if, in fact, the change addressed a real or a perceived emergency condition. In all cases, the review must determine if additional action is required, what that action should be and who will be responsible for the action. Documentation requirements for Emergency changes are the same as any change. The Requester is responsible for meeting all requirements for the change documentation within one week of the implementation. How do you know that the change falls under Level E?

IT Change Management Procedure

XXXXX Page 12

For non-application changes:

Is the change needed to restore immediate service to the end user? Is the change necessary to fix an existing problem immediately? Is this a change that must be installed immediately but the need for it was not

recognized early enough to be approved through the regular process?

For application changes:

Must this change be done immediately to fix problems for jobs that ABENDed during the previous night or are required to run in order to bring up on-line systems?

What types of management approval is required for Level E changes? Approval required by:

• Director of Information Technology or her designee • Change Management Process Owner or his designee • Manager of the user department requesting the change

Depending on the scope and impact of the proposed change, approval by one or more of the following individuals may be required.

• Operations Manager • Application Development Manager • Network & Technical Services Manager.

Level 4 Changes A Level 4 Change would have a major impact on IT services if a problem occurs during install. The install time is lengthy and the backout is very difficult or impossible. Level 4 Change Requests are to be entered into the Change Management Data Base at least thirty (30) business days prior to the planned implementation date. The Requester or representative for a Level 1 change is required to attend the Change Communication meeting immediately prior to implementation so that any questions or concerns may be addressed. Whenever a Level 4 change must be expedited to address a critical timing situation, a special meeting must be held. To expedite a Level 4 change, all parties that may be affected by this change must be present or represented at the special meeting. It is the responsibility of the change requester to arrange the meeting and assure attendance by the required groups or individuals. If the required groups or individuals cannot be assembled, the change cannot be expedited and an escalation will be required. How do you know that the change falls under Level 4?

IT Change Management Procedure

XXXXX Page 13

For non-application changes:

From the end user's eyes, is it possible for the change to have a major impact on services if problems occur?

Is the change visible to all end users? Is this a high-risk change? Is this the first time this change has been done? Is the change difficult or impossible to backout? Is it extremely difficult to install the change? Does the change involve a lengthy install time?

For application changes:

Would failure of the job being changed stop the flow of all jobs for critical files or an application system?

What types of management approval is required for Level 4 changes? Approval required by:

• Change Review Board • Manager of user department requesting change

Depending on the scope and impact of the proposed change, approval by one or more of the following individuals may be required.

• Operations Manager • Application Development Manager • Network & Technical Services Manager.

Level 3 Changes A Level 3 Change may impact a large number of end users. It is a high-risk change that requires a significant effort to backout. Level 3 Change Requests must be entered into the Change Management database fifteen (15) business days prior to implementation. All Level 3 changes will be communicated via the Change Management reporting system. The requester or representative for a Level 3 change is required to attend the Change Communication Meeting immediately prior to implementation so that any questions or concerns may be addressed.

IT Change Management Procedure

XXXXX Page 14

How do you know that the change falls under Level 3? For non-application changes:

Will the change be visible to a large number of end users? Is this a high-risk change? Has the change been done only infrequently? Will a significant effort be required to backout the change? Is it difficult to install the change?

For application changes:

Would failure of the job being changed stop the flow of jobs for non-critical files or applications?

What types of management approval is required for Level 3 changes? Approval required by:

• Manager of user department requesting change • Network & Technical Services Manager • Change Review Board

Level 2 Changes A Level 2 Change is not transparent, but is minimal in risk and impact. It is the responsibility of the Requester to notify any areas of a potential impact. The change is a Level 2 if it requires an IPL of a system, subsystem or the restart of a critical component on a production system. Level 2 Change Requests must be entered into the Change Management database prior to the Scheduled Change Window being requested. The Requester or representative for a Level 2 change is required to attend the Change Communication meeting immediately prior to planned implementation so that any questions or concerns may be addressed. All Level 2 changes will be communicated via the Change Management reporting system and will be tracked and reported by the Change/Problem Coordinator. Examples of Level 2 changes:

• Single fixes - APAR, PTF, etc. • Low usage program product upgrades, installations • PARMLIB updates which require an IPL to implement • Regular maintenance updates to system or application libraries • Hardware Preventative Maintenance • Data management to critical volumes

IT Change Management Procedure

XXXXX Page 15

How do you know that the change falls under Level 2? For non-application changes:

Will the change have only minor impact on services provided to the end users if problems occur?

Will the change be visible only to a small group of end users? Is this a moderate risk change? Is the change relatively simple to install? Has the change been implemented successfully a number of times before? Does it require only a moderate effort to backout the change quickly? Will it require only an IPL, recycle of major application or reloading of an NCP

to implement or backout? For application changes:

Is this the first time the job has been installed? Must this job be fixed to run tonight?

What types of management approval is required for Level 2 changes? Approval required by:

• Manager of user department requesting change • Change Review Board

Level 1 Changes A Level 1 Change has little or no external visibility, no external dependencies or no operator intervention. There is no associated risk or impact with the change, either to the system if the change is incompatible or to the Requester if the change implementation is delayed. The change does not require an IPL or recycle of an application to implement or backout. Level 1 changes are entered into the Change data base and will be communicated daily to any affected areas where impact or interest can be identified outside of the Requester's own area. How do you know that the change falls under Level 1? For non-application changes:

Will the change have only minimal or no impact on services provided to the end users if a problem occurs?

Is the change familiar or common to those who will implement it? Is the change reliable and low risk?

IT Change Management Procedure

XXXXX Page 16

Is the change easy to backout if a problem occurs? Can it be backed out without an IPL, recycle of a major application, or

reloading of an NCP? For application changes:

Would failure of the job stop just this job? Is this a low priority job (target within three days)?

What types of management approval is required for Level 1 changes? Approval required by:

• Manager of user department requesting change • Change Review Board

IT Change Management Procedure

XXXXX Page 17

Change Level Summary Table The following table is a guide for establishing the initial change level.

Considerations

Level 1

(Minimal Risk)

Level 2

(Low Risk)

Level 3

(Medium Risk)

Level 4

(High Risk)

Organizational Visibility of Change

or Financial Exposure

Routine IT activity or minimal financial

exposure

Visible to Directors or Principals or low financial exposure

Visible to the Board level or medium

financial exposure

Visible to the Board level, high financial

exposure or negative external

publicity

Impact to other Systems or

Applications

None 1 other system or application related

to change

2 - 3 other systems or applications

related to change

4 or more systems or applications

related to change

Back Out

Effort

Minimal Back out In place and easily executed

Back out possible, though not easily

executed

Back out difficult, impossible or undesirable

Business Process Change

Minimal Little change required

Moderate change required by IT

and/or customers

Considerable and complex change

required by IT and/or customers

Scope of Change Single component, such as hardware, software or network

on one platform

Two such components on one

platform

Hardware & software & network

on one platform

Hardware & software & network

across platforms

Degree of Visibility to IT Customers

Minimal Low Medium High

Change Experience

Existing technology,

considerable experience

Existing technology, some

experience

New technology, limited experience

New technology, no experience

Expected Time to Complete

1 month or less

1 quarter or less 6 months or less Greater than 6 months or

mandated due date

IT Change Management Procedure

XXXXX Page 18

Risk/Complexity Scoring

The following matrix is designed to assist the Change Sponsor, Change Implementer, Change Requester and the Change Review Board in determining the appropriate assignment of the change category. This is only a guideline, as changes may be categorized at a different level based on management judgment of the risk/complexity involved.

Factor: Points Organizational Visibility of Change or Financial Exposure:

Visible to Executive Vice President level, high financial exposure or negative external publicity

Visible to Senior Vice President level or medium financial exposure 2

Visible to First Vice President level or low financial exposure 3

Routine IT Activity or minimal financial exposure 4

Impact to other Systems or Applications:

4 or more systems or applications related to change 1

2 - 3 other systems or applications related to change 2

1 other system or application related to change 3

None 4

Back Out Effort:

Back out difficult, impossible or undesirable 1

Back out possible, through not easily executed 2

Back put in place and easily executed 3

Minimal 4

Business Process Change:

Considerable and complex change required by IT and/or the customers 1

Moderate change required by IT and/or the customers 2

Little change required 3

Minimal 4

Scope of Change:

Hardware & software & network across platforms 1

Hardware & software & network on one platform 2

Two components on one platform 3

IT Change Management Procedure

XXXXX Page 19

Factor: Points

Single component 4

Degree of Visibility to IT Customers:

Minimal 1

Low 2

Medium 3

High 4

Change Experience:

New technology, no experience 1

New technology, limited experience 2

Existing technology, some experience 3

Existing technology, considerable experience 4

Expected Time to Complete:

Greater than six months or mandated due date 1

6 months or less 2

1 quarter or less 3

1 month or less 4

Risk/Complexity Scoring Grid

If the Total Score Equals: Then Risk/Complexity Level Assigned is:

8 - 14 4(Maximum)

15 - 20 3

21 - 26 2

27 - 32 1(Minimum)

IT Change Management Procedure

XXXXX Page 20

Summary of the XX Change Management Procedures

The following are the procedures to be used when implementing changes in the XX IT environment. A more detailed explanation of these procedures is contained in the following pages:

A change request form will be filled in for all changes to be implemented. This is done to ensure that all changes are sufficiently communicated to all potentially impacted parties as well as for future reference. All changes must have management approval commensurate with their risk assessment levels (see Change Request Form section).

There is a group called the Change Review Board (CRB) that meets periodically to review requests for change to the IT environment, change assessments and implementation of changes (see XX Change Review Board section).

All requested changes will be entered into the Change Management System prior to implementation. This includes Emergency and Exception Changes.

The requester will assign the appropriate risk assessment category (1, 2, 3, 4, or E), taking into account the impact to the user community in the event of failure of the change upon implementation (see Change Level section).

Once the request is submitted, a Technical Assessment will be scheduled. This is a review of the request by appropriate parties to determine the technical impact of the change to the environment. This review will encompass:

Technical Impact/Risk Analysis Technical Adequacy of plans Dependencies and/or conflicts Ensuring compliance with existing Strategies, Plans and Change

Management Standards The resulting analysis of this assessment is a key input into the change

approval process. A Business Assessment is then done to determine the business impact of

installing or not installing the change. The resulting analysis also becomes a key input into the change approval process.

Once the Technical and Business Assessments are successfully completed, change approval can be given. This is done at any one of the three Change Team meetings which take place weekly (see Meetings section). At this time, the change team assigns a date and time for change implementation. As part of the approval process, it is assumed that, as one of the criteria for approval of the change request, the requester's manager has ensured that the proper testing procedures have been followed and that there was a successful test completed (see Management Approval section).

The change implementation is complete when the requester validates that the acceptance criteria, defined prior to the change install, have been successfully met.

IT Change Management Procedure

XXXXX Page 21

Tracking of the change by the change team stops after the change has been installed and is verified as successful.

IT Change Management Procedure

XXXXX Page 22

Change Request Flows

High Level Process Flow

1. Enter Change Request

5. Approve Change

6. Commit Change

Schedule

7. Deploy Change

8. Change Quality

Assurance

2. Assign Change

Implementer

2. Assign Change

Implementer

3. Monitor Change

Calendar

4. Perform Assessments

9. Close Change 9. Close Change

IT Change Management Procedure

XXXXX Page 23

1. Enter Change Request Flow Description The Enter Change Request flow begins when a change request is submitted. In this activity, all required information about the change and supporting documentation is entered into the Change Management system. The change request should be submitted in accordance with the time frame required by the initial impact assessment. Scope Inclusion

• All changes, including software, hardware, control mechanisms, configurations, environments, facilities, databases, business applications, processes, and procedures.

Scope Exclusion

• Development activities that produce the actual change content. • The coordination of sets of changes (i.e., project coordination). • Testing of the change package.

Goal(s)

• To introduce changes into the environment with minimal disruption to information technology and its users.

• To communicate such that all affected users are aware of changes. • To log all changes into the change management system. • To ensure all pertinent change information is collected. • To ensure all changes meet lead time criteria.

Start Trigger

• Change Request Stop Trigger

• Fully documented and approved change request.

IT Change Management Procedure

XXXXX Page 24

Workflow Diagram for Enter Change Request Workflow Details for Enter Change Request

• Document and Submit Change Request Collect system change request and begin preliminary review of the change.

• Valid Request?

Notify Requester Change Request received –

email [Open CR]

Notify Requester Change Request rejected – phone call or e-mail

Assign request to IT analyst

Conduct Technical Assessment

Valid

Request?

Valid

Request? Close Change

Yes

Complete Change Record to Request Level

Establish Initial Impact

Document and Submit Change Request

IT Change Management Procedure

XXXXX Page 25

Determine whether or not to submit change request into change management system based on whether the request form has a managers signature, it is within IT responsibility, and filled in correctly.

• Notify Requester Change Request rejected – phone call or e-mail If change request is rejected, provide a form of notification.

• Notify Requester Change Request received – email [Open CR] If change request is approved for the change management system, a change record is opened and a change number is assigned. A notification is auto-sent to the change requester by Peregrine.

• Assign request to IT analyst Assign the change request to an initial analyst to review the change record.

• Establish Initial Impact Determine impact of the change to the customer community. This will include times when service is not available, testing time, new procedures, new support requirements, and any other impact that may occur as a result of the change.

• Conduct Technical Assessment Determine the feasibility of the change from a technical perspective. This assessment will include the amount of resources, level of knowledge, and skills necessary for the change.

• Complete Change Record to Request Level Based on initial impact and technical assessment, determine the type and category level of change, and complete all descriptive fields. Additionally, the completeness of the change success criteria is validated.

• Valid Request? Based on the initial assessments, determine whether to perform this change. This decision is based on the change conforming to the strategy, resources being available, and whether or not it is already being worked on.

• Close Change Mark change record as closed when it doesn’t pass validation requirements.

IT Change Management Procedure

XXXXX Page 26

2. Assign Change Implementer Flow Description The Assign Change Implementer flow begins once a change request has been documented and selected for the change management process. During this workflow, a change record is assigned to an appropriate owner, the change record is updated with this assignee information, and the change is sent to the assignee. Scope Inclusion

• All changes reviewed by the Change Review Board. Scope Exclusion

• Changes not accepted by the Change Management process or Changes not reviewed by the Change Review Board.

Goal(s)

• To ensure that change requests are assigned to appropriate implementers. • To ensure that the change management workload is allocated by area of

expertise. • To balance workload within an area of expertise.

Start Trigger

• Initial change record. Stop Trigger

• Initial change record is assigned to an owner.

IT Change Management Procedure

XXXXX Page 27

Workflow Diagram for Assign Change Implementer Workflow Details for Assign Change Implementer

• Update Change Record w/ Assignee Assign the change an owner based on the classification of the change.

• Send Change to Assignee Place the assignee information into the change record and send an e-mail notification to the assignee.

Update Change Record w/ Assignee

Send Change to Assignee

IT Change Management Procedure

XXXXX Page 28

3. Monitor Change Calendar Flow Description The Monitor Change Calendar flow determines the scheduling for changes to be deployed. During this workflow, changes are penciled into a calendar, and the schedule is monitored for changes that are completed or have run out of time in their scheduled change deployment window. If time has expired for a change then it can be escalated and rescheduled based on escalation standards. Scope Inclusion

• Changes that are formally put into the change calendar. Scope Exclusion

• Changes that are not formally put into the change calendar. Goal(s)

• Monitor the change calendar for changes that have not been completed and have run out of time for the purpose of change escalation.

• Allow for changes to be rescheduled. • Allow for changes to be removed from the change calendar upon completion.

Start Trigger

• A change request has been assigned an owner and has been sent to that assignee.

Stop Trigger

• A change is complete and removed from the calendar.

IT Change Management Procedure

XXXXX Page 29

Workflow Diagram for Monitor Change Calendar Workflow Details for Monitor Change Calendar

• Change Complete? Monitor the change calendar for change work that has been completed.

• Time Expired? Determine whether a change record that is incomplete has run out of time.

• Escalate Change Reclassify the change to a higher change category level if time has expired.

• Reschedule Change Update the calendar with a schedule for the change after it has been escalated or if the change package is incomplete.

Change

Complete? Escalate Change

Time

Expired?

Yes

YesNo

No Reschedule

Change

Complete? Escalate Change

Time

Expired?

Yes

YesNo

No Reschedule

Change

IT Change Management Procedure

XXXXX Page 30

4. Perform Assessments Flow Description The Perform Assessments flow involves conducting both a business and technical review of the change package. The assessments determine if the change package is complete and can therefore continue through the change management process. Specifically, the perform business assessment flow involves validating the impact of the proposed change on XX from a business perspective, evaluating the completeness of the success criteria and communication plan and reviewing the backup / backout / recovery plans. The assessment looks at the proposed timing of the change and ensures that the customer’s management has given the agreement necessary for the change to be approved and scheduled. Standards, business requirements, and SLAs are reviewed and a recommendation is made to approve, reject, or reschedule the change. The perform technical assessment flow reviews the completeness of the change plan, test plan, backup / backout / recovery plans, platform impact assessment, estimated install time, etc. from a technical perspective. The change success criteria are validated and the impact of the change to the environment is reviewed to ensure it has been accurately evaluated. Technical standards are enforced and a decision is made to approve, reject, or reschedule the change. Scope Inclusion

• All documented changes with a change category that requires a formal business or technical assessment.

Scope Exclusion

• Changes with change categories that specifically do not require formal business or technical assessments.

Goal(s)

• To ensure that all factors have been taken into consideration in terms of the business aspects of the change.

• To ensure that all factors have been taken into consideration in terms of the technical aspects of the change.

• To ensure that everything required to deploy the change and to maintain service is included in the change request.

Start Trigger

• Fully documented change record.

IT Change Management Procedure

XXXXX Page 31

Stop Trigger

• Assessed (business or technical) change Workflow Diagram for Perform Assessments Workflow Details for Perform Assessments

• Business Review of Change Package Review the change package for the following points:

o Ensure that the business requirements will be met. o Verify existence and completeness of backup / backout recovery plans. o Verify existence of test plans, including the testers names and expected

results. o Ensure that the change conforms to business standards and policies. o Determine whether the change conforms to service level agreements. o Review communication plan for change.

• Technical Review of Change Package Review the change package for the following points:

o Determine the impact on the technical environment. o Ensure that the change conforms to technical standards. o Verify the completeness of the change plan.

• Package Complete?

Business Review of Change Package

Package

Complete?

Return to Assignee

Yes

Technical Review of Change Package

IT Change Management Procedure

XXXXX Page 32

Make a decision on whether the package is complete based on the results of the business and technical reviews.

• Return to Assignee If the package is determined not complete than the change is returned to the assignee and can be rescheduled.

IT Change Management Procedure

XXXXX Page 33

5. Approve Change Flow Description The Approve Change flow is initiated as soon as both the business and technical assessments have been completed. If the change is approved, it is passed on to the next sub-process to finalize scheduling. If the change is rejected or determined to be rescheduled, it may be sent back to the business or technical assessment sub- processes once the necessary actions are taken. All parties that have been involved to this point in the process should be notified of the approval, rejection or rescheduling. Scope Inclusion

• All changes that have been forwarded for approval from a business and technical perspective and whose change categories indicate the requirement for formal approval.

Scope Exclusion

• Changes with change categories that specifically so not require formal approval. Goal(s)

• To ensure that appropriate approval is obtained for change requests. • To ensure that the change record is properly updated. • To minimize service interruption.

Start Trigger

• Completed change record with business and technical review including recommendation.

Stop Trigger

• Approval for change deployment.

IT Change Management Procedure

XXXXX Page 34

Workflow Diagram for Approve Change Workflow Details for Approve Change

• Final Change Review Final review of change prior to acceptance and scheduling.

• Accept Change? Based on the result of the final change review, determine whether to go ahead with or close the change.

• Close Change If it is decided not to continue with change, then change record is closed by change coordinator.

• Notify Requester Change Request rejected – phone call or e-mail

Final Change Review

Change?

Yes

No Notify Requester Change Request rejected – phone call or e-mail

Close Change

IT Change Management Procedure

XXXXX Page 35

6. Commit Change Schedule Flow Description During this sub-process, a consolidated change schedule is compiled for all approved changes for a particular period of time. Any conflicts between changes are resolved at this point and a final schedule is produced. This sub-process is also responsible for performing the activities needed to communicate the change schedule and gain agreement from the Change Implementers and Requesters regarding implementation dates. All affected parties are given final notification. Scope Inclusion

• Includes scheduling around resource constraints and backout times. • The combination of all approved changes to ensure there are no conflicts during

a given period of time. • Negotiation of schedule changes due to conflicts.

Scope Exclusion

• Emergency changes. • Changes not requiring scheduling (i.e., those changes which have no impact on

business / users – adding printers, adding users) • Assignment of personnel or resources

Goal(s)

• To ensure all changes are properly scheduled for a particular period of time. • To ensure those responsible for service delivery are informed about the final

change. Start Trigger

• Approved change record with completed technical and business reviews. • Current consolidated change schedule.

Stop Trigger

• Scheduled change.

IT Change Management Procedure

XXXXX Page 36

Workflow Diagram for Commit Change Schedule Workflow Details for Commit Change Schedule

• Schedule Change Commit the change to the change schedule.

Schedule Change

IT Change Management Procedure

XXXXX Page 37

7. Deploy Change Flow Description The deploy change flow is where the change is actually implemented. Upon the completion of the implementation, a user acceptance test is conducted to determine whether or not the change was successfully installed. If the change implementation is not successful, then it is determined if it can be fixed. If it can be, then it is re- implemented and acceptance tested. Scope Inclusion

• Change requests that require a formal implementation and user acceptance testing process.

Scope Exclusion

• Change requests that do not require formal implementation and user acceptance testing processes.

Goal(s)

• To determine whether the deployed change was successful or not. • Allow for the unsuccessful change installations to be fixed and re-tested.

Start Trigger

• A change request has been scheduled for deployment. Stop Trigger

• A change request has been successfully deployed.

IT Change Management Procedure

XXXXX Page 38

Workflow Diagram for Deploy Change Workflow Details for Deploy Change

• Implement Change Deploy the change and execute the test plan.

• Conduct User Acceptance Test Perform a user acceptance test to determine whether or not the change was deployed successfully.

• Successful Change?

• Can be fixed during install? Determine whether or not a change can be fixed during install or if it needs to be rejected and removed.

• Fix change Modify the change record to record any change fixing activity. Perform the fixes and then re-deploy and re-test.

• Reject change and remove from install Send out notifications to requester that the change has been rejected. Determine whether or not the change will be rescheduled or restarted.

Implement Change

Conduct User Acceptance Test

Successful

Change?

Reject change and remove from install

Can be fixed

during install? Fix change

Yes

IT Change Management Procedure

XXXXX Page 39

8. Assure Change Quality Flow Description The Assure Change Quality flow is a post-change workflow that reviews the change request process. During this workflow, the change management process can be updated and lessons learned are collected. This information is used to make continuous improvements on the change management process. Scope Inclusion

• Changes that formally go through the change management process. Scope Exclusion

• Changes that do not formally go through the change management process. Goal(s)

• Ensure that the change management process is continuously improved. • Allow a mechanism to collect lessons learned for future change management

updates. Start Trigger

• A change is deployed or cancelled.

Stop Trigger

• A post-change review has been conducted and process improvements and lessons learned have been extracted.

IT Change Management Procedure

XXXXX Page 40

Workflow Diagram for Assure Change Quality Workflow Details for Assure Change Quality

• Conduct Post-Change Review Conduct a review of the change management process to determine what went wrong, what went right, and what changes to make to the process.

• Process Changes? • Updated Change Process

If changes to the process are identified, then recommend these changes be made to improve the process.

• Lessons Learned? • Document Lessons Learned

Document any lessons learned that were uncovered during the post-change review. Use the lessons learned to recommend changes to procedures.

Conduct Post- Change Review

Process

Changes?

Yes

Update Change Process

Lessons

Learned?

Yes

Document Lessons Learned

IT Change Management Procedure

XXXXX Page 41

9. Close Change Flow Description The Close Change flow is used to close changes that have been deployed or cancelled following a post-change review. After a change is closed, the problem management system is notified of change activity and requesters are notified of change closure. Scope Inclusion

• All deployed changes • All cancelled changes

Scope Exclusion

• None Goal(s)

• To close change records with all required information. Start Trigger

• Change record where deployment has been indicated as complete. • Cancelled change record.

Stop Trigger

• Closed change request.

IT Change Management Procedure

XXXXX Page 42

Workflow Diagram for Close Change Workflow Details for Close Change

• Update Change Records Update the change records with emergency change documentation, implementation activity, and problem activity.

• Close Changes Change coordinator changes the status of the change record to closed.

• Notify Problem Management system of Change activity The problem management system is notified of changes so that the help desk can notify appropriate backout / recovery personnel if needed.

• Notify Requestors of Change Closure Send an automated e-mail to the change requester to inform them of change closure.

Update Change Records

Close Changes

Notify Requesters of Change Closure

Notify Problem Management

system of Change activity

IT Change Management Procedure

XXXXX Page 43

Change Request Form The following page contains the Request for Change form. The following is a description of what should be entered into each section of that form:

• DATE REQUESTED - The date the request was submitted to the Change Review Board (MM/DD/YY)

• DATE PLANNED - The date the requester would like to implement the change (MM/DD/YY)

• PEREGRINE NUMBER - The unique Change Request number assigned by the Change Management System. This number should be used in all communications pertaining to this change.

• REASON FOR CHANGE - The business and/or technical justification for the change.

• DESCRIPTION OF CHANGE - A detailed description of what the requester wishes to change and what is to be accomplished as a result of the change.

• REQUEST CATEGORY – The scope of the change, i.e., to which environment it applies

• PROJECT CATEGORY – The size or complexity of the project.

• CHANGE TYPE – Whether the change applies to the Administrative environment or the Instructional environment

• RISK ASSESSMENT CATEGORY - The category of risk that the requester has determined the change should be assigned.

• USER ACCEPTANCE CRITERIA DEFINED AND AGREED TO? – This YES or NO question is to insure that the individual responsible for accepting the change on behalf of the users has defined the means for IT to judge the quality of the installation.

• CHANGE REQUESTED BY - The name of the person requesting the change.

• LOCATION – Location of the requester or location of the change (system)?

• CHANGE AUTHORIZED BY - (For applications or systems changes where there is an owner (e.g., Chauncery or SIS) - The signature of the Owner of the system or application.

• CHANGE APPROVED BY - The signature of the approver(s) of the change. This may be singular or multiple based on the risk category of the change.

• DISPOSITION – The status of the change after review by the approver. Can be approved, conditionally approved or rejected.

• INDIVIDUAL RESPONSIBLE FOR IMPLEMENTATION - The name of the person responsible for actually implementing the change. This is, quite often, different than the requester.

• INDIVIDUALS RESPONSIBLE FOR TEST - The name(s) of the person responsible for the unit and systems test as well as the name of the user responsible for user acceptance test.

• TEST SCHEDULE - The end dates the unit, system and user acceptance testing will be completed (MM/DD/YY).

• COMMUNICATION PLAN - The plan to notify all potentially affected users of the change.

• USER MANUALS AND OPERATING INSTRUCTIONS UPDATED - The manuals and instructions which have to be updated as a result of the change and the target completion date for those updates.

• FALLBACK PROCEDURE - The actions to be taken by the operations staff in case of unsuccessful implementation of the change.

IT Change Management Procedure

XXXXX Page 44

• DATE IMPLEMENTED - The date that the change was implemented or tried to be implemented (MM/DD/YY).

• TIME IMPLEMENTED - The start time of the implementation (HH:MM).

• CHANGE IMPLEMENTED BY - The person who performed the implementation.

• CHANGE ACCEPTED BY – The person accepting the change on behalf of the change requester.

• DATE CHANGE RECORD CLOSED – The date that the Change Request was closed in the Change Management system and the person closing the change request.

The {blue text} on the form indicates that the item appears on the XX-0028 form but not on the XXX form. It should be added to the XX Change Record. The (red text) on the form indicates items that are not on the XX-0028 from but are on the XXX form. The items should be on the XX Change Record. The black text on the form indicates that the item appears on both forms and the [bracketed text] is the name of the item on the XX-0028 form.

IT Change Management Procedure

XXXXX Page 45

CHANGE REQUEST FORM

DATE REQUESTED ___[Date]__________ DATE PLANNED_[Target Completion Date]_____________ PEREGRINE CHANGE NUMBER ___________ [Control No.]___________________________________ REASON FOR CHANGE _________________[Justification for Request]__________________________ ___________________________________________________________________________________ _ DESCRIPTIONS OF CHANGE __________[Nature of Request]_________________________________ ___________________________________________________________________________________ _ {REQUEST CATEGORY:___LOCAL ___DISTRICT MISSION ___STATE ___FEDERAL ___OTHER} {PROJECT CATEGORY: ____MAJOR ____MODERATE ____MINOR ____AD HOC} {CHANGE TYPE: ADMINISTRATIVE_________ INSTRUCTIONAL________} (RISK ASSESSMENT CATEGORY _______________________________________________________) (USER ACCEPTANCE CRITERIA DEFINED AND AGREED TO? YES____ NO____) CHANGE REQUESTED BY _______[Submitted by:]__________________________________________ {LOCATION _________________________________________________________________________} CHANGE AUTHORIZED BY ______[Approved by:]___________________________________________ (CHANGE APPROVED BY______________________________________________________________) {DISPOSITION: ____APPROVED FOR IMMEDIATE WORK ____APPROVED AS PRIORITIZED ____APPROVED FOR FURTHER INVESTIGATION (Cost/Benefit, Impact Analysis) ____REQUEST REJECTED Explanation:______________________________________________________} {TARGET BEGIN DATE:______________} INDIVIDUAL RESPONSIBLE FOR IMPLEMENTATION _____________[Assigned to:]_______________ (INDIVIDUAL RESPONSIBLE FOR UNIT TEST _____________________________________________) (INDIVIDUAL RESPONSIBLE FOR SYSTEM TEST _______________________________) (INDIVIDUAL RESPONSIBLE FOR USER ACCEPTANCE TEST ______________________) (TEST SCHEDULE - UNIT TEST END DATE __________________________________) ( SYSTEM TEST END DATE ________________________________) ( USER ACCEPTANCE TEST END DATE _______________________) (COMMUNICATION PLAN ___________________________________________________) (______________________________________________________________________) (USER MANUALS AND OPERATING INSTRUCTIONS TO BE UPDATED_________________) (______________________________________________________________________) (FALLBACK / BACKOUT PROCEDURE _________________________________________) (______________________________________________________________________)

IT Change Management Procedure

XXXXX Page 46

(DATE IMPLEMENTED - _______________________ TIME IMPLEMENTED - __________) (CHANGE IMPLEMENTED BY - ___________________ ACCEPTED BY - ______________________) (IMPLEMENTATION COMMENTS - ______________________________________________) (DATE CHANGE RECORD CLOSED - ________________ BY ________________________________)

IT Change Management Procedure

XXXXX Page 47

Scheduled Change Windows

To maintain 7x24 stability and achieve IT Service Level Commitments, Information Technology has established predetermined dates and times for implementing changes. These dates and times are as follows:

Wednesday Night/Thursday Morning Change Window

• Midnight - 08:00 Friday Night through Monday Morning Change Windows

• Midnight Friday - 08:00 Saturday • Midnight Saturday 08:00 Sunday • Midnight Sunday - 08:00 Sunday

When requesting a stand-alone window, please notify the Change/Problem Coordinator at least two weeks prior to the requirement. The Wednesday/Thursday change window is for quick problem repair and Level 3 and 4 changes. Changes that require detailed activity or extensive programmer hands-on time or intervention should be scheduled in the weekend windows. Emergency changes that fall outside the change windows and can be performed by Operations should be scheduled on second or third shift.

IT Change Management Procedure

XXXXX Page 48

Lead Times for Changes

The following guidelines for entering a change request allow time for changes to be coordinated more efficiently. These guidelines highlight the number of days from initial request until installation. The earlier a change is entered into the system, the better communication it will receive through the Change Process. Coordination with other affected departments and notification of users remains a responsibility of the requester.

• Level 4 - 1 workday • Level 3 - 3 workdays • Level 2 - 15 workdays • Level 1 - 30 workdays

IT Change Management Procedure

XXXXX Page 49

Unsuccessful Changes

The following guidelines will be used to determine if a change has been unsuccessful (CU) or caused an outage (CO) to service.

Expected results did not occur. Change caused an impact to the User or Operations. Change must be backed out. Incomplete instructions or inaccurate documentation provided to

Operations. Change could not be installed in requested time period. Problem opened as a direct result of the change

Level E Change - problem severity 1,2,3,4 Level 1 Change - problem severity 1,2,3 Level 2 Change - problem severity 1,2,3 Level 3 Change - problem severity 1,2 Level 4 Change - problem severity 1,2

Unsuccessful Changes For any change that is closed CU (Change Unsuccessful), the Change Requester must enter into the Change Request the reason(s) why the change was unsuccessful. The requester must also enter another change request into the system before the change will be attempted or scheduled again. The level of the new change request will be the same as the original; however, the new change request will have to cycle through the complete approval process again.

Changes Causing Outages A change that was attempted or implemented and caused a disruption of committed service delivered by Information Technology to the user will be closed as causing an outage (CO). For any change which is closed as CO, the Change Requester must enter into the Change Request the reason(s) why and how the outage occurred. The requester must enter another change request into the system before it will be attempted or scheduled again. The level of the new change request will be the same as the original; however, the new change request will have to cycle through the approval process again.

Changes Causing Intervention The Closed Intervention (CI) status will be used to indicate a change that was installed successfully but required unplanned intervention from applications programmers, systems programmers, users, analysts or operations personnel after normal business hours.

IT Change Management Procedure

XXXXX Page 50

Canceled Changes A change that was entered and later canceled will be closed as Change Canceled (CC). For any change that is closed CC, the Change Requester must enter into the Change Request the reason(s) why the change was canceled. The Requester must enter another change in the system before it is attempted again. The level of the new change request will be the same as the original. The resubmission requirements for the new change will be negotiated between the Change Coordinator and the Change Requester.

Postponed Changes A change that was scheduled but during the installation process could not be safely promoted (ran out of time, potential scheduling impact found, etc.) will be coded as a Postponed Change (PC). The change will be automatically rescheduled for the next Change Window.

IT Change Management Procedure

XXXXX Page 51

Roles and Responsibilities

Change Review Board The Change Review Board (CRB) is a team of people made up of IT management and subject matter experts, members of the user community, vendors and outside consultants. It is chaired by the Change Coordinator. The mission of the Change Review Board is to plan and monitor all changes introduced into the IT environment. Responsibilities include ensuring the following things are present for every change:

The Change Request has been submitted with the required information There is a business reason for the change A user has been identified who is totally accountable for the change A viable Change Plan exists A viable Recovery Plan exists A viable User Acceptance Plan exists A Technical Impact Assessment has been done A Business Impact Assessment has been done A Communications Plan has been developed ensuring communication to the

IT and user communities of the intended change and the potential impact to them in case of failure of the implementation.

Appropriate management approval has been obtained based on the risk assessment category.

A post installation review of the completed change to ensure proper and successful implementation.

IT Change Management Procedure

XXXXX Page 52

Change Coordinator The Change Coordinator acts as the user’s primary interface into the change process and represents their interests and the IT requirement to meet service commitments. The Change Coordinator’s responsibilities for specific changes include: Owns, maintains and ensures accuracy and timeliness of the consolidated change

schedule Ensures that all changes are appropriately planned and communicated Reviews change requests for procedural compliance, information quality and

completeness Ensures that accurate priority and impact are assigned to change requests Coordinates and owns the change approval and rejection process which

incorporates routing to reviewers, receiving reviewer responses and relaying appropriate information to requesters. This also includes negotiation with both parties and final ruling

Undertakes post change reviews and owns the sign off mechanism Schedules and attends all meetings concerning the Change Management process Ensures that asset and configuration updates are only permanently applied as a

result of successful and signed-off changes Participates in project meetings with applications development teams and the

business where the subject is change impact analysis, implementation and scheduling of large changes

Responsible for owning efficient and quality problem resolution, where Change Management service expertise is required

Responsible for escalation and exception reporting to the Change Management Process Owner

Complies with Change Management service standards, process and procedures as required

Provides input to Change Management service improvement Provides and is responsible for the accuracy of appropriate Change Management

service input to knowledge bases as a result of changes and problem resolution Responsible for contract management and day to day maintenance management of

third party technology suppliers as a result of Change Management issues with the service

Initiates and is a technical resource to the IMAC service where Change Management service expertise is required

Provides a technical resource to Project Requests where Change Management service expertise requirement forms an element of the project

Captures and reports appropriate Change Management service measurement data Attends appropriate problem escalation / resolution, project development and

service support reviews, where Change Management service expertise is required

IT Change Management Procedure

XXXXX Page 53

Change Requester

The Change Requester initiates and completes the Change Management process and has overall responsibility for accepting changes. Standards dictate who can act as a change requester. Change Requester responsibilities for given changes include: Owns individual changes requested and is ultimately responsible for the success of

the change Review change request with department manger for approval Assess the change for risk/impact and ensure the appropriate risk category has

been applied. Ensure that the change request is complete with accurate information at a sufficient

level of detail to implement the change without intervention. Ensure Proper lead-time for changes is allowed. (See "Lead Time for Changes"

section in this document). Conduct User Acceptance testing of change. Convene the Level 1 Expedite meeting as required. Communicate intention of change to all potentially affected parties. Notify the Change Coordinator of any change in date or time of implementation

before the target date is reached.Initiates the Change Control service by completing and distributing a completed change request

Responsible for obtaining appropriate resource for all change tasks requiring completion for change success

Co-ordinates task documentation within a change request with other participating staff as appropriate

Ensures that pre and co-requisites for the change are considered and completed Ensures completeness of reviewer distribution list as much as possible Attends change assessment, scheduling and review meetings, as appropriate Responsible for accurate representation of priority, impact and change window / time

requirements Ensures all owned rejected changes are placed into a ‘fit state’ for re-submission Co-ordinates implementation tasks where appropriate and is responsible for any

backout decisions for owned changes in conjunction with Change Control Updates owned change requests as required and requested Responsible for undertaking change tasks within the change implementation as

required Participates in change task co-ordination meetings as part of change implementation

planning

IT Change Management Procedure

XXXXX Page 54

Change Implementer

The Change Management Implementer has overall responsibility for understanding the requested change; documenting its implications on both the business and the IT environments; creating, with other resources as required, the coding, system, procedure and/or process modifications required to implement the change; with the Change Requester, representing the change to the Change Review Board; monitoring and/or testing the code prior to final promotion into production and requesting change closure by the Review Board. Specific Change Implementer responsibilities include:

Monitoring the Change Assignment process for assigned Changes Meeting with the Change Requester to understand the requested change and to

complete the Change Request documentation As required, assisting the Change Requester in the preparation of a business case

for the change With the Change Requester, presenting the Change to the Change Review Board

from a technology and IT architecture perspective for approval to proceed Developing technology and operations impact statements Developing backup and/or back out plans Identifying and assembling the team required to create the change Designing and creating the code, procedures or process modifications required to

effect the change Designing and developing the tests required to demonstrate the quality and

usefulness of the change With the Change Requester, presenting the completed change to the Change

Review Board for approval to promote into production Monitoring the promotion (on site or remotely) of the change into production Resolving issues associated with promoting the change into production, where

possible With the Change Requester (as appropriate), participating in the review of the

promotion of the change Requesting closure of the successful change from the Board

IT Change Management Procedure

XXXXX Page 55

Change Management Process Owner

The Change Management Process Owner has overall responsibility for ensuring the quality of the Change Management process. Specific Change Management Owner responsibilities include:

Is responsible for and owns the Change Management service Is responsible for development and implementation of Change Management mission

and strategy, in line with XXXXX and IT strategies Escalates to senior management exceptions as appropriate Ultimately responsible for resolving Change Management service dissatisfaction Ensures compliance with Change Management process standards and procedures Has a nominated deputy to cover for service owner absence Sponsors and/or manages internal improvement projects to implement new

technology and process improvement Communicates Change Management service procedures and working practices and

changes to internal standards, processes, procedures and technology Coordinates and sets annual service requirements, objectives and targets for the

Change Management service in conjunction with other IT Process Owners Finalizes annual service requirements, objectives and targets with the Service

Request, Call Center and Problem Management Process Owners Attends appropriate senior management level service support and development

reviews Involved in development of and subsequent agreement on service level targets and

target improvements related to the Change Management service Develops requirements for Change Management standards, procedures,

measurements, tools and technology in conjunction with other IT Process Owners Approves and sponsors Change Management improvement ideas

IT Change Management Procedure

XXXXX Page 56

Service Center Administrator

The Service Center Administrator has overall responsibility for monitoring and configuring the Change and Problem Management processes. Specific Change Management responsibilities include:

Developing requirements for Change Management standards, procedures,

measurements, tools and technology in conjunction with other IT Process Owners Managing the tools and procedures that support Change Management Identifying process, procedure and tool improvements that may benefit XXXXX to

the Change Review Board Making changes to the processes, procedures and tools that support the Change

Management process as directed by the Change Review Board Escalating to XX senior management issues as appropriate Ensuring compliance with Change Management process standards and procedures Communicating changes to Change Management internal standards, processes,

procedures and technology Attending appropriate senior management level service support and development

reviews

IT Change Management Procedure

XXXXX Page 57

Change Controller

The Change Controller is responsible for scheduling and overseeing all changes introduced into the IT production environments and service delivery infrastructure to ensure that the risk of impacting the availability of services is minimized. Specific responsibilities include: Monitoring Change Categories and Service Risks Ensuring that all Information Technology customer and Company interests are

protected Building and maintaining the Consolidated Change Schedule: Integrating new changes into the existing change schedule Identifying conflicts in the schedule, and negotiating adjustments with the relevant

parties Notifying affected parties that changes are scheduled and ready for implementation Monitoring the implementation of changes Handling schedule slips and escalating the appropriate parties to recover the

schedule Identifying and resolving change assignment issues Managing change approval Facilitating the Change Review Board meetings Managing exceptions of rejected records Resolving day-to-day change coordination actions Accepting and managing external change input Monitoring regular change control measurements Creating, coordinating, consolidating, and monitoring the change schedule.

IT Change Management Procedure

XXXXX Page 58

Change Scheduler

The Change Scheduler is a delegate of the Change Controller, responsible for the creation, coordination, consolidation, and monitoring of change schedules.

Performs duties delegated by the Change Controller Represents the Change Controller on initial issues relating to the Change Schedule Responsible for the creation, coordination, consolidation, and monitoring of change

schedules.

IT Change Management Procedure

XXXXX Page 59

XX Change Review Board

Change Review Definition The Change Review Board (CRB) is a team of people made up of IT team members supplemented, as required, by members of the user community, vendors and outside consultants. It is chaired by the Change Coordinator.

In addition to these members, other members will be included depending on the change being analyzed. For instance, if the team is analyzing a change to the Network, a Network Specialist or his or her designee will be present to help that analysis. The mission of the Change Review Board is to plan and monitor all changes introduced into the IT environment. Responsibilities include ensuring the following things are present for every change:

IT and user communities of the intended change and the potential impact to them in case of failure of the implementation.

Appropriate management approval has been obtained based on the risk assessment category.

A post installation review of the completed change to ensure proper and successful implementation.

IT Change Management Procedure

XXXXX Page 60

Change Approver Table Change Category Category Definition Approver(s)

Cable / Facilities – Major Wiring for servers, desktops, telephony, networks

Cable / Facilities – Minor

Firmware Upgrade – Major Engineering changes to a device chip

Firmware Upgrade – Minor Mainframe Application Software – Major

Mainframe Application Software – Minor

Mainframe Operating System Upgrade – Major Changes to CIXX, OS/390…

Network System Software – Major Netview, VTAM

Network System Software – Minor

Network Hardware – Major Changes to 8265’s, 8271’s, 3Com switches

Network Hardware – Minor Network Security – Major Firewalls, authentication Network Security – Minor Server Application Software Rollout – Major

Server Application Software – Major

Server Application Software – Minor

Server Hardware – Major Netfinity, disk drives, communication adapters, memory, CPU, CD drive

Server Hardware – Minor Server Hardware Rollout – Major

Server System Software – Major

Windows 2000, Windows NT, Windows XP, AIX, Linux, etc.

Server System Software – Minor

Telephony PBX – Major PBX changes Telephony PBX – Minor Telephony VoIP – Major Voice over IP changes Telephony VoIP – Minor

Desktop – Major XXX, MaXX, Dell, desktop software and hardware

Desktop – Minor

IT Change Management Procedure

XXXXX Page 61

Meetings The major scheduled meetings of the Change Management Process are the Change Review Board meeting. These meetings are held every Monday, Wednesday and Friday with specific agendas for each day's meeting as follows:

Monday The Monday morning meeting of the Change Review Board is called to analyze the change activity from the previous weekend. The analysis is based on successful or unsuccessful change activity. When unsuccessful changes occur, the Change Review Board develops a plan at this meeting to address the issue. All requesters with category 1 or 2 changes scheduled for the preceding weekend or any requester whose change caused problems during the install process are represented at this meeting in addition to the Change Review Board. It takes place at 9:00 A.M. every Monday morning in the IT Conference Room.

Wednesday The Wednesday meeting of the Change Review Board is called to plan future changes. All requests for change are presented at this time for consideration. Permanent members of the Change Team may present category 3 and 4 changes. The requester or his/her manager must present category 1 and 2 change requests. All members of the Change Review Board and any Category 1 or 2 change requesters attend this meeting. It is held every Wednesday at 9:00 A.M. in the Information Technology Conference Room. Any change to be implemented in the IT environment must be reviewed at a Wednesday or Friday meeting.

Friday The Friday meeting of the Change Review Board is called to plan the following weekend's change schedule and analyze the change installation activity from Wednesday. The analysis is based on successful or unsuccessful change activity. When unsuccessful changes occur, the Change Review Board develops a plan at this meeting to address the issue. All requesters whose changes caused problems during the Wednesday installation must be present at the meeting. Anyone expecting to have a change implemented over the weekend must be present at this scheduling meeting to ensure that all prerequisites have been accomplished prior to implementing the change. Category 3 or 4 change requests may be represented by permanent members of the Change Review Board on behalf of the requester; however, if total representation cannot be achieved by these substitutes, then the change will not be scheduled for that weekend. Requesters of Level 1 and 2 changes must be present for their changes to be considered for weekend implementation. This meeting is held every Friday morning at 9:00 A.M. in the Information Technology Conference Room.

IT Change Management Procedure

XXXXX Page 62

XX Change Review Board Meeting Agenda

1. Review of most recent promotion into production activity The planned promotion activity is compared to the actual activity and deviations are noted and discussed. When issues or concerns are identified that have not already been documented this activity will document them. Process quality issues are raised here.

2. Review of outstanding issues (including E-Change issues) Issues that have been raised by the above review, the most recent promotion into production, and previous Review Board meetings are reviewed for relevance, progress toward resolution and escalation.

3. Assignment of issues or resolution of issues Issues are assigned to individual board members for resolution. Issues that can be resolved by the Board without further assignment are resolved and documented. Issues that have been resolved are approved for closure.

4. Review of E-Change activity since last promotion All E-Change activity since the last scheduled promotion into production window are reviewed to determine if the Emergency or Expedite status was warranted, if the packages prepared in support of the changes are complete and if the quality associated with the E-Changes is in line with the quality of Board scheduled changes.

5. Identification and assignment of issues related to recent E-Change activity Issues with either the work done in support of individual changes or the E-Change process itself are raised, documented and assigned for resolution.

6. Review changes proposed for inclusion in the next Change Window The changes proposed by the Change Management system are reviewed for completeness, sponsorship, business impact and technical feasibility. Together, Implementers and Change Requesters present their proposed changes to the Board for approval to proceed.

7. Review the proposed Change Schedule for potential impacts to service Examine, with the help of technical staff, the proposed implementation schedule for the proposed changes.

IT Change Management Procedure

XXXXX Page 63

8. Approve, reject or reschedule changes Where business or technical impacts are likely to occur, evaluate the business case for proceeding and, if the risks are acceptable, approve the promotion. Authorize communication to all affected parties to apprise them of the potential impact. If the risk is not acceptable, remove the change from the promotion package. Where no business or technical impact is anticipated approve the Change for promotion.

9. Review the Change Calendar to assess its integrity Receive requests to formally enter changes into the Change Management system. Examine the requests for completeness, business justification and technical feasibility. Review the Change Calendar for potential impacts with either the customer environment or planned change activity. Schedule a preliminary promotion date on the calendar.

10. Review the Change productivity and quality measurements Review the metriXX for the most recent promotion activity including, number of changes promoted, number of successful changes promoted, number of changed promoted with modification, number of changes backed out of the promotion schedule and number of incident records associated with changes promoted.

11. Identify and assign for resolution issues associated with the Change Process Evaluate the trends and, as required, modify the metriXX, the measurements, the procedures or the Change Process.

12. Review communications planned as a result of the meeting (rejections, approvals, concerns and issues)

Review with the Change Coordinator, the communications that will proceed from the meeting to ensure that all issues are communicated, all parties are included and what is being communicated is the intent of the Board.

IT Change Management Procedure

XXXXX Page 64

Measurements

A number of standard reports on all changes activity are available from the Change Control Coordinator. These reports are available to anyone who has a need for the information. If interested in seeing what is available, please contact the Change Coordinator.

In addition to the standard reports available, all change activity is reported on a monthly basis in the standard Information Technology Monthly Measurement Meeting. These measurements include, at minimum, the following:

Changes logged versus not logged Changes with incomplete information Types of changes by category Number of approved, rejected or rescheduled changes by type Number of changes by risk / impact Number of unsuccessful changes by failure type Number of changes with inadequate information Number of successful changes by category Hours of outage caused by changes Number of rescheduled changes

Other measurements periodically appear in the Monthly Measurements based on management requests.

IT Change Management Procedure

XXXXX Page 65

Glossary

This section contains definitions of terms relevant to the Change Management process. Term Definition

Activation Status Information about the result of change activation activities (that is, status and level of success / completeness of the activation). Approval Lead Times See Lead Times.

Approved Change Request

A change request that has been accepted, assessed and approved, and scheduled for execution.

Authorized Change Initiator

An individual authorized to the Peregrine Service Center to enter changes into the system.

Back out Execution Status Information about the result of back out procedures.

Back out Plan For failed changes, a plan that restores service to previously existing levels. Back out Problem Notification

Defect information created and sent to the Problem Management process as a result of executing back out procedures.

Back out Request A request to execute appropriate back out procedures, as defined in the change back out plan. This request is issued when the completion criteria of an implementation step has not been met.

Business Policy Business considerations and rules that may influence the way processes are managed and executed.

Change

A Change consists of any installation or alteration of hardware, system or application software, procedures, or environmental facilities, which adds to, deletes from or modifies the Information Technology environment or its attached network. Reasons for making changes could be: Addition of a new function Performance improvement Growth Technology change Problem resolution or prevention

Change Calendar The change calendar is a list of accepted changes and their proposed implementation dates.

Change Level

Change levels define the importance of the change being handled within the process. Different levels receive different treatment. There are five levels which represent the implementation complexity and risk:

1 Major 2 Medium 3 Minor 4 Business as Usual 5 Emergency or Exception (E-Change)

Changed Environment

The Information Technology managed resources and environment modified as the result of the change implementation.

Change Status Information about the change implementation activities, including problem resolution status.

Change Flow A change flow shows the activities and the order that those activities must be completed within the change management process.

IT Change Management Procedure

XXXXX Page 66

Term Definition

Change Standards Principles, rules, specifications and prescribed steps to plan, control and execute changes.

Change Record The formal document within the change management system that displays change details and the status of the change.

Change Reports

Formatted information about the result of change planning and implementation activities, communicated to users and customers of the process. This includes information about the progress of change requests (for example, approval status), change plans (for example, Consolidated Change Schedule), change results (for example, problem resolution), process health, etc.

Change Request A request identifying the IT resource(s) to be changed and a description of the change. Change requests may be submitted by any authorized change initiator.

Change Request To Be Rescheduled

A change request which was not approved because the proposed schedule cannot be accepted.

Business Assessment

A validation of the impact of the proposed change on XX from a business perspective, an evaluation of the completeness of the success criteria and communication plan and a review of the backup / backout / recovery plans.

Technical Assessment

A review of the completeness of the change plan, test plan, backup / backout / recovery plans, platform impact assessment, estimated install time, etc. from a technical perspective.

Change Type

There are three change types: Emergency: Changes that are vital to meeting a business need

and cannot conform to the normal change process, particularly the assessment and approval phases. Exception: Changes that are vital to meeting a business need but

cannot conform to the normal change process, particularly lead times. Normal: Changes that follow the change process to the letter.

Change Window

Scheduled time periods established for implementing changes so as to minimize the impact to services and their users. Change windows may vary, depending on the account, on the services, and on the technical environment. The change windows are documented and made available to all individuals involved in the change process.

Consolidated Change Schedule

A report of all changes to be implemented during a given period of time (for example, a week or month), specifying the date and time when each change is scheduled be implemented. The Consolidated Change Schedule also contains information about change dependencies and interactions.

Emergency Change

A change that is vital to meeting a business need and cannot conform to the normal change process, particularly the assessment and approval phases. Emergency changes must be approved or endorsed by either the Director of Information Technology or the Change Management Process Owner prior to implementation.

Endorsement

The endorsement of a change may be necessary where exceptional circumstances dictate that the normal change process cannot be followed. Endorsement includes the authorization to proceed for changes that are not fully approved, and the authorization to stop a scheduled change from proceeding, pending rescheduling. Who is authorized to endorse must be documented and must be reachable at all times.

Escalation Referring unresolved issues that arise during process activities to appropriate and increasing levels of authority to obtain resolution.

IT Change Management Procedure

XXXXX Page 67

Term Definition

Exception Change Changes that are vital to meeting a business need but cannot conform to the normal change process, usually lead times.

IT Change Standard Information Technology standards that may influence the way changes are introduced and managed in the Information Technology environment.

Initial Change Request

A change request which has been accepted by the Change Coordinator. Acceptance includes checking that all required data elements, as defined by the Information Technology change policy for administration, have been completed. Acceptance also commits this request to the change process and all associated activities.

Initial Impact The Change Requesters documentation of the potential impact of the change on XX.

Lead Times

The time intervals required to allow proper analysis and approval of changes prior to their scheduled implementation. There are two lead times, which must be defined for each Change Category to meet Information Technology Requirements.: Analysis Times are based on the category of the change and

reflect the time interval from when the change request is submitted to when it is available for review. This lead time is to ensure that there is sufficient time between raising and accepting a change request to allow the organization to properly analyze its implications. Approval Lead Times shows the time before the scheduled

activation date that changes should be approved. This period is to allow the proper management and control of the change activation to be set up.

Normal Change A change that follows the change process to the letter. Operating Environment

The environment in which an organization performs day-to-day operating activities.

Original Environment

The Information Technology managed resources and environment before the change is implemented.

Outage A disruption of service in a system.

Problem

A problem is any deviation from an expected norm. That is, a problem is any event resulting in a loss or potential loss of the availability or performance to a service delivery resource and / or its supporting environment. This includes errors related to systems, networks, workstations and their connectivity; hardware, software, and applications. The recognition of problems can come from any point in the environment and can be identified using a variety of automated and non-automated methods.

Problem Notification Defect information about a failing IT resource or service sent to the Problem Management process for resolution.

Process Compliance Issue

A non-approved deviation from a formally documented Information Technology process. Process compliance issues are documented in detail and submitted to the Change Review Board for resolution.

Process Improvement

A required improvement to one or more related processes associated with delivery of contracted services or support of the Information Technology infrastructure environment. Required process improvements are documented in detail and submitted to the Change Review Board for further handling.

Process Trend Any process tendency, positive or negative, discovered as a result of analyzing completed requests and reviewing process measurements and reports.

Production Platform A system or component of a system that is responsible for the actual running of a business function.

IT Change Management Procedure

XXXXX Page 68

Term Definition

Quality Assurance The process of determining whether a process, product, or service met its requirements within the given constraints in the most efficient manner possible.

Rejected Change Request

Notification that the request does not comply with change process criteria and, therefore, was rejected.

Request (To Another Process)

A request for action issued by the Change Management process to another process (for example, to the Problem Management process to log and handle Change related problems).

Requester Information

Information identifying the requester of the change (for example, requester’s name, area / department, phone, e-mail address, etc.).

Restored Environment

The Information Technology managed resources and environment that are returned to their original condition as the result of the execution of change back out procedures.

Scheduled Change Request

A change request proposed for execution at a certain date and time. The date and time need to be assessed and approved before execution can actually start. If the proposed date and time are rejected during the approval step, then the request must be rescheduled.

Service Delivery Environment

The hardware, software, network, procedures required for IT to deliver services to end-users.

Service Level Commitments

Thresholds and service windows that may influence the way Information Technology processes are managed and executed.

Target Lead Times See Lead Times. Technical Assessment Standards

Principles, rules, and specifications that must be taken into account when considering the technical impact of a change.

Technical Information

Technical documentation about products involved in the change, as provided by the product supplier / manufacturer. This includes information about the resources to be changed and information about the tools used to implement the change.

Trend Analysis Analysis of process behavior to discover both positive and negative patterns. Trigger An event that initiates another event.

�

THE UK’S LEADING PROVIDER OF EXPERT SERVICES FOR IT PROFESSIONALS

NATIONAL COMPUTING CENTRE

IT Governance Developing a successful governance strategy

A Best Practice guide for decision makers in IT

IT Governance Developing a successful governance strategy A Best Practice guide for decision makers in IT

The effective use of information technology is now an accepted organisational imperative - for

all businesses, across all sectors - and the primary motivation; improved communications and

commercial effectiveness. The swift pace of change in these technologies has consigned many

established best practice approaches to the past. Today's IT decision makers and business

managers face uncertainty - characterised by a lack of relevant, practical, advice and standards

to guide them through this new business revolution.

Recognising the lack of available best practice guidance, the National Computing Centre has

created the Best Practice Series to capture and define best practice across the key aspects of

successful business.

Other Titles in the NCC Best Practice series:

IT Skills - Recruitment and Retention ISBN 0-85012-867-6

The New UK Data Protection Law ISBN 0-85012-868-4

Open Source - the UK opportunity ISBN 0-85012-874-9

Intellectual Property Rights - protecting your intellectual assets ISBN 0-85012-872-2

Aligning IT with Business Strategy ISBN 0-85012-889-7

Enterprise Architecture - understanding the bigger picture ISBN 0-85012-884-6

IT Governance - developing a successful governance strategy ISBN 0-85012-897-8

Security Management - implementing ISO 27000 ISBN 0-85012-885-4

All title are available from NCC see the website for further details www.ncc.co.uk

The National Computing Centre - generating best practice

IT Governance Developing a Successful Governance Strategy A Best Practice Guide for Decision Makers in IT

IT Governance Developing a Successful Governance Strategy

2 3

Foreword For organisational investment in IT to deliver full value, it is recognised that IT has to be fully aligned to business strategies and direction, key risks have to be identified and controlled, and legislative and regulatory compliance demonstrated. IT Governance covers this and more, and in light of recent corporate failures, scandals and failure, enjoys a higher profile today than ever before.

Back in 2003, IMPACT launched an IT Governance Specialist Development Group (SDG) to identify the issues that need to be addressed and to share and further develop the practical approaches to IT governance used in their organisations.

Over the past two years, heads of IT governance from Abbey, Aon, Avis, Barclays, BOC, DfES, Eli Lilly, Learning & Skills Council, Legal & General, NOMS, Royal Mail and TUI Group have examined what they identified as the key topics and, with the guidance of IT governance expert Gary Hardy, have defined the good practices captured in this guide.

For further information on the IMPACT Programme, its Professional Development Programme and the IT Governance and CobiT Specialist Development Group, please contact Elisabetta Bucciarelli on 0207 842 7900 or email elisabetta.bucciarelli@ impact-sharing.com. The IMPACT Programme is a division of the National Computing Centre.

The IMPACT Programme International Press Centre 76 Shoe Lane London EC4A 3JB

IT Governance Developing a successful governance strategy A Best Practice Guide for decision makers in IT

Published by The National Computing Centre Oxford House Oxford Road Manchester M1 7ED

Website: www.ncc.co.uk Tel: 0161 242 2121 Fax: 0161 242 2499

First published November 2005

ISBN: 0-85012-877-8

British Cataloguing in Publication A CIP catalogue record for this book is available from the British Library

Printed and bound in the UK

All rights reserved: no part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise without either the prior written permission of the authors and Publisher or as permitted by the Copyright, Designs and Patents Act 1988. Enquiries for such permissions should be made to the Publisher.

Disclaimer Every care has been taken by the authors, and by the National Computing Centre, and associated working groups, in the preparation of this publication, but no liability whatsoever can be accepted by the authors or by National Computing Centre, or associated NCC working groups, for actions taken based on information contained in this document.

All trademarks acknowledged.

IT Governance Developing a Successful Governance Strategy

2 3

1 IT Governance – The Business Case . . . . . . . . . . . 4 1.1 Why is IT Governance important? . . . . . . . . . . 5 1.2 What does IT Governance cover? . . . . . . . . . . 6 1.3 What are the benef i ts? . . . . . . . . . . . . . . . . . 6 1.4 What is IT Governance best pract ice? . . . . . . . 7

2 Performance Measurement . . . . . . . . . . . . . . . . . . 9 2.1 Why is performance measurement important? . 9 2.2 What does performance measurement cover? . 10 2.3 Who are the stakeholders and what are

their requirements? . . . . . . . . . . . . . . . . . . . . 11 2.4 What should we measure? . . . . . . . . . . . . . . . 12 2.5 What is best pract ice? . . . . . . . . . . . . . . . . . . 12

3 Implementation Roadmap . . . . . . . . . . . . . . . . . . . 14 3.1 Goals and success cr i ter ia . . . . . . . . . . . . . . . 14 3.2 How to get started . . . . . . . . . . . . . . . . . . . . 15 3.3 Who needs to be involved and what are their

ro les and responsibi l i t ies? . . . . . . . . . . . . . . . 16

4 Communication Strategy & Culture . . . . . . . . . . . . . 18 4.1 Who do we need to inf luence? . . . . . . . . . . . . 18 4.2 What are the key messages? . . . . . . . . . . . . . 19 4.3 Communicat ion best pract ices . . . . . . . . . . . . 20 4.4 Developing an inf luencing strategy . . . . . . . . . 20 4.5 Change roadmap . . . . . . . . . . . . . . . . . . . . . 22

5 Capability Maturity & Assessment . . . . . . . . . . . . . . 23 5.1 Why IT capabi l i ty is important . . . . . . . . . . . . 23 5.2 How to measure IT capabi l i ty . . . . . . . . . . . . . 24 5.3 Sett ing matur i ty targets and consider ing

improvements . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4 Roadmap for sustaining the approach . . . . . . . 25 5.5 Sel f assessment tool . . . . . . . . . . . . . . . . . . . 26

6 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1 What are the r isks? . . . . . . . . . . . . . . . . . . . . 28 6.2 What is the best approach for r isk analysis

and management? . . . . . . . . . . . . . . . . . . . . 29 6.3 Using standards and best pract ices –

is cert i f icat ion useful? . . . . . . . . . . . . . . . . . . 30 6.4 What are the roles of management, staf f

and audi tors? . . . . . . . . . . . . . . . . . . . . . . . . 31 6.5 Who needs to be competent? . . . . . . . . . . . . . 31 6.6 What competence is required? . . . . . . . . . . . . 32 6.7 How to obtain, develop, retain and ver i fy

competence . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.8 When to source competence from outside . . . . 35 6.9 Key learning points . . . . . . . . . . . . . . . . . . . . 35

7 Supplier Governance . . . . . . . . . . . . . . . . . . . . . . . . 37 7.1 Why is suppl ier governance important? . . . . . . 37 7.2 The customer ’s role . . . . . . . . . . . . . . . . . . . 38 7.3 How best to select a suppl ier . . . . . . . . . . . . . 40 7.4 The customer/suppl ier re lat ionship . . . . . . . . . 40 7.5 Service management techniques and SLAS . . . 41 7.6 The suppl ier /outsourcing governance l i fecycle . 42

8 IT & Audit Working Together and Using CobiT . . . . . 43 8.1 Introduct ion to CobiT . . . . . . . . . . . . . . . . . . 43 8.2 How is CobiT being used? . . . . . . . . . . . . . . . 44 8.3 What are the roles of IT and audi t for

IT Governance? . . . . . . . . . . . . . . . . . . . . . . 45 8.4 How can IT and internal audi t work better

together? . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

9 Information Security Governance . . . . . . . . . . . . . . 48 9.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.2 What is informat ion secur i ty? . . . . . . . . . . . . . 49 9.3 Where to focus . . . . . . . . . . . . . . . . . . . . . . . 50 9.4 Roles and responsibi l i t ies . . . . . . . . . . . . . . . 50 9.5 Act ion planning and best pract ice . . . . . . . . . . 52

10 Legal & Regulatory Aspects of IT Governance . . . . . 53 10.1 Legal and regulatory factors af fect ing

IT Governance . . . . . . . . . . . . . . . . . . . . . . . 53 10.2 Roles and responsibi l i t ies . . . . . . . . . . . . . . . 54 10.3 Best approach to compl iance . . . . . . . . . . . . . 55 10.4 What IT has to do . . . . . . . . . . . . . . . . . . . . . 56 10.5 Deal ing wi th th i rd part ies . . . . . . . . . . . . . . . . 58 10.6 Cr i t ical success factors . . . . . . . . . . . . . . . . . 59

11 Architecture Governance . . . . . . . . . . . . . . . . . . . . 60 11.1 Why is archi tecture governance important? . . . 60 11.2 What are the object ives of archi tecture

governance? . . . . . . . . . . . . . . . . . . . . . . . . 61

12 Managing the IT Investment . . . . . . . . . . . . . . . . . . 63 12.1 Why is managing the IT investment important? 63 12.2 Port fo l io management . . . . . . . . . . . . . . . . . . 64 12.3 Benef i ts management . . . . . . . . . . . . . . . . . . 65 12.4 Measur ing investment performance . . . . . . . . 65 12.5 Improve value del ivery and ROI . . . . . . . . . . . 66 12.6 Measur ing and control l ing IT operat ional costs 66 12.7 Project r isk management . . . . . . . . . . . . . . . . 66

13 Success Factors . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Contents

IT Governance Developing a Successful Governance Strategy

4 5

1 IT Governance – The Business Case 1.1 Why is IT Governance important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 1.2 What does IT Governance cover? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 1.3 What are the benefits? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 1.4 What is IT Governance best practice? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

The guide focuses on 12 key topics selected by the group because of their importance to effective IT governance:

The business case – The organisat ion needs to understand the value proposi t ion Performance measurement – Is the ship “on course”? Implementat ion roadmap – How to start – What path to fo l low Communicat ions – How to explain the object ives and change the cul ture Capabi l i ty assessment – Finding out the t rue current state of IT governance Risk management – What r isks exist and how to make sure they are deal t wi th Suppl ier governance – External part ies play a big role and must be included IT and audi t working together – How to co-operate for a common goal Informat ion secur i ty – A key topic in today’s networked environment Legal and regulatory aspects –Compl iance is a global concern Archi tectures – The foundat ion for ef fect ive technical solut ions Managing investments – Ensur ing value is del ivered and benef i ts real ised

Implementation of this guidance, or indeed any IT best practice, should be consistent with your organisation’s management style and the way your organisation deals with risk management and delivery of IT value. Please share these ideas with your business users, external service providers, and auditors, since to realise their full value, all stakeholders of IT services should be involved.

All analysts currently agree that probably the biggest risk and concern to top management today is failing to align IT to real business needs, and a failure to deliver, or be seen to be delivering, value to the business. Since IT can have such a dramatic effect on business performance and competitiveness, a failure to manage IT effectively can have a very serious impact on the business as a whole.

Corporate Governance generally has taken on even greater significance. It is being recognised that IT has a pivotal role to play in improving corporate governance practices, because critical business processes are usually automated and directors rely on information provided by IT systems for their decision making. With the growth of direct connection between organisations and their suppliers and customers, and more and more focus on how IT can be used to add value to business strategy, the need to effectively manage IT resources and avoid IT failures and poor performance has never been greater.

The current climate of cost reduction and budget restriction has resulted in new norm – there is an expectation that IT resources should always be used as efficiently as possible and that steps are taken to organise these IT resources ready for the next cycle of growth and new IT developments. A key aspect of these factors is the increasing use of third party service providers and the need to manage these suppliers properly to avoid costly and damaging service failures.

This briefing provides a high level set of business arguments for IT Governance. It also explains how an IT Governance initiative can enable business and IT executives to:

Be sure that that they are aware of a l l IT related r isks l ikely to have an impact on their organisat ion;

Know how to improve the management processes within IT to manage these r isks; Ensure there are manageable relat ionships wi th suppl iers, service providers and

with the business (customers); Ensure there is a t ransparent and understandable communicat ion of these IT

act iv i t ies and management processes to sat isfy the Board and other interested stakeholders.

IT Governance Developing a Successful Governance Strategy

4 5

IT Governance covers the culture, organisation, policies and practices that provide this kind of oversight and transparency of IT – IT Governance is part of a wider Corporate Governance activity but with its own specific focus. The benefits of good IT risk management, oversight and clear communication not only reduce the cost and damage caused by IT failures – but also engenders greater trust, teamwork and confidence in the use of IT itself and the people trusted with IT services.

1.1 Why is IT Governance important? IT Governance has become very topical for a number of reasons:

In the wake of Enron and other corporate scandals, “Governance” general ly has taken on even greater s igni f icance. IT has a pivotal ro le to play in improving corporate governance pract ices.

Management ’s awareness of IT related r isks has increased. There is a focus on IT costs in al l organisat ions. There is a growing real isat ion that more management commitment is needed to

improve the management and control of IT act iv i t ies.

IMPACT’s IT Governance Special Interest Group (SIG) has examined these trends and found that the following issues drive the need for IT Governance:

There is a general lack of accountabi l i ty and not enough shared ownership and clar i ty of responsibi l i t ies for IT services and projects. The communicat ion between customers ( IT users) and providers has to improve and be based on jo int accountabi l i ty for IT in i t iat ives.

There is a potent ia l ly widening gap between what IT departments th ink the business requires and what the business thinks the IT department is able to del iver.

Organisat ions need to obtain a better understanding of the value del ivered by IT, both internal ly and from external suppl iers. Measures are required in business ( the customer ’s) terms to achieve this end.

Top management wants to understand “how is my organisat ion doing with IT in comparison with other peer groups?”

Management needs to understand whether the infrastructure underpinning today’s and tomorrow’s IT ( technology, people, processes) is capable of support ing expected business needs.

Because organisat ions are rely ing more and more on IT, management needs to be more aware of cr i t ical IT r isks and whether they are being managed. Furthermore, i f there is a lack of c lar i ty and transparency when taking signi f icant IT decis ions, th is can lead to reluctance to take r isks and a fa i lure to seize technology opportuni t ies.

And f inal ly, there is a real isat ion that because IT is complex and has i ts own fast changing and unique condi t ions, the need to apply sound management discipl ines and controls is even greater.

Stakeholders include:

Top level business leaders such as the Board, Execut ive, non-Execs, and especial ly heads of Finance, Operat ions and IT.

Those that have a responsibi l i ty for investor and publ ic relat ions. Internal and external audi tors and regulators. Middle level business and IT management. Key business partners and suppl iers. Shareholders. Customers.

Concerns they typically have include:

Avai labi l i ty, secur i ty and cont inui ty of IT services. Costs and measurable returns on investments. Qual i ty and rel iabi l i ty of service – no embarrassments. IT not appear ing to respond to the real needs of the business. Ident i f icat ion and management of IT related r isks to the business.

IT Governance – The Business Case1

IT Governance Developing a Successful Governance Strategy

6 7

Capabi l i ty and ski l ls of human resources. Compl iance to legal , regulatory and contractual requirements. Responsiveness and nimbleness to changing condi t ions.

1.2 What does IT Governance cover? IT Governance is a relatively new concept as a defined discipline and is still evolving.

IT Governance is not just an IT issue or only of interest to the IT function. In its broadest sense it is a part of the overall governance of an entity, but with a specific focus on improving the management and control of Information Technology for the benefit of the primary stakeholders. Ultimately it is the responsibility of the Board of Directors to ensure that IT along with other critical activities is adequately governed. Although the principles are not new, actual implementation requires new thinking because of the special nature of IT.

IT Governance spans the culture, organisation, policy and practices that provide for IT management and control across five key areas1:

Alignment – Provide for strategic direct ion of IT and the al ignment of IT and the business with respect to services and projects.

Value Delivery – Conf i rm that the IT/Business organisat ion is designed to dr ive maximum business value from IT. Oversee the del ivery of value by IT to the business, and assess ROI.

Risk Management – Ascertain that processes are in place to ensure that r isks have been adequately managed. Include assessment of the r isk aspects of IT investments.

Resource Management – Provide high- level d i rect ion for sourcing and use of IT resources. Oversee the aggregate funding of IT at enterpr ise level . Ensure there is an adequate IT capabi l i ty and infrastructure to support current and expected future business requirements.

Performance Measurement – Ver i fy strategic compl iance, i .e. achievement of strategic IT object ives. Review the measurement of IT performance and the contr ibut ion of IT to the business ( i .e. del ivery of promised business value).

IT Governance is not a one-time exercise or something achieved by a mandate or setting of rules. It requires a commitment from the top of the organisation to instil a better way of dealing with the management and control of IT. IT Governance is an ongoing activity that requires a continuous improvement mentality and responsiveness to the fast changing IT environment. IT Governance can be integrated within a wider Enterprise Governance approach, and support the increasing legal and regulatory requirements of Corporate Governance.

1.3 What are the benefits?

Investments are likely to be needed to improve and develop the IT Governance areas that need attention. It is important therefore, to begin with as good a definition as possible of the potential benefits from such an initiative to help build a viable business case. The expected benefits can then become the project success criteria and be subsequently monitored.

The IMPACT IT Governance SIG has identified the following main areas of benefit likely to arise from good IT Governance:

Transparency and Accountability

Improved transparency of IT costs, IT process, IT port fo l io (projects and services). Clar i f ied decis ion-making accountabi l i t ies and def in i t ion of user and provider

relat ionships.

Return on Investment/Stakeholder Value

Improved understanding of overal l IT costs and their input to ROI cases. Combining focused cost-cut t ing wi th an abi l i ty to reason for investment. Stakeholders al lowed to see IT r isk/returns. Improved contr ibut ion to stakeholder returns.

1. Board Briefing on IT Governance, 2nd Edition, the IT Governance Institute®.

IT Governance Developing a Successful Governance Strategy

6 7

Enhancement and protect ion of reputat ion and image.

Opportunities and Partnerships

Provide route to real ise opportuni t ies that might not receive at tent ion or sponsorship.

Posi t ioning of IT as a business partner (and clar i fy ing what sort of business partner IT is) .

Faci l i tate jo int ventures wi th other companies. Faci l i tate more businessl ike relat ionships wi th key IT partners (vendors and

suppl iers) . Achieve a consistent approach to taking r isks. Enables IT part ic ipat ion in business strategy (which is then ref lected in IT strategy)

and vice versa. Improve responsiveness to market chal lenges and opportuni t ies.

Performance Improvement

Achieve clear ident i f icat ion of whether an IT service or project supports “business as usual” or is intended to provide future added value.

Increased transparency wi l l ra ise the bar for performance, and advert ise that the bar should be cont inuously raised.

A focus on performance improvement wi l l lead to at ta inment of best pract ices. Avoid unnecessary expendi tures – expendi tures are demonstrably matched to

business goals. Increase abi l i ty to benchmark.

External Compliance

Enables an integrated approach to meet ing external legal and regulatory requirements.

1.4 What is IT Governance best practice?

Experiences gained by IMPACT SIG members have identified a number of practical organisational and process issues that need to be addressed when implementing IT Governance. This has enabled the Group to recommend the following best practices (critical success factors) when planning IT Governance initiatives:

An enterprise wide approach should be adopted

The business and IT must work together to def ine and control requirements. IT wi l l need to develop a control model appl icable to al l business uni ts/div is ions. A commit tee approach is recommended for set t ing, agreeing, and monitor ing

direct ion/pol icy etc. A shared, cohesive v iew of IT Governance is needed across the enterpr ise based on

a common language. There should be a c lear understanding (and approval) by stakeholders of what is

wi th in the scope of IT Governance.

Top level commitment backed up by clear accountability is a necessity

IT Governance needs a mandate and direct ion f rom Board/Execut ive level management i f i t is to succeed in pract ice.

Make sure management responsibi l i t ies and accountabi l i t ies in the business as wel l as IT have been def ined.

An agreed IT Governance and control framework is required

IT Governance – The Business Case1

IT Governance Developing a Successful Governance Strategy

8 9

Al though i t may generate chal lenges and pushback, and wi l l require a consensus, an agreed framework for def in ing IT processes and the controls required to manage them must be def ined for IT Governance to funct ion ef fect ively.

The processes for IT Governance need to be integrated with other enterpr ise wide governance pract ices so that IT Governance does not become just an IT owned process.

The framework needs to be supported by an ef fect ive communicat ion and awareness campaign so that object ives are understood and the pract ices are compl ied wi th.

Incent ives should be considered to mot ivate adherence to the f ramework. Pay at tent ion to devolved decentral ised IT organisat ions to ensure a good balance

between central ly dr iven pol icy and local ly implemented pract ices. Avoid too much bureaucracy.

Trust needs to be gained for the IT function (in house and/or external)

For IT Governance to work the suppl iers of IT services and know-how need to be seen as professional , expert and al igned to customer requirements. Trust has to be developed by whatever means including awareness programmes, jo int workshops, and the IT Director act ing as a br idge between the business and IT.

Measurement systems will ensure objectives are owned and monitored

Creat ion of an IT scorecard wi l l underpin and reinforce achievement of IT Governance object ives.

Creat ion of an in i t ia l set of measures can be a very good way to raise awareness and in i t iate an IT Governance programme.

The measures used must be in business terms and be approved by stakeholders.

Focus on costs

I t is l ikely that there wi l l be opportuni t ies to make f inancial savings as a consequence of implement ing improved IT Governance. These wi l l help to gain support for improvement in i t iat ives.

IT Governance Developing a Successful Governance Strategy

8 9

2 Performance Measurement 2.1 Why is performance measurement important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 2.2 What does performance measurement cover? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 2.3 Who are the stakeholders and what are their requirements? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 2.4 What should we measure? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 2.5 What’s best practice? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

One of the greatest challenges faced by those trying to manage IT in today’s fast moving economy and complex technical environment is knowing whether the “ship is on course” and being able to predict and anticipate failures before it is too late. Like driving a car or steering a ship, good instruments are essential. The use of measures to help steer the IT function has for many years been a challenge that few appear to have successfully addressed, which is why the expression “it’s like driving a car with a blacked out windscreen and no instruments” is often used. If it is difficult for those literate in technology and relatively close the IT function, then it is even worse for the end customer who finds technical jargon a smokescreen and lack of information relevant to his business a major headache.

There is no doubt that a practical and effective way to measure IT performance is an essential part of any IT Governance programme, just as transparency and reliability of financial results is a Corporate Governance necessity. Performance management is important because it verifies the achievement of strategic IT objectives and provides for a review of IT performance and the contribution of IT to the business (i.e. delivery of promised business value). It is also important in providing a transparent assessment of IT’s capability and an early warning system for risks and pitfalls that might otherwise have been missed. Performance measurement provides transparency of IT related costs, which increasingly account for a very significant proportion of most organisations’ operating expenses.

Stakeholders play a key part in IT Governance, since at the heart of the governance responsibilities of setting strategy, managing risks, allocating resources, delivering value and measuring performance, are the stakeholder values, which drive the enterprise and IT strategy.

For performance measurement to be successful, it is important to understand who the stakeholders are and what their specific requirements and drivers are so that the performance measurements will be meaningful to them. An IT Governance best practice is the approval of measures by stakeholders. A performance measurement system is only effective if it serves to communicate to all who need to know what is important and then motivates positive action and alignment to common objectives. The measures are not an end in themselves but a means to take corrective action and to learn from real experiences. Concise and understandable communication and clear accountabilities are therefore critical success factors if measures are to be turned into effective actions.

“If you can’t measure it, you can’t manage it”

2.1 Why is performance measurement important?

“Teams that don’t keep score are only practising.” Tom Malone, President Milliken & Company

Performance measurement is a key component of IT Governance. It verifies the achievement of strategic IT objectives and provides for a review of IT performance and the contribution of IT to the business (i.e. delivery of promised business value).

Performance measurement supports the other key elements2 of IT Governance by:

Al ignment – monitor ing the strategic direct ion of IT and the al ignment of IT and the business.

Value Del ivery – assessing whether the IT/Business organisat ion is providing business value from IT and assessing ROI.

Risk Management – monitor ing whether r isks are being ident i f ied and managed and measur ing the cost and benef i t of r isk management investments.

Performance Measurement2

2. Board Briefing on IT Governance, 2nd Edition, the IT Governance Institute®.

IT Governance Developing a Successful Governance Strategy

10 11

Resource Management – measur ing the ef fect iveness of sourcing and use of IT resources, the aggregate funding of IT at enterpr ise level , and measur ing IT capabi l i ty and infrastructure compared to current and expected future business requirements.

Performance measures are required to ensure that the outcomes of IT activities are aligned to the customer’s goals. Internal IT process measures are required to ensure that the processes are capable of delivering the intended outcomes cost-effectively. Advanced performance measurement enables the measurement of key aspects of IT capability such as creativity and agility (new ideas, speed of delivery and success of a change programme), development of new solutions, ability to operate reliable and secure services in an increasingly demanding IT technical environment, and the development of human resources and skills.

Performance measurement may also be a vital tool when assessing mergers and acquisitions to allow earlier insight into IT strengths and gaps. The introduction of a performance measurement system focused on a few key measures can be an excellent way to kick-start an IT Governance initiative, providing, perhaps for the first time, transparency of critical activities and a way to bridge the communication gap between IT and its customers.

2.2 What does performance measurement cover? Performance measures are the “vital signs” of an organisation. They quantify how well the activities within a process or the outputs of a process achieve a specific goal. The measures tell people what and how they’re doing as part of the whole. They communicate what’s important throughout the organisation: strategy from top management down, process results from the lower levels up, and control and improvement within the process. Only with a consistent view of the “vital signs” can everyone work toward implementing the strategy, achieving the goals, and improving the organisation (Vital Signs, by Steven M. Hronec).

An IT performance measurement system should help to:

Focus on the customer to increase customer sat isfact ion Improve processes so problems are ant ic ipated and prevented Understand and reduce costs Encourage and faci l i tate change by obtaining facts about current state, desired

state and the gap that needs to be met Set real ist ic benchmarks for comparison

Effective performance measurement of IT will enable management and other stakeholders to know whether or not IT is meeting its objectives. It provides a transparent and objective communication mechanism, as long as the measures are understandable by both the customers and the service providers. The measures should address two aspects (The IT Governance Institute’s CobiT Management Guidelines provides example metrics for all IT processes and explains the difference between Goal Indicators (KGIs) and Process Indicators (KPIs)):

Outcome focused – is IT meet ing the object ives set by the customer? Process focused – are the IT processes operat ing ef fect ively and l ikely to lead to

the customer object ives being met?

The IT Governance SIG recommends that performance measures meet the following requirements to be successful:

Def ined using a common language appropr iate and understandable for the audience

Approved by the stakeholders In keeping with the cul ture and sty le of the organisat ion Based on targets der ived from IT’s object ives Contain a mix of object ive and subject ive measures Flexible and responsive to changing pr ior i t ies and requirements Based on easy to col lect actual measurement resul ts Include both posi t ive measures ( to mot ivate) and negat ive measures ( to correct) Balanced, i .e. measur ing more than just f inancial resul ts. The Balance Scorecard is

recommended as an ef fect ive approach providing f inancial , customer, internal and learning dimensions (The Balanced Scorecard, Kaplan & Norton)

Limited in number and focused only on pr ior i ty areas but suf f ic ient to support decis ion making (passes the “so-what?” test)

IT Governance Developing a Successful Governance Strategy

10 11

Easy to interpret (e.g. report ing should be visual using RAG or heat map techniques) and permit dr i l l ing down for more detai l and examinat ion of root causes. A scorecard is somet imes not appropr iate, e.g. for project review and pr ior i t isat ion or detai led analysis (where aggregat ion distorts or confuses)

Show trends to enable backward examinat ion and forward extrapolat ion Consol idated for hierarchical report ing Support benchmarking internal ly between peer groups and external ly wi th best

pract ice Integrated i f possible wi th any exist ing business level performance measurement

system

2.3 Who are the stakeholders and what are their requirements? Stakeholders play a key part in IT Governance. At the heart of the governance responsibilities of setting strategy, managing risks, allocating resources, delivering value and measuring performance, are the stakeholder values, which drive the enterprise and IT strategy. For performance measurement to be successful, it is important to understand who the stakeholders are and what their specific requirements and drivers are so that the performance measurements will be meaningful to them. An IT Governance best practice is the approval of measures by stakeholders (IT Governance Institute – Board Briefing on IT Governance).

For the purposes of performance measurement, we have classified stakeholders into three groups: investors, controllers and deliverers/providers with specific measurement interests and requirements as follows:

Investors – (business management, business partners and IT management)

Interests – they provide the funding and want to see a return on their investment and al ignment wi th their strategic object ives

Requirements - Financial – ROI, cost v. budget, product iv i ty, benef i ts real isat ion - Customer – surveys and feedback (subject ive as wel l as object ive), strategic

object ives v. actual projects/act iv i t ies - Process – capabi l i ty benchmark, performance except ions, t ransformat ion

capabi l i ty and tact ical agi l i ty - Learning – at t r i t ion, retent ion, ski l l prof i le, resource short fa l l , t ra in ing and

development

Controllers – (internal and external audit, risk and compliance officers, finance, human resources, industry specific regulators)

Interests – they monitor r isk and compl iance and have an interest in due process, regulatory and legal requirements, evidence of governance and r isk management, amount of rework/repeat ef for t , and compl iance with strategy

Requirements - Financial – losses, investments in control improvements - Customer – except ions/breaches, r isk management, compl iance with legis lat ion

and regulat ions - Process – control ef fect iveness, compl iance - Learning – r isk ident i f icat ion, r isk prevent ion

Deliverers/Providers – (IT service and product suppliers, in-house and outsourced, contract and procurement management and staff involved in IT delivery and support)

Interests – they need to meet customer expectat ions, and del iver in an ef f ic ient and ef fect ive way, preserving and enhancing reputat ion

Requirements - Financial – operat ional and project costs, cost a l locat ion/recovery, service

credi ts, cost opt imisat ion - Customer – performance against SLAs, sat isfact ion feedback e.g. survey

responses, customer retent ion and growth stat ist ics, ef fect iveness of deal ing wi th business churn

Performance Measurement2

IT Governance Developing a Successful Governance Strategy

12 13

- Process – internal improvement in ef f ic iency and r isk reduct ion, internal v. outsource decis ion support

- Learning – capabi l i ty to del iver, readiness for new requirements, t ime to market for new in i t iat ives

2.4 What should we measure? The ownership of measures and accountability for achieving targets should be clear. Furthermore, ownership and the collection of measurement data will not always be an IT responsibility, e.g. measurement of customer-focused outcomes. It should therefore also be clear whose responsibility collection is. Where appropriate, measures should be formalised in Service Level Agreements (SLAs) based on service descriptions written in a language and using terms meaningful to the customer. For third party service providers an SLA should form part of the contractual agreement so that performance measurement can be backed up with contractual recourse in the event of performance failure. To support IT Governance the following top fifteen areas to measure are recommended, with an indication of who has a primary interest and therefore who should approve the measures (figure 2.4)

2.5 What is best practice? Experiences gained by the IMPACT SIG members have identified a number of enablers and inhibitors that will assist in the achievement of Performance Measurement best practices when supporting IT Governance. Since the Interest Group is not primarily focused on performance measurement techniques we are not attempting to provide best practice guidance on measurement methods and/or tools.

In general, performance measurement should support this classic control model (figure 2.5)

Area Investors Controllers Providers

Business & IT alignment √

Major project delivery performance (objectives, time and budget) √ √

Overall financial performance (costs v. budgets) √ √ √

ROI for IT investments (business benefit) √

Status of critical risks √ √ √

Performance with respect to reliability and availability of critical services

√ √

Complaints (QOS) and customer perception √

Number of significant reactive fixes to errors √

SLA performance by third parties √ √

Relationships with suppliers (quality & value) √ √

Capability e.g. process maturity √

HR measures for people involved in IT activities √

Internal and external benchmarks √ √

Audit weaknesses √ √

Business continuity status √ √ √

Figure 2.4

IT Governance Developing a Successful Governance Strategy

12 13

Enablers

Support and ownership of performance measurement by Stakeholders Measures that are approved by and meaningful to the Stakeholders Measures that al ign wi th agreed IT object ives Measures that focus on processes cr i t ical to the success of IT object ives Measures that are easy to col lect and understand Targets that are chal lenging but also achievable Measures that are balanced e.g. based on the Balanced Scorecard technique Measurement reports and scorecards that are easy to interpret , wi th explanat ions

of except ions Where possible, measures should be automated

Inhibitors

Too much focus on technical measures (especial ly i f they are not al igned to IT object ives)

Lack of ownership and accountabi l i ty Measures which are not straightforward to interpret or encourage counter-product ive

behaviour (cf . Nat ional Heal th Wait ing List targets) Measures which are expensive to col lect or not focused on pr ior i ty areas Too many measures obscur ing relevant and important informat ion

Performance Measurement2

Figure 2.5 3

3. Board Briefing on IT Governance, 2nd Edition, the IT Governance Institute®.

IT Governance Developing a Successful Governance Strategy

14 15

3 Implementation Roadmap 3.1 What are the goals and success criteria? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 3.2 How to get started – the key initial activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 3.3 Who needs to be involved and what are their roles and responsibilities? . . . . . . . . . . . . . . . . . . . . . . . . . . .16

This chapter describes an “Implementation Roadmap” for activating an effective IT Governance programme to deliver the above benefits, and is based on the practical implementation experiences gained by the IMPACT IT Governance SIG members.

The roadmap begins with establishing clear goals and objectives in order to align effort with the real needs of the enterprise, to manage expectations, and to ensure continual focus. The roadmap then consists of activities to get started, followed by the key implementation tasks with suggested roles and responsibilities. IT Governance is an ongoing task and therefore this roadmap is only the initial phase of what needs to become an iterative sustainable approach.

3.1 What are the goals and success criteria? Implementing IT Governance for many organisations will mean major changes. It is important therefore to not only have high- level sponsorship but also the active involvement of key stakeholders. The roadmap is an iterative lifecycle that begins with an initial phase to define overall goals and to gain the support and commitment of top management which then leads to the ongoing effective governance of IT activities.

A generic set of initial objectives has been identified by the SIG and is shown in Figure 3.1. Figure 3.1.1 suggests some success criteria for this initial phase of IT Governance.

Typical objectives of the initial implementation phase “Agreed” √

Define the meaning of governance in your organisation and where/if IT Governance fits

Identify any organisational/environmental/cultural constraints and enablers

Achieve a broad understanding of IT Governance issues and benefits across all stakeholders

Agree, publish and gain acceptance of an initial IT Governance framework, tools and processes

Completion of an initial gap analysis against best practice – to demonstrate where IT Governance is already in place and to highlight areas of focus for the roadmap

Creation of a Project Initiation Document (PID) and/or Terms of Reference (ToR) that has the support of stakeholders

Creation of a Project Plan with definition and prioritisation of the initial ITG project deliverables

Identification and commitment of the resources required to deliver this initial project

Identification and sign-off of Key Performance Indicators and Critical Success Factors for this project

Documented estimated timescales and resource (£s and FTE) implications as well as expected ROI

Alignment of the ITG Initiative with business objectives/strategy

Figure 3.1

IT Governance Developing a Successful Governance Strategy

14 15

3.2 How to get started – the key initial activities Having set the goals, and gained support, activation consists of two steps – planning, based on analysis of the current environment, followed by implementation itself.

Planning These are recommended implementation planning activities together with some critical success factors:

Activities CSFs • Identify champions - Stakeholders (including partners), Input providers, IT strategy committee

(council) members • Establish IT strategy committee (council) • Identify IT “hotspots” in the organisation, and where governance could enable

‘hotspot’ resolution: - Strategy? Delivery? IT Cost? Architecture? - Where current approaches have not worked or caused serious failures • Identify skill set and capabilities needed from people involved • Identify existing good practice (‘pseudo governance’) or successes that could be

built on or shared • Identify cost/benefit arguments – why do we need to do anything? • Identify inconsistencies in process/practice • Identify opportunities for “rest of business” to get involved in IT • Explore opportunity to adopt industry best practice model, or standards

framework • Utilise external influences • Create a measurement approach for an area or activity to expose actual evidence

of problems • Do some gap analysis against industry best practice

√ Authoritative and articulate champions

√ Available skills and capabilities

√ Well prepared business cases approved by stakeholders

√ Real opportunities for the business to see the benefit of participating

√ Practical and useful governance approaches

√ Effective and useful measures

√ Expose the truth /whole picture, warts and all, about project success /failure, showing how governance can be helpful

Implementation Roadmap3 Success criteria for the initial implementation phase “Done” √

Key stakeholders identified, engaged and actively involved

Key stakeholders contributing towards and able to explain and support the business case for ITG

Stakeholders have an understanding of the expectations of the IT Governance initiative

Some initial ‘quick wins’ have been identified and implemented – to make governance “real”

Acceptance of the published IT Governance framework by those responsible for implementation

An effective communication plan – who to, what, when etc. to overcome any barriers and to motivate change

Current key IT projects mapped against ITG plan, to look for easy fit/implications

Changes are sustainable and institutionalised, i.e. they become Business as Usual practices

Figure 3.1.1

IT Governance Developing a Successful Governance Strategy

16 17

Implementation These are the recommended activities to start up the implementation roadmap, together with some critical success factors:

Activities CSFs • Create a sound project structure - Define scope (what is included/excluded) and deliverables - Agree success criteria/quality criteria - Set realistic timeframes - Allocate suitable resources and roles - Identify risks and a risk mitigation strategy • Gain approval from Senior Management (the higher the better within the

Enterprise) • Find reference site, or external examples to learn from • Build communication plan to gain buy-in, and break down barriers - Who/what/how frequent/purpose • Do a pilot activity (demonstrate the business case) to show how it would work and

demonstrate potential benefits • Follow a phased introduction, e.g. - Focus on critical but easier to address areas - Assess projects first - Build up operational performance improvement progressively based on

prioritising maximum return for lowest cost - Consider one business area first, others later - Aim to establish some successes while learning how to be effective

√ Good project management (set the governance tone)

√ Expectations set correctly √ Approved business case √ Manage IT like you manage

the rest of the business √ Convincing reference sites √ Successful pilot √ Address quick wins first to

demonstrate results and realise benefits before attempting any major changes

3.3 Who needs to be involved and what are their roles and responsibilities?

All three generic groups of stakeholders, and their interests, should be involved in an IT Governance initiative. A key characteristic of any successful IT Governance initiative is the establishment of an enterprise-wide approach that clearly sets out roles and responsibilities, emphasising that everyone has a part to play in enabling successful IT outcomes.

Figure 3.3: This timeline is generic and intended only to be an example – it is based on the SIG’s experience. Thanks to Legal and General for the concept.

IT Governance Developing a Successful Governance Strategy

16 17

It may also be helpful to include an external, or internal, facilitator to provide an objective and neutral position. The suggested generic roles and responsibilities of the three main groups are shown in Figure 3.3.1.

Implementation Roadmap3

Investors Providers Controllers

Management board (authority to make things happen)

• Give direction backed up with adequate support and sponsorship

• Balance requirements with available resources, making available additional resources if required

• Insist on and seek measurable benefit realisation

• Coordinate overseas/satellite parts of the enterprise to ensure their interests and constraints have been considered

• Create organisation and structure to ensure board involvement in the governance process – by forming committees, establishing reporting processes

• Monitor performance, monitor risks, correct deviations

Business and IT senior managers, business partners and project sponsors

• Implement organisation and necessary infrastructure

• Take ownership of requirements • Champion and collaborate in IT

governance activities • Ensure business strategy and objectives

are set and communicated and aligned with IT

• Assess business risks and impacts • Establish reporting processes meaningful

to stakeholders • Communicate any business concerns in

a balanced and reasoned way • Provide project champions, creating the

seeds of change

User representatives • Take responsibility for Quality Assurance

programme (design and output) • Regularly check actual results against

original (or changed) goals • Provide service feedback to providers

IT management (internal and external), with support from business management

• Take ownership and set direction of IT Governance activities

• Build and achieve a pilot business case

IT management • Set IT objectives • Define IT governance and control

framework • Identify critical IT processes • Assess risks, identify concerns • Assess IT capability, identify gaps • Initiate a continuous improvement

programme • Develop business cases for

improvements • Design and implement solutions • Commit skilled resources • Establish performance measurement

system • Report to senior management • Respond to QA feedback from customers

Suppliers/business partners • Integrate any own existing or planned

governance practices with customer’s • Support and contribute to customer’s

governance approach • Agree service definitions, incentives,

measures and contracts/agreements

Training and Development • Ensure adequate education and

communication

HR function • Incorporate governance principles into

induction and performance measurement process

Core team • Define plan and deliverables • Organise team and roles (architects,

senior responsible officer, facilitator, project manager, process owners)

• Undertake core tasks • Report progress to plan

Internal and External Audit • Scope audits in coordination with

governance strategy • Provide assurance on the control over IT • Provide assurance on the control over

the IT performance management system

Risk Management • Ensure that new risks are timely

identified, provide advice

Compliance officers • Ensure that IT complies with policy, laws

and regulations

Finance • Advise on and monitor IT costs and

benefits • Provide support for management

information reporting • Incorporate governance requirements

into purchasing/contract process

Figure 3.3.1

IT Governance Developing a Successful Governance Strategy

18 19

4 Communication Strategy & Culture 4.1 Who do we need to influence? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 4.2 What are the key messages? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 4.3 Communication best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 4.4 Developing an influencing strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 4.5 Change roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

IT Governance and risk management is about improving the management and control of IT activities and enabling top management to exercise proper oversight. To achieve this, better processes, controls, best practices and management techniques are required. However all of these improvements will only have a chance of succeeding in a sustainable way if the culture of the organisation is changed to drive and support the desired new management approach.

Effective communications are a key enabler of these changes, just as poor communications can create a legacy of misunderstanding, lack of trust, and technical mystique and hype in many organisations. As we said earlier, if it is difficult for those literate in technology and relatively close to the IT function, then it is even worse for the end customer who finds technical jargon a smokescreen and lack of information relevant to his business a major headache. Communication and cultural behaviour, based on appropriate influencing strategies are therefore key ingredients of any IT Governance improvement programme. In order to best influence stakeholders, and communicate the major objectives and benefits of IT Governance throughout the organisation, the right language must be used. Given the significance of IT both in terms of investment and potential impact on the business – the risks of IT and of failing to exploit IT for strategic advantage must be stressed in any communication about IT Governance. Wake-up calls are sometimes required at the highest levels. Stakeholders must understand and feel responsible for safeguarding against IT risks.

Effective communications will ensure that “everyone is on the same page” – that key issues have been grasped, objectives have been positively accepted by management and staff, and everyone understands their role. Every organisation will have its own existing culture and choice of IT Governance approach that it wishes to adopt. The roadmap to follow for cultural change and effective communication will therefore be unique to each organisation, however there may be common elements.

4.1 Who do we need to influence? A fundamental element of IT Governance is change. When considering who needs to be influenced for successful IT Governance, it is important to remember that different messages are needed for different stakeholders. Whatever the topic is about, the language used must be understandable, relevant to the intended audience, and motivate positive attitudes towards change.

Identifying and gaining the support of key influencers of success and failure help enable successful communications strategies. It is also vital to recognise the main stakeholders impacted by the change, identify why we want to influence a particular stakeholder, and identify any resistance that needs to be overcome. Positive attitudes need to be promoted and used to influence others.

All three generic groups of stakeholders, and their interests, should be involved in an IT Governance initiative. It is critical to influence these groups positively so that they understand the objectives and benefits of IT Governance and are able to communicate consistently to each other and within their groups (Figure 4.1).

IT Governance Developing a Successful Governance Strategy

18 19

4.2 What are the key messages? In order to best influence stakeholders, and communicate the major objectives and benefits of IT Governance, the right language must be used. An inability to communicate effectively has been one of the major causes of IT failures, with too much technical jargon, lack of business understanding and poor appreciation of the other party’s requirements and issues. Ideally, a common language is required, and a balance has to be found between the business trying to understand IT and IT trying to understand the business. Communications will improve if the business views the technology provider not as a simple enabler but as a valued business partner and if IT presents benefits in the language that the business understands. The following are examples of some of the key messages that need to be communicated, based on three primary IT Governance objectives and the related benefits that can be realised (Figure 4.2).

Communication Strategy & Culture4 Who needs to be influenced?

Investors Providers Controllers • The Board • IT Council/Management Team • Senior business unit managers e.g. key

customers of IT services • Business Partners • External investors/shareholders – as part

of corporate governance

• Project and change managers (IT and Business)

• Programme managers • Business managers and users • Technical delivery and support teams • Key players e.g. business sponsors,

project champions • Relationship managers and internal

communications teams • Suppliers (especially outsourced service

providers) • Contract and procurement management • Peripheral players/influencers/policy

owners e.g. HR, Facilities Management, Legal

• Internal audit and external audit (due diligence)

• External regulators • Corporate governance coordinator • Risk managers • Compliance – regulatory and internal • Finance/Project Managers/IT and

business managers – reviewers of benefits/ROI

• Post investment appraisal/post project review teams

Key Messages • Benefits of governance • Why we need to do it • Impact on the business strategy • Commitment to support action plans

• Benefits of governance • Why we need to change • Your role and responsibility • How you need to change

• Need for independent assessment and assurance

• Relate to real business risks and impacts • Work positively with management to

address control needs

Figure 4.1

Ability to address these Objectives will realise these Benefits IT and Business strategic and operational alignment • IT and business working towards the same corporate goals • Architecture and other technology approaches seen as relevant

and value adding to the business

RoI/Stakeholder Value, Transparency and Accountability + Shareholder Value + Leveraging investments for greatest return + Better use of IT capabilities + Cost effective IT solutions

Effective Relationship Management (internal and external) • Mutual understanding of goals • Shared language and terminology • Working in partnership – equal investment and responsibility • Clear accountabilities

Opportunities and Partnerships + Increased synergies + Improved speed to market + Improved efficiencies, particularly with third parties + Agility to respond to change

Management Control/Quality Management • Standardised processes • Consistent approaches • Comparison/adoption of external best practices (e.g. ISO, CMMi,

CobiT, ITIL) • Professional IT services • Management of risks

Performance Improvement + Risk mitigation + Continuous efficiency and quality improvements + Increased assurance that controls are working + Transparency and confidence about measures

Figure 4.2

IT Governance Developing a Successful Governance Strategy

20 21

4.3 Communication best practices The experiences of the IT Governance SIG have shown that it is best practice to emphasise the importance of controlling IT related risks when communicating the need for IT Governance. In particular, make sure stakeholders understand and feel responsible for safeguarding against risks that would not exist if they had put in place effective IT Governance controls:

a) The “downside” business risks associated with the use and function of IT, i.e. financial losses, damage to reputation, loss of service etc.

b) The “upside” business risks of not exploiting IT effectively, i.e. loss of competitive advantage, inefficiencies, failure to respond to changing markets etc.

Recommended approaches If IT risks are not communicated effectively, and instead are surrounded by hype and complexity, then stakeholders will not appreciate their real impact, take the issues seriously, or be motivated to insist on better controls. The following approaches are recommended to ensure risks have been properly appreciated:

Emphasise the business impact of r isks associated with misal igned IT strategies, misuse of technology, badly managed operat ions and inef fect ive project management. Show how these r isks can be mit igated by ef fect ive controls.

- Use case studies that have impacted the business or other businesses (e.g. v i rus at tacks, cr i t ical service outages, projects wi th “unexpected outcomes”) to i l lustrate how issues might ar ise.

Ident i fy relevant examples of governance providing business benef i ts beyond the basic requirement of evidencing control .

- Use case studies to i l lustrate how effect ive governance has ident i f ied r isk to the business, i ts object ives and strategy, and brokered an al ternat ive solut ion.

- Use case studies to i l lustrate business benef i ts as a direct resul t of ef fect ive governance, e.g. reduced costs, improved qual i ty, product iv i ty, reputat ion and market ing advantages.

Scenar io model l ing wi th r isk assessment and mit igat ion: - Consider known and new r isks across both business and IT (e.g. external audi t

requirements) - How governance can help mit igate the r isk - Calculate a r isk factor = l ikel ihood x impact - Consider opt ions – accept, mit igate or assign

Using common business language: - Technological r isk in f inancial /economic/business terms - Legal / regulatory, contractual impl icat ions

Critical Success Factors

Involve al l re levant stakeholders in a faci l i tated workshop environment Get c lear ownership and funding commitment for r isk mit igat ing act ions Monitor/ t rack al l act ions

4.4 Developing an influencing strategy Critical to the success of any IT Governance initiative is an effective communications plan. The communications plan should be based on a well-defined influencing strategy. Behaviours will need to be changed and care should therefore be taken to ensure that participants will be motivated and see the benefits of the new approaches, as well as understanding the consequences of accepting responsibility. If this is not positively communicated, then IT Governance will not be perceived as part of the corporate mission with Board level support. Management will resist it as a barrier to getting the job done, a deviation from current priorities, or another management fad.

The strategy should identify opportunities for the active involvement of stakeholders in developing the governance approach, planning and implementing IT management changes, and ideally building specific change objectives/targets into personal performance plans. The stakeholders are likely themselves to be the targets of change and should be involved in discussing/ evolving responses to the change via collaborative workshops, focus groups etc.

IT Governance Developing a Successful Governance Strategy

20 21

The influencing strategies need to be designed to work in specific situations with the individual influence targets identified. The following table shows four typical influencing styles, examples of the communications involved and the associated leadership styles. It is important to select the most appropriate style taking into account who needs to be influenced and on what topic.

Focus on Roles and Responsibilities

Ident i fy an overal l sponsor and steer ing group with speci f ic tasks and responsibi l i t ies for leading the change

Ensure there is a complete structure of cascaded sponsorship down to team/l ine manager level

Focus on individual situations

Ident i fy champions ( those high on interest and/or inf luence) Use successes as benchmarks Disseminate across teams and support format ion of new teams

Figure 4.4.1 shows different change approaches that can be used. For IT Governance initiatives experience shows that the best approach is incremental change evolving and adapting of current practices to a new collaborative IT management approach.

Communication Strategy & Culture4 Influencing style examples

Asserting Persuading Bridging Attracting • Stating expectations of

improved IT Governance and consequences of not adopting the new control model

• Evaluating current capability, risk management, delivery quality etc. and exposing unacceptable performance

• Creating incentives by setting clear IT Governance objectives, based on business priorities, backed up by the personal reward scheme

• Proposing new management approaches, best practices, standards for IT activities, based on development workshops

• Reasoning that changes are needed, by educating top management about the key IT issues and the benefits IT Governance can provide, e.g. more ownership in the business of IT projects

• Involving the business in IT decision making, by breaking down technical barriers and encouraging shared responsibility for IT outcomes

• Listening to user feedback about IT services and encouraging suggestions via satisfaction surveys

• Disclosing IT problems and incidents seeking workable solutions instead of covering them up

• Finding Common Ground by developing corporate mission statements and policies about IT Governance with support from the Board

• Visioning by IT and the business developing shared strategies and action plans, backed up by measurable and accountable objectives and targets

Push Pull

Figure 4.4

Figure 4.4.1

IT Governance Developing a Successful Governance Strategy

22 23

4.5 Change roadmap Every organisation will have its own existing culture and choice of IT Governance paradigm that it wishes to adopt. The roadmap to follow for cultural change and effective communication will therefore be unique to your specific situation.

The following techniques (Exploring Strategic, Change Veronica Hope-Hailey, Julia Balogun, Gerry Johnson, Kevan Scholes, Cranfield University) can help guide the best path to follow, and can be used to assess how your organisational culture and management style currently deals with the governance of its IT activities and what cultural style it desires. To do this you must:

Analyse the exist ing state Def ine the desired state

Cultural style and paradigms are formed from several characterictics which can generally be illustrated as shown in Figure 4.5.

Figure 4.5.1 illustrates some of the typical current and desired IT Governance behaviours found in many organisations today.

Figure 4.5

Characteristic Current Desired Myths and Stories Poor business and IT alignment:

Project failures; budget overruns; poor service, failure to meet business needs.

Effective business and IT alignment: Demonstrable RoI, project success stories, user satisfaction, business driving IT.

Symbols Mystique and technical jargon, lack of business terms.

Common language based on customer needs. Business literate in IT issues and opportunities.

Power Structures Them and us attitudes. Collaboration. Organisational Structures Divisive. IT seen as overhead function. Partnerships. IT seen as business enabler. Control System Based on departmental units and who knows

the most. Based on defined processes, standards and best practices owned by the organisation.

Routines and Rituals Hidden agendas, measures in provider’s terms and a general lack of transparency leaving top management in the dark.

Joint forums for monitoring progress, measures in customer’s terms, transparent reporting to top management.

Figure 4.5.1

IT Governance Developing a Successful Governance Strategy

22 23

5 Capability Maturity Assessment 5.1 Why IT capability is important . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 5.2 How to measure IT capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 5.3 Setting maturity targets and considering improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 5.4 Roadmap for sustaining the approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 5.5 Self-assessment tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Monitoring and assessing the adequacy of IT Resources (people, applications, technology, facilities, data) to ensure that they are capable of supporting the current and proposed IT strategy is a key aspect of IT Governance. In many organisations board level management have a very unclear view of their IT capability, and find it very difficult to understand the technical and organisational IT environment upon which they increasingly depend. Often inadequacies only manifest themselves when projects fail, costs spiral, operational systems crash, or service providers fail to deliver the value promised. To exercise sufficient governance and oversight, senior management should insist on objective and regular assessments of their internal and externally provided IT services to ensure any inadequate capabilities are exposed before serious problems occur, and then take the necessary action to rectify weaknesses. In recent years, surveys and assessments carried out around the world have shown that in general IT capabilities have not kept pace with increasing IT complexities and the growing demands for reliable, secure and flexible services. Cost control and reducing inefficiencies are also important reasons for reviewing technical and organisational capability.

Improving the maturity of IT capability both reduces risks and increases efficiency – cost saving is often a justification.

Capability Maturity Modelling (CMM) techniques (CMM was created by the Software Engineering Institute with Carnegie Mellon) are increasingly being adopted by many organisations for assessing IT capability. This technique focuses on the IT management processes that control IT resources, and assessments usually reveal significant weaknesses and an IT capability disproportionate to the high dependency organisations have on their IT service providers. Using the CMM scale it is rare to find even a defined (level 3) process in many organisations.

Management should insist on objective and transparent assessments, and carry out these analyses as part of any due diligence review, or request third party certifications when considering outsourcing or during mergers and acquisitions. Agreement then must be reached regarding where and how to address inadequacies, by either investing in the internal infrastructure or seeking externally provided outsourced resources, or accepting the risks.

5.1 Why IT capability is important A key to successful IT performance is the optimal investment, use and allocation of IT resources (people, applications, technology, facilities, data) in servicing the needs of the enterprise. Most enterprises fail to maximise the efficiency of their IT assets and optimise the costs relating to these assets. In addition, the biggest challenge in recent years has been to know where and how to outsource and then to know how to manage the outsourced services in a way that delivers the values promised at an acceptable price.

Boards need to address appropriate investments in infrastructure and capabilities by ensuring that:

The responsibi l i t ies wi th respect to IT system and services procurement are understood and appl ied.

Appropr iate methods and adequate ski l ls exist to manage and support IT projects and systems.

Improved workforce planning and investment to ensure recrui tment and more important ly, retent ion, of ski l led IT staf f .

IT educat ion, t ra in ing and development needs are fu l ly ident i f ied and addressed for al l staf f .

Appropr iate faci l i t ies are provided and t ime is avai lable for staf f to develop the ski l ls they need.

Capability Maturity Assessment5

IT Governance Developing a Successful Governance Strategy

24 25

Boards needs to ensure that IT resources are used and managed wisely by ensuring that:

Appropr iate methods and adequate ski l ls exist in the organisat ion to manage IT projects.

The benef i ts accruing from any service procurement are real and achievable.

IT assets are complex to manage and continually change due to the nature of technology, and changing business requirements. Effective management of the lifecycle of hardware, software licences, service contracts, and permanent and contracted human resources is a critical success factor in not only optimising the IT cost base, but also for managing changes, minimising service incidents, and assuring a reliable quality of service.

Of all the IT assets, human resources represent the biggest part of the cost base and on a unit basis the one most likely to increase. Identifying and anticipating the required core competencies in the workforce is essential. When these are understood, an effective recruitment, retention and training programme is necessary to ensure that the organisation has the skills to utilise IT effectively to achieve the stated objectives.”8

5.2 How to measure IT capability To ensure IT resources are managed effectively, IT capability should be assessed on a regular basis and whenever resources are critical to strategic IT decisions. The capability assessment should be:

Based on al ignment of IT goals wi th business goals Targeted at the IT processes cr i t ical to business success by,

- Assessing the current capabi l i ty of these IT processes - Determining the required capabi l i ty - Analysing any gaps in capabi l i ty - Providing transparent v is ib i l i ty of the capabi l i ty posi t ion - Def in ing and just i fy ing necessary improvement projects or - Re-adjust ing the IT strategy Adjust ing goals Improving capabi l i ty Outsourcing when cost-ef fect ive

The measurement of IT capability should be an objective assessment oriented towards business requirements. This will ensure that the current “as-is” and required “to-be” capabilities are realistic and measurable enabling any gaps to be identified and a plan to be drawn up to rectify any shortcomings.

The Capability Maturity Model (CMM) approach first developed by the Software Engineering Institute for measuring software delivery capability is increasingly being adopted as the basis for assessing overall IT capability. This model provides a standard scale for assessing the maturity of any IT process on a five-point scale (figure 5.2).

The following principles are recommended when carrying out an assessment:

Set Scope Select a reference model based on standards and best pract ices most sui table

for your business, e.g. CobiT, ITIL, SEI-CCM, SixSigma, ISO9000/9001, PMBOK – perhaps consider ing weight ing measures

Use an acceptable measurement methodology agreed with the stakeholders which is def ined and transparent

Set a basel ine in the context of 1 and 2 above and present the current state assessment using a scale or rat ing system

Set reasonable object ives for the targeted level of capabi l i ty Def ine measures which relate both to “ the journey” as wel l as the “end goal” (e.g.

the KPIs and KGIs recommended by CobiT) Ensure s impl ic i ty and f lexibi l i ty L imit the number of measures, minimise measurement overhead, and avoid

informat ion over load

Consider the following critical success factors:

Appropr iate level of ownership Avoid complexi ty and be f lexible

IT Governance Developing a Successful Governance Strategy

24 25

Embed measures into business as usual processes Ensure staf f have adequate ski l ls , t ra in ing and tools Create a repeatable process and agree frequency of report ing Where possible automate measurement and report ing Assess achievement against targets alongside other business as usual targets

5.3 Setting maturity targets and considering improvements The real value of a capability assessment comes from the identification and implementation of cost effective improvements. A realistic and practical approach is required to ensure that the proposed improvements are based on business priorities, will be supported and funded by management, and will be successfully implemented.

The following approach is recommended:

1. Understand the environment 2. Establ ish capabi l i ty improvement f ramework 3. Set real ist ic targets and respond to environment changes 4. Ident i fy gaps – pr ior i t ise improvements 5. Propose achievable solut ions

5.4 Roadmap for sustaining the approach Having initiated a capability assessment approach, and perhaps performed a pilot project, a capability assessment process needs to be implemented as part of normal business procedures.

The following practices are recommended to help ensure the process is sustainable

Art iculate current capabi l i t ies in relat ion to an adopted framework Set current levels of capabi l i ty in the context of external comparisons

Capability Maturity Assessment5

Figure 5.2

IT Governance Developing a Successful Governance Strategy

26 27

State the ef fect on the business of the current IT capabi l i ty state of af fa i rs. Descr ibe the ramif icat ions of NOT improving capabi l i ty e.g. addi t ional costs or r isks, inabi l i ty to real ise opportuni t ies, late or non-del ivery of the strategic development programme, redundant ef for t

Descr ibe the benef i ts of implement ing improvements in speci f ic areas Descr ibe the projected ef fect on the business af ter del ivery of enhancements

Initiating and sustaining capability enhancements

Agree steer ing and review mechanism, sponsorship etc. Agree on pr ior i t ised programme of improvements Look for cont inuous improvement opportuni t ies where improvement is relevant or

necessary Fol low the 80:20 rule, i .e. don’ t implement more than is necessary Embed al l improvements as “business as usual” , not a one-of f in i t iat ive Al l improvements should be achievable, sustainable, re levant Mot ivate everyone involved by publ ishing and celebrat ing successes Agree key measures around implementat ion of improvements and measures of

resul tant business benef i t – make part of a wider IT balanced scorecard Agree communicat ion to targets, stakeholders and sponsors as wel l as the wider

community where there is l ikely to be a general interest in outcomes Per iodical ly review the object ives and reset goals i f necessary, checking val id i ty of

goals against business strategy

5.5 Self-assessment tool The simple self-assessment diagnostic in figure 5.5 can be used to help show overall capability at a high level. It is based on the four domains of CobiT, broken down into the 34 CobiT sub-processes. The extent of the analysis depends on how precise you wish to be. A management workshop can be used to arrive at an approximate initial assessment without extensive analysis.

IT Governance Developing a Successful Governance Strategy

26 27

Capability Maturity Assessment5

IT Process/Maturity Im po

rt an

A d

ho c

R ep

ea ta

bl e

D efi

ne d

M an

ag ed

O pt

im is

Planning & Organisation

PO1 Define a Strategic Information Technology Plan H

PO2 Define the Information Architecture M

PO3 Determine the Technology Direction M

PO4 Define the IT Organisation and Relationships M

PO5 Manage the Investment in Information Technology M

PO6 Communicate Management Aims and Direction L

PO7 Manage Human Resources L

PO8 Ensure Compliance with External Requirements M

PO9 Assess Risks M

PO10 Manage Projects L

PO11 Manage Quality L

Acquisition & Implementation

AI1 Identify Solutions L

AI2 Acquire and Maintain Application Software M

AI3 Acquire and Maintain Technology Architecture M

AI4 Develop and Maintain Information Technology Procedures M

AI5 Install and Accredit Systems L

AI6 Manage Changes M

Delivery & Support

DS1 Define Service Levels M

DS2 Manage Third-Party Services H

DS3 Manage Performance and Capacity M

DS4 Ensure Continuous Service L

DS5 Ensure Systems Security M

DS6 Identify and Allocate Costs L

DS7 Educate and Train Users L

DS8 Assist and Advise Information Technology Customers L

DS9 Manage the Configuration M

DS10 Manage Problems and Incidents H

DS11 Manage Data H

DS12 Manage Facilities L

DS13 Manage Operations M

Monitoring

M1 Monitor the Process M

M2 Assess Internal Control Adequacy M

M3 Obtain Independent Assurance M

M4 Provide for Independent Audit M

Figure 5.5

IT Governance Developing a Successful Governance Strategy

28 29

6 Risk Management 6.1 What are the risks? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 6.2 What is the best approach for risk analysis and management? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 6.3 How can standards and best practices be used – is certification useful? . . . . . . . . . . . . . . . . . . . . . . . . . . .30 6.4 What are the roles of management, staff and auditors? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 6.5 Who needs to be competent? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 6.6 What competence is required? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 6.7 How to obtain, develop, retain and verify competence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 6.8 When to source competence from outside . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 6.9 Key learning points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

The management of risks is a cornerstone of IT Governance, ensuring that the strategic objectives of the business are not jeopardised by IT failures. IT related risks are increasingly a Board level issue as the impact on the business of an IT failure, be it an operational crash, security breach or a failed project, can have devastating consequences. However, managing IT risks and exercising proper governance is a challenging experience for business managers faced with technical complexity, a dependence on an increasing number of service providers, and limited reliable risk monitoring information. As a consequence, management are often concerned whether risks are being cost effectively addressed, and they need assurance that risks are under control.

The universal need to demonstrate good enterprise governance to shareholders and customers is the driver for increased risk management activities in large organisations. Enterprise risk comes in many varieties, not only financial risk. Regulators are specifically concerned about operational and systemic risk, within which technology risk and information security issues are prominent. The Bank for International Settlements, for example, supports that view because all major past risk issues studied in the financial industry were caused by breakdowns in internal control, oversight and IT. Infrastructure protection initiatives in the US and the UK point to the utter dependence of all enterprises on IT infrastructures and the vulnerability to new technology risks. The first recommendation these initiatives make is for risk awareness of senior corporate officers.

Therefore, the board should manage enterprise risk by4:

Ascertaining that there is t ransparency about the s igni f icant r isks to the enterpr ise and clar i fy ing the r isk-taking or r isk-avoidance pol ic ies of the enterpr ise.

Being aware that the f inal responsibi l i ty for r isk management rests wi th the board so, when delegat ing to execut ive management, making sure the constraints of that delegat ion are communicated and clear ly understood.

Being conscious that the system of internal control put in place to manage r isks of ten has the capaci ty to generate cost-ef f ic iency.

Consider ing that a t ransparent and proact ive r isk management approach can create compet i t ive advantage that can be exploi ted.

Insist ing that r isk management is embedded in the operat ion of the enterpr ise, responds quickly to changing r isks and reports immediately to appropr iate levels of management, supported by agreed pr inciples of escalat ion (what to report , when, where and how).

We must be conscious though that risk taking is an essential element of business today. Success will come to those organisations that identify and manage risks most effectively. Risk is as much about failing to grasp an opportunity as it is about doing something badly or incorrectly.

6.1 What are the risks? To enable effective Governance, IT risks should always be expressed in the business context rather than in the technical language favoured by IT risk experts. The following generic structure for expressing IT risks in any organisation is suggested:

Business specific risk (e.g. Operational risk of orders not being received)

4. Board Briefing on IT Governance, 2nd Edition, the IT Governance Institute®.

IT Governance Developing a Successful Governance Strategy

28 29

Generic common IT risk (e.g. IT availability risk)

Specific IT risk (e.g. Denial of service attack on Internet customer order system)

Business risks are affected by the business environment (management style, culture, risk appetite, industry sector factors such as competition, reputation etc., national and international regulations). IT risks can be similarly affected.

There is no single accepted set of generic IT risk definitions, but these headings can be used as a guide (Taken from a global study by the Economist Intelligence Unit in 2002):

Investment or expense r isk Access or secur i ty r isk Integr i ty r isk Relevance r isk Avai labi l i ty r isk Infrastructure r isk Project ownership r isk

The OGC’s M_o_R framework visualises four levels of risks in a pyramid with appropriate escalation to higher levels for significant risks (Figure 6.1).

For IT to be effectively governed, top management must be able to recognise IT risks and ensure that significant risks are managed. Significance of an IT risk is based on the combination of impact (what effect the risk would have on the organisation if it occurred) and likelihood (the probability of the risk occurring). Because of the complexity and fast changing nature of IT, education and awareness is essential to ensure risks are recognised – not just at the top management level but at all levels throughout the organisation. It is increasingly common for a dedicated risk management function to be established or for external advice to be obtained on a regular basis to ensure that risks are monitored and the rest of the organisation is kept informed. Maintenance of a risk catalogue or risk register can be helpful to ensure that a thorough review of all IT related risks takes place on a periodic basis and for providing assurance to management that risks are being addressed.

6.2 What is the best approach for risk analysis and management? Risk management consists of two main elements:

Risk Analysis Risk Management

Having defined risk appetite and identified risk exposure, strategies for managing risk can be set and responsibilities clarified. Dependent on the type of risk and its significance to the business, management and the board may choose to:

Risk Management6

Figure 6.1

IT Governance Developing a Successful Governance Strategy

30 31

Mit igate, by implement ing controls Transfer, by shar ing r isk Accept, by formal ly acknowledging that the r isk exists and monitor ing i t

The following framework for managing risk in Figure 6.2 is suggested by the OGC (OGC Risk Management Framework www.ogc.gov.uk).

The analysis of IT risks can be very time-consuming and there is a danger of “analysis paralysis”. To ensure effective and timely identification of risk, management workshops involving knowledgeable and interested representatives from the business, IT, audit and, if necessary external advisors, can help to rapidly pinpoint key risks requiring attention, as well as prioritising risk management actions. It is also important to identify the benefits of managing a risk as they can help to justify the business case for taking action. Benefits can include financial savings such as reduced losses and improved efficiencies as well as intangibles such as improved reputation and image.

Risk management checklists are useful for raising awareness and reminding everyone of typical risk related issues. Regular self-assessments, internal audits and external audits/assessments are also helpful to ensure objectivity, and a thorough approach. For technical areas such as Internet security, the advice of an expert is likely to be required to ensure any technical vulnerabilities have been identified.

6.3 Using standards and best practices – is certification useful? There is no doubt that effective management policies and procedures help to ensure that risks are identified and managed as a routine part of everyday activities. Adoption of standards and best practices will help to enable quick implementation of good procedures and avoid lengthy delays re-inventing wheels and agreeing approaches.

The best practices adopted have, however, to be consistent with the risk management framework and be appropriate for the organisation, and be integrated with other methods and practices that are being used. Standards and best practices are not a panacea and their effectiveness will depend on how they have been actually implemented and kept up to date. They are most useful when applied as a set of principles and as a starting point for tailoring specific procedures. To avoid practices becoming “shelf-ware”, change enablement is required, so that management and staff understand what to do, how to do it, and why it is important. For risk management to be effective, the use of a common language and a standardised approach oriented towards real business requirements is best – making sure everyone follows the same set of objectives, issues and priorities.

Benchmarking is another very useful way to compare how risk management is being addressed within the organisation in relation to best practice, industry peer groups and other organisations. Conformance to generally accepted standards and practices can be very helpful when managing risks relating to outsourced services and third party suppliers. Certification

Figure 6.2

IT Governance Developing a Successful Governance Strategy

30 31

against a standard may be important for helping to establish trust with trading partners, or for raising significance within the organisation. However, there is a danger that acquiring a certificate becomes more important as a marketing tool, than operating effective management itself. Certification may also only mean conformance with a baseline and may in itself not be sufficient to address all the risks in the organisation. In the IT environment there is no specific standard relating to risk management, but there are standards and best practices covering specific areas. Of these CobiT, ISO17799, ITIL, ISO9000, PMBOK and Prince2 are the most widely used.

6.4 What are the roles of management, staff and auditors? The ownership of IT risks, and giving direction for managing key risks is a fundamental aspect of IT Governance. An absence of top management responsibility and accountability for risk management can result in serious risks being ignored, potentially misguided actions, and even costly investments being wasted. Ultimately it is the business – the user of IT services – who must own business related risks including those related to the use of IT. They should set the mandate for risk management, provide the resources and funding to support any necessary risk management plan designed to protect their business interests, and monitor whether risks are being managed. In practice, due to the complex and technical nature of IT, the IT service provider will need to provide guidance and work with business management to ensure adequate safeguards are in place. IT management will then have a responsibility to endorse, establish and monitor the agreed risk management framework including key principles and mitigation strategies. IT and user staff have a responsibility to implement the framework, assessing, escalating and delivering mitigating actions.

Auditors can provide initial momentum by highlighting to senior management inadequate risk management practices or specific risks that are not being adequately addressed. Audit should also align audits with key business risks and known areas of weakness, and provide independent assurance to management, make sure that appropriate risk management plans are in place and are being followed in all key areas or provide improvement recommendations.

The OGC make the following suggestions regarding risk ownership:

Al locate responsibi l i ty at a senior level for managing key r isks Ensure that every r isk has an owner; there may be separate owners for the act ions

to mit igate the r isks Ensure anyone al located ownership has the author i ty to take on the responsibi l i ty

and that they are aware that they are the designated owner Adopt a mechanism for report ing issues – ul t imately to the indiv idual who has to

retain overal l responsibi l i ty

6.5 Who needs to be competent? A key characteristic of any successful IT Governance initiative is the establishment of an enterprise-wide approach that clearly sets out roles and responsibilities, emphasising that everyone has a part to play in enabling successful IT outcomes. Implementation of effective IT Governance therefore depends on everyone having adequate and appropriate skills to fulfil their specific role. In most organisations, Investors and Controllers will have a good understanding of governance principles but they usually have a very poor understanding of how to apply these principles in the world of IT. Providers, who are usually IT specialists, conversely understand IT but have a poor appreciation of governance and control principles.

Most IT Governance initiatives begin with the establishment of an IT Governance project team and the appointment of an IT Governance project manager. The team is likely to be made up of people with some existing skills and relevant experiences, sometimes supported by external advisors, but usually even these teams will require training to improve their competence in IT Governance concepts and implementation approaches. Over time the project team will become the specialists, guiding and mentoring all role players. For IT Governance to be successful and sustainable, skills must be transferred from the specialists to the rest of the organisation.

Risk Management6

IT Governance Developing a Successful Governance Strategy

32 33

6.6 What competence is required? Each group of role players will require different sets of skills to support IT Governance effectively (Figures 6.6-6.6.2).

Investors Role & Responsibilities Competence Required Management board (authority to make things happen) • Give direction backed up with adequate support and sponsorship • Balance requirements with available resources, making available

additional resources if required • Insist on and seek measurable benefit realisation • Coordinate overseas/satellite parts of the enterprise to ensure

their interests and constraints have been considered • Create organisation and structure to ensure board involvement

in the governance process – by forming committees, establishing reporting processes

• Monitor performance, monitor risks, correct deviations Business and IT senior managers, business partners and

project sponsors: • Implement organisation and necessary infrastructure • Take ownership of requirements • Champion and collaborate in IT governance activities • Ensure business strategy and objectives are set and communicated

and aligned with IT • Assess business risks and impacts • Establish reporting processes meaningful to stakeholders • Communicate any business concerns in a balanced and reasoned

way • Provide project champions, creating the seeds of change User representatives • Take responsibility for Quality Assurance programme (design and

output) • Regularly check actual results against original (or changed) goals • Provide service feedback to providers

General executive leadership skills: - Ability to understand the big picture and how IT plays a part - Ability to think strategically – how can IT make a positive difference

to enterprise strategy? - Ability to make strong decisions relating to IT, and be able to direct

and challenge IT approaches Ability to challenge: - Uncover IT related issues - Probe business cases - Assess concerns - Assess performance IT awareness and understanding: - Ability to demonstrate value of IT to the business, including return

on investment - Ability to understand how the business can use IT profitably - Ability to appreciate the impact of IT on the business, from a value

perspective but also from a risk perspective - Be able to link the IT and business strategy, and show how IT

supports and enables the overall strategic approach Ability to challenge: - Uncover IT related issues - Assess accuracy of requirements - Assess and prioritise concerns - Assess performance - Assess impacts of risks and poor performance Ability to articulate requirements and monitor delivery: - Understand how to express IT related requirements, test

deliverables and provide constructive feedback

Figure 6.6

Providers Role & Responsibilities Competence Required IT management (internal and external), with support from business management • Take ownership and set direction of IT Governance activities • Build and achieve a pilot business case IT management • Set IT objectives • Define IT governance and control framework • Identify critical IT processes • Assess risks, identify concerns • Assess IT capability, identify gaps • Initiate a continuous improvement programme • Develop business cases for improvements • Design and implement solutions • Commit skilled resources • Establish performance measurement system • Report to senior management • Respond to QA feedback from customers

Ability to manage overall IT activities: - Ability to communicate well in business language - Influencing skills – particularly, able to influence the Investors - Knowledge of the IT organisation and the wider business

organisation - Awareness of overall business and IT strategy - Ability to take a high level view and understand the rationales - Aggregate assessment – be able to appreciate the whole IT

picture, identify and prioritise key issues and actions - Ability to justify improvement actions - Understand the principles of regulation Supplier management skills: - Contract and commercial management - Risk management - Stakeholder management – who should be involved and why - Portfolio management - Budget management

IT Governance Developing a Successful Governance Strategy

32 33

6.7 How to obtain, develop, retain and verify competence

Recruitment When considering who to place in IT Governance lead positions, especially when creating an initial project team, staff in a number of existing positions may be excellent candidates. The IMPACT IT Governance SIG members have found that the following roles often provide people who would be effective in IT Governance roles.

Audi tors Project Managers Risk Managers Business Analysts Infrastructure Management Procurement/Contract Management IS Strategy – al ignment wi th the business Qual i ty Management Business Relat ionship Management Programme Managers

However, there is a need for breadth of business and IT knowledge rather than too narrow a specialisation.

Risk Management6 Suppliers/business partners • Integrate any own existing or planned governance practices with

customer • Support and contribute to customer’s governance approach • Agree service definitions, incentives, measures and contracts/

agreements Training and Development • Ensure adequate education and communication HR function • Incorporate governance principles into induction and performance

measurement process Core team • Define plan and deliverables • Organise team and roles (architects, senior responsible officer,

facilitator, project manager, process owners) • Undertake core tasks • Report progress to plan

People related IT Governance skills: - Understanding of roles - Understanding of competencies required - Understanding of sources of expertise Delivery management skills: - Familiarity with best practices - Understanding of IT processes, how they should be controlled,

and how to monitor performance - Knowledge of corporate standards and policies affecting IT - Ability to provide cost estimates - Engagement and project management

Figure 6.6.1

Controllers Role & Responsibilities Competence Required Internal and external audit • Scope audits in coordination with governance strategy • Provide assurance on the control over IT • Provide assurance on the control over the IT performance

management system Risk management • Ensure that new risks are identified in a timely manner, provide

advice Compliance officers • Ensure that IT complies with policy, laws and regulations Finance • Advise on and monitor IT costs and benefits • Provide support for management information reporting • Incorporate governance requirements into purchasing/contract

process

How to apply good Governance practices effectively in IT: - Understand the business environment and its impact on IT - Awareness of the business impact, the need for and justification of

IT control - Ability to be practical and pragmatic - Ability to communicate and explain the context of need for control,

regulations etc. and the benefits of taking action - Analysis ability – root cause determination - Able to put theory into practice, be knowledgeable of real world

examples - Objectivity and independence - Coaching, mentoring and skills transfer competence so that others

learn control theory - Negotiating skills to persuade others

Figure 6.6.2

IT Governance Developing a Successful Governance Strategy

34 35

Developing Skills Demonstrating commitment by senior management for the importance of IT Governance and the value of being competent, removing cultural barriers and improving communications are all critical success factors for improving competence. Suggested techniques for improving skills by each group of role players are shown below:

Investors

Obtain external exper iences to help posi t ion and chal lenge internal act iv i t ies Obtain “360 degree feedback” Consider appoint ing Execut ive mentor ing advisors Obtain and read Execut ive br ief ings Seek non-execut ive chal lenges to the Board Consider external Execut ive IT awareness courses Foster cul tural change act iv i t ies Foster col laborat ive working and co- locat ion Enable job exchanges to improve awareness

Providers

Formal ise documentat ion of governance, standards and best pract ices When training, focus on special ised and relevant areas Organise internal events to raise awareness Rotate involvement in governance meet ings to improve understanding Use the resul ts of assessments and matur i ty model l ing to raise awareness

of governance issues, gaps in capabi l i ty, and impact on the business of IT weaknesses

Ensure management and control of IT is taken ser iously Manage the transfer of ski l ls f rom the special ists to the organisat ion

The sequence of events should be:

1. Training 2. Establ ish an environment which fosters governance 3 . Rol l out the processes and ski l ls 4. Measure compl iance with standards and reinforce

Controllers

Ski l ls development is of ten more about learning on the job than about t ra in ing courses

Understand the business, how IT af fects the business, the IT related business r isks, and why IT needs to be control led

Focus on Professional t ra in ing in IT Governance and consider cert i f icat ion in relevant ski l ls

Maintain cont inuing professional development Consider `sof t ` ski l ls t ra in ing to improve communicat ion and inf luencing ski l ls

Retention of Skills The most effective way to retain IT Governance skills is by establishing standards and practices within the organisation rather than only within individuals. This reduces reliance on key individuals and ensures sustainable processes are put into place. In addition:

At a l l levels there wi l l be a need to refresh ski l ls cont inual ly because of the changing nature of IT

Ski l ls t ransfer should always be encouraged, especial ly f rom experts to operat ional staf f

Providers must be valued for their governance ski l ls and encouraged to invest in them. This is especial ly t rue of external service providers.

Induct ion t ra in ing is required for new jo iners, especial ly those holding key posi t ions in control ler funct ions.

IT Governance Developing a Successful Governance Strategy

34 35

If there is institutionalised, sustained implementation of IT governance then the environment will support continual skills growth.

Verifying Skills The best way to verify competence is to include governance skills in the appraisal process. This should be based on performance on the job:

Clear job object ives and role def in i t ion for IT Governance IT Governance competencies required for role Review of competency performance

In addition, surveys can be carried out periodically to measure the level of awareness in key competencies. This technique can also be a valuable awareness raising and reinforcing technique. Another approach to verifying competence is to measure the maturity of IT Processes, focusing on competency aspects. The chart below shows generically how this could be done based on guidance from CobiT’s Management Guidelines (Figure 6.7).

6.8 When to source competence from outside Acquiring IT Governance competence from outside the organisation will be driven by two different objectives:

When i t is more cost-ef fect ive to outsource ski l ls that are not avai lable in-house When outside input of expert ise is benef ic ia l in i ts own r ight

However, if implementation of IT Governance is to be successful and sustainable, competence will have to be developed within the organisation, since management of IT must be owned within the organisation. In many organisations where all or significant parts of the IT service have been outsourced, responsibility and competence for controlling use of these services should still be retained internally. It is essential to retain sufficient skills internally to be able to sustain the business – and to understand and manage what is being outsourced.

6.9 Key learning points The following list of key points have been identified by the IMPACT IT Governance SIG and should be considered when developing IT Governance skills:

Ski l ls opt imisat ion Governance ski l ls are normal ly found at the top level , but are typical ly not

understood in the context of IT The appointment of an IT Governance manager and team should not be permanent

because governance pract ice should become business as usual

Risk Management6

Generic Maturity Model for Governance Competence (CobiT)

Understanding & Awareness Training & Communication Expertise

1 Initial/Ad Hoc Recognition Sporadic communication on issues

2 Repeatable but Intuitive Awareness Communication on the overall issues and needs

3 Defined Process Understanding of need to act Informal training supports individual initiatives

IT Governance expertise exists within the Process owner and team

4 Managed & Measurable Understand full requirements Formal training supports a managed programme

IT Governance expertise is monitored and measured outside the Process

5 Optimised Advanced, forward-looking, understanding

Training and communications support external best practices and use leading edge concepts

Use of external experts and industry leaders for guidance, comparison to best practices

Figure 6.7

IT Governance Developing a Successful Governance Strategy

36 37

People must understand why governance is important Governance ski l ls need to be transferred from the special ists to the organisat ion as

a whole The best approach to t ra in ing is learning by doing and being part of the process

The sequence of events should be:

1. Special ised training 2. Establ ish an environment which fosters governance 3. Rol l out the processes and ski l ls 4. Measure compl iance with standards and re-enforce

IT Governance Developing a Successful Governance Strategy

36 37

7 SupplierGovernance 7.1 Why is Supplier Governance important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 7.2 The customer’s role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 7.3 How best to select a supplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 7.4 The customer/supplier relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 7.5 Service management techniques and SLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 7.6 The supplier/outsourcing governance lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

Every organisation relies on numerous suppliers to support their business and IT strategy. It is not unusual for external organisations to provide critical IT infrastructure (such as telecommunications networks, hosted data centres, and software applications) used by critical business processes, and increasingly the trend is to outsource significant parts of the internal IT function.

Effective governance of IT suppliers is therefore a key component of IT Governance, to make sure that risks are managed and value is delivered from the investment in supplier products and services. Most organisations are highly dependent on a limited number of key suppliers, and so governance should be focused on those relationships with the greatest risk and investment. For supplier governance to be effective the role of the customer is crucial. The customer should take ownership of the whole transaction from defining requirements and selection all the way through to engagement, operation and termination. Even when the bulk of IT is outsourced, several key functions should be retained because they supply continuity for clients of IT, provide for the oversight of the outsourcer, are highly specific to the way the business operates, and are strategic to the organisation. To some extent, the mix will vary with the reason(s) for outsourcing and which functions have been outsourced. However, all organisations will need to retain some expertise in strategic functions, such as project oversight, architecture, planning, vendor management, and security.

One of the best ways to establish effective supplier governance is to focus on the relationship

The correct form of the relat ionship (commodity provis ion, ‘market relat ionship’ a l lows clear ly def inable boundar ies between cl ient and suppl ier, whi le the ‘partnership’ end of the scale requires an ongoing and close cooperat ion)

How both part ies engage with each other Commitment by both part ies at a senior level Responsibi l i ty and accountabi l i ty by senior decis ion makers on both s ides Speci f icat ion of governance responsibi l i t ies in a “governance schedule” wi th in the

contract

Try to create a win/win partnership so that both parties are motivated for success – beating down the supplier is generally seen as poor practice, while cooperation, considered openness and mutuality of benefit defines the basis for better working relationships.

Underpinning the customer/supplier relationship should be formal service level agreements which define objectives and measures in customer relevant terms, managed according to service management best practices such as ITIL.

7.1 Why is Supplier Governance important? “Because organisations are relying more and more on IT, management needs to be more aware of critical IT risks and whether they are being managed. Furthermore, if there is a lack of clarity and transparency when taking significant IT decisions, this can lead to reluctance to take risks and a failure to seize technology opportunities. There is a realisation that because IT is complex and has its own fast changing and unique conditions, the need to apply sound management disciplines and controls is even greater.” (IT Governance – The Business Case)

Most organisations are highly dependent on a limited number of key suppliers, and so governance should to be focused on those relationships with the greatest risk and investment. The outsourcing of a function or service is likely to be a major

Supplier Governance7

IT Governance Developing a Successful Governance Strategy

38 39

strategic decision which should be governed carefully. Outsourcing is also a huge global commercial business opportunity for the service providers who will compete fiercely for market share. In such a complex technical and commercial situation, proper governance is crucial to help avoid potential service failures and large financial losses.

7.2 The customer’s role For supplier governance to be effective, the role of the customer is crucial. The customer should take ownership of the whole transaction from defining requirements and selection all the way through to engagement, operation and termination. It is essential that what is outsourced by the customer is NOT its core competency as this is what defines what the organisation is, how customers perceive it and how it retains its position in the marketplace. Only under a limited set of circumstances, one example being technology catch-up, should core competencies be outsourced. The supplier is of course also a stakeholder and will want to ensure the relationship is properly managed, and that the financial and operational requirements are acceptable. It will be in the customer’s interest to balance the supplier’s needs with his own in order to arrive at a solution that provides reasonable incentives for the supplier while properly meeting the customer’s needs.

If the relationship is critical in support of the customer’s business strategy (which will be the case if significant outsourcing is planned, or if critical infrastructure needs to be supported), then the customer’s role in ensuring effective governance will be particularly important and should address:

Unclear buyer expectations 23%

Misaligned interests 15%

Poor Governance 13%

Not mutually beneficial 11%

Other 11%

Poor communication

11%

Provider's poor performance 8%

Poor cultural fit 5%

Buyer's multi-buyer environment

Figure 7.1: Causes of outsourcing failures – source Outsourcing Center 2004

IT Governance Developing a Successful Governance Strategy

38 39

Discipl ine over managing the transact ion and transparency of the resul ts Independence from the suppl ier Accountabi l i ty and responsibi l i ty for key decis ions Increasing stakeholder value (both internal and for the suppl ier) Key governance steps at each stage, best def ined in a governance schedule in

the contract , and in a shared procedure manual where key responsibi l i t ies and escalat ion procedures are def ined.

How to be an effective customer

Organisation

Focus on what ’s cr i t ical Have the r ight capabi l i ty to manage IT suppl iers Ensure there are c lear roles and responsibi l i t ies on the customer ’s s ide of the

relat ionship Ensure there is an Execut ive level sponsor who wi l l be responsible and accountable

for a l l s igni f icant decis ions regarding key suppl iers Commit long-term Establ ish relat ionships at mult ip le levels Organise suppl iers according to cr i t ical i ty and roles

Technical

Manage technical IT issues to ensure conformance where necessary and compat ib i l i ty wi th in-house technical standards

Ensure al l re levant legal and regulatory requirements have been considered Standardise and commodit ise solut ions wherever possible Set real ist ic expectat ions regarding service del ivery Take t ime to understand product and service of fer ings Understand how your own IT assets may be af fected by supply of external products

or service Ensure there is good control of the internal environment af fected by the external

supply

Project Approach

Take care to manage al l staf f re lated issues Set up a co-ordinat ion commit tee of senior customer representat ives Make sure there is a process for both part ies to fo l low Bui ld into the requirements and contract p lans for t ransi t ion/ t ransformat ion f rom the

current state to an outsourced service Approach contracts and relat ionships in a balanced way ensur ing r isks have been

considered in the context of the value expected from the suppl ier Avoid the danger of mixed messages coming from di f ferent parts of the customer

organisat ion Make sure there is top-down management commitment to support a l l key decis ions

How to monitor and measure

1. Identify a limited range of meaningful and measurable key measures e.g.: Performance Financial Risks Compl iance Relat ionship Value added Del ivery

2. Take ownership and define and obtain agreement for all measures

3. Supplier senior management should:

Supplier Governance7

IT Governance Developing a Successful Governance Strategy

40 41

Provide data for a l l measures he is responsible for Monitor del ivery performance Agree remedial act ion wi th customer Commit remedial act ions

4. Customer IT service management should: Be responsible for monitor ing and report ing Pr ior i t ise and recommend act ions

5. Customer should: Provide customer sat isfact ion measurement data Consider benchmarking to other organisat ions and other services

What functions should be retained by the customer? (Reference Forrester Research “Functions to Retain when Outsourcing, July 2004)

Even when the bulk of IT is outsourced, several key functions should be retained because they supply continuity for clients of IT, provide for the oversight of the outsourcer, are highly specific to the way the business operates, and are strategic to the organisation. To some extent, the mix will vary with the reason for outsourcing. However, all organisations will need to retain some expertise in strategic functions.

7.3 How best to select a supplier The following steps are suggested:

1. Research the markets to ident i fy preferred suppl iers 2. Consider the s ize of suppl ier compared to your organisat ion and your

requirements 3. Consider the need to integrate several suppl iers 4. Do due di l igence reviews 5 . Prepare an ef fect ive RFP 6. See key people 7. Consider pi lots and pre-project t r ia ls 8. Check track record 9. Consider impact of any of f -shore s i tuat ions

7.4 The customer/supplier relationship One of the best ways to establish effective supplier governance is to focus on the relationship:

contract

Make sure each party understands its role. Figure 7.4 summarises how IMPACT SIG members believe each group of stakeholders should focus in the customer/supplier relationship.

IT Governance Developing a Successful Governance Strategy

40 41

7.5 Service management techniques and SLAs Underpinning the customer/supplier relationship should be formal service level agreements, managed according to service management best practices. ITIL is recommended as the best source of guidance in this area, and the IMPACT SIG members recommended the following techniques:

Use a suppl ier governance framework to dr ive service management pract ices ( f igure 7.5).

Create a service management board to oversee service del ivery Create a service code of pract ice “how to engage” Adopt standard processes for managing the services Develop a common language and common understanding of service object ives Ensure there is a c lear def in i t ion of service scope Def ine the scope of the retained IT funct ion Maintain the contract as a resul t of service changes Create a pol icy and procedure manual for both part ies to fo l low Where possible def ine a service credi t regime – th is descr ibes how ‘overs and

unders’ on the service provis ion are handled without recourse to hard, f ixed penal t ies

Supplier Governance7 Party Stakeholder Focus

Customer

Investors

Define outsourcing and procurement strategy

Define supplier governance framework

Provide supplier with strategic direction

Approve contracts and any changes

Consider future business requirements

Define business objectives

Evaluate performance

Providers

Specify architecture

Define business requirements

Manage relationship

Manage projects

Monitor service

Controllers

Verify financial ROI

Manage contract

Assess and monitor risk

Ensure legal/regulatory compliance

Perform financial analysis

Ensure supplier service audit

Establish security policy

Supplier

Investors

Define business objectives

Protect supplier and customer investments

Commit resources for delivery

Define service strategy

Define governance framework

Providers Define services

Define service levels

Monitor service quality

Controllers Measure financial performance

Monitor risk management

Manage contracts

Figure 7.4

IT Governance Developing a Successful Governance Strategy

42 43

7.6 The supplier/outsourcing governance lifecycle The outsourcing lifecycle is useful in determining major points for governance throughout the contract, but more importantly ensures a common understanding of the major processes (Figure 7.6).

Figure 7.5

Figure 7.6

IT Governance Developing a Successful Governance Strategy

42 43

8 IT & Audit Working Together & Using CobiT

8.1 Introduction to CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 8.2 How is CobiT being used? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 8.3 What are the roles of IT and Audit for IT Governance? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 8.4 How can IT and internal audit work better together? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

The growing interest in IT Governance and increasing pressure to deal with regulatory compliance (e.g. Sarbanes Oxley), and a continuing focus on security, has made IT management much more involved in risk management and control activities. There is therefore a need for IT management to work more closely with IT auditors.

For many years there have been barriers between auditors (both internal and external) and auditees (IT functions and business units). This can be due to communication gaps, hidden checklists, and a failure to collaborate on control assessment and control improvement. A more effective approach requires better recognition of one another’s role and alignment to a mutually accepted and understood control framework, so that everyone is “on the same page”.

CobiT is an IT Control and Governance Framework that is increasingly being adopted by organisations around the world as a common reference model for IT Control. CobiT has historically been mostly used by IT auditors but the trend now is for IT management to use CobiT as a basis for IT process ownership, a reference model for good controls and as a way to integrate other best practices under one “umbrella” aligned to business needs. More advanced users make use of CobiT’s maturity modelling and metrics to measure performance and drive improvement initiatives.

As a consequence, many IT functions and IT service providers are adopting CobiT as part of their operational control framework.

8.1 Introduction to CobiT Business orientation is the main theme of CobiT. It is designed to be employed not only by users and auditors, but also, and more importantly, as comprehensive guidance for management and business process owners. Increasingly, business practice involves the full empowerment of business process owners so they have total responsibility for all aspects of the business process. In particular, this includes providing adequate controls. The CobiT Framework provides a tool for the business process owner that facilitates the discharge of this responsibility. The Framework starts from a simple and pragmatic premise:

In order to provide the information that the organisation needs to achieve its objectives, IT resources need to be managed by a set of naturally grouped processes.

The Framework continues with a set of 34 high-level Control Objectives, one for each of the IT processes, grouped into four domains: planning and organisation, acquisition and implementation, delivery and support, and monitoring. This structure covers all aspects of information and the technology that supports it. By addressing these 34 high-level control objectives, the business process owner can ensure that an adequate control system is provided for the IT environment.

IT Governance guidance is also provided in the CobiT framework. IT Governance provides the structure that links IT processes, IT resources and information to enterprise strategies and objectives. IT Governance integrates optimal ways of planning and organising, acquiring and implementing, delivering and supporting, and monitoring IT performance. IT Governance enables the enterprise to take full advantage of its information, thereby maximising benefits, capitalising on opportunities and gaining competitive advantage.

In addition, corresponding to each of the 34 high-level control objectives is an Audit Guideline to enable the review of IT processes against CobiT’s 318 recommended detailed control objectives to provide management assurance and/or advice for improvement.

IT & Audit Working Together & Using CobiT8

IT Governance Developing a Successful Governance Strategy

44 45

The Management Guidelines further enhances and enables enterprise management to deal more effectively with the needs and requirements of IT governance. The guidelines are action oriented and generic and provide management direction for getting the enterprise’s information and related processes under control, for monitoring achievement of organisational goals, for monitoring performance within each IT process and for benchmarking organisational achievement. CobiT’s Management Guidelines are generic and action oriented for the purpose of answering the following types of management questions: How far should we go, and is the cost justified by the benefit? What are the indicators of good performance? What are the critical success factors? What are the risks of not achieving our objectives? What do others do? How do we measure and compare?” (CobiT Framework 2000, www.itgi.org)

ISACA recognised in the early 1990’s that auditors, who had their own checklists for assessing IT controls, were talking a different language to business managers and IT practitioners. In response to this communication gap, CobiT was created as an IT control framework for business managers, IT managers and auditors, based on a generic set of IT processes meaningful to IT people. The best practices in CobiT are a common approach to good IT control – implemented by business and IT managers, and assessed on the same basis by auditors. Over the years CobiT has been developed as an open standard and is now increasingly being adopted as the control model for implementing and demonstrating effective IT Governance.

Today, as every organisation tries to deliver value from IT while managing an increasingly complex range of IT related risks, the effective use of best practices can help to avoid re-inventing wheels, optimise use of scarce IT resources, and reduce the occurrence of major IT risks such as:

Project fa i lures Wasted investments Secur i ty breaches System crashes Fai lures by service providers to understand and meet customer requirements

Due to its high level and broad coverage, and because it has been based on many existing practices, CobiT is often referred to as the “integrator”, bringing disparate practices under one “umbrella” and just as importantly, helping to link these various IT practices to business requirements.

8.2 How is CobiT being used? Although the long-term aim of CobiT was to be a common framework used by management and auditors, it began as an Audit reference. This was largely due to its origins within ISACA and its early adoption by ISACA members who are mostly from the computer audit profession. Over the years its usage has widened out into the IT community and nowadays this is the fastest growing user segment. Whereas auditors have been using CobiT mostly as a controls checklist, IT managers see it more as a “best practice” framework for performance measurement and improvement planning. With increasing regulatory requirements such as Sarbanes-Oxley in the US, both auditors and IT managers are adopting CobiT as the compliance framework for IT controls. The CobiT IT Process model has helped convey a view of IT understandable to business management, auditors and IT, and at the same time provide a basis for IT functions to organise themselves into a process structure with accountable process owners.

The maturity modelling and metrics concepts within CobiT are probably the most popular for IT managers, providing an easy and powerful technique for positioning IT control gaps in the context of business requirements. The profiles and scorecards that results are a powerful tool for communicating with senior management and demonstrating the reality of current IT capability in relation to what the business might have expected.

As organisations have adopted the CobiT approach, it has driven the professional Audit firms to follow similar approaches, and to integrate CobiT into their internal proprietary methodologies. This has helped to break down communication barriers and improve the mutual understanding of IT controls. There is also a trend among service providers to use CobiT and other best practices to improve their market image and quality of service. This is also helping to improve communication of control issues and make it easier to manage and audit IT activities against a commonly accepted basis. Because CobiT is open and independent of any specific vendor all parties can use it freely. It is not a “standard” as such but a “best practice” framework and set of guidance materials to be tailored for each specific situation.

There is currently a great deal of focus on the Sarbanes-Oxley Act in the US, and the reporting requirements that this legislation requires for Company Directors. Many companies are using CobiT as the framework for reporting the status of IT systems and controls, and consequently a massive CobiT-based controls documentation effort is underway. While Sarbanes- Oxley has been very useful for putting IT governance and control on the Board’s agenda, there is a danger that the effort will be limited to a documentation exercise to achieve compliance. The real value from any control evaluation, especially when based on CobiT, is the identification of control gaps and the implementation of a sustainable improvement programme. There

IT Governance Developing a Successful Governance Strategy

44 45

is an analogy with the Y2K experience in that Sarbanes-Oxley should not be a one off exercise but an ongoing programme for improving management control and establishing governance.

8.3 What are the roles of IT and Audit for IT Governance?

Role of IT Audit IT Governance is a management responsibi l i ty, and therefore not the sole

responsibi l i ty of an Audi t funct ion. The Audi t funct ion should remain independent, but th is can provide an excel lent posi t ion to inf luence and recommend change. Independence should not inhibi t provis ion of advice, so long as management take ful l responsibi l i ty and accountabi l i ty for implementat ion and operat ion of controls. Taking responsibi l i ty for enabl ing an IT Governance in i t iat ive or for in i t iat ing governance projects should not compromise Audi t .

IT Governance requires management commitment and ownership wi th in IT and the business in order to make i t happen. Audi t can then determine i f i t is happening, and provide assurance to the board.

When reviewing Governance, Audi t must do more than just ident i fy problems. They need to ident i fy root causes and make construct ive recommendat ions.

Audi t can test controls especial ly where control is cr i t ical and assurance is required. But increasingly there is a t rend for IT to “ test themselves” by performing sel f -assessments.

Audi t can play a part in set t ing standards, and providing control cr i ter ia and control benchmarks, part icular ly in respect of external regulat ion.

Given the speed of IT change and the high cost of development projects, i t makes sense to involve audi tors in projects. To be ef fect ive audi tors must:

- Be credible and conf ident to gain the respect of IT

- Not wai t unt i l the end of a phase to cr i t ique – but give pro-act ive guidance on what should be done

Role of IT IT has to be responsible for changing the cul ture of the IT organisat ion, for

managing the IT processes, and adopt ing a focus on controls. IT professionals of ten have a poor understanding of what controls are and why they

are needed. Educat ion in control pr inciples may be needed, and audi t can help wi th th is by working together wi th IT, and by providing training, workshops and staf f secondments.

A common framework and understanding is needed in order to ensure that IT Management is exercis ing IT Governance. Using a common framework for control such as CobiT, wi l l help to ensure that everyone is “on the same page”.

The CIO and Head of Internal Audi t should work together to dr ive change. IT should take a lead on governance; audi t can “sow the seeds”. I f IT (as so of ten) is in ` f i re f ight ing` mode i t is harder for them to dr ive

governance. Execut ive management may point to histor ic data as showing no problems- so

why should they worry about governance? However, the problems can usual ly be ident i f ied by IT digging into process fai lures – e.g. project delay and excess cost. IT management have to be conf ident of their posi t ion to draw at tent ion to internal weaknesses.

8.4 How can IT and internal audit work better together? Increasingly, control self-assessments are being performed by IT functions because it is more efficient than relying on limited IT audit resources, and more likely to motivate corrective action.

Typical examples using self-assessments are: Risk assessments Compl iance with speci f ic standards ( ISO 17799) Compl iance with regulatory requirements such as Sarbanes-Oxley Qual i ty of service assessments

IT & Audit Working Together & Using CobiT8

IT Governance Developing a Successful Governance Strategy

46 47

IT Process Matur i ty assessments (e.g. CobiT)

The methods used vary from formal schemes, perhaps based on IIA (Institute of Internal Auditors) or Internal Audit guidance to less formal approaches. All approaches can provide value e.g.:

Quest ionnaires – based on pol icy (e.g. secur i ty) How do you consider you have addressed each object ive?

Sel f cert i f icat ion by management e.g. Sarbanes-Oxley Face-to-face interviews and workshops Pre-def ined checkl ists

IT contribution Governance Phase Audit contribution

Common approach – culture, charter, communication and language, clear ownership

• Get CIO commitment. • Know your audience when explaining IT

Governance, controls adoption and CobiT. • Get ownership from the business side, using

business language, RAG charts and scorecards. Demonstrate strengths and weaknesses.

• Influence the business and the board about IT management issues (use ITGI Board Briefing) (www.itgi.org).

• Achieve a balance between regulation and improvement planning. Leverage regulations for positive effect.

• Coordinate with service providers who may be a trigger and may be using CobiT.

Building Awareness & Ownership

• Provide thought leadership. • Influence the Board and Audit Committee to take

issues seriously and mandate change. • Use objective and independent position to

recommend organisational change. • Don’t just make general recommendations – point

to root causes. • Provide independent view of the risk profile. • Regulations like Sarbanes-Oxley can be an

enabler of change – encourage response to be more than just a documentation exercise.

• Demonstrate benefits.

• Adopt a Framework e.g. CobiT. • Appoint process owners. • Liaise with 3rd parties and service providers. • Integrate existing and other best practices.

Framework Approaches

• Provide thought leadership on available techniques.

• Perform “open book” audits (no hidden checklists or issues).

• Ensure business and IT orientation to audit approach and recommendations.

• Share audit information and documentation. • Perform risk self assessment. • Perform business impact analysis with business

units. • Define business requirements for IT Governance

together with business units. • Understand impact of regulatory and compliance

issues. • Perform a maturity self assessment on critical IT

processes. • Understand risk appetite.

Focus

• Ensure scope alignment (audits versus governance).

• Identify key risks. • Analyse audit history and use to prioritise. • Share planning approach. • Identify key control weaknesses. • Define regulatory compliance requirements. • Coordinate with external auditors.

• Do internal/external benchmarking. • Internal/external analysis. • Perform controls self-assessments. • Perform detailed self maturity assessments.

Assess

• Provide assurance of IT self –assessments. • Provide positive statements where appropriate. • Provide independent control evaluations for critical

areas.

• Produce scorecards and RAG charts for IT performance in business terms.

• Provide explanations for deviations, successes and significant trends.

Scorecard

• Review and assure measures. • Provide “Audit scorecards” showing performance

against past audit reports. • Provide where appropriate independent

scorecards of IT performance. • Define HOW improvements can be made. • Create business case for changes. • Create implementation action plan. • Provide Project Control and QA. • Facilitate job rotation/secondees.

Improvement

• Advise on WHAT should be improved. • Provide training in controls. • Provide workshops to improve understanding. • Organise shared events. • Facilitate job rotation/secondees.

Figure 8.5

IT Governance Developing a Successful Governance Strategy

46 47

The effectiveness of a self-assessment depends on the quality, objectivity, skill and experience of the people performing the review. Using an alternative means of checking to supplement the questionnaire can help as can obtaining Internal audit input in an educating/reviewing role.

There are a number of constraints and challenges relating to self-assessments: Level of matur i ty Number/volume of test ing Rel iance on the resul ts

- Object iv i ty - Completeness and Rigour

Resources – IT is typical ly over loaded with day to day pressures Pol i t ical issues need to be addressed – how to get management buy- in, and there

may be a ret icence to ident i fy and quant i fy r isks Cul tural aspects should be considered – e.g. the need to balance posi t ive messages

with weaknesses Avoid rout ine t ick ing boxes exercises which are much less valuable

The following are some practical requirements for self-assessments: Indiv iduals performing assessments recognise accountabi l i ty There wi l l be a need framework/object ives/pol icy to sel f assess against (e.g. based

on CobiT) Wel l designed quest ionnaires – keep them simple wi th no ambigui ty, and examples

to aid interpretat ion Coaching/training may be needed i f using a web-based quest ionnaire Require support ing evidence to be documented Training may be needed on r isk ident i f icat ion, def in i t ion, and quant i f icat ion

IT & Audit Working Together & Using CobiT8

IT Governance Developing a Successful Governance Strategy

48 49

9 Information Security Governance

9.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 9.2 What is information security? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 9.3 Where to focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 9.4 Roles and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 9.5 Action planning and best practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

Executive management has a responsibility to ensure that the organisation provides all users with a secure information systems environment. Sound security is fundamental to achieving this assurance. Information systems can generate many direct and indirect benefits, and as many direct and indirect risks. These risks have led to a gap between the need to protect systems and the degree of protection applied. Although awareness of these security issues has increased significantly at board levels, most senior business managers are uncertain about actions they should take and rely heavily on technical advisors. Proper governance of security, like any other aspect of IT, requires top management to be more involved in setting direction and overseeing the management of risk. Faced with the fear of unknown risks, and uncertainty regarding the effectiveness of existing controls, top management naturally wonder where to focus attention and set priorities. A risk assessment is usually the best place to start. A complimentary approach is to focus on establishing a security baseline irrespective of the risks – i.e. ensure that all the basic measures are in place.

Managing investments in the implementation and operation of controls is critical, since security can be an expensive and time-consuming task, and experience has shown that large sums of money can be wasted on ineffective or inadequately implemented technical solutions. However, proving security ROI can be difficult since actual reductions in losses or incidents must be shown, and it is sometimes impossible to know if a risk has been prevented.

There is no doubt though, that the easiest way to demonstrate cash return is by showing the cost of incidents and wherever possible this should be done even if the examples are based on assumptions rather than actual figures. Increasingly, the benefits of good security are being recognised by management who understand that security is needed to enable e-business and that a reputation for good security can enhance customer loyalty, sales and ultimately share price. These benefits should be considered when building the business case for security investments. Given that IT security is a specialised topic and there is a shortage of skills, organisations will often seek support from third parties. Information security specialists can play a key role although governance and final decision-making must remain in-house.

9.1 Background “In a global information society, where information travels through cyberspace on a routine basis, the significance of information is widely accepted. In addition, information and the information systems and communications that deliver the information are truly pervasive throughout organisations—from the user’s platform to local and wide area networks to servers to mainframe computers. Accordingly, executive management has a responsibility to ensure that the organisation provides all users with a secure information systems environment. Furthermore, there is a need for organisations to protect themselves against the risks inherent with the use of information systems while simultaneously recognising the benefits that can accrue from having secure information systems. Thus, as dependence on information systems increases, security is universally recognised as a pervasive, critically needed, quality.” (International Federation of Accounts (IFAC) Statement on Managing Security of Information 1998)

Because new technology provides the potential for dramatically enhanced business performance, improved and demonstrated information security can add real value to the organisation by contributing to interaction with trading partners, closer customer relationships, improved competitive advantage and protected reputation. It can also enable new and easier ways to process electronic transactions and generate trust.” 5

The view of the IMPACT IT Governance SIG is that Information security concerns have increased due to:

5. Information Security Governance: Guidance for Boards of Directors and Executive Management, the IT Governance Institute®.

IT Governance Developing a Successful Governance Strategy

48 49

Technical complexi ty Hackers and virus spreaders Increasing ease of use, and the accessibi l i ty of IT systems Anywhere/anyt ime access

Although awareness of these security issues has increased significantly at board levels, most senior business managers are uncertain about actions they should take and rely heavily on technical advisors. Proper governance of security, like any other aspect of IT, requires top management to be more involved in setting direction and overseeing the management of risk.

It is essential therefore for executive management to understand why information security is important and take action to ensure that:

The importance of informat ion secur i ty is communicated to al l and that a pol icy exists to underpin act iv i t ies in a changing environment.

The ownership and responsibi l i ty for informat ion secur i ty is accepted by senior management in the business as wel l as in IT.

Everyone understands that secur i ty wi l l not be sat isf ied s imply by the appointment of a secur i ty manager – the secur i ty funct ion is there to assist management and secur i ty is ul t imately the responsibi l i ty of everyone.

Any shortage of ski l led resource in th is area is addressed, as i t may be impossible to retain al l the necessary ski l ls and funct ions in-house.

Responsibi l i ty for any secur i ty aspects of corporate compl iance is accepted by the Board.

Management concerns are focused on: Gaps – what and where are the s igni f icant and speci f ic weaknesses in secur i ty? Are these weaknesses being addressed? Are resources and money being wisely invested and are the r ight controls being

implemented in the areas most vulnerable to threat?

9.2 What is information security? One of the causes of poor information security and ineffective governance of information security is a misunderstanding of what it actually covers and how it should be addressed. The ITGI publication, Information Security Governance: Guidance for Boards of Directors and Executive Management, describes information security as follows:

“Security relates to the protection of valuable assets against loss, misuse, disclosure or damage. In this context, “valuable assets” are the information recorded on, processed by, stored in, shared by, transmitted or retrieved from an electronic medium. The information must be protected against harm from threats leading to different types of vulnerabilities such as loss, inaccessibility, alteration or wrongful disclosure. Threats include errors and omissions, fraud, accidents and intentional damage. The objective of information security is “protecting the interests of those relying on information, and the systems and communications that deliver the information, from harm resulting from failures of availability, confidentiality and integrity.

Information Security Governance9

Policy Development The security objective and core principles provide a framework for the first critical step for any organisation – developing a security policy.

Roles & Responsibilities For security to be effective, it is imperative that individual roles, responsibilities, and authority are clearly communicated and understood by all.

Design Once a policy has been approved by the governing body of the organisation and related roles and responsibilities assigned, it is necessary to develop a security and control framework that consists of standards, measures, practices, and procedures.

Implementation Once the design of the security standards, measures, practices, and procedures has been approved, the solution should be implemented on a timely basis, and then maintained.

Monitoring Monitoring measures need to be established to detect and ensure correction of security breaches, such that all actual and suspected breaches are promptly identified, investigated, and acted upon, and to ensure ongoing compliance with policy, standards, and minimum acceptable security practices.

Awareness, Training, & Education

Awareness of the need to protect information, training in the skills needed to operate information systems securely, and education in security measures and practices are of critical importance for the success of an organisation’s security program.

Figure 9.2

IT Governance Developing a Successful Governance Strategy

50 51

According to the IFAC guidance, the major activities associated with Information Security management relate to the items in Figure 9.2.

9.3 Where to focus Faced with the fear of unknown risks, and uncertainty regarding the effectiveness of existing controls, top management naturally wonder where to focus attention and set priorities. A risk assessment is usually the best place to start and this should be based on analysis of the likelihood of different threats, vulnerability and impact. Consideration of the impact of security threats should always be the responsibility of business management, who should ultimately sign-off acceptance of the risk management plan. In practice, this is an area where the business needs to be more involved.

It will be helpful if the risk assessment can be converted to a financial value derived from the impact – even if this is only approximate and based on rough estimates or scales – since decisions to improve security will usually be made based on financial parameters.

A complimentary approach is to focus on establishing a security baseline irrespective of the risks – i.e. ensure that all the basic measures are in place. This can be based on standard guidance such as the ISO17799 (www.iso.org) standard or freely available guidance such as the CobiT Security Baseline (www.itgi.org). A key element of this approach is to create security within the infrastructure, rather than on a piecemeal basis.

9.4 Roles and Responsibilities “Executive management, information systems security professionals, data owners, process owners, technology providers, users, and information systems auditors all have roles and responsibilities in ensuring the effectiveness of information security. Due diligence must be exercised by all individuals involved in the management, use, design, development, maintenance, operation, or monitoring of information systems.” (International Federation of Accounts (IFAC) Statement on Managing Security of Information, 1998)

“Too often information security has been dealt with as a technology issue only, with little consideration given to enterprise priorities and requirements. Responsibility for governing and managing the improvement of security has consequently been limited to operational and technical managers.

However, for information security to be properly addressed, greater involvement of boards of directors, executive management and business process owners is required. For information security to be properly implemented, skilled resources such as information systems auditors, security professionals and technology providers need to be utilised. All interested parties should be involved in the process.” 6

Specific roles: A Forum or Council should be established to set policy, ensure that consensus is reached on where security investments should be made, and for approving and overseeing execution of the risk management plan. The Forum should share knowledge of IT and risks, be focused on business objectives not technical solutions and include representatives from key business units, IT, internal audit and outsource suppliers. It should report into a governance board (or group IT board).

An IT Security Manager should be in place as an advisor to management and the project owner of security action plan. However, care must be taken to avoid implying that security has now been dealt with by hiring such a person (when it is everyone’s responsibility) or that this role relieves top management of their overall governance responsibilities. The role can be part time and is often supported by external advisors. It is often part of a Risk Management function.

An Operational Team will be needed to maintain and monitor security processes and operate administrative procedures. This is usually a technical function and it is increasingly being outsourced.

The Audit Function plays a key independent role in monitoring and assessing the adequacy of security within the organisation.

A useful approach to improving the understanding, awareness and ownership of security within the business is to appoint Information Security Coordinators.

It is critical to influence the Investors, Providers & Controllers positively so that they understand the objectives and benefits of IT Governance and are able to communicate consistently to each other and within their groups. The table below

6. Information Security Governance: Guidance for Boards of Directors and Executive Management, the IT Governance Institute®.

IT Governance Developing a Successful Governance Strategy

50 51

summarises how IMPACT SIG members believe each group of stakeholders should focus on their security responsibilities (Figure 9.4).

Third party security providers Given that IT security is a specialised topic and there is a shortage of skills, organisations will often seek support from third parties.

Information security specialists can play a key advisory role although governance and final decision-making must remain in-house. There is also an opportunity for cost reduction compared with permanent in-house staff. Examples of outsourced security activities include:

Test ing (e.g. fo l lowing patches) Vulnerabi l i ty test ing (note: Penetrat ion test ing must be performed with care as i t

may crash the system) Incident management

Special care should be taken when dealing with outsourced suppliers: Contractors need to be vetted for secur i ty purposes Suppl iers do have a responsibi l i ty to manage secur i ty wi th in their own act iv i t ies

– make sure th is happens Al though the suppl ier has to be trusted to carry out checks, the c l ient must ensure

that the necessary checks are in place Regulat ions such as Sarbanes-Oxley requires that governance responsibi l i ty

remains in-house

Information Security Governance9

Who needs to be involved?

Investors Providers Controllers • The Board • IT Council/Management Team • Senior business unit managers e.g. key

customers of IT services • Business Partners • External investors/shareholders – as part

of corporate governance

• Project and change managers (IT and Business)

• Programme managers • Business managers and users • Technical delivery and support teams • Key players e.g. Business sponsors,

Project champions • Relationship managers and internal

communications teams • Suppliers (especially outsourced service

providers) • Contract and procurement management • Peripheral players/influencers/Policy

owners e.g. HR, Facilities Management, Legal

• Internal audit and external audit (due diligence)

• External regulators • Corporate governance coordinator • Risk managers • Compliance – regulatory and internal • Finance/Project Managers/IT and

business managers – reviewers of benefits/ROI

• Post investment appraisal/Post project review teams

Key Security Responsibilities • Risk sign-off • Own the business case • Set policy • Define expectations and requirements • Ensure legal and regulatory compliance • Review performance • Monitor delivery • Quantify impact of risk • Challenge the risk management plan • Approve proposals and metrics • Prioritise actions and investments • Supply necessary resources • Set culture and environment

• Risk analysis • Design and implementation • Creation of business cases – cost and

solution • Security operations • Security administration • Monitoring security incidents • Education and training (both IT and HR) • Creation and maintenance of scorecards

for performance measurement

• Understand impact of regulations • Monitor adequacy and performance of

controls (assessments and audits) • Test actual performance of controls • Monitor performance (execution of

improvements) • Provide independent assurance to

management

Figure 9.4

IT Governance Developing a Successful Governance Strategy

52 53

9.5 Action planning and best practice IMPACT SIG members suggest the following action steps be considered:

1. Classify objectives and actions into technical and non-technical areas 2. Ensure that an effective security policy is in place 3. Establish a security baseline 4. Cover key vulnerabilities 5. Communicate management concerns for security to ensure staff awareness 6. Focus on changes – evaluate and test for security exposures 7. Ensure that Board presentations emphasise security as an enabler and not as a disabler

IT Governance Developing a Successful Governance Strategy

52 53

10 Legal & Regulatory Aspects of IT Governance

10.1 Legal and regulatory factors affecting IT Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 10.2 Roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 10.3 Best approach to compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 10.4 What IT has to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 10.5 Dealing with third parties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 10.6 Critical success factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59

In recent years there has been a general increase in the number of regulations affecting the use of IT and also the number of situations where legal measures need to be considered. This is due to the need to guard against a wide range of new IT related risks and from a general increase in corporate regulations.

The impact of not taking sufficient care over legal or regulatory requirements can be considerable including:

Loss of reputat ion Inabi l i ty to t rade Financial penal t ies and losses Loss of compet i t ive advantage Loss of opportuni ty

On the other hand the benefit of complying with regulatory requirements and using legal measures to protect commercial interests can be considerable, including:

General improvement in overal l control of IT related act iv i t ies Reduced losses and administrat ive costs More ef f ic ient and ef fect ive negot iat ion of commercial t ransact ions A greater abi l i ty and conf idence to take r isks – because senior management feel

more in control

There are a wide range of laws and regulations, some specific to industry sectors that can have an impact on IT. Every organisation must identify the specific regulations affecting them and respond accordingly, and ensure that the roles and responsibilities for understanding legal and regulatory matters are properly defined for each group of stakeholder so that each group can apply its specific expertise effectively. External advice must be sought whenever the issues are sufficiently risky or complex.

Every organisation relies on a growing number of third parties for support of IT services. From a legal and regulatory perspective this means that there is potentially a complex hierarchy of responsibilities that combine to meet the legal and regulatory needs of the customer. Ultimately it is the customer’s responsibility to ensure that all the right controls are in place with any third party that is relied upon for legal and regulatory compliance.

10.1 Legal and regulatory factors affecting IT Governance The recent increase in the number of regulations affecting the use of IT is due to a number of factors, including:

Legal & Regulatory Aspects of IT Governance10

IT Governance Developing a Successful Governance Strategy

54 55

A greater interest by regulators in the operat ions of a l l organisat ions caused by major corporate f inancial fa i lures and scandals, which is resul t ing in regulat ions l ike the US Sarbanes- Oxley Act forc ing Boards of Directors to express opinions about their systems of control .

Concerns about secur i ty and pr ivacy fueled by the overal l increase in use of computers and networks and the impact of the Internet.

Laws to protect personal informat ion and i ts potent ia l misuse in electronic form.

A growth in the use of computer systems and networks for cr iminal act iv i ty and terror ism, including viruses, hacking, money launder ing and pornography etc.

A growth in complex contractual re lat ionships for IT services and products (outsourcing, managed services, product l icenses etc.) .

The growth in al l forms of e lectronic media and the potent ia l for misuse of valuable informat ion assets, resul t ing in copyr ight and intel lectual property issues of concern to both vendors and users.

What might appear to be an initial regulatory burden can become an opportunity to transform to better managed practices if the rules are used positively and applied productively. Corporate regulations like the Sarbanes-Oxley Act can be just a minimalist compliance procedure with no potential benefit to the business or be used as an opportunity to invest in better IT controls. Compliance with IT-related legal and regulatory requirements and the effective use of legal contracts are clearly part of the effective control and oversight of IT activities by senior management and therefore key aspects of IT Governance.

There are a wide range of laws and regulations, some specific to industry sectors, that can have an impact on IT. Every organisation must identify the specific regulations affecting them and respond accordingly.

The IMPACT SIG has identified the following areas that ought to be considered:

Personal data and pr ivacy Corporate Governance, f inancial report ing, stock market

requirements Money launder ing, and other cr iminal acts Intel lectual Property, Trademarks and Copyr ight Electronic communicat ion, s ignatures etc. Electronic commerce Emai l monitor ing, appropr iate use and conf ident ia l i ty Emai l defamat ion Document and record retent ion IT products and services contracts Sector speci f ic regulat ions e.g. f inancial , heal th, pharmaceut ical

etc.

10.2 Roles and Responsibilities Dealing with legal and regulatory requirements and knowing how best to use legal contracts can be challenging for IT experts who are not knowledgeable about legal matters, and for business managers who may not appreciate all the legal risks and issues associated with the use of advanced technology.

Organisations should therefore ensure that the roles and responsibilities for understanding legal and regulatory matters are properly defined for each group of stakeholder so that each group can apply its specific expertise effectively. External advice must be sought whenever the issues are sufficiently risky or complex.

IT Governance Developing a Successful Governance Strategy

54 55

10.3 Best approach to compliance Ideally organisations should deal with legal and regulatory requirements on a “business as usual” basis instead of reacting on a case-by-case basis.

In practice, it is recommended that a framework for dealing with legal and regulatory issues be established. Because IT is fast changing and new regulations are also emerging, any such framework must be flexible and responsive to new requirements.

Legal & Regulatory Aspects of IT Governance10 Who needs to be involved?

Investors Providers Controllers

• The Board • IT Council/Management Team • Senior business unit managers e.g. key

customers of IT services • Business Partners • External investors/shareholders – as part of

corporate governance

• Project and change managers (IT and Business) • Project and change managers (IT and

Business) • Programme managers • Business managers and users • Technical delivery and support teams • Key players e.g. Business sponsors, Project

champions • Relationship managers and internal

communications teams • Suppliers (especially outsourced service

providers) • Contract and procurement management • Peripheral players/influencers/Policy owners

e.g. HR, Facilities Management, Legal

• Internal audit and external audit (due diligence) • External regulators • Corporate governance coordinator • Risk managers • Compliance – regulatory and internal • Finance/Project Managers/IT and business

managers – reviewers of benefits/ROI • Post investment appraisal/Post project

review teams

Legal and Regulatory Responsibilities

• Understand requirements (what regulations are to be complied with)

• Set the mandate • Set priorities and expectations • Establish and ensure the expected degree of

compliance • Based on advice concerning risk and cost: • Assess impact on business • Provide resource and funding to ensure

issues are addressed • Define who is accountable • Obtain internal or external assurance as

required that issues have been addressed and controls established

• Monitor and evaluate compliance programmes and significant commercial contracts

• Sign off specific compliance programmes • Provide approvals when required for

significant legal or regulatory decisions

• Advise on IT related technical and commercial risks that could impact legal and regulatory requirements

• Provide proposals and business cases for legal and regulatory programmes, projects or action plans

• Formulate solutions for compliance or commercial contracts

• Identify best practices for ongoing good control of legal and regulatory requirements

• Exploit technology and tools where appropriate for ensuring compliance (e.g. asset registers)

• Execution of compliance and contractual processes, and operation of elated controls

• Provide compliance framework to ensure a sustainable “business as usual” approach to compliance

• Provide evidence of compliance • Provide information relating to the cost of

compliance and also cost of any incidents • Evaluate impact on business environment

together with business units • Ensure vendors, service providers, and

subcontractors are involved properly and integrated within the overall compliance approach

• Maintain awareness of current and emerging laws, and regulations affecting IT to assess their impact on the organisation’s business

• Develop an understanding of their impact on the organisation and advise accordingly on “what is needed” - not necessarily “how”

• Monitor adequacy of controls and compliance processes

• Monitor the business and IT functions for performance in meeting legal and regulatory requirements and report back to management with advice regarding any shortcomings

• Provide independent assurance to management that adequate controls are in place to deal with legal and regulatory requirements

Table 10.2

IT Governance Developing a Successful Governance Strategy

56 57

Figure 10.3 illustrates a common problem when new regulatory requirements are imposed. To be effectively handled the decisions concerning the regulation should be taken at the level at which business objectives are set and within the group or business risk framework. This is the necessary level at which priorities can be determined and the standards framework can be applied.

However, as illustrated, a special programme is frequently set up outside the remit of existing standards and governance in the hope that the new regulatory environment can be incorporated. This is usually unsuccessful or inefficient because outside of existing governance it is very difficult to allocate and establish responsibilities for monitoring and testing. Similarly, there can be no clear prioritisation or co-ordination among different regulatory requirements. Conversely, when the left-hand route is followed and a new regulation comes into force, it is possible to identify where there are already procedures in place that enable the new requirements to be met.

For complex IT environments, the importance of the framework is emphasised by the need to understand which standards affect which systems. Then it becomes possible to address all the relevant systems when standards have to change:

Consider regulatory issues together Do not set up separate projects which may conf l ic t wi th the standard approach Decis ion making must rest wi th the business in terms of the extent and nature of

compl iance

10.4 What IT has to do Historically, most IT people did not think about compliance- except in terms of good practice, because regulations rarely impacted the technical environment. Gradually this has changed, first with IT specific legislation like the Data Protection act, and most recently by the realisation that corporate level regulations like Sarbanes-Oxley must be inextricably linked to the IT systems because corporate information and financial reporting has become so automated.

Figure 10.3

IT Governance Developing a Successful Governance Strategy

56 57

In addition, due to the very significant cost of IT investments, and the complexity of customer and supplier relationships, legal contracts for IT services are being given much more careful attention. These contracts in turn demand greater controls be demonstrated by the parties to the contract, over many issues such as security, intellectual property, service availability, ownership of deliverables, support of products etc.

As a consequence, IT service providers, vendors, and internal IT functions are all realising that they must be better organised from a control and compliance perspective. It is only a relatively recent realisation that IT related controls should be documented and monitored by IT functions, increasingly driven by regulatory pressure.

Business objectives and processes should drive the system of internal control and therefore the documentation process. The flow should be:

For an efficient and effective compliance process, the documentation should be in a language that auditors would use, and therefore it is best to work with the audit community and adopt a common language and approach such as CobiT.

IT functions increasingly need to be more involved in legal and regulatory requirements and should:

Work wi th the business users and r isk management groups to ident i fy cr i t ical systems and compl iance pr ior i t ies.

Document archi tectures so that the overal l environment is understood on a cont inuous basis.

Def ine processes in IT in a logical wel l ordered fashion, meaningful to audi tors and management (e.g. based on CobiT).

Appoint process owners so there is accountabi l i ty and responsibi l i ty. Understand control concepts, the need for IT controls, and how they relate to

business level controls. Document these processes and controls (especial ly for compl iance cr i t ical systems),

and maintain the documentat ion as changes occur.

Legal & Regulatory Aspects of IT Governance10

Figure 10.4

IT Governance Developing a Successful Governance Strategy

58 59

Standardise wherever possible to avoid dupl icat ion of ef for t . Maintain evidence of controls being exercised to be better able to demonstrate

compl iance. Generate business benef i ts f rom the control and compl iance projects by performing

gap analyses to dr ive improvements and ef f ic iencies as wel l as bui ld ing good controls.

Consider the whole infrastructure rather than tackl ing i tems on a piecemeal basis. Be responsible for d i l igent procurement and proper control and management of th i rd

part ies.

To achieve these objectives:

IT should seek advice f rom HR, Legal , and Audi t , and i f necessary external experts.

Adopt standard approaches and best pract ices – don’ t at tempt to reinvent the wheel as i t wastes t ime and makes working with partners and audi tors much less ef fect ive (compare with account ing- standard procedures are essent ia l ) .

Bui ld in the need for th i rd party test ing as required.

10.5 Dealing with third parties Every organisation relies on a growing number of third parties for support of IT services. From a legal and regulatory perspective this means that there is potentially a complex hierarchy of responsibilities that combine to meet the legal and regulatory needs of the customer. Ultimately it is the customer’s responsibility to ensure that all the right controls are in place with any third party that is relied upon for legal and regulatory compliance.

Conversely, service providers have their own corporate governance agenda, combined with the pressures of their business models – usually to provide a better service at a lower cost than the customer had previously experienced:

They have to work wi th di f fer ing governance models of business partners and cl ients.

In theory they might use a standard model across al l but in pract ice th is is unl ikely.

- Large cl ients, in part icular, are unwi l l ing to change their own model. - Cl ients cannot be obl iged to do business in a way speci f ied by the provider.

The outsourcer or provider may not ensure full coverage of legal and regulatory requirements:

The customer may go to the provider and speci fy what is required or provide a quest ionnaire, but the provider may st i l l not have taken act ion himsel f or know what is required.

People who negot iate outsourcing contracts are usual ly at a commercial business level , not dr iven by controls and compl iance issues.

In order for both sides to be clear on responsibilities it is essential that sufficient in-house capability is retained. Most organisations actually get more rigour when they outsource but most contracts are built around existing operations with all their limitations. The onus should be on the provider to spell out the risks – but the provider will not improve controls unless paid to do so, or can see a commercial benefit in making the necessary investment.

Legally there is a standard reasonable expectation of basic service, and ultimately it is a question of negligence if controls were not operated properly.

The provider is unlikely to provide a higher level of control in specific situations (such as security) than the client had originally operated himself – but must have nevertheless an adequate set of controls. Special requirements such as vulnerability testing will not normally be seen as part of a contract unless formally requested and paid for.

IT Governance Developing a Successful Governance Strategy

58 59

10.6 Critical success factors The IMPACT SIG identified the following success factors to enable effective ongoing legal and regulatory compliance and proper control of legal contracts:

Establ ish the r ight cul ture to encourage di l igence and good controls Communicat ion throughout the organisat ion based on a Board level mandate is

essent ia l to make sure everyone takes the issues ser iously and uni formly Involve the r ight people as advisors but do not abdicate responsibi l i ty Retaining responsibi l i ty for control and compl iance when using service providers Standardisat ion and a common approach is the most ef fect ive and ef f ic ient way to

meet compl iance requirements Use frameworks and accepted compl iance models especial ly those accepted by

audi tors Integrate compl iance object ives into the IT strategy Ensure management are act ively involved – not just performing a s ign-of f at the

end - Set the tone at the top

Inst i tut ional ise compl iance behaviour - Engage the governance and r isk management groups ( those who own the

framework) as soon as possible - Provide a posi t ive spin – good controls can be very benef ic ia l - Make compl iance normal business pract ice rather than a project

Make compl iance meaningful and relevant - Translate into normal language - Explain business context - Carry out awareness training

Establ ish mechanisms for evidence and documentat ion Establ ish metr ics for monitor ing performance Create incent ives and/or penal t ies as part of personal object ives Do regular compl iance checking and tests Do regular review of r isks ( include 3rd part ies) Have good incident management procedures to learn f rom legal and regulatory

incidents

Legal & Regulatory Aspects of IT Governance10

IT Governance Developing a Successful Governance Strategy

60 61

11 Architecture Governance 11.1 Why is Architecture Governance important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60 11.2 What are the objectives of Architecture Governance? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

Given the complexity and fast-changing nature of IT, architectures are important for defining technical direction, captured in a formal design that will support evolution and change, based on generally accepted standards as well as specific design standards. Architecture governance is therefore to do with ensuring that the principles of architectures are properly applied to the design and maintenance of information systems, meeting technical design standards as well as the business purpose and strategic objectives for IT.

There are generally three overall end goals with respect to architecture governance: Business and IT Al ignment ( f i t for purpose) Risk Management (reduced l ikel ihood of design fai lures) Resource Management (cost ef fect iveness and value for money)

The process of determining technological direction via an IT Architecture satisfies the business requirement to take advantage of available and emerging technology to drive and make possible the business strategy. This is enabled by creation and maintenance of a technological infrastructure plan that sets and manages clear and realistic expectations and standards, of what technology can offer in terms of products, services and delivery mechanisms. Given the significant amount of outsourcing of IT services, the effective governance of architectures in these situations is a key consideration. The business strategy may depend on an effective IT architecture, but who defines the architecture in the outsourced situation? The customer should always take control of his own requirements including architectural decisions even if the provider offers existing solutions and approaches. Senior management may assume that providers will develop technology to improve productivity – this is not always the case. A capability for setting the direction for technology improvement should be retained in house and often contracts will call for customers to control their own technical direction. Cost will usually be the driving factor in contractual arrangements – who will pay for architectural upgrades?

The group identified the following critical success factors for achieving architectural governance: Ensure that the Archi tecture process and i ts governance is adequately funded Ensure good communicat ions among al l the groups concerned Al ign the archi tecture wi th the business strategy and the cul ture of the

organisat ion Recognise that persuasion is always needed for compl iance and that th is can be

enhanced by act ive project involvement, technical consul tancy, provis ion of readi ly- avai lable, cost-ef fect ive tool-k i ts and components

Share al l ar tefacts wi th outsource providers

11.1 Why is Architecture Governance important? Architecture (in Greek αρχή = first and τέχνη = craftsmanship) is the art and science of designing structures. In the context of computers, the term architecture is used to describe the technical design and interoperability of components that together make up the information system i.e. hardware, software and network components.

Given the complexity and fast-changing nature of IT, architectures are important for defining technical direction, captured in a formal design that will support evolution and change, based on generally accepted standards as well as specific design standards. There is an analogy with the original use of architectures for defining the design of buildings – providing the blueprint that demonstrates what the end product should look like, that it is formed on a solid foundation, that it is built according to defined design standards, and that it meets the purpose for which it was intended.

Architecture governance is therefore to do with ensuring that the principles of architectures are properly applied to the design and maintenance of information systems, meeting technical design standards as well as the business purpose and strategic objectives for IT. The IT Governance and Technical Architecture SIG members believe that in many organisations the

IT Governance Developing a Successful Governance Strategy

60 61

challenge is to commit to a properly funded and business driven architectural approach. Often it is treated as too technical an activity, with inadequate or insufficiently skilled resources, and with limited business and top management direction.

The group assessed the maturity of Architectural activities based on the CobiT® maturity model (see Appendix). This assesses maturity on a scale from 0 to 5. An analysis of the maturity level of the organisations represented showed the following:

Current matur i ty ranged from 1+ to 4 - In larger organisat ions there was a spread (e.g. f rom 2 to 4) across the di f ferent

parts of the organisat ion - The lowest matur i ty was in a business where IT had recent ly been outsourced

The matur i ty level aspired to was between 3+ and 4 - No organisat ion saw level 5 as necessary

11.2 What are the objectives of Architecture Governance? The definitions CobiT® provides for setting technical direction were used to help define the purpose of Architecture Governance:

It considers: Capabi l i ty of current infrastructure Monitor ing technology developments v ia rel iable sources Conduct ing proof-of-concepts Risk, constraints and opportuni t ies Acquis i t ion plans Migrat ion strategy and roadmaps Vendor relat ionships Independent technology reassessment Hardware and software pr ice/performance changes

Covering the following activities: Technological infrastructure planning Monitor ing future t rends and regulat ions Assessing technological cont ingency Planning hardware and software acquis i t ions Def in ing technology standards

The group believe that measurement of these activities is difficult and may often rely on perception of trends.

CobiT® suggests focusing on these key measurable outcomes: Number of technology solut ions that are not al igned with the business strategy Percent of non-compl iant technology projects planned Number of non-compat ib le technologies and plat forms Decreased number of technology plat forms to maintain Reduced appl icat ions deployment ef for t and t ime-to-market Increased interoperabi l i ty between systems and appl icat ions

And these performance measures: Percent of IT budget assigned to technology infrastructure and research Number of months s ince the last technology infrastructure review Business funct ions’ sat isfact ion wi th the t imely ident i f icat ion and analysis of

technological opportuni t ies Percent of technological domains wi th in the technology infrastructure plan that have

sub-plans speci fy ing current state, v is ion state and implementat ion roadmaps Average length of t ime between the ident i f icat ion of potent ia l ly re levant new

technology and the decis ion as to what to do with that technology

The Open Group (www.opengroup.org) defines an Architecture Governance Framework which covers:

Architecture Governance11

IT Governance Developing a Successful Governance Strategy

62 63

Governance processes Pol icy management Compl iance assessments Dispensat ion procedures Monitor ing and report ing Business control (compl iance with the organisat ion’s business pol ic ies) Environment management ( the physical and logical reposi tory management) and

governance environment (administrat ive processes).

Given the significant amount of outsourcing of IT services, the effective governance of architectures in these situations is a key consideration. The business strategy may depend on an effective IT architecture, but who defines the architecture in the outsourced situation? The customer should always take control of his own requirements including architectural decisions even if the provider offers existing solutions and approaches. Unfortunately, weaknesses and bad practices in outsourcing arrangements can lead to architectural misunderstandings or restrictions that can be costly or damaging to business performance. On the other hand the provider may enable a customer to adopt a proven, reliable architecture at much lower cost and in much faster timescales than agreeing and developing a solution in house (for example hosting services).

Senior management may assume that providers will develop technology to improve productivity – this is not always the case. A capability for setting the direction for technology improvement should be retained in house and often contracts will call for customers to control their own technical direction. Cost will usually be the driving factor in contractual arrangements – who will pay for architectural upgrades? Even when improvements are called for by the contract, they may not be provided.

IT Governance Developing a Successful Governance Strategy

62 63

12 Managing the IT investment 12.1 Why is managing the IT investment important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 12.2 Portfolio management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 12.3 Benefits management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 12.4 Measuring investment performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 12.5 Improving value delivery and ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 12.6 Measuring and controlling IT operational costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 12.7 Project risk managment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

Ensuring that value is obtained from investment in information technology is an essential component of IT governance. No investment, whether IT-related or not, should be undertaken without full knowledge of the expected cost and the anticipated return. Expected return should always be related to risk as, given the higher likelihood of failure, high-risk projects should always have an anticipation of a higher return. Ensuring that the right projects are approved in the first place implies a need for accurate predictive costing of the total project across its lifetime and robust predictions of the potential return, including quantification of the direct and indirect benefits. To ensure that the total process works and becomes part of the culture of the organisation, it is essential to establish proper tracking mechanisms to determine the actual value delivered and enable accountability.

Given the volatility of a portfolio of IT-related business projects, it is essential to embed active portfolio management into the organisation to maximise value creation and minimise the risk of value destruction. As with any aspect of IT governance, the process needs visibility, leadership and commitment from the top.

12.1 Why is managing the IT investment important? “The basic principles of IT value are the on-time and within-budget delivery of appropriate quality, which achieves the benefits that were promised. In business terms, this is often translated into: competitive advantage, elapsed time for order/service fulfilment, customer satisfaction, customer wait time, employee productivity and profitability. Several of these elements are either subjective or difficult to measure, something all stakeholders need to understand. Often, top management and boards fear to start major IT investments because of the size of investment and the uncertainty of the outcome. For effective IT value delivery to be achieved, both the actual costs and the return on investment need to be managed” (ITGI Board Briefing V2 2004).

20% of all expenditure on IT is wasted7, representing, on a global basis, annual value destruction of US$500bn according to a 2002 Gartner paper (Gartner, ‘The Elusive Business Value of IT’, August 2002). It is then no surprise that there is an increasing demand from boards and executive management for generally accepted guidelines for investment decision-making and benefit realisation. While particularly applicable to IT-enabled business investments, where IT is a means to an end, the need is equally applicable to all investment decisions. In the case of IT, the ‘’end” is to contribute to the process of value creation in the enterprise.

IT-enabled business investments, when managed well within an effective governance framework, provide organisations with significant opportunities to create value. Without effective governance and good management, they provide an equally significant opportunity to destroy value. Horror stories abound around the value destruction suffered by major organisations through the failed implementation of IT enabled business investments. Nike reportedly lost more than US$200m through difficulties experienced in implementing its supply chain software, failures in IT enabled logistics systems at MFI and Sainsbury in the UK led to multi-million pound write-offs, profit warnings and erosion of share price. Other organisations have suffered in a similar fashion.

On the other hand, many successful organisations have created value through selection of the right investments, and successfully managing them through implementation to realising the expected value. Examples include IBM who reportedly was able to save more than US$12bn over two years by linking disparate pieces of its supply chain and thereby reducing inventory levels, and Southwest Airlines who were able to reduce procurement costs and increase service levels through their supply chain transformation project.

Managing the IT Investment12

7. IT Governance Institute® research on IT Value.

IT Governance Developing a Successful Governance Strategy

64 65

The message is clear. IT-enabled business investments can bring huge rewards with the right governance and management processes and full commitment from all management levels. The process for managing IT investments can be summarised as developing, implementing, operating and maintaining financial controls over IT investments and expenditures in line with the IT strategic and tactical plans. Essential elements in this process are benefit and cost justification, budget ownership and accountability and control of actual spending. The process should enable the effective and efficient use of IT resources and provides transparency and accountability into the benefit realisation, total cost of ownership and return on investment of IT.

The role of IT Councils Organisations should establish an IT Council (or Strategy Committee or similar group) at board level to ensure that IT governance, as part of corporate governance, is adequately addressed. This committee reviews major investments on behalf of the full board and advises on strategic direction. Below this committee an IT steering committee (or equivalent) should be established to oversee the IT function and its activities and developing IT plans. The committee should determine prioritisation of IT resources and projects in line with business needs and should be composed of executive management, business and IT representatives. This committee structure will provide the oversight and direction of IT investments, ensuring accountability at senior level and proper involvement of all stakeholders.

12.2 Portfolio management Portfolio management is a good practice for coordinating any group of investments and can be effectively applied to IT investments. It consists of:

Working with the business to establ ish and maintain a port fo l io of new and exist ing IT-enabled investment programmes that are needed to achieve business goals and which, together wi th exist ing IT services and assets, form the basis of the IT budget.

Bui ld ing a port fo l io that recognises that there wi l l be a var iety of categor ies of investment which wi l l d i f fer both in complexi ty and in the degree of f reedom in al locat ing funds.

Al igning the port fo l io wi th the strategic direct ion of the enterpr ise in order to achieve the r ight balance of investments.

Having evaluat ion cr i ter ia in place that should include, at a minimum: al ignment wi th the enterpr ise’s strategic object ives; f inancial worth (as determined by the pract ices of each enterpr ise); and r isk, both del ivery r isk ( the r isk of not del iver ing a capabi l i ty) and benef i ts r isk ( the r isk of not real is ing the expected benef i t f rom the capabi l i ty) .

Implement ing a decis ion-making process to pr ior i t ise the al locat ion of resources for IT operat ions, maintenance and systems development in order to manage and del iver an opt imal return on the IT port fo l io.

Portfolio management is needed to balance and prioritise between new projects and the operating costs of existing systems. It can lead to possible savings on operating costs – e.g. via outsourcing or establishing shared services. Real portfolio management implies a group at the top with an overview of priorities and what is needed – otherwise decisions will be based on relationships and sometimes “who shouts loudest” rather than an objective analysis. Portfolio management should focus on the total ongoing commitment not only the cost of the initial implementation. Managing portfolios can be difficult and requires sound business judgment as well as disciplined management otherwise projects that may be significant to the business may be overlooked or missed in the detailed management processes. For example, projects that are significant to aligning with the business strategy or small initiatives that are critical opportunities may be overlooked. Like all governance activities decisions made at the top level regarding the portfolio investment approach must be communicated down to individual programmes and projects and be monitored.

Portfolio Monitoring Having created an investment portfolio approach, and approved individual investment programmes, there is a need to monitor (post sign-off) all active programmes, just as one would a financial investment portfolio of for example, equities or properties. Costs need to be monitored as well as cost reduction in business areas and revenue generating potential in the business. The portfolio should also be monitored to ensure continuous alignment with strategic business drivers which may be changing with time and with risk factors – both internal to projects and externally. Projects can be very hard to stop, although it is a good practice to review projects on a regular basis and cancel those that are not likely to deliver value. It is recommended that a project office be established working at the programme level, monitoring standards, targets and deliverables. It can be difficult to find and keep the appropriate people in place for this kind of work. Experience has shown that it can be effective to use bright, temporary people or contractors who will also be more likely to give objective assessments.

IT Governance Developing a Successful Governance Strategy

64 65

Acquisition programmes and procurement projects in the UK central civil government are subject to OGC Gateway Reviews. The OGC Gateway Process examines a programme or project at critical stages in its lifecycle to provide assurance that it can progress successfully to the next stage; the process is based on well-proven techniques that lead to more effective delivery of benefits together with more predictable costs and outcomes. It is designed to be applied to delivery programmes and procurement projects, including those that procure IT-enabled business change. The OGC Gateway Process provides assurance and support for Senior Responsible Owners (SROs) in discharging their responsibilities to achieve their business aims. For more guidance refer to www.ogc.gov.uk.

12.3 Benefits management Monitoring whether or not benefits are being delivered is a key aspect of investment management. Without it, it will be impossible to know whether a return on the investment has been realised. In practice though, it seems this is rarely done for IT investments.

The objectives of benefits management should include: Implementat ion of a benef i t monitor ing process. Ident i f icat ion of IT’s expected contr ibut ion to business resul ts, e i ther as a

component of IT-enabled investment programmes, or as part of regular operat ional support and then agreed, monitored and reported on.

Report ing opportuni t ies to improve IT’s contr ibut ion, appropr iate act ions should be def ined and taken.

Updat ing the programme business case where changes in IT’s contr ibut ion impact the programme, or where changes to other related projects impact the programme

The IMPACT IT Governance SIG members believe that seldom does true benefit monitoring take place. Business sponsors should manage benefits but usually they do not. This may be because of job movement in the business, or because the business owner of change is often not the operational owner of the benefits. The main reason though is probably a lack of willingness for the senior business sponsor to take ownership and accountability for monitoring benefits. Investment oversight and the drive to apply discipline to the monitoring process should be directed by the IT Council or management team via a standard process.

12.4 Measuring investment performance Management should establish a general monitoring framework and approach that defines the scope, the methodology and the process to be followed for monitoring IT’s contribution to the results of the enterprise’s portfolio management and programme management processes. The framework should be integrated with the corporate performance management system. The objective is to assess the overall performance of the portfolio of investments. Investment performance assessment should review how the products of IT activities are performing – not just IT as such but the whole process. Many lessons can be

Managing the IT Investment12

Figure 12.4

IT Governance Developing a Successful Governance Strategy

66 67

learnt from analysing why projects are successful or not successful. Setting actual targets and metrics should be driven by the stakeholders who should also approve and monitor them.

12.5 Improving value delivery and ROI To optimise the business value realised from IT-enabled investments it is recommended that8 :

IT-enabled investments are managed as a port fo l io of investments. IT-enabled investments include the ful l scope of act iv i t ies that are required to

achieve business value. IT-enabled investments are managed through their fu l l economic l i fe-cycle. Value del ivery pract ices def ine and monitor key metr ics and respond quickly to any

changes or deviat ions. Value del ivery pract ices engage the business and assign appropr iate accountabi l i ty

for the del ivery of capabi l i t ies and the real isat ion of business benef i ts. Value del ivery pract ices are cont inual ly monitored, evaluated and improved. A discipl ined approach is enforced to port fo l io, programme and project management,

insist ing that the business takes ownership of a l l IT-enabled investments and that IT ensures opt imisat ion of the costs of del iver ing IT capabi l i t ies and services.

Technology investments are standardised to the greatest extent possible to avoid the increased cost and complexi ty of a prol i ferat ion of technical solut ions.

12.6 Measuring and controlling IT operational costs When managing IT investments, there is a tendency to concentrate on new projects rather than ongoing operations. The operational budget is likely to be a much larger financial amount than new investments, and there are often opportunities to optimise these ongoing costs. It is therefore recommended that a cost management process be implemented comparing actual costs to budgets. Costs should be monitored and reported. Where there are deviations, these should be identified in a timely manner and the impact of those deviations on programmes should be assessed and, together with the business sponsor of those programmes, appropriate remedial action should be taken and, if necessary, the programme business case should be updated. If the costs are recorded and analysed down to the lowest “service” level, then the business can decide whether to use the service. Doing this may be costly – especially if carried to too low a level, so it is most effective to focus on significant services and cost areas.

12.7 Project risk management Project risk management is a very valuable process, providing an independent monitoring function. Its purpose is to eliminate or minimise specific risks associated with individual projects through a systematic process of planning, identifying, analysing, responding to, monitoring and controlling the areas or events that have the potential to cause unwanted change. It can include a focus on costs and benefit realisation. In this context project risk management should focus on the following:

Risk assessments that look beyond the internals of the project Ident i fy ing the factors to be considered in advance in a “r isk register” Tracking these i tems on a cont inuous basis Understanding the proximity of the r isk – when might i t h i t? Evaluat ing the sever i ty of the r isk to determine the frequency of monitor ing

needed Risks considered to be high should be closely monitored – by the steer ing commit tee

i f appropr iate – and feedback should be obtained Project r isks that re late to execut ion and del ivery; examples of external business-

related r isk include: - Wi l l the customer want i t? - Need for market test ing - Proof of concept needed?

8. IT Governance Institute®, ValIT Framework.

IT Governance Developing a Successful Governance Strategy

66 67

13 SuccessFactors Focus on the following success factors:

Treat IT governance in i t iat ives as a project not a ‘one-of f ’ step. The goal is to make governance “business as usual” .

Obtain top management buy- in and ownership. This needs to be based on the pr inciples of best managing the IT investment.

Remember that implementat ion involves cul tural change as wel l as new processes. Make sure you enable and mot ivate these changes.

Manage expectat ions. In most enterpr ises, achieving successful oversight of IT takes some t ime and wi l l involve cont inuous improvement.

Success Factors13

�NATIONAL COMPUTING CENTRE

IT Governance Developing a successful governance strategy A Best Practice guide for decision makers in IT

Throughout the past five years, we have witnessed unparalleled corporate scandals and

failures in global businesses. The result; heightened focus on corporate governance, stricter

regulations and new directors’ responsibilities, all adding to the pressure on IT Directors and

CIOs. They must now demonstrate to auditors that IT systems which support financial reporting,

as well as monitor and manage business performance are based on sound management

systems and controls.

Against this background, it has never been more important to ensure your organisation

governs the use of IT properly. With corporate governance on every boardroom agenda -

and increasing scrutiny of IT’s performance - IT governance has become a hot topic around

the world. For some many businesses, IT governance initiatives are already transforming the

way their organisations take responsibility for IT. For others, it is a challenge just knowing

where to start.

Recognising the challenges faced by CIOs in establishing effective IT governance, the NCCs

IMPACT Programme launched an IT Governance Special Interest Group (SIG). Its aim was

to identify not just the issues that need to be addressed, but also practical approaches for

organisations to follow. Over the past two years, heads of IT governance from Abbey, Aon,

Avis, Barclays, BOC, DfES, Eli Lilly, Learning & Skills Council, Legal & General, Marsh, NOMS,

Royal Mail, and TUI Group examined the key challenges. They shared successful approaches

and defined best practice.

This IT Governance Best Practice Guide is a comprehensive insight of the principles and

practices that the group put together. It is presented in a form that should help you to

understand better how to guide successful IT governance initiatives and make effective

management and control of IT resources “business as usual”.

This Guide forms part of the NCC ‘Best Practice’ Guides series and is intended to be of

practical use for decision makers in IT. This guidance is achieved through industry consensus,

managed by NCC, across the broadest range of professionals and experts.

National Computing Centre

Oxford House,

Oxford Road,

Manchester M1 7ED

Tel: 0161 242 2121

Fax: 0161 242 2499

The IMPACT Programme

International Press Centre,

76 Shoe Lane,

London EC4A 3JB

Tel: 0207 842 7900

Fax: 0207 842 7979

ISBN 0-85012-897-8

£35.00 NCC Members

£50.00 Non NCC Members

The following excerpt comes from IT Governance and its mechanisms, written by Wim Van Gremberen Ph.D., and Steven De Haes of the University of Amtwerp Management School. The IT Governance Institute recently developed a specific IT Governance maturity model. According to this model, enterprises that are assessed at level 0 are characterized by a complete lack of any recognizable IT Governance process. To move up to level 1, the organization at least needs to recognize the importance of addressing IT Governance issues. Maturity 5 implies an advanced and forward-looking understanding of IT Governance issues and solutions, supported by an established framework and best practices of structures, processes and relational mechanisms. It should be noted that the desired “to- be” position should be identified in function of the context where one operates (industry, geography, size, etc.) and of the enterprise strategy. When the “as-is” and “to-be” positions are known, gaps can be determined, project defined and specific actions be taken. IT Governance maturity model (IT Governance Institute)

0 Nonexistent

There is a complete lack of any recognizable IT Governance process. The organization has not even recognized that there is an issue to be addressed and hence there is no communication about the issue.

Governance, such as it is, is predominantly centralized within the IT organization, and IT budgets and decisions are made centrally. Business unit input is informal and done on a project basis. In some cases, a steering committee may be in place to help make resource decisions. 1 Initial /Ad Hoc

The organization has recognized that IT Governance issues exist and need to be addressed. There are, however, no standardized review processes, but instead management considers IT management issues on an individual or case-by-case basis. Management's approach is unstructured and there is inconsistent communication on issues and approaches to address the problems that arise. Although it is recognized that the performance of the IT function ought to be measured, there are no proper metrics in place—reviews are based on individual managers’ requests. IT monitoring is implemented only reactively to an incident that has caused some loss or embarrassment to the organization. Governance is difficult to initiate and the central IT organization and business units may even have an adversarial relationship. The organization is trying to increase trust between IT and the business and there are normally periodic joint meetings to review operational issues and new projects. Upper management is involved only when there are major problems or successes.

2 Repeatable but Intuitive

There is awareness of IT Governance objectives, and practices are developed and applied by individual managers. IT Governance activities are becoming established within the organization’s change management process, with active senior management involvement and oversight. Selected IT processes have been identified for improvement that would impact key business processes. IT management is beginning to define standards for processes and technical architectures. Management has identified basic IT Governance measurements, assessment methods and techniques, but the process has not been

adopted across the organization. There is no formal training and communication on governance standards and responsibilities are left to the individual. An IT steering committee has begun to formalize and establish its roles and responsibilities. There is a draft governance charter (e.g., participants, roles, responsibilities, delegated powers, retained powers, shared resources and policy). Small and pilot governance projects are initiated to see what works and what does not. General guidelines are emerging for standards and architecture that make sense for the enterprise and a dialogue has started to sell the reasons for their need in the enterprise. 3 Defined Process

The need to act with respect to IT Governance is understood and accepted. A baseline set of IT Governance indicators is developed, where linkages between outcome measures and performance drivers are defined, documented and integrated into strategic and operational planning and monitoring processes. Procedures have been standardized, documented and implemented. Management has communicated standardized procedures and informal training is established. Performance indicators over all IT Governance activities are being recorded and tracked, leading to enterprise-wide improvements. Although measurable, procedures are not sophisticated, but are the formalization of existing practices. Tools are standardized, using currently available techniques. IT balanced business scorecard ideas are being adopted by the organization. It is, however, left to the individual to get training, to follow the standards and to apply them. Root cause analysis is only occasionally applied. Most processes are monitored against some (baseline) metrics, but any deviation, while mostly being acted upon by individual initiative, would unlikely be detected by management. Nevertheless, overall accountability of key process performance is clear and management is rewarded based on key performance measures. The IT steering committee is formalized and operational, with defined participation and responsibilities agreed to by all stakeholders. The governance charter and policy is also formalized and documented. The governance organization beyond the IT steering committee is established and staffed. 4 Managed and Measurable There is full understanding of IT Governance issues at all levels, supported by formal training. There is a clear understanding of who the customer is and responsibilities are defined and monitored through service level agreements. Responsibilities are clear and process ownership is established. IT processes are aligned with the enterprise and with the IT strategy. Improvement in IT processes is based primarily upon a quantitative understanding and it is possible to monitor and measure compliance with procedures and process metrics. All process stakeholders are aware of risks, the importance of IT and the opportunities it can offer. Management has defined tolerances under which processes must operate. Action is taken in many, but not all cases where processes appear not to be working effectively or efficiently. Processes are occasionally improved and best internal practices are enforced. Root cause analysis is being standardized. Continuous improvement is beginning to be addressed. There is limited, primarily tactical, use of technology, based on mature techniques and enforced standard tools. There is involvement of all required internal domain experts. IT Governance evolves into an enterprise-wide process. IT Governance activities are becoming integrated with the enterprise governance process.

There is a fully operational governance structure that addresses a consistent architecture for reengineering and interoperation of business processes across the enterprise, and ensures competition for enterprise resources and ongoing incremental investments in the IT infrastructure. IT is not solely an IT organizational responsibility but is shared with the business units. 5 Optimized There is advanced and forward-looking understanding of IT Governance issues and solutions. Training and communication is supported by leading-edge concepts and techniques. Processes have been refined to a level of external best practice, based on results of continuous improvement and maturity Page 12 IT Governance and its mechanisms modeling with other organizations. The implementation of these policies has led to an organization, people and processes that are quick to adapt and fully support IT Governance requirements. All problems and deviations are root cause analyzed and efficient action is expediently identified and initiated. IT is used in an extensive, integrated and optimized manner to automate the workflow and provide tools to improve quality and effectiveness. The risks and returns of the IT processes are defined, balanced and communicated across the enterprise. External experts are leveraged and benchmarks are used for guidance. Monitoring, self-assessment and communication about governance expectations are pervasive within the organization and there is optimal use of technology to support measurement, analysis, communication and training. Enterprise governance and IT Governance are strategically linked, leveraging technology and human and financial resources to increase the competitive advantage of the enterprise. The governance concept and structure forms the core of the enterprise IT governing body including provisions for amending the structure for changes in enterprise strategy, organization or new technologies.

Learn About Information Technology Infrastructure Library

• • • BY LAURA SCHNEIDER Updated January 29, 2020

The Information Technology Infrastructure Library (ITIL) is a set of concepts and techniques for managing information technology (IT) infrastructure, development, and operations. ITIL is the most widely accepted approach to IT service management in the world.

ITIL provides a cohesive set of best practices, drawn from the public and private sectors internationally. A whole ITIL philosophy has evolved from the guidance contained within the ITIL books and the ITIL professional qualification scheme.

ITIL consists of a series of books giving guidance on the provision of quality IT services and on the accommodation and environmental facilities needed to support IT. ITIL has been developed in recognition of organizations' growing dependency on IT and embodies best practices for IT Service Management.

Information Technology Infrastructure Library Benefits

By providing a systematic approach to the management of IT service, ITIL can help an enterprise in the following ways:

• reduced costs • improved IT services through the use of proven best practice processes • improved customer satisfaction through a more professional approach to service

delivery • standards and guidance

https://www.thebalancecareers.com/management-issues-surrounding-customer-satisfaction-2275735

• improved productivity • improved use of skills and experience • improved delivery of third party services through the specification of ITIL or ISO

20000 as the standard for service delivery in services procurements.

The ITIL certifications are among the most sought after in the IT industry. Several of the ITIL Certifications typically make it to the list of the highest paying technical certifications. ITIL certifications are managed by the ITIL Certification Management Board (ICMB), which is composed of the OGC, IT Service Management Forum International and two examinations institutes: EXIN (based in the Netherlands) and ISEB (based in the UK). The EXIN and ISEB administer exams and award qualifications at Foundation, Practitioner and Manager/Masters level currently in 'ITIL Service Management', 'ITIL Application Management,' and 'ICT Infrastructure Management' respectively.

The Five ITIL Volumes

The Five ITIL Volumes are as follows:

Service Strategy

he Service Strategy book provides a view of ITIL that aligns business and information technology. It specifies that each stage of the service lifecycle must stay focused upon the business case, with defined business goals, requirements, and service management principles.

Service Design

The Service Design book provides guidance upon the production/maintenance of information technology policies, architectures, and documents.

Service Transition

https://www.thebalancecareers.com/your-ultimate-guide-to-technical-certifications-2071453

The Service Transition book focuses on the change management role and the release practices, providing guidance and process activities for the transition of services into the business environment.

Service Operation

This book focuses on delivery and control process activities based on a selection of service support and service delivery control points.

Continual Service Improvement

This book focuses on the process elements involved in identifying and introducing service management improvements as well as issues surrounding service retirement.

ITIL Version 2

The previous version of ITIL focused less on lifecycle and more on the process. ITIL V2 was divided into two main areas: service support and service delivery.

Service Support answers the concern: How does the data center ensure that the customer has access to the appropriate services? It includes disciplines that enable IT Services to be provided effectively. Service Support is divided into the following areas:

• Change Management • Release Management • Problem Management • Incident Management • Configuration Management

Service Delivery is the management of the IT services themselves and involves a number of management practices to ensure that IT services are provided as agreed between the Service Provider and the Customer. Essentially, service providers need to offer business users adequate support. Service Delivery covers those issues which must be taken into consideration to ensure this. Service Delivery is divided into:

• IT Financial Management • IT Continuity Management • Capacity Management • Availability Management • Service Level Management • Service Desk

ITIL Certifications

Each version of ITIL has three corresponding certification programs. They are:

The Foundation Certificate

This certificate enables people to understand the terminology used within ITIL. It focuses on foundation knowledge with regard to the ITIL Service Support and Service Delivery sets as well as generic ITIL philosophy and background. It is a prerequisite for the Practitioner's and Manager's Certificates in IT Service Management.

The Practitioner Certificate

This focuses on the understanding and application of the specific processes within the IT Service Management discipline.

The Manager's Certificate

The Manager's Certificate Is aimed at experienced professionals, who will be involved in managing service management functions.

ITIL Exams are coordinated through two agencies, the EXIN and the ISEB.

EXIN Information

EXIN is the Examination Institute for Information Science in the Netherlands. They are a global IT examination provider and an independent organization establishing educational requirements for developing and organizing examinations in the field of Information Technology.

https://www.exin.com/en

https://www.thebalancecareers.com/educational-requirements-525660

EXIN has been involved in the ITIL Certification area since ITIL’s inception in the early 1990s and is now one of the agencies involved in ITIL’s continued development.

ISEB Information

The ISEB is the Information Systems Examination Board. They are aligned with the British Computer Society and focus on providing certifications that add value to professional careers by providing both the means and the platform for recognition and enhanced career development.

http://www.bcs.org/

https://www.thebalancecareers.com/what-is-career-development-525496

TODAY'S TOP STORIES

What is ITIL? Your guide to the IT Infrastructure Library ITIL is a framework of best practices for delivering IT services. ITIL’s systematic approach to IT service management can help businesses manage risk, strengthen customer relations, establish cost-effective practices, and build a stable IT environment that allows for growth, scale and change.

By Sarah K. White and Lynn Greiner CIO | JAN 18, 2019 3:23 PM PST

What is ITIL?

The IT Infrastructure Library (ITIL) is a library of volumes describing a framework of best practices for delivering IT

services. ITIL has gone through several revisions in its history and currently comprises five books, each covering

various processes and stages of the IT service lifecycle. ITIL’s systematic approach to IT service management can help

businesses manage risk, strengthen customer relations, establish cost-effective practices, and build a stable IT

environment that allows for growth, scale and change.

Developed by the British government's Central Computer and Telecommunications Agency (CCTA) during the 1980s,

the ITIL first consisted of more than 30 books, developed and released over time, that codified best practices in

information technology accumulated from many sources (including vendors' best practices) around the world. IBM,

for example, says that its four-volume series on systems-management concepts, A Management System for

Information Systems, known as the Yellow Books, provided vital input into the original ITIL books.

[ Learn more about the top ITSM tools today and how ITSM is evolving in the digital transformation era. | Get the latest CIO insights direct, with our CIO Daily newsletter. ]

In April 2001, CCTA, along with several other agencies, were rolled into the Office of Government Commerce (OGC),

which is now known as the Cabinet Office. The OGC adopted the project as part of its mission to work with the U.K.

public sector as a catalyst to achieve efficiency, value for money in commercial activities, and improved success in

the delivery of programs and projects.

The goal wasn't to create a proprietary product that could be commercialized; rather, it was to gather best practices

that could assist with what the government recognized was an increasing dependence within the government on IT

combined with a painful lack of standard procedures that were increasing costs and allowing errors to perpetuate. It

quickly became apparent that distributing these best practices would profit both public and private-sector

organizations.

UNITED STATES 

https://www.cio.com/article/3304243/software/top-itsm-tools.html#tk.cio_fsb

https://www.cio.com/article/3298517/it-service-management/5-ways-businesses-are-modernizing-itsm.html#tk.cio_fsb

http://www.cio.com/newsletters/signup.html

http://www.ogc.gov.uk/

https://www.gov.uk/government/organisations/cabinet-office

https://www.cio.com/

Over the years, ITIL's credibility and utility became recognized, and in 2005 its practices contributed to and aligned

with the ISO/IEC 20000 Service Management standard, the first international standard for IT service management; it

is based on British standard BS15000.

Since 2013, ITIL is owned by Axelos — a joint venture between the Cabinet Office and Capita. Axelos gives

businesses the license to use the ITIL framework, while managing updates and process changes. However, to use ITIL

internally, organizations do not need a license. ITIL v3 was released in 2011, under the Cabinet Office, bringing

updates to the 2007 version published under OGC.

In 2018, Axelos announced ITIL 4 – a major overhaul to the entire framework and the biggest change since ITIL v3

was published in 2007. ITIL 4, which started rolling out in Q1 of 2019, offers a more agile, flexible and customizable

version of ITIL that is updated for modern businesses. The latest version encourages less siloes, more collaboration,

communication across the entire business and integrating agile and DevOps into ITSM strategies.

RECOMMENDED WHITEPAPERS

Content: The Critical Ingredient for Personalization

Cognizant Solutions for Financial Services on AWS

Optimizing the Critical Link Between Employee and Customer Experience

What's in the ITIL?

The ITIL has gone through several revisions in its history. The original 30 books of the ITIL were first condensed in

2000 (when ITIL V2 was launched) to seven books, each wrapped around a facet of IT management. Later, the ITIL

Refresh Project in 2007 consolidated the ITIL to five volumes consisting of 26 process and functions – this is referred

https://www.cio.com/article/3331909/itil/itil-4-update-itsm.html

https://www.cio.com/resources

https://www.cio.com/resources/213748/content-the-critical-ingredient-for-personalization

https://www.cio.com/resources/213755/cognizant-solutions-for-financial-services-on-aws

https://www.cio.com/resources/213648/optimizing-the-critical-link-between-employee-and-customer-experience

to as the ITIL 2007 edition. In 2011, another update — dubbed ITIL 2011 — was published under the Cabinet Office.

The five volumes remained, and ITIL 2007 and ITIL 2011 remained similar.

ITIL 4, which was released in 2019, maintains the same focus on automating processes, improving service

management and integrating the IT department into the business. However, it also updates the framework to

accommodate and answer to modern technology, tools and software. Since ITIL’s last update, the IT department has

grown to become integral to every business and the new framework accommodates this by being more agile,

flexible and collaborative.

ITIL 4 contains nine guiding principles that were adopted from the most recent ITIL Practitioner Exam, which covers

organizational change management, communication and measurement and metrics. These principles include:

Focus on value

Design for experience

Start where you are

Work holistically

Progress iteratively

Observe directly

Be transparent

Collaborate

Keep it simple

The newest version of ITIL focuses on company culture and integrating IT into the overall business structure. It

encourages collaboration between IT and other departments, especially as other business units increasingly rely on

technology to get work done. ITIL 4 also emphasizes customer feedback, since it’s easier than ever for businesses to

understand their public perception, customer satisfaction and dissatisfaction.

For more information on the benefits of the latest version of ITIL, see “ITIL 4: ITSM gets agile.”

SponsoredPost Sponsored by Silver Peak SASE and the Peanut Butter Cup – A Fable

SponsoredPost Sponsored by AWS & Cognizant Data Modernization for the Digital Age

https://www.cio.com/article/3331909/itil/itil-4-update-itsm.html

https://www.networkworld.com/article/3596138/sase-and-the-peanut-butter-cup-a-fable.html

https://cio.com/article/3602976/data-modernization-for-the-digital-age.html

How do I put ITIL into practice?

ITIL is a collection of e-books, but merely going on a reading binge won't improve your IT operations. First, you have

to wrap your brain around the concepts and then get staff buy-in. Getting some IT personnel to adopt new

procedures can be like herding cats, but there are tools that can help.

Along with the ITIL comes a whole suite of consulting, training and certification services. From the early 1990s,

certifications were administered by two independent bodies: EXIN and ISEB, depending on your location. The two

bodies formed an alliance at the end of 2006 to further IT service management.

Since 2014, Axelos is the owner of the ITIL personnel certification and exams are administered by Accredited

Training Organizations (ATOs). Accreditations are administered by Strategic Examination Institutes (EIs). EIs need to

be accredited directly by Axelos in order to offer accreditation to ATOs.

Before implementing ITIL at your organizations, there are several questions you should answer, such as what

problems your organization is trying to solve and what is your route to continual service improvement.

For a deeper look at putting ITIL into practice, see "7 questions to ask before implementing ITIL" and "How to get

started with ITIL."

What is ITIL certi�cation and is it worth it?

The ITIL v3 certification scheme previously consisted of five levels: Foundation, Practitioner, Intermediate, Expert and

Master. Each level required a stronger depth of knowledge and understanding of ITIL. The certification scheme

under ITIL 4 has been streamlined to include the ITIL Foundation and the ITIL Master exams. The ITIL Foundation

exam has two paths, ITIL Managing Professional (MP) or ITIL Strategic Leader (SL), which each have their own

modules and exams.

The ITIL Managing Professional (MP) exam is designed for IT practitioners who are involved with technology and

digital teams throughout the organization, not just in the IT department. This path will teach professionals

everything they need to know about running successful IT projects, teams and workflows.

Modules include:

ITIL Specialist – Create, Deliver and Support

ITIL Specialist – Drive Stakeholder Value

https://www.axelos.com/becoming-an-axelos-partner/examination-institutes

http://www.cio.com/article/3040629/libraries-frameworks/7-questions-to-ask-before-implementing-itil.html

http://www.cio.com/article/2926178/systems-management/how-to-get-started-with-itil.html

https://www.axelos.com/certifications/itil-certifications

https://www.axelos.com/itil-update

https://cio.com/article/3602976/data-modernization-for-the-digital-age.html

ITIL Specialist – High Velocity IT

ITIL Strategist – Direct, Plan & Improve

The ITIL Strategic Leader (SL) exam is designed for those who deal with “all digitally enabled services,” and not just

those that fall under IT operations. This path focuses on how technology directs business strategy and how IT plays

into that.

Modules include:

ITIL Strategist – Direct, Plan & Improve

ITIL Leader – Digital & IT Strategy

Both paths can lead to the ITIL Master exam, which is the highest level of certification you can achieve with ITIL 4.

For those already in the middle of working towards a ITIL v3 certifications, credits will transfer over to the new

certifications. Axelos recommends that all ITIL certification candidates continue the path towards ITIL master.

For in-depth analysis of ITIL certification, see "What ITIL certifications mean to your IT management practices."

How can ITIL improve my company's business performance?

A well-run IT organization that manages risk and keeps the infrastructure humming not only saves money, but it also

allows the business people to do their jobs more effectively. For example, brokerage firm Pershing reduced its

incident response time by 50 percent in the first year after restructuring its service desk according to ITIL guidelines,

allowing users with problems to get back to work much more quickly.

ITIL provides a systematic and professional approach to the management of IT service provision, and offers the

following benefits:

reduced IT costs

improved IT services through the use of proven best practice processes

improved customer satisfaction through a more professional approach to service delivery

standards and guidance

improved productivity

improved use of skills and experience

improved delivery of third-party services through the specification of ITIL or BS15000 as the standard for service delivery in services procurements

According to Axelos, ITIL can also help businesses improve services by:

helping businesses manage risk, disruption and failure

strengthening customer relations by “delivering efficient services that meet their needs”

establishing cost-effective practices

building a stable environment that still allows for growth, scale and change.

http://www.cio.com/article/2388142/careers-staffing/careers-staffing-what-itil-certifications-mean-to-your-it-management-practices.html

http://www3.pinkelephant.com/articles/TheBenefitsOfITILv26.pdf

https://www.axelos.com/best-practice-solutions/itil/key-benefits-of-itil

For a deeper look at how to get the most from ITIL, see "5 steps to successful ITIL adoption."

What will ITIL cost?

Getting started involves the purchase of the ITIL either as hardcopy, PDF, ePub or through an online subscription

directly from Axelos. Then there's the cost of training, which fluctuates each year. The course leading to the initial

Foundation Certificate typically runs for two days, and courses leading to higher certifications can be a week or

more.

Add to that the inevitable cost of re-engineering some processes to comply with ITIL guidelines, and adjustment of

help desk or other software to capture the information you need for tracking and generating metrics.

There is, by the way, no such thing as "ITIL-compliant" software; the ITIL is a framework, not a standard. Some help

desk and management software has been engineered with ITIL practices in mind, however, and so will lend

themselves better to teams working within the framework.

Examples of software and services designed with ITIL and ITSM in mind include:

Samange: Offers service desk automation with the ITIL framework in mind

InvGate Service Desk: A web-based ITIL-ready service that boasts a user-friendly interface

ManageEngine ServiceDesk Plus: Web-based help desk and asset management software that is available in an ITIL edition

Vision Helpdesk: A multifunction service desk solution with ITIL integration

How long will an ITIL project take?

ITIL is not a "project"; it's an ongoing journey to improve IT service management. Best practices have to be baked

into everything, and they have to evolve as the enterprise evolves. With IT staff buy-in, changes can begin once staff

are trained, and some results should be apparent within weeks or months. Process changes do take time, however,

as entrenched bad practices are rooted out and modified (and, potentially, staff changes occur), but many

companies have reported substantial savings after their first year.

To get a better idea of what it will take to adopt and implement ITIL, you can browse through case studies on the

Axelos website. Recent case studies include companies like Sony and Disney — two companies with massive IT

operations to manage.

What savings can I expect?

Corporations and public sector organizations that have successfully implemented ITIL best practices report huge

savings.

http://www.cio.com/article/2399368/itil/5-steps-to-successful-itil-adoption.html

https://www.axelos.com/best-practice-solutions/itil/what-is-itil

https://www.samanage.com/

https://www.invgate.com/

https://www.manageengine.com/

https://www.visionhelpdesk.com/

https://www.axelos.com/case-study-and-white-paper-search?type=casestudies

For example, in its Benefits of ITIL paper, Pink Elephant reports that Procter and Gamble saved about $500 million

over four years by reducing help desk calls and improving operating procedures. Nationwide Insurance achieved a

40 percent reduction in system outages and estimates a $4.3 million ROI over three years, and Capital One reduced

its "business critical" incidents by 92 percent over two years. After three years of ITIL implementation, forest products

company MeadWestvaco claimed to have eliminated more than $100,000 annually in IT maintenance contracts and

recognized a 10 percent gain in operational stability thanks to ITIL.

Without buy-in and cooperation from IT staff, however, any implementation is bound to fail. Bringing best practices

into an organization is as much a PR job as it is a technical exercise.

Other criticisms include the fact that it’s impossible to plan for every failure, event or incident so it’s not an exact

science. In reality, you won’t know the exact ROI on ITIL until you implement it within your organization and use it

effectively. Ultimately, since ITIL is a framework, it can only be as successful as corporate buy-in allows. Embracing

certifications, training and investing in the shift will help increase the chances of success and savings.