Change management is volgens ITIL een nuttig proces. Maar ook een stroperig proces. En star. Hoe maak je dit proces meer agile? In dit blog ga ik in op het eerste deel van het change management proces: hoe ga je slimmer om met change requests?
Agile voor standard of non-standard changes?
Allereerst: voor standard changes heeft een agile werkwijze iets minder toegevoegde waarde dan voor non-standard changes. Het idee is dat het je helpt omgaan met werk dat onvoorspelbaar is, en standard changes zijn juist ontworpen met volledige voorspelbaarheid in het oog.
Neem een aanvraag voor een laptop die je ondersteunt: je neemt een laptop uit de voorraad, installeert het voorgeschreven besturingssysteem en een vaste set applicaties, en je levert hem uit. Geen verrassingen daar.
Het proces voor non-standard changes, daar valt nog een wereld te winnen. Daarom focus ik in deze blogpost op de non-standard changes binnen change management. Is dit concept nog wat nieuw voor jou? Lees dan de 5 meest gestelde vragen over agile service management.
Wat is het probleem van ITIL Change Management?
Change management is bedacht voor het gecontroleerd doorvoeren van wijzigingen in je IT-infrastructuur. Zo voorkom je bijvoorbeeld dat het hele netwerk eruit vliegt als je een server vervangt. Daarom zitten er allerlei checks en controlemechanismen in het proces ingebouwd. Lees de 5 niet te missen items voor op je change management checklist.
Nuttig natuurlijk, die controles. Maar het proces voor non-standard changes is daardoor wel enorm uitgebreid geworden. Dat heeft ook nadelen waar veel organisaties tegenaan lopen:
• Een Request for Change (RfC) indienen is veel werk. Technische oplossing uitdenken, impact analyseren, risico inschatten, kosten ramen – moet allemaal gebeuren. Terwijl je niet eens zeker weet of de change ooit uitgevoerd wordt. En of je gegevens nog kloppen wanneer de change eindelijk wordt geïmplementeerd.
• Het Change Advisory Board (CAB) is veel tijd kwijt aan RfC’s beoordelen. In sommige organisaties wordt elke RfC, groot of klein, urgent of niet, besproken door het hele CAB. Soms discussiëren er wel 6 tot 8 CAB-leden over een relatief eenvoudige aanvraag.
• Het change-proces is eenrichtingsverkeer. Voordat je een Request for Change indient, moest moet alles afgekaderd zijn. Na goedkeuring is je enige optie uitvoeren wat je bedacht hebt. Voortschrijdend inzicht? Tussentijds van koers veranderen is nauwelijks een optie.
• Het change-proces duurt langer dan nodig. Al die controlemechanismen zijn allemaal vertragingen in het proces. Soms heb je alles voorbereid om een change door te voeren, maar denk je ‘O ja, dit moeten we nog laten goedkeuren door het CAB, maar die vergaderen pas volgende week woensdag’.
RfC – maar dan zonder overbodige administratie
Ik zeg niet dat al die processen en controles geen zin hebben. Integendeel: ik raad organisaties vaak juist aan om met RfC-formulieren te werken. Een vorm van impactanalyse is altijd verstandig om te voorkomen dat er van alles misgaat bij de implementatie.
Maar moet je elke keer dat hele RfC-formulier invullen? Ik vind van niet. Je moet een balans vinden tussen de belangrijkste risico’s afdekken en de IT-afdeling vertrouwen geven de juiste keuzes te maken in hun werk. Een agile benadering van change management helpt daarbij.
Wil je meer agile omgaan met al je Requests for Change? Dan verandert vooral de rol van de change manager en het CAB.
Zo maak je jouw change management proces eenvoudiger >>
De Change Manager: Product Owner van het Change Backlog
Traditioneel is de change manager vooral een procesmanager. Bij een agile werkwijze wordt de change manager een meer inhoudelijke en sociale rol. Dit zijn de taken van een agile change manager:
• Je inventariseert en prioriteert alle wensen van je stakeholders. Die RfC’s plaats je als change requests op een change backlog. Een backlog is weinig anders dan een geprioriteerde lijst werk. Om goed te kunnen prioriteren, moet je een goed beeld hebben van wat er in de organisatie leeft. Je verdiept je inhoudelijk in de verschillende RfC’s en weegt belangen en problemen tegen elkaar af. Die prioritering herzie je regelmatig, bijvoorbeeld eens per 2 weken.
• Je zorgt dat alle RfC’s duidelijk genoeg omschreven zijn. Voor elke RfC een compleet formulier invullen is niet nodig. Zorg dat je genoeg informatie hebt om de RfC te kunnen prioriteren. Denk aan: welk probleem moet de RfC oplossen? Wat zijn mogelijke oplossingsrichtingen? Wat is de geschatte scope? Wat je nog niet hoeft vast te leggen is, zijn zaken als een gedetailleerde oplossing, implementatieplan en budget.
• Je zorgt dat de top-5 RfC’s uitgebreid is omschreven. Hanteer voor RfC’s de richtlijn: hoe lager iets op het backlog staat, hoe minder gedetailleerd de aanvraag hoeft te zijn. Alleen voor de RfC’s waar je binnenkort mee aan de slag gaat, maak je een uitgebreide omschrijving van de aanvraag. En alleen die RfC’s leg je voor aan het CAB.
Het CAB: minder inhoudelijk, meer strategisch
Als de change manager meer tijd gaat besteden aan het inventariseren en prioriteren van change request, rijst de vraag: wat doet het CAB dan nog? Zij blijven een belangrijke rol spelen in het proces, alleen zal die rol strategischer zijn. Dit worden de taken van het CAB:
• De belangrijkste RfC’s beoordelen. Deze taak blijft inhoudelijk hetzelfde: het CAB beoordeelt of de aanvragen compleet zijn, en kan sommige RfC’s afwijzen. Het verschil is dat het CAB alleen de hoogst geprioriteerde RfC’s onder ogen krijgt, wat een hoop tijd scheelt.
• De prioritering van de backlog accorderen. De change manager heeft de RfC’s al geprioriteerd – aan het CAB om te controleren of ze het eens zijn met die prioritering. Als hij zijn werk goed voorbereid heeft, zal het CAB weinig aanpassingen willen doorvoeren.
• Go of no-go geven op beslismomenten. Bij klassieke implementaties geeft het CAB voor de livegang, bijvoorbeeld tijdens de testfase, een go of no-go. Bij een agile werkwijze wordt een nieuwe dienst in stukjes uitgeleverd en heb je lang niet altijd meer een ‘big bang’. Wanneer moet het CAB dan zijn fiat geven? Dat zal per implementatie anders zijn. Het IT-team en het CAB spreken daarom onderling af op welke momenten het CAB bij de implementatie wordt betrokken.
Changes uitvoeren op een agile manier
Een change request is goedgekeurd en staat als hoogste geprioriteerd. Klaar om te gaan. Hoe voer je een change op een agile manier door? Daarover meer in mijn blog change management op een agile manier implementeren.
Meer lezen?
Download het gratis e-book en lees wat je nodig hebt om jouw IT-afdeling wendbaarder te maken.
