Business Value voor IT-projecten
Bij EIC zijn we gewend te werken aan complexe projecten. Het organisatiebreed uitrollen van nieuwe software of een nieuw concept om de werkplek in te richten; het zijn operaties die invloed hebben op de werkwijze van de hele organisatie. We zien echter nog vaak dat deze projecten er niet geheel of slechts gedeeltelijk in slagen om het succes te bewerkstelligen dat men ermee voor ogen had. De ervaring leert dat dit vaak te maken heeft met een tekort aan aandacht voor de veranderkundige kant van de zaak. Een nieuw IT-systeem staat immers niet op zichzelf, maar heeft impact op de organisatie en de mensen die daar werken. Wil je echt het succes boeken dat je voor ogen hebt, dan is aandacht voor dit aspect heel hard nodig. Een model dat daarbij dienstbaar kan zijn is het achtstappen verandermodel van Kotter.
De Amerikaanse bedrijfskundige John Paul Kotter deed jarenlang onderzoek naar veranderprocessen in allerlei typen organisaties. Hij leerde door te kijken naar zowel de succesverhalen als de mislukkingen en distilleerde daar een verandermodel uit dat eenvoudig is toe te passen en helpt om uiteindelijk de waarde te creëren die met de verandering wordt beoogd.
In dit artikel pas ik het model van Kotter toe op de dagelijkse praktijk van IT-projecten. Een kanttekening is hierbij op zijn plaats. Zuivere IT-projecten bestaan niet. Elke IT-project heeft altijd een veranderdoel en raakt daarmee de hele organisatie en haar mensen.
Ik begin met de eerste drie stappen. Die zijn vooral gericht zijn op het creëren van het juiste klimaat voor de beoogde verandering.
Fase 1: Creëren van urgentie
Volgens Kotter is dit de belangrijkste stap. Wie immers voelt dat de verandering noodzakelijk is, zal er sneller zijn medewerking aan verlenen. In de dagelijkse IT-praktijk betekent dit onder meer heel goed uitleggen waarom de verandering noodzakelijk is. Leg bijvoorbeeld uit dat het oude concept kwetsbaar is voor cyber attacks of maak de onderhoudskosten inzichtelijk van het bestaande systeem en de besparing die je kan bereiken. Of laat zien welke bedrijfsprocessen niet goed ondersteund worden en wat daar de consequenties van zijn. Soms hebben we geluk en is de urgentie meer dan duidelijk, bijvoorbeeld wanneer bestaande systemen slechte performance leveren.
Fase 2: Samenstellen van de leidende coalitie
Hoe groter en ingrijpender de verandering, hoe meer een brede dekking vanuit de organisatie noodzakelijk is. IT-projecten worden nogal eens ingestoken vanuit het operationele niveau, terwijl daarmee de tactische of strategische doelen niet gediend zijn. De leidende coalitie wordt bij het traject betrokken en kan de voorhoede vormen. Concreet betekent dit dat dit de mensen zijn die als eerste de nieuwe werkplek in gebruik nemen en overtuigd alle voordelen ervan uitdragen naar de rest van de organisatie. Een leidende coalitie is bij voorkeur samengesteld uit een dwarsdoorsnede van de organisatie.
Fase 3: Het creëren van een nieuwe visie
Wat beogen we met de verandering? Wat willen we echt bereiken? Willen we alleen een snellere werkplek of hebben we andere organisatiedoelen voor ogen? Gaat de nieuwe werkplek bijvoorbeeld helpen om medicatiefouten te verminderen? Door de visie uit te dragen weet iedereen wat de bedoeling is en waarom er verandering nodig is.
De stappen vier tot en met zes leggen vervolgens de relatie tussen de verandering en de organisatie.
Fase 4: Het creëren van draagvlak
Mensen vinden weinig zo vervelend als tegen hun wil een verandering opgedrongen te krijgen. Ineens mag je niet meer met je vertrouwde thin client op kantoor werken, maar loop je met je eigen laptop door het pand. Kotter stelt dat draagvlak onder andere gecreëerd wordt door het uitdragen van de visie. Waarom is deze verandering echt nodig? Welk doel dient het en waarom kunnen we niet verder op de oude manier? Mijn eigen ervaring is dat het ook helpt om voordelen te vinden en benoemen voor de medewerkers zelf: ‘What’s in it for me?’
Fase 5: Verwijderen van obstakels
Het klinkt zo logisch maar toch besteden we vaak te weinig aandacht aan de obstakels die we vooraf al hadden kunnen bedenken. Concreet kan dat verzet zijn door een coalitie vanuit de organisatie, bijvoorbeeld een afdeling die grote bedenkingen heeft. Bij IT-projecten zijn het soms ook de technische randvoorwaarden die niet goed zijn ingevuld. Voordat je daadwerkelijk kunt beginnen, zullen de obstakels op zijn best weggenomen, of op zijn slechtst onder controle moeten zijn.
Fase 6: Zorg voor korte termijn succes
IT-projecten duren vaak lang. Soms zelfs meerdere jaren, waardoor de mensen in de organisatie het wachten moe kunnen worden. Waarom zit ik nog steeds op Windows 7 terwijl ik thuis al op 11 zit? Waarom kan ik nog steeds geen röntgenbeelden bekijken op mijn thuiswerkplek terwijl ons dat wel is beloofd? Het creëren van succes op korte termijn verhoogt het draagvlak. Wellicht is het mogelijk om wat tijdelijke voorzieningen te creëren om de ergste pijn te verhelpen.
Dan kom ik bij de laatste twee fasen uit het model van Kotter. Deze fasen zijn gericht op implementatie van de verandering en bovendien op het vasthouden van de verandering.
Fase 7: Consolideer verbeteringen
Het is vaak heel verleidelijk om een verbetering door te voeren en het daarbij te laten. We hebben een mooie manier bedacht om een proces optimaal te ondersteunen, we rollen de daarbij behorende werkplek uit en besteden er vervolgens geen aandacht meer aan. Na een jaar blijkt iedereen zijn werk weer te doen op de oude manier en is de mooie nieuwe oplossing in de vergetelheid geraakt. Om veranderingen te laten beklijven is veel aandacht nodig in de vorm van coaching en scholing, niet alleen bij de uitrol maar gedurende langere tijd. Kotter stelt dat veranderingen soms wel tot 10 jaar nodig hebben voordat ze echt onderdeel uitmaken van het DNA van de organisatie.
Fase 8: Borg de veranderingen
Borgen wil zeggen het opnemen van de verandering in de besturingsmechanismen van de organisatie. Zorg bijvoorbeeld dat de nieuwe werkwijze onderdeel uitmaakt van de jaarlijkse interne auditplanning. Zorg ook voor regelmatige evaluatie van de verandering en check of bijsturing noodzakelijk is.
Tot slot, het model van Kotter is geen recept voor succes. Veranderen blijft noeste arbeid maar het helpt wel als je ook onze IT-projecten meerwaarde geeft. Welk doel streven we na met ons project? Is het uitsluitend gericht op het oplossen van technical debt of zoeken we echt naar mogelijkheden om business value te realiseren? Bij EIC zien we dat organisaties steeds meer neigen naar het tweede, maar dat gaat lang niet altijd vanzelf. En misschien dat Kotter er een handje bij kan helpen.
Wil je eens met ons doorpraten over hoe jouw IT-projecten business value kunnen leveren? Neem dan contact met ons op!