Vaak lopen it-projecten en itsm-implementaties niet zoals verwacht. De tijdsplanning wordt overschreden, de kosten lopen op of de effectiviteit valt tegen. Hoe komt het nou dat projecten en implementaties zo vaak falen? Ik denk dat de betrokkenen vaak de bouwblokken van het project op een bepaald moment uit het oog verliezen.
Elke constructie is opgebouwd uit onderdelen die op zichzelf niets betekenen, maar met elkaar samen bestemd zijn voor de eeuwigheid. De piramides in Egypte zouden zonder blokken aan één van de vier zijden jammerlijk in elkaar zakken, de Eiffeltoren is zonder één van de vier poten een zielige hoop staal en de Chinese Muur zou haar doel compleet voorbijgeschoten zijn als in het midden een stuk van enkele kilometers miste.
De bouwblokken in itsm
Zo geldt dat ook voor de meeste itsm-implementaties. Daarin herken ik drie bouwblokken die elk van groot belang zijn voor het slagen van het project: mensen, processen en technologie. Ongetwijfeld heb je wel eens van deze driedeling gehoord. Toch blijken projectleiders en betrokkenen vaak meer aandacht te geven aan één of twee van deze drie pijlers. Niet bewust, ze zijn simpelweg te gefocust op de mogelijkheden van een nieuwe oplossing, of de richtlijn om ermee te werken. Ze lopen het gevaar om de projectleden, it-medewerkers en eindgebruikers uit het oog te verliezen. Verklaarbaar, maar daarom niet minder kwalijk. Daarom bespreek ik hieronder de losse bouwblokken en hun plaats in het geheel.
– Mensen
Ik begin direct met het belangrijkste én meest onderschatte bouwblok: de betrokken mensen. De it-medewerkers, de mensen die uiteindelijk verantwoordelijk zijn voor de dienstverlening aan de interne klant moeten het gaan doen! Het is daarom belangrijk dat zij volledig achter het project staan. De implementatie van een nieuwe oplossing brengt immers veranderingen met zich mee en stuit daardoor bijna altijd op weerstand. Het creëren van draagvlak is noodzaak, maar wordt in veel projecten onderschat.
– Processen
De manier van werken is een belangrijk onderdeel van elk project. Vaak is hier dan ook wel aandacht voor, maar omvatten de vastgelegde processen alles wel? In het geval van itsm gaat het om het inrichten van ITIL- en/of ISM-processen, zoals incident-, change-, configuration en operations management. In veel projecten zijn deze zaken wel vastgelegd, maar niet concreet genoeg. Het risico bestaat dan dat it-medewerkers op eigen initiatief en naar eigen inzicht gaan werken, met als gevolg een kwaliteitsverlies in de dienstverlening. Het project zou dan een averechts effect hebben. Het is dus zaak om de procesgang volledig vast te stellen!
– Technologie
De technologie, bijvoorbeeld een it-servicemanagementoplossing die de procesgang goed moet ondersteunen en een interface is tussen klantorganisatie en it-afdeling, is de resterende 33 procent van de constructie. Het verschil zit er in, dat de gemiddelde it-professional veel minder sterk overtuigd hoeft te worden van het belang van dit bouwblok. Keer op keer heb ik bij itsm-implementaties gemerkt dat opdrachtgevers zeer benieuwd waren naar alle mogelijkheden en in de verleiding kwamen om elke functionaliteit toe te passen. Maar als iets kán, moet het dan ook? Het is de vraag die het aanbod bepaalt, niet andersom.
Stapsgewijze aanpak
Het is in een implementatie van belang dat de drie bouwblokken voortdurend even veel aandacht krijgen, zodat ze alle drie blijven groeien. Als er één achterblijft of meer aandacht krijgt, ontstaat er scheefgroei en hieronder kan het hele project lijden. Om te voorkomen dat je project een averechtse uitwerking heeft, is het goed om dat te allen tijde te beseffen. Zo zorg je ervoor dat je constructie is bestemd voor de eeuwigheid, ook al is een eeuwigheid binnen it een betrekkelijk begrip.
Goed om ITSM weer eens onder de aandacht te brengen, al vind ik het wat ‘hoog over’ gaan. Mijn duiten:
Mensen.
Het is goed eerst vast te stellen of, en zo ja in welke mate en met betrekking tot welke aspecten, er verandering gewenst is. Consensus over noodzaak van de verandering en commitment over de wijze waarop deze effectief kan worden doorgevoerd, is zeker in ITSM (waar het inderdaad per definitie gaat om mensen – in processen, welteverstaan) van groot belang. Oplossingen gaan alleen maar werken als dat wat ze oplossen daadwerkelijk als probleem of knelpunt is herkend, de aanpak wordt gedragen en men de oplossing(srichting) als verbetering en kans ervaart en deze niet als bedreiging ziet. Last but not least moet er goed op gemanaged worden.
Processen.
Mijn ervaring met dit soort trajecten is dat het “gevaar” van eigen initiatief en eigen inzicht helemaal geen gevaar hoeft te zijn, zolang er duidelijke afspraken zijn over het vastleggen en delen van de gevolgde werkwijze – en al helemaal als die werkwijze succesvol was. In feite is dat waar ITSM over gaat: het procesmatig organiseren van de werkwijze van IT-beheer (uit: De ISM Methode – Hoving en Van Bon). ITIL biedt handvatten, ISM biedt methodische ondersteuning, maar in alle gevallen gaat het uiteindelijk om de afspraken die mensen met elkaar hebben over manier van (samen) werken. En dat ze worden gemanaged op het maken, nakomen en waar mogelijk structureel verbeteren van die afspraken.
Technologie.
In onze zucht naar “control” wordt tooling vaak aangegrepen om daar grip op te krijgen. Echter, de beste tooling schiet zijn doel voorbij als niet eerst duidelijk is dat aan de hiervoor genoemde zaken kan worden voldaan. Grip krijgen doe je door consensus, samenwerking en duidelijk afspraken. Goede, of eigenlijk goed ingerichte tooling is dan de slagroom op de taart en borgt en versterkt de afgesproken werkwijze en het de mogelijkheid deze continu te verbeteren.
Alleen als er binnen een IT-beheer afdeling sprake is van een zootje ongeregeld zou ik me voor kunnen stellen dat het andersom ook kan werken: dus eerst de tooling en die als blauwdruk laten gelden voor herinrichting van de organisatie. Verschillende bekende ITSM-tools bieden op voorhand de mogelijkheid te kiezen voor bepaalde uitgangspunten en/of methodiek. Dit vraagt dan minstens om stevig (nieuw?) management en heeft overigens vergaande consequenties voor (de werkafspraken met) het team.