Agile maken van het change management proces

Change management is volgens ITIL een waardevol, maar vaak stroperig en star proces. Hoe maak je dit proces wendbaarder? In dit blog wordt ingezoomd op het eerste deel van het change managementproces: hoe ga je slimmer om met change requests?

Agile voor standard of non-standard changes?

Allereerst: voor standaard changes biedt een agile werkwijze minder toegevoegde waarde dan voor niet-standaard changes. Het idee achter agile is dat het helpt bij het omgaan met onvoorspelbaar werk, terwijl standaard changes juist volledig voorspelbaar zijn ontworpen.

Denk bijvoorbeeld aan een aanvraag voor een laptop: er wordt een laptop uit de voorraad genomen, het voorgeschreven besturingssysteem en een vaste set applicaties worden geïnstalleerd, waarna de laptop wordt uitgeleverd. Hier zijn geen verrassingen.

Het probleem van ITIL Change Management

hange management is ontwikkeld om wijzigingen in de IT-infrastructuur gecontroleerd door te voeren. Zo wordt voorkomen dat bijvoorbeeld het hele netwerk uitvalt bij het vervangen van een server. Daarom zijn er diverse checks en controlemechanismen in het proces ingebouwd.Lees de 5 niet te missen items voor op je change management checklist.

Natuurlijk zijn die controles nuttig, maar daardoor is het proces voor non-standard changes flink uitgebreid. Dit brengt ook nadelen met zich mee waar veel organisaties tegenaan lopen:

• Een Request for Change (RfC) indienen kost veel tijd.

De technische oplossing uitdenken, de impact analyseren, risico’s inschatten en kosten ramen — het moet allemaal gebeuren. Terwijl je niet eens zeker weet of de change daadwerkelijk wordt uitgevoerd, of de gegevens nog kloppen als de change eindelijk wordt geïmplementeerd.

• Het Change Advisory Board (CAB) besteedt veel tijd aan het beoordelen van RfC’s.

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 een Request for Change wordt ingediend, moet alles tot in detail zijn uitgewerkt. Na goedkeuring is de enige optie om precies uit te voeren wat is bedacht. Voortschrijdend inzicht of tussentijds van koers veranderen is nauwelijks mogelijk.

• Het change-proces duurt langer dan nodig.

Al die controlemechanismen zorgen voor vertragingen. Soms is alles klaar om een change door te voeren, maar moet je wachten op goedkeuring van het CAB, en dat vergadert pas volgende week woensdag.

RfC – maar dan zonder overbodige administratie

Er wordt niet gezegd dat alle processen en controles overbodig zijn. Integendeel: het gebruik van RfC-formulieren wordt juist vaak aanbevolen. Een vorm van impactanalyse is essentieel om te voorkomen dat er tijdens de implementatie problemen ontstaan.

Maar is het nodig om telkens het volledige RfC-formulier in te vullen? Dat niet. Het draait om een balans tussen het afdekken van de belangrijkste risico’s en het vertrouwen geven aan de IT-afdeling om de juiste keuzes te maken. Een agile aanpak van change management ondersteunt dit.

Wie meer agile wil omgaan met Requests for Change, ziet vooral veranderingen in 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 krijgt 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.

RfC’s plaats je als change requests op een change backlog. Een backlog is eigenlijk niets meer dan een geprioriteerde takenlijst. Om goed te kunnen prioriteren, is het belangrijk een duidelijk beeld te hebben van wat er binnen de organisatie speelt. Je verdiept je inhoudelijk in de verschillende RfC’s en weegt belangen en problemen tegen elkaar af. Deze prioritering wordt regelmatig herzien, bijvoorbeeld eens per twee weken.

• Je zorgt dat alle RfC’s duidelijk genoeg omschreven zijn.

Het is niet nodig om voor elke RfC een compleet formulier in te vullen. Zorg ervoor dat je voldoende informatie hebt om de RfC te kunnen prioriteren. Denk aan vragen als: welk probleem moet de RfC oplossen? Wat zijn mogelijke oplossingsrichtingen? Wat is de geschatte scope? Zaken zoals een gedetailleerde oplossing, een implementatieplan en budget hoeven op dit moment nog niet vastgelegd te worden.

• 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 het volgende 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.