The True Value of Change Management

1. The True Value of Change Management March 23, 2006 2:00pm EST, 11:00am PST George Spafford, President, Spafford Global Consulting

2. Housekeeping • Submitting questions to speakers • Questions will be answered during 10 minute Q&A session at end of presentation • Locate “Ask a Question” button at bottom of your screen. • Technical difficulties? • Press *0 on telephone to talk with operator • Dial 888-569-3848 or 719-785-6626

3. Main Presentation

4. Agenda • Why change management matters • Review change management at a high level • Change advisory board composition • Risk Management • Emergency changes

5. Business Continuity • Hitachi Data Systems bi-annual survey of 800 IT directors in 21 countries in EMEA identified the top three business continuity concerns: • Fire 57% • Computer Viruses 55% • Human Error 50% From Managing Automation, September 13, 2005http://www.managinginformation.com/news/content_show_full.php?id=4255

6. Security • May 17, 2005 – Third annual CompTIA study shows human error still counts for the majority of security incidents – 79.3%. That number is virtually the same as 2004. • 53% of organizations do not have written IT security policies. • 50% have no plans to implement security awareness training. • 63% have no plans to hire IT security personnel in the next year. • 27% of firms polled require IT security training and only 12% require any form of certification. http://www.comptia.org/about/pressroom/get_pr.aspx?prid=611

7. Availability System Outages 20% Operator Error 60% 5% Security Related 15% Non-Security Related Application Failure 20% Data Source: IDC, 2004. Graphic Source: Tripwire

8. Change Management and Mean Time to Repair (MTTR) • MTTR is the average time it takes to recover a service to a level acceptable in the service level agreement. • If we don’t know what changed, the first part of dealing with an incident is trying to figure that out!!!! • Groups with poor change management spend an inordinate amount (as high as 80%) of the MTTR simply trying to figure out what changed. • Phone calls, emails, running down the hall, etc. • MTTR is impacted negatively by poor change management.

9. Changes • Is IT paid to make changes or successful changes? • 80% of the fires IT fights are generated by IT! • Even if that number is high, a very large percentage of unplanned work (45% in one client’s case) is caused by failed changes. • Change management isn’t about inspection – it’s about having appropriate controls and processes. • “Inspection with the aim of finding the bad ones and throwing them out is too late, ineffective, costly. Quality comes not from inspection but from improvement of the process.” – W. Edwards Deming • Change management is a control gate but it also generates data that can, and must, be used to improve processes.

10. Resources • Who here • Has budget limitations? • Has more work than what his/her IT organization can handle? • Who has spare head count sitting idle? • If we can reduce unplanned work • Operating expenses are decreased • Headcount is freed up from performing unproductive work • Planned projects can be addressed instead

11. The Delusion of Speed • Getting things done quickly is vastly different than getting the right things done quickly. • Beware the delusion of speed – you may be moving quickly, but is it in the right direction? • AT Kearney tells us that 70% of business executives believe that technology innovation is critical yet 80% of the actual investment is spent on infrastructure and core operations. 45% of business executives strongly agreed that IT was too focused on day-to-day IT requirements.This tells us that IT is losing traction due to problems. • This is the curse of firefighting – investing too many resources in unplanned work.

12. Effective change management can help

13. Three very inter-connected ITIL processes • Change Management Is the set of standardized processes and tools used to handle change requests in order to support the business while managing risks. (Risk Management) • Release ManagementUses formal controls and processes to safeguard the production environment. Coordinates the rollout of changes. (Quality Control) • Configuration ManagementFocuses on tracking and documenting configurations and then providing this information to other areas including Change and Release Management. Configuration tracks relationships to understand who is affected and assess impact.

14. A Basic Change Management Process • Identify a potential change • Create Request For Change (RFC) • Change Manager • Filters requests • Determines urgency • Determines if it is a standard change • Identifies the category based on business impact • Minor Impact (Change manager authorizes, schedules & notifies CAB) • Significant Impact (Change manager sends RFC copy to CAB) • Major Impact (Decided at a senior management or Board level) • CAB advises the change manager who chairs the CAB • The Change Manager authorizes or rejects the change • The change is built • Release management engages to oversee testing, rollout planning, etc. • Configuration management tracks what is where and relationships.

15. Who should sit on the CAB? • Change Manager (ITIL role) • Problem Manager (ITIL role) • Service Level Manager (ITIL role) • Affected customers and users • Development staff • Consultants / Vendors / Outsourcers • Services Staff • Service Desk • IT Security • IT Audit • Note: • The CAB will be composed based on the changes to be considered • Attendees can vary, even during a given meeting • The CAB is a decision making body, not a forum for communications. Ask “Does the potential attendee add a needed perspective?” • Use the Forward Schedule of Change (FSC) to communicate

16. Change Management & Other Processes (1) • Incident Management • Changes to address incidents must route through Change Management • Incidents associated with changes • Problem Management • Changes arising from the generation of workarounds from known errors as well as final solutions are processed through Change Management. • The Problem Manager sits on the CAB. • Post Implementation Review • Problems associated with changes • Availability Management • Projected Service Availability (really negotiated unavailability) for confirmation • Forward Schedule of Change (FSC) • Reports on implemented changes and their potential impact to availability

17. Change Management & Other Processes (2) • IT Service Continuity Management • Proposed changes for ITSCM review • Notification of implemented ITSCM related changes • Capacity Management • RFCs from Capacity Management • Review of proposed changes for capacity impact • Review of backed out changes • Financial Management • Financial assessment of proposed RFCs • Financial review of implemented RFCs • Security Management • RFCs from Security Management • Assessment of proposed RFCs

18. Change management is all about risk management It’s up to you as to whether the process is bureaucratic or not

19. Don’t try to eliminate risk! 100% You can spend a fortune and you will never truly hit a 100% level of assurance. The objective is to lower risk to an acceptable level, not eliminate it because you can’t! Level of Assurance Level of Investment

20. Change Management Process • You either follow it or you change it – there is no other option. • Design a process that is sustainable. • The process must temper the need to support the business with the need to manage risks. • The exact process needs to take the organization’s unique mix of resources, business needs and risks into account. • For example, the process for a small company may look very different than that of a firm in a highly regulated industry.

21. Tip: Implement a Detective Control • To enforce the policy and drive cultural change, implement a detective control. • At the outset, the rate of changes going through the process is often far smaller than the actual rate of changes going around the process. • Integrity management systems specialize in monitoring key areas of systems for changes and reporting what is found. • Compare current production builds to last known good builds • Report on changes detected outside of approved maintenance windows • Prove that detected changes tie out to only approved changes

22. Emergency Changes • Emergency changes still follow a process • Change manager convenes the CAB or CAB/EC • They then quickly review resources, impact and urgency to make a go/no-go decision. • The change manager can authorize without the CAB or CAB/EC • Emergency changes have higher risk as they follow an abbreviated process • Follow a defined escalation list • Follow a defined check list • Test in greater detail afterwards • Review in the next CAB meeting

23. We need to stop the fires • W. Edwards Deming attributed this to Juran: • “You are in a hotel. You hear someone yell fire. He runs for the fire extinguisher and pulls the alarm to call the fire department. We all get out. Extinguishing the fire does not improve the hotel. That is not improvement of quality. That is putting out fires.” • "People work in the system. Management creates the system." • So, how does firefighting in IT improve anything? We must stop the errors before they go into production.

24. Process References • ITIL’s Service Support volume is the standardhttp://www.ogc.gov.uk/index.asp?id=2261 • Microsoft’s Operations Frameworkhttp://www.microsoft.com/technet/itsolutions/cits/mo/smf • British Educational Communications and Technology Agency (BECTA)http://www.becta.org.uk/tsas • IT Process Institute’s Visible Ops Methodologyhttp://www.itpi.org

25. Thank you! George Spafford george@spaffordconsulting.com http://www.spaffordconsulting.com Daily News Archive http://www.spaffordconsulting.com/dailynews.html

26. Questions?

27. If you have any further questions, e-mail webcasts@jupitermedia.com Thank you for attending