itsmf Service Transition SIG Scenarios to Initiate Discussion Richard Horton (Transition SIG Chair) Scenarios written by Richard Horton and Vawns Guest based on input from, and reviewed by the Service Transition SIG Working Group Introduction When we want to explore the nitty gritty of ITIL processes with groups we face challenges How do we bring ITIL to life? The ITIL books describe how processes work but what happens when we apply them in real life? What behaviours do we encounter and does the way we behave get the sort of result we are looking for? The Service Transition scenarios provided below offer a selection of radio plays where 2 or 3 characters play out scenes, picking out various challenges that we encounter in the world of Service Transition. Each of them lasts about 2 minutes to play out. The Service Transition SIG have used these as a launch-pad for discussion, inviting people to address such questions as How true to life did you think that was? What did the Transition person do well in the situation? What pressures did you think were most acute? What would you do differently? What one thing can you learn from this scenario and our discussion of it? How could the Transition person in the scenario respond to the Attitude-Behaviour- Culture challenges that lead to these scenarios. The scenarios that have been used are given here, for use, along with some comments that may be a help in approaching them. 2013 itsmf - 1 -
Contents 1. Scenario : removal of configuration budget :... 3 IT manager (chair), finance manager, service manager... 3 2. Scenario : Inadequate signoff... 5 Infrastructure Manager, Change Manager... 5 3. Scenario : Perils of supplier management/joint venture... 6 Project Manager, External Project Manager... 6 4. Scenario : Lack of shared view of process :... 8 Service Manager, Infrastructure Manager, Change Manager... 8 5. Scenario : Last minute changes... 9 Change Manager, Project Manager... 9 6. Scenario : Impact assessment missing... 10 Project Manager, Change Manager... 10 7. Scenario : Late engagement/check list... 11 Project Manager, Change Manager... 11 8. Scenario : non-attendance at CAB... 13 Service Manager, Change Manager... 13 9. Scenario : Tools reduce risk... 15 Change Manager, Infrastructure Manager,... 15 10. Lack of Change Evaluation... 16 Director, Change Manager... 16 11. Challenging lack of change evaluation... 18 Project manager, Change manager... 18 12. Using change evaluation in response to failed change... 20 Director, Change Manager... 20 2013 itsmf - 2 -
1. Scenario : removal of configuration budget : In this scenario we are looking at how attempts to manage configuration can end up being de-prioritised, and what the results of that can be. This isn t the same as saying that it should go to the top of the priority pile, and you still need to work out what level of configuration management is required. However change, release and configuration have been closely linked since ITIL V2 for good reason. What s the quality of your change management if you don t understand your configuration? IT manager (chair), finance manager, service manager IT Manager : so here we are again. Time to set our budget for the coming year. We re all here apart from Service Manager. Anyone know where (s)he is? Finance Manager : apparently he s dealing with something that s cropped up and will join us when (s)he can IT Manager : I did say this was an important meeting and I needed everyone here. Still, we ll start without her/him. Finance Manager Name, you re our Finance Manager, I think we all know the score, but just to make sure just tell us what we need to do Finance Manager : we need to knock 20% off what we budgeted last year. IT Manager : It s going to be tight. Let s start by looking for things we can easily cull. Finance Manager :Service Manager Name has got an item in for configuration management. I think he had that in last year as well. We removed it then and don t seem to have suffered as far as I can see. What s to stop us doing the same again? What does it give us? IT Manager : I think (s)he s put it in to help with audit. We didn t fare too well last time the auditors came round. Finance Manager : Why can t we just wait for the auditors to highlight things and respond. IT Manager : I d rather be more proactive than that, but we have to cut costs somewhere, and I agree that s the obvious place to start. OK, everyone agreed, so that s one down. Let s move on. <Enter Service Manager, out of breath> Service Manager: Apologies for being late, we ve had an outage that took half our critical services down and I was just dealing with it. 2013 itsmf - 3 -
IT Manager : That explains it we wondered where you had got to. Anyway, we started without you. I m afraid we ve just removed your configuration item from the budget we need to get Project Grandiose in and need to make cuts somewhere. Service Manager: Hang on a minute before you do that, do you realise that the reason why we had the outage this morning was precisely because we don t have configuration management. A change to the infrastructure as preparation for Project Grandiose went fine in itself but no one realised it has a direct impact on the overnight schedule. We haven t sent any invoices out and the load of data into the data warehouse hadn t completed at the start of the day. The phones haven t stopped ringing. Project Grandiose is only going to make the position more complex. This isn t just about audit. We don t have enough knowledge about what we have to be able to make changes safely. If we are going to build time critical services and depend on them as a business, then we need this. Can we go back discuss this again, please? 2013 itsmf - 4 -
2. Scenario : Inadequate signoff Generating standard questions that people need to answer is fine, but if it s just treated as a box ticking exercise and the real meaning of those questions isn t understood then you end up with Garbage-In-Garbage-Out. Equally, if someone who is trying to get the right answer is given the OK, and then its overridden at the point of implementation, that s potentially crippling for projects. In giving authorisation you are taking responsibility for what you are authorising. Infrastructure Manager, Change Manager Infrastructure Manager: Change Manager Name, I need to have a word with you. What s this I hear about Project Grandiose going live this weekend? Change Manager: That s right. It went through CAB this week and everyone was happy with it. Infrastructure Manager: Maybe they were, but I m not. Change Manager: You were on holiday and James represented your team, he was happy. Infrastructure Manager: Someone within the project team told James at CAB that our bit of this will communicate with the suppliers bit, and James approved it on that basis. Unfortunately this isn t James main area so he didn t realise the full implications of this. Change Manager: I thought all the questions had been covered here - what wasn t covered? Infrastructure Manager: The right questions were asked but the wrong answer was given. Before getting to CAB, someone has signed off the design without knowing what they were talking about. Then they have misled CAB through how they have presented it. They should have involved us earlier. I would have spotted this immediately. 2013 itsmf - 5 -
3. Scenario : Perils of supplier management/joint venture When different organisations have different working cultures then that can make working together difficult. Assumptions can be made and then exposed at the point of implementation. Or you may just end up with a poor working relationship with the other party persisting in not behaving how you expect. Project Manager, External Project Manager Project Manager: Hello External Project Manager Name. Now that our organisations have agreed to work together as partners in this joint venture, we d better work out what that s going to mean for us. We ve got this joint project to work on and a pretty loose brief as to how we make it happen. From my perspective, it makes sense to start by talking about what processes we ll use. Here in ITIL-Land we use a formal Service Design Package for every new service. Service Management provide a Service Acceptance pack which people have to follow through in evaluating the impact of their change. It s all pretty rigorous, but we find it makes life easier in the long run. What do you do? External Project Manager: We re a bit more informal about things, Project Manager Name. We ll have a project charter, but we leave it up to individual project managers to liaise with service management when they need to, and work out on a case by case basis what level of interaction is required. Project Manager: Does that work for you? External Project Manager: Generally yes. I mean we have the usual exceptions where people come to implement something that has missed something obvious, but everyone gets that. Project Manager: I m not sure that I m comfortable with such an approach. This is really important for our companies as we start working together and we can t afford to have something slip between the cracks. External Project Manager: Don t worry about that, I ll make sure my team keep on the ball. Project Manager: I m not doubting that you ll do that, but when we have a process which we mandate internally and has given us good results I ll be given a hard time if I try to justify bypassing those controls for a key project. 2013 itsmf - 6 -
External Project Manager: No need to worry there. We just compartmentalise it and I ll look after my side by our controls and you can use your process straightjacket on your stuff. Project Manager: Hmm I can see where you are coming from but I have the feeling that this might come unstuck. After all this is about working together there will be interfaces and shared practices and technology to consider. 2013 itsmf - 7 -
4. Scenario : Lack of shared view of process : Incident is a standard ITIL concept but for many people whether something is an Incident, Problem or Change doesn t matter to them they just want something done. What are the implications of this? Service Manager, Infrastructure Manager, Change Manager Service Manager: Morning all, welcome to today s call. I see we have an issue with system Kraken? Does anyone know what s going on with this? Infrastructure Manager: Hi Service Manager Name, yes, we had a fault last night with Medusa so one of the guys fixed it as it was an emergency. Unfortunately, while fixing Medusa, he accidentally rebooted Kraken by mistake which is why we re having problems this morning. Change Manager: Why weren t we made aware of the Change? Infrastructure Manager: We didn t want to bother you as it was the middle of the night. The local manager authorised it verbally and it was all done under the fault ticket? Change Manager: You mean the Incident? Infrastructure Manager: They re all the same though aren t they? Incidents, Changes, they re all just tickets to us. Change Manager: No, they re not! If you need to make an emergency change in response to an incident I need to know. If you had done that we could have sent out comms to all our customers first thing this morning. As it is, we ll be lucky if we don t have an angry mob waiting for us outside later! 2013 itsmf - 8 -
5. Scenario : Last minute changes In the high octane context of the final push for project implementation it is easy to lose sight of some fundamentals. We test for a reason. If we introduce change after testing we introduce risk. On the other hand what is the risk-opportunity equation? If the potential gains are high enough, proceeding may be the right thing to do. Change Manager, Project Manager Project Manager: Hi Change Manager Name, just wanted to let you know that the business have requested a small code change to Project Thin Ice before it goes live tomorrow morning. We won t be able to test it properly but the Business are saying it s critical and the Dev team are well up for it. Change Manager: Hang on a second, why am I only being told about this now? Project Manager: The big boss read an article about social networking so wants the Thin Ice application to be able to talk to Twitter. The business have said that they pay our wages so they have the right to change their minds on requirements at the last minute. Change Manager: What did the test team say? Project Manager: Erm, well, they re not happy, as you d expect, but the business are jumping up and down and the Dev team are saying it will be fine so no need to worry. Change Manager: If you think I m going to sign off on an untested code change to a critical system hours before go live, you ve another think coming. I m sorry, but the time for code changes is past, we either implement as is or you tell the business we need more time. 2013 itsmf - 9 -
6. Scenario : Impact assessment missing Forms can be excessive, but, if we design them well, then there is a reason why we are asking for the information they ask for. How we understand the relationships between services and components is a specific question, but the more general question here is how information is gathered to work out what the impact of a change will be. Project Manager, Change Manager Project Manager: Hi Change Manager Name, I ve just sent you through one of the RFCs for Project BodgitandLegit, can you have a look at it and let me know what you think? CM: Lets have a look <clickety click>. It s a bit light on detail, why is the Impact section blank? Project Manager: Well, we re only taking down 1 server and it s only for a couple of minutes so the users won t notice. CM: Let s have a look at the server You do realise that the server you re planning to take down hosts the pay roll system? And you re planning to do this in office hours the day before pay day? Project Manager: I d better look at the rest of my Changes. Sorry Change Manager Name, let me get back to you later. 2013 itsmf - 10 -
7. Scenario : Late engagement/check list It s easy to criticise the project manager in this scenario for not having satisfied the checks. However has the change manager engaged early enough? If you have gone to the trouble of working out what criteria need to be satisfied to achieve service acceptance, then project managers need to know about this at the start of their projects rather than the end. If all checks aren t completely satisfied what do we do? Depending on the nature of the business and nature of the change it may be that the issue encountered would lead to a delayed implementation. But the business context might mean that it s more appropriate to proceed, accepting the higher level of risk. Project Manager, Change Manager Project Manager: Hi Change Manager Name, Project Thin Ice is ready to launch. I have the RFC and the supporting documentation you asked for. Change Manager: Let s have a look. How did you get on with incorporating Service Acceptance Criteria that I gave you the other day into your project plans? Project Manager: Well to be honest, at first I thought it would be another layer of red tape, but having used it, I m really happy with it. It s provided a structure that means we won t forget anything and the templates have made things quicker. I really wish I d had this earlier, though. Change Manager: How do you mean? Project Manager: Well the acceptance criteria have set out what checks we should be doing at each stage of the project. We ve missed a hardware compatibility issue and now only have a week to fix it. The business is furious that the whole project may be at risk and I ll get it in the neck if we don t deliver it on time. Change Manager: That s not good. Are you going to be able to get it sorted? Project Manager: I don t know. We ll try, but I can t see us being able to complete all our UAT checks. If we can get this Change Manager: We ll need to get clarification about the reduced level of testing coverage and whether the business would be prepared to accept this. Given the potential benefits it sounds as though they might. We need to be clear about what risk we would be introducing. 2013 itsmf - 11 -
I can t say I m comfortable with this, but keep working with the criteria and that will give the best chance of being ready. 2013 itsmf - 12 -
8. Scenario : non-attendance at CAB If our CAB is not as effective as we would like then why is that? People are busy and don t want to waste time, but if representation at CAB doesn t go across areas then its value is diminished. Organisations are exploring ways of streamlining this e.g. by maximising the preparation work done before the meeting, or by giving change raisers more authority for authorising themselves and holding them accountable for the results. Standard changes are an obvious starting point. Service Manager, Change Manager Service Manager: I thought at today s team meeting we d take a look at change management. Change Manager Name, you ve been responsible for this for 6 months now. How well do you think this is functioning? Change Manager: we have established change management and we have CAB set up and generally accepted, but we do find that when we come to meetings we don t have the people we need there. Service Manager: How come isn t it mandatory to go through CAB for changes? Change Manager: It is but it feels like some people are treating it as a box ticking exercise rather than something that adds value. People who might provide the wider perspective that we need don t come. Service Manager: Maybe CAB isn t pitched at the right level. Change Manager: How do you mean? Service Manager: If you are going through lots of trivial changes in the meeting then people perceive it as a waste of their time. Change Manager: True and we do get that sort of feedback, but when we try to get people to use change models to set up standard changes they are suddenly too busy or not interested in putting in the work to define what doesn t need to come to CAB. Service Manager: Well, they are their own worst enemies then. But it s having a wider impact. Maybe we need to help them get started, and then they will be able to do work with less red tape and not needing to gain approvals each time and still be adhering to process. 2013 itsmf - 13 -
2013 itsmf - 14 -
9. Scenario : Tools reduce risk There have been some very high profile and expensive outages caused by low-level staff doing things slightly wrong. If complex processes rely on this then risk is increased. What can we automate? Where we can t automate, are our instructions clear, is there appropriate cover, and have we put work into analysing what could go wrong and implemented appropriate mitigation? Change Manager, Infrastructure Manager, Change Manager: Infrastructure Manager Name, I need to talk to you urgently. I heard that John made a Change to the firewall last night that went wrong and now nothing is working. The IT Director is furious and wants answers. What s going on? Infrastructure Manager: I ve had a chat with John. He followed the work instructions but apparently there was a prompt that he hadn t seen before and wasn t documented. Normally, he would have had one of the other engineers there as back up, but Bob was sick last night. He didn t know what to do, panicked, and tried to carry on, but this caused the system to crash with no way of backing out the Change. Change Manager: Why on earth wasn t this documented properly? And why was he carrying out manual tasks on our firewall? Infrastructure Manager: We did want to automate everything, but you know our IT Director : he wants his pet projects done yesterday and has no patience for anything else. Change Manager: Maybe now is the time to do something about this, we can t have this happening again -we all look like fools. 2013 itsmf - 15 -
10. Lack of Change Evaluation This is the first of 3 linked scenarios which seek to highlight how use of change evaluation can help you even if things do end up going wrong. Director blasts change manager for a change which wrecked the business failure to evaluate exposes both the business and you. Director, Change Manager Director: Ah Change Manager Name, come in you ve got some explaining to do, and it had better be good. As you know for the last day none of our staff have been able to do anything, all our services are unavailable, and the national press have been having a field day. We ve spent all year trying to differentiate ourselves through quality of service and now this mess hits us. I gather this happened because of some sort of change you made. What on earth were you playing at? Change Manager: Er, The Project Titanic wanted to launch. When we implemented the software and tried it out everything crashed. Director: What do you mean everything crashed Change Manager: There is a key interface, interface Iceberg, that everything goes through. Once we d upgraded that we found nothing could go through Iceberg. We thought we knew what the problem was so we kept going trying to fix it. By the time we decided that we weren t going to get it to work we couldn t get back to where we started. That s when we realised we were sunk. Director: Hang on a minute: why were you doing this when we are in the thick of month end? Hadn t you tested doing this beforehand? Anyway, I thought you took backups before doing changes? Change Manager: We do normally. We were told it would take too long, that the change couldn t go wrong anyway, and that Titanic needed to be implemented urgently Director: Why? Change Manager: I think it was to hit the project deadline Director: That s outrageous. How am I supposed to run this business so it makes money if you lot do things like this to me? I m the project sponsor and Project Titanic didn t have a deadline for this month. Anyway, even if it did it s not worth causing the havoc you have caused. Can you guarantee me next time you introduce anything like this it will be 100% successful and have no impact on the business services that I m already providing and this company depends on? 2013 itsmf - 16 -
Change Manager: Er, no Director: Well, I ll tell you what. How about you take my place the next time a major customer rings to complain about the effect this is having on them. See how you like that! On second thoughts no I want to keep these customers. 2013 itsmf - 17 -
11. Challenging lack of change evaluation This is the second of 3 linked scenarios which seek to highlight how use of change evaluation can help you even if things do end up going wrong. Change manager fends off project manager who is steam-rolling project into production change evaluation brings accountability to implementation decisions Project manager, Change manager Project Manager: Hello, Change Manager Name. Just thought I d let you know we re launching Project Titanic tomorrow Change Manager: What? Project Manager: Yes, it s really important that it goes out then. All the communications have gone out and everyone is expecting it. Change Manager: That s all very well, Project Manager Name, but you ve not been though our standard processes here Project Manager: I know. Sorry about that we ve had huge pressure to get everything delivered with all the extra features that were added at the last minute, and the problems that we had in testing. Anyway we ve got everything sorted now and we re ready to go. I ve done an RFC for you. It s a bit light on detail, but I m afraid it s the best I can manage in the time available. Change Manager: Thanks for doing the RFC. However I need a bit more than that. Titanic is a significant project. We can t just launch it without going through a few safety checks. Project Manager: Don t worry, Change Manager Name. We ve checked everything. The plan is on the RFC have a look. Change Manager: We talked about this a few months back, and said that you would have to do a Change Evaluation for this project. Can I have a look at that please Project Manager: Sorry, that one slipped off the radar. We ll have to go live without it. Change Manager: I m not so sure about that. How about picking up a couple of key points now and we can then consider how we proceed. Have you tested the implementation in pre-production? Project Manager: Sort of. We did a first attempt, but it wasn t entirely successful. There have been all sorts of changes since then, and we ve run out of time to do a full test. When we looked at it in detail we realised it would be far too long and expensive to do the sort of exhaustive tests on interface Iceberg that were originally planned. We re confident it will be OK, though as the design is so strong. 2013 itsmf - 18 -
Change Manager: Who is the business sponsor for Project Titanic? Project Manager: Director Name Change Manager: Have they OK d this change of approach? Project Manager: They really want it as soon as possible, and they wouldn t understand this level of detail. We re happy with it. Change Manager: Name may not understand the detail but ultimately it s his name, and mine, that are in the firing line if this goes wrong, so we need to understand what risk we are choosing to accept. We ll come back to that. What about the timescale. Why the urgency? Project Manager: Well, it s when we said we d do it, they are expecting it, and all our communications have gone out. Change Manager: But that s not quite the same as saying they need it now. I realise there would be a comms issue. What brown stuff hits the fan if it gets delayed a week? Project Manager: I don t know Change Manager: So you are saying that you haven t been through our evaluation, you haven t done the things that are supposed to ensure that your change has the maximum chance of being successful, and that the pressure to implement is basically because that s when you have told people you will do it. Do you want to go straight to D Name with this or shall we sit down and do a bit of replanning first? 2013 itsmf - 19 -
12. Using change evaluation in response to failed change This is the third of 3 linked scenarios which seek to highlight how use of change evaluation can help you even if things do end up going wrong. Change manager helps director construct a response to business disaster change evaluation enables you to become part of the solution not just the problem, and makes clear where accountability lies. Director, Change Manager Director: Ah Change Manager Name, come in you ve got some explaining to do, and it had better be good. As you know for the last day none of our staff have been able to do anything, all our services are unavailable, and the national press have been having a field day. We ve spent all year trying to differentiate ourselves through quality of service and now this mess hits us. I gather this happened because of Project Titanic. You did that evaluation before it went live. I thought you said it was a thorough check on its safety. What went wrong? Change Manager: Yes, I m really sorry about this. When we did the evaluation we tried to cover all the risks we felt were relevant. This one caught us out I m afraid. We knew that there was a key dependency with interface Iceberg, and we had designed how to cater for that. However we decided, if you remember, that it would be too expensive and difficult to do a trial run of all the possible scenarios there. I m afraid that our solution proved to be less robust than we had thought. I know that doesn t make it less of a disaster for us as a company, but we had considered the risk, and you had signed off our approach to it as being acceptable. Director: Yes, I did didn t I. Could we have done better? Change Manager: I think what this shows is that interface Iceberg is a difficult area to be safe in. I know it was a flagship feature in the Titanic design, but the proposal that I ll be making is that we should try to find ways to ensure that we don t go through it in future rather than continuing with it as an integral part of the system. Director: Well, it s already proved hugely damaging to us. Can you get that proposal knocked up quickly. I need to get something out that shows that we can learn from our mistake and build confidence that we can do better in the future. Change Manager: It s already in progress. I ll ensure it gets top priority. Director: Thanks, Change Manager Name. Can you get it to me by the end of the day? Change Manager: I ll do that, Director Name. 2013 itsmf - 20 -