Fixed Price, Fixed Date, Fixed Result Service Manager: show balls

Transcriptie

1 Besturen van IT-dienstverleners door de klant 3.5 Service Manager: show balls Van ICT Service Managers die het moeten hebben van klanten wordt meer gevraagd dan vroeger. Was het een paar jaar geleden nog zo dat men tegen een hoog uurtarief ITIL-schema s kon kopiëren uit boeken, nu worden garanties voor het eindresultaat geëist. Niet alleen qua functionaliteit maar ook op het gebied van tijd en geld. Dit is niet een ontwikkeling waar alleen externe aanbieders mee te maken hebben. Ook als Service Manager in vaste dienst ervaart men steeds meer de druk van fixed price, fixed date en fixed result (fpfdfr). De vraag is nu, hoe moet men dit als Service Manager aanpakken zonder Russische roulette te spelen? Hoe kan men voor zichzelf en zijn collega s zekerheid inbouwen zonder dat de klant daar last van heeft? Welke eisen moet men aan de klant stellen? Wat zoekt de klant nu eigenlijk? Zekerheid over wanneer de klant wat krijgt voor welk bedrag? Of is het schijnzekerheid waarmee de klant zich op zijn beurt kan indekken? Wat moet de klant doen om zinvolle afspraken op basis van fixed price, fixed date en fixed result te maken? Is de klant er aan toe? In hoeverre leent het Service Management vak zich voor een fpfdfr-aanpak? Dit artikel levert handreikingen die los staan van een projectmanagement methodiek. Het maakt voor dit artikel niet uit of men nu Prince-2, DSDM, PMBoK of een andere methode gebruikt om het werk te structureren. Ook levert dit artikel geen nieuwe methode. Het is namelijk niet in de eerste plaats de methode waardoor het succes van een project wordt bepaald Auteurs: Jan F. Bouman, directeur van Value to Essence BV, en Albert Chr. van Loon, Senior Business Consultant bij Ordina SI&D Project Management. Noot: De afkorting fpfdfr staat in dit artikel voor fixed price, fixed date en fixed result. SILVER BULLET Moeten wij nu op zoek gaan naar de silver bullet? De toverformule die alle service management projecten doet slagen, vanuit het perspectief van fixed price, fixed date en fixed result? Het zou mooi zijn als dat kon maar dat is een illusie. Er zijn mensen nodig om in te spelen op het onverwachte en het ongeplande dat niet te vatten is in een formule of een methode. De projectmanager en leden van het projectteam kunnen niet worden vervangen door computerprogramma s of robots. Dat heeft te maken met de onmogelijkheid om de omgevingsfactoren van het project volledig te beheersen. Service Management is bij uitstek een discipline die te maken heeft met de omgeving, namelijk IT Service Management, best practices

2 178 de business processen waar het een bijdrage aan levert. Er is een voortdurende wisselwerking tussen Service Management en de organisatie waar het deel van uit maakt. Geen silver bullet dus, maar mensen die inspelen op het onverwachte en die risico s beheersen. Dit artikel stelt de vraag: Hoe kan men een fpfdfr-project uitvoeren met calculated risks waar de Service Manager en (vooral) zijn klant mee kunnen leven. RISICO S Er zijn veel mogelijke oorzaken van het mislukken van projecten. Stuk voor stuk zijn het zaken die roet in het eten kunnen gooien als het gaat om fpfdfr-commitments. Hier volgt een - niet uitputtend - overzicht: onduidelijke verantwoordelijkheden (wie heeft welke bevoegdheden, wie mag wat beslissen); afwezigheid van klant als opdrachtgever (feitelijke afwezigheid of gebrek aan interesse); veranderende specificaties en doelstellingen; vage specificaties en doelstellingen (ruimte voor verschillende interpretaties); veranderende omgeving en organisatie; onbekendheid met de materie; slecht functionerende projectteam en projectorganisatie (competenties, rollen, motivatie); verborgen agenda s; onbekendheid met omgeving en organisatie; optreden van rampen (met de organisatie, met sleutelfiguren); mission Impossible (bijvoorbeeld onder politieke druk of met de vooropgezette bedoeling te mislukken); te weinig kennis en vaardigheden; ongefundeerd optimisme voor wat betreft tijd en inspanning; te weinig betrokkenheid van toekomstige gebruikers van het (eind)resultaat. Het vervolg van dit artikel geeft handreikingen om risico s te reduceren of zelfs te vermijden. VERANDEREN Een project is beslist niet de enige manier om een organisatie te veranderen voor wat betreft (bedrijfs)processen, ICT, techniek of anderszins. Pas als de verandering van tevoren gedefinieerd is en het veranderingsproces bestuurbaar en beheersbaar is, kan er volgens gangbare definities sprake zijn van een project. In de praktijk spelen vaak meerdere veranderingsprocessen tegelijk. Naast het project, met afspraken over tijd, geld en resultaat, spelen ook machtsspellen, menselijke verhoudingen, leerprocessen en andere dynamische processen een rol. Herman de Smit (citerend De Caluwé/ Vermaak [8]) heeft hiervan in het IT Beheer Jaarboek 2002 [2] een helder, bruikbaar en vooral kleurrijk overzicht gegeven. Zie tabel 1. De Smit schrijft over veranderingsstrategieën. Keuze van een strategie is afhankelijk (volgens De Caluwé/Vermaak) van een vijftal factoren: 1. Beoogde uitkomsten; 2. Stand van zaken nu; 3. Verschil tussen huidige en gewenste situatie; 4. Weerstanden, blokkades en energie op individueel, groeps- c.q. organisatieniveau; 5. Persoonlijke stijl van de veranderaars. In dit artikel hebben wij het over veranderingsprocessen in plaats van veranderingsstrategieën. De veranderingen zijn namelijk vaak verankerd in de organisatie- en managementcultuur waardoor er geen sprake is van een volledig vrije keuze. Veranderingen vinden plaats of men nu wil of niet. Er is slecht sprake van een zeer beperkte maakbaarheid. Wij voegen in het kader van dit artikel een factor toe aan bovengenoemde vijf, namelijk:

3 Besturen van IT-dienstverleners door de klant Geeldruk Blauwdruk Rooddruk Groendruk Witdruk Veranderen is een machtsspel gericht op haalbare oplossingen rationeel te ontwerpen en implementeren een ruilexercitie met mensen mensen motiveren om te willen leren met elkaar en van elkaar energie losmaken Kernbegrippen Belangen, partijen, actoren, standpunten, win-winsituaties Plan, organiseer, resultaatgericht, stappenplan, complexiteit beheersen Managementstijl, personeelssamenstelling, competenties, belonen, motiveren Bewust onbekwaam maken, leervermogen, leersituaties Crisis als kans, blokkades wegnemen, dynamiseren Het ideaal Nastreven van overkoepelende belangen; de haalbare oplossing De wereld is maakbaar en planbaar; de beste concrete oplossing Juiste fit tussen organisatie-doelen en individuele doelen; een motiverende oplossing Lerende organisatie: met iedereen, over alles, alijd; een oplossing die mensen zichzelf eigen maken Spontane evolutie; de kunst van het niethandelen De valkuil Luchtfietserij; machtsstrijd ( loose - loose ) Over mensen heen walsen; irrationele aspecten negeren Zachte heelmeesters; negeren van machtsspel; verstikken van het individu Ontkennen dat niet iedereen alles kan of wil leren; geen prioritering; gebrek aan acties Laissez faire ; de medewerker opzadelen met zelfsturing Het resultaat Onbekend en verschuivend Vooraf omschreven en gegarandeerd Vooraf bedacht, maar niet gegarandeerd Vooraf geschetst, maar niet gegarandeerd Onvoorspelbaar ( de weg is de herberg ) Aanpak Alliantievorming; arbitrage; bemiddeling; topstructurering; onderhandelen; opvattingen afdwingen Projectmatig werken; vergaderprocedures; voortgangsmeting Beoordelen en belonen; sociale activiteiten; loopbaanplannen Opleidings-trajecten; gaming; coaching; intervisie; teambuilding Zelfsturende teams; persoonlijke groei Tabel 1 Veranderstrategieën (de Smit naar De Caluwé/Vermaak) 6. eisen en wensen van de klant. Dit is een zinvolle toevoeging, zeker in het kader van de relatie klant dienstverlener én voor wat betreft fixed price, fixed date, fixed results. Bij een fpfdfr-propositie denken we uiteraard in eerste instantie aan een blauwdruk in termen van tabel 1: de verandering is rationeel te ontwerpen en te implementeren, het is planbaar en stuurbaar en er is een vooraf omschreven en gegarandeerd eindresultaat. We spreken van een projectmatige aanpak. Echter, daar komen we niet mee weg, zeker niet met complexe projecten in dito organisaties. Zelfs al is de verandering goed in te kaderen in definities, specificaties, planningen en procedures zelfs als rekening gehouden wordt met alle aspecten van risicomanagement en perceptiemanagement (te behandelen in de volgende paragrafen) dan nog zullen andere veranderingsmechanismen plaats vinden, parallel aan het project. Het is dus zaak dat bij fpfdfr-proposities, naast blauwdruk veranderingen, wordt nage- IT Service Management, best practices

4 180 gaan of en in hoeverre er sprake is van geeldruk, rooddruk, groendruk en witdruk veranderingsprocessen. Als dat is gebeurd, moet worden beoordeeld of deze (kleurrijke) veranderingsprocessen belemmerend of stimulerend zijn voor het beoogde blauwdruk project. Tenslotte zal de projectmanager en het projectteam beïnvloedend moeten optreden conform de laatste kolom van tabel 1. SPECIFICATIES VOOR OPLEVERING Tom Poppendieck zegt in zijn artikel The Agile Customer s Toolkit dat 20% van de specificaties van het project voor 80% bepalend zijn voor tevredenheid van de klant [1]. Het gaat natuurlijk niet om die percentages want die kunnen ook respectievelijk 13%/80%, 28%/78% of anders zijn. Het gaat wel om het besef dat slechts een klein deel van de specificaties bepalend is voor een groot deel van de klanttevredenheid. En klanttevredenheid is bepalend voor succes. In de paragraaf over De klant en zijn perceptie wordt ingegaan op het begrip klanttevredenheid. Ook wordt daar een relatie gelegd tussen klanttevredenheid en fixed price, fixed date, fixed result. Het is belangrijk om te bepalen welke specificaties deel uit maken van dat relatief lage percentage dat bepalend is voor klanttevredenheid (S A1 + S A2). Hierbij is het zinvol om onderscheid te maken tussen enerzijds bedrijfs- en businessbelang (S A1) en anderzijds gebruikscomfort en functionaliteit (S A2). Het één heeft vaak betrekking op de klant als opdrachtgever en het ander op de klant als gebruiker. Daarnaast is er bijna altijd sprake van een groep projectspecificaties die niet direct bepalend zijn voor de klanttevredenheid maar waarvan realisatie om andere redenen wel belangrijk is (S B). Tenslotte is het zinvol om na te gaan of er projectspecificaties zijn die helemaal geen effect op klanttevredenheid hebben (S C). Samenvattend komen we tot de volgende categorieën projectspecificaties: S A1 = projectspecificaties die bepalend zijn voor klanttevredenheid vanuit de optiek van bedrijfs- of businessbelang; S A2 = projectspecificaties die bepalend zijn voor klanttevredenheid vanuit de optiek van gebruikscomfort en functionaliteit; S B = projectspecificaties die niet bepalend zijn voor klanttevredenheid maar waarvan realisatie om andere redenen wel belangrijk is; S C = projectspecificaties die geen effect op klanttevredenheid hebben. Een veel gebruikte benadering voor het bepalen van prioriteiten is het stellen van zogenaamde MoSCoW vragen: Must have - top prioriteit, zonder realisatie van deze specificaties is het project niet de moeite waard. Categorieën S A1 en S A2. Should have - belangrijk, zonder realisatie van deze specificaties is acceptatie door de klant een probleem. Categorieën S A1, S A2 en een deel van S B. Could have - leuk om te hebben, niet van wezenlijk belang voor het projectresultaat. Categorie S B. Won t have - niet nodig voor het projectresultaat. Categorie S C. Voor het totaal aan projectspecificaties geldt dan de volgende optelsom: S TOTAAL = S A1 + S A2 + S B + S C Wat is het nut van zo n triviale optelsom? Een van de belangrijkste boodschappen van dit artikel is dat risico s van uitloop van het project op het gebied van tijd, geld en resultaat, zoveel mogelijk moeten worden afgewenteld op categorie S C. Als dat niet mogelijk is omdat S C niet bestaat of leeg is, dan moeten deze risico s afgewend worden op S B waarbij men zich ernstig moet afvragen welk effect dit op acceptatie door de klant zal hebben. Risico s zullen echter nooit afgewenteld mogen worden op S A1 en S A2. Deze projectspecificaties moeten safe and sound leiden tot de beoogde resultaten binnen gestelde tijd en budget. Management van project-resources zal zich moeten concentreren op het realiseren van S A1 en S A2, de specificaties die bepalend zijn

5 Besturen van IT-dienstverleners door de klant Categorie S A1 S A2 S B S C Beschrijving projectspecificaties die bepalend zijn voor klanttevredenheid vanuit de optiek van bedrijfs- of businessbelang projectspecificaties die bepalend zijn voor klanttevredenheid vanuit de optiek van gebruikscomfort en functionaliteit projectspecificaties die niet bepalend zijn voor klanttevredenheid maar waarvan realisatie om andere redenen wel belangrijk is projectspecificaties die geen effect op klanttevredenheid hebben MoSCoW Must have Should have Must have Should have Should have Could have Won t have Risico Management management van resources zonder gevaar voor realisatie (resultaat, tijd, geld) management van resources zonder gevaar voor realisatie (resultaat, tijd, geld) management van resources met zo weinig mogelijk gevaar voor realisatie (resultaat, tijd, geld) concentreren van zo veel mogelijk risico s voor realisatie (resultaat, tijd en geld) 181 Tabel 2 Prioriteiten van specificaties voor acceptatie van de klant. Daarnaast zal zoveel mogelijk van SB moeten worden gerealiseerd. Zie volgend overzicht: S A1 en S A2 - management van resources zonder gevaar voor realisatie (resultaat, tijd, geld); S B - management van resources met zo weinig mogelijk gevaar voor realisatie (resultaat, tijd, geld); S C - concentreren van zo veel mogelijk risico s voor realisatie (resultaat, tijd en geld). Tabel 2 geeft een samenvatting van deze paragraaf. DE KLANT EN ZIJN PERCEPTIE De klant is of wordt geacht - geëmancipeerd te zijn. Hij laat zich geen knollen voor citroenen verkopen. De klant wil duidelijke afspraken en commitments van de dienstverlener. Vaak in de teneur van fixed price, fixed date, fixed result. Het contract met de klant kan dus simpel zijn: een bedrag, een datum en een verzameling specificaties. Maar is dit wel zo simpel? Bij het bouwen van een eenvoudig systeem, bijvoorbeeld een keukentafel of een applicatie voor het invullen van acceptgiro s, lijkt dit inderdaad simpel. Bij het realiseren van een Service- Managementoplossing dringt zich echter complexiteit op. Daar hebben we te maken met een veelheid van technische, organisatorische, financiële en menselijke relaties. Veel specificaties van een Service- Managementoplossing zijn daardoor onderhevig aan verschillende interpretaties. Veel is afhankelijk van de persoon die de oplossing beoordeelt, van onderlinge verhoudingen en allerlei omgevingsfactoren. Welk fixed result levert de Service Manager binnen het budget van fixed price uiterlijk op fixed date? Een goed gesprek tussen projectmanager en klant is dus nodig. Volgens Schneider & Bowen [3] wordt de perceptie van de klant bepaald door expectations en needs, verwachtingen en (onderhuidse) behoeften. Dit is beschreven in ons artikel Beauty is in the Eye of the Beholder van The Guide to IT Service Management, Volume I [4]. Verwachtingen zijn formeel beschreven in specificaties. Behoeften zijn niet beschreven maar zijn daarentegen wel bepalend voor de interpretatie van het resultaat. Tabel 3 geeft een overzicht: 3 IT Service Management, best practices

6 182 EXPECTATIONS NEEDS Conscious Unconscious Specific Global Surface Deep Short-term Long-term Desired outcomes from service encounters Desired outcomes from human existence (e.g. short response time) (e.g. self-esteem) If you dissatisfy Customers If you dissatisfy Customers by not meeting their expectations, by not meeting their basic needs, you can still recover you will lose them Tabel 3 The Difference between Expectations and Needs (source: Schneider/Bowen) Schneider & Bowen zijn duidelijk: ls men specificaties (expectations) niet nakomt dan is de situatie vaak te herstellen, maar als men het vertrouwen schaadt door behoeften (needs) te verontachtzamen, dan houdt het op. Klanttevredenheid, zoals hiervoor genoemd (vorige paragraaf), wordt vooral bepaald door dit vertrouwen. Perceptiemanagement bij fpfdfr-service Management projecten is dus essentieel ondanks het feit dat de aanduiding (3x fixed) anders doet vermoeden. Juist bij Service Management zijn er veel afhankelijkheden met andere domeinen waardoor er ruimte blijft voor verschillende interpretaties van het resultaat. Het nadeel van deze afhankelijkheden is dat het meetbaar voldoen aan specificaties heel lastig wordt. Het voordeel echter is dat men ruimte krijgt de klant te overtuigen. Een projectmanager die dat niet kan, moet nooit aan fpfdfr-opdrachten beginnen, tenzij hij een resultaat moet opleveren waarbij omgevingsfactoren geen rol spelen. Belangrijk hierbij blijft dat de projectmanager voldoende te bieden heeft dat binnen de categorie S A1 + S A2 (de belangrijkste specificaties) van de vorige paragraaf valt. Als blijkt, door goed te luisteren en te beïnvloeden, dat er specificaties zijn van minder of zelfs geen belang, dan kan de projectmanager die indelen bij categorie S B of S C. Op deze wijze worden kansen op succes voor het project aanzienlijk vergroot. Perceptiemanagement in projecten moet dus niet worden geassocieerd met negatieve begrippen als manipulatie en goed praten wat niet goed is. Perceptiemanagement gaat hand in hand met risicomanagement en dient in de eerste plaats om aan te sluiten op verwachtingen en behoeften van de klant. Daar waar die verwachtingen en behoeften primair op gericht zijn, moeten zo weinig mogelijk risico s liggen voor het te behalen resultaat. HET CONTRACT Het contract dient als ondersteuning en stimulans voor het behalen van doelstellingen op het gebied van tijd, geld en resultaat c.q. kwaliteit. Dit geldt voor klant én dienstverlener. Zo gauw het contract de vorm aanneemt van een houdgreep waardoor de ene partij de andere in zijn macht heeft, worden er grote risico s geïntroduceerd. Zo n houdgreep reduceert de mogelijkheden voor risico- en perceptiemanagement. Partijen staan niet open en eerlijk tegenover elkaar, waardoor verkeerde signalen worden uitgewisseld. Het is van groot belang dat - voordat afspraken over tijd, geld en resultaat worden vastgelegd in een contract - eerst de analyse uit paragraaf Specificaties voor oplevering wordt uitgevoerd. Met andere woorden: eerst moet worden vastgesteld welke specificaties meer of minder belangrijk zijn. Vaak levert dit een dilemma voor de klant op. Hij wil eigenlijk alles gerealiseerd hebben, ook de minder belangrijke zaken. Door nu aan te geven dat sommige specificaties minder belangrijk zijn, vreest hij dat de projectleiding er te weinig aandacht aan zal schenken. Anderzijds zal

7 Besturen van IT-dienstverleners door de klant de klant niet graag zien dat essentiële specificaties ondermijnd worden door te veel aandacht voor bijzaken. Over het algemeen is het in het belang van klant én dienstverlener om prioriteiten van specificaties helder en duidelijk vast te leggen in het contract. Om het dilemma, genoemd in de vorige alinea, te verzachten kunnen partijen vastleggen dat de beloning varieert, al naar gelang de hoeveelheid gerealiseerde specificaties. Bijvoorbeeld: 100% van fixed price bedrag: Realisatie van S A1 + S A2 + S B 80% van fixed price bedrag: Realisatie van S A1 + S A2 Daarnaast moeten partijen duidelijke afspraken maken over veranderende omstandigheden tijdens de loop van het project; veranderingen op het gebied van: Specificaties Prioriteiten Organisatie Beleid Politiek Bedrijfsprocessen Technologie Personele bezetting Budgetten Deadlines (tijdsaspecten) Beschikbare middelen. Veranderingen, betrekking hebbend op bovengenoemde zaken, kunnen zowel bij klant als bij dienstverlener plaats vinden. Voor elk van deze aspecten moeten twee maal de volgende vragen (tabel 4) gesteld en beantwoord worden, één keer voor veranderingen bij de klant en één keer voor veranderingen bij de dienstverlener. Als bij beantwoording van de vragen volgens tabel 4 bij één of beide partijen ALARM wordt gescoord dan is het noodzakelijk een goed gesprek te houden over de beoogde doelstellingen van het project. Als men bepaalde ALARM-scores aanvaardt, moet dat bewust worden gedaan en moeten eventuele consequenties worden vastgelegd. Het is een illusie te verwachten dat bij een grondige analyse volgens tabel 4, er geen ALARM-scores zullen zijn, zeker bij een complex Service Management project. Wat een minder ervaren en diplomatiek Vragen en antwoorden Kunt u de verandering beïnvloeden? JA Kunt u bij deze verandering de risico s op het gebied van tijd, geld en resultaat/kwaliteit beheersen? JA Geen belemmering voor het project / leg afspraken vast in contract JA, gedeeltelijk Aanvaardt u, samen met de andere partij, een gedeelde verantwoordelijkheid ten aanzien van de risico s op het gebied van tijd, geld en resultaat/kwaliteit? JA Geen belemmering voor het project / leg afspraken vast in contract NEE ALARM NEE Aanvaardt u een onzekere afloop van dit project op het gebied van tijd, geld en resultaat/kwaliteit? JA Geen belemmering voor het project / leg afspraken vast in contract NEE ALARM NEE Kunt u bij deze verandering de risico s op het gebied van tijd, geld en resultaat/kwaliteit bij de andere partij neerleggen? JA Geen belemmering voor het project / leg afspraken vast in contract NEE Aanvaardt u een onzekere afloop van dit project op het gebied van tijd, geld en resultaat/kwaliteit? JA Geen belemmering voor het project / leg afspraken vast in contract NEE ALARM Tabel 4 Omgaan met veranderingen in omgevingsfactoren IT Service Management, best practices

8 184 bedreven projectmanager als onbeïnvloedbaar ziet, zal zijn meer ervaren en getalenteerde collega als juist wel beïnvloedbaar zien. Het is dus belangrijk om te beseffen dat toepassing van tabel 4 een subjectief karakter heeft. Eerder in het artikel werd al betoogd dat de kwaliteit van projectmanager en projectteam meer bepalend is voor het succes dan de methode die wordt toegepast. Het is daarom van belang dat de projectmanager zelf een bepalende invloed heeft op selectie van zijn projectteam. De competenties moeten compleet zijn, de mensen moeten kunnen samenwerken en het moet een gebalanceerd team zijn. OPDELEN Een beproefde wijze om risico s op het gebied van tijd, geld en resultaat te beheersen is het opdelen van het project in goed gedefinieerde en beheersbare brokken. Deze aanpak heeft tenminste vier grote voordelen: Klant en dienstverlener getroosten zich moeite om de samenhang tussen de delen van het project ( brokken ) te onderkennen en te beschrijven. Klant en dienstverlener bereiken overeenkomst over die samenhang (v.w.b. dat deel van het project waarvoor het startsein wordt gegeven). Na elk deel van het project is er een duidelijke en heldere rapportage over de voortgang (aan de hand van een acceptatieprotocol), op grond van de specificaties van het deelproject. Na elk deel van het project zijn partijen vrij (ten aanzien van vastgelegde verplichtingen) om het geheel bij te stellen onder invloed van allerlei omgevingsfactoren. Het moge duidelijk zijn dat bij grote en/of complexe projecten het aantal onzekerheden groot is en dat een afwijking op het gebied van tijd, geld of resultaat, qua effect exponentieel kan doorwerken naarmate het project voortschrijdt. Daarom is het voor alle partijen zinvol om zo nu en dan alle parameters weer eens op nul te kunnen zetten. Bovengenoemde brokken of deelprojecten zijn in Prince2 zogenaamde Stages. De samenhang tussen Stages wordt vastgelegd in het Projectplan. In het proces Planning wordt voor elke Stage een Stageplan ontwikkeld. Vervolgens worden de Stages door middel van de processen Controlling a Stage en Managing Product Delivery beheerst en tot een goed einde gebracht. Tussen de Stages door worden door middel van het proces Managing Stage Boundaries resultaten getoetst aan de Business Case. Dit kan betekenen dat het project wordt bijgestuurd of zelfs gestaakt. Prince2 is, afhankelijk van interpretatie en werkwijze van de projectmanager, een prima methode om - door middel van het opdelen in brokken - risico s op het gebied van tijd, geld en resultaat te beheersen. In zijn bijdrage in het IT Beheer Jaarboek 2002 Sturen op afspraken [7] schetst Haagsma de situatie bij Defensie Telematica Organisatie (DTO). Kennelijk is er een parallel te trekken tussen complexiteit bij service (management)-organisaties en complexiteit bij projecten. Haagsma legt namelijk uit dat allerlei oorzaken op het gebied van historie (geërfde situaties), organisatie, besturing, communicatie, contracten, verschillen in cultuur en kwaliteitsnormen leiden tot een zeer complexe organisatie. Door die complexiteit is men niet meer in staat om aan verwachtingen van de klant te voldoen. De problemen worden als volgt geschetst: Er wordt een te krappe tijd afgesproken tussen contractondertekening en levering. De prijs wordt te krap berekend (wegens commerciële omstandigheden of omdat niet alles bij de kostprijsberekeing is meegenomen). Er wordt functionaliteit beloofd die de organisatie niet kan waarmaken. We zien hier de fpfdfr-problematiek van dit artikel terug komen. De oplossing voor DTO wordt onder andere gevonden op het gebied van zelfstandige eenheden die verantwoordelijk (en bevoegd)

9 Besturen van IT-dienstverleners door de klant zijn voor de levering. Daarnaast wordt de dienstverlening gebaseerd op assemblage van bouwstenen. Standaardisatie dus. Opvallend is dat ook hier wordt gegrepen naar het middel van opdelen. De contractvorm wordt zodanig gekozen dat operationele managers hun verantwoordelijkheid kunnen overzien, beheersen en waarmaken. Het blijkt dat analyses en hier gegeven handreikingen rond risico s op het gebied van tijd, geld en resultaat niet alleen voor projecten gelden. Ook bij het sluiten van een servicecontract gelden afwegingen van risicomanagement, perceptiemanagement, opdelen en volwassenheid van de organisatie. VOLWASSENHEID VAN DE ORGANISATIE De organisatie waarin en waarmee een project wordt uitgevoerd is medebepalend voor het succes. De organisatie moet er aan toe zijn, moet volwassen genoeg zijn om projectmatig te werken. Er zijn op dit moment veel adviesbureaus bezig met het ontwikkelen van zogenaamde maturity ontwikkelingsmodellen. De meeste zijn gebaseerd op het Capability Maturity Model dat ontwikkeld is vanaf 1986 op aangeven van het Department of Defence in de USA, ten behoeve van software ontwikkelingstrajecten. Zie tabel 5. Er is reeds een CMM-variant in ontwikkeling, specifiek voor IT Service Management [5]. METEN VAN VOLWASSENHEID C.Q. PROFESSIONALITEIT Steeds vaker wordt de vraag of wens gehoord dat organisaties willen professionaliseren. Datzelfde geldt voor het projectmanagement binnen organisaties. De eerste vraag die gesteld kan worden is dan: Wat bedoelt u daarmee? Met als gevolg dat er verwachtingsvol naar de gesprekspartner gekeken wordt en termen als; op tijd, opleiding en planning gemompeld worden. Het blijkt steeds weer moeilijk om aan te geven wat er met de term professionalisering bedoeld wordt. Het zijn immers toch professionals die zich met projecten bezighouden. Eén ding is echter wel duidelijk: men is niet tevreden over de wijze waarop projecten worden uitgevoerd. In het voorgaande is een aantal oorzaken benoemd. In deze paragraaf geven wij antwoord op de vraag hoe de roep om professionalisering expliciet gemaakt kan worden. Een eerste constatering is de steeds groeiende behoefte aan een totaaloverzicht van kennis en vaardigheden (lees: skills), die nodig zijn om de effectiviteit van projectmanagement binnen een organisatie te borgen. Met andere woorden: welke skills bepalen het ontwikkelingsniveau van projectmanagement? Om een antwoord te kunnen geven op deze vraag heeft Ordina het Projectmanagement Ontwikkel Model (PM3) geschikt gemaakt voor de Nederlandse markt [6] PM3 is gebaseerd op de negen kennisgebieden van PMBoK [9] en de vijf maturity levels van CMM en toetst een organisatie op deze negen gebieden. De negen gebieden van De niveaus van CMM Maturity Levels Beschrijving 1 Initial Voldoet in principe iedere organisatie aan 2 Repeatable Activiteiten kunnen worden herhaald 3 Defined Standaardisatie van aanpak 4 Managed Meetbare en vergelijkbare prestaties 5 Optimizing Continue verbetering ingebouwd Tabel 5 Capability Maturity Model IT Service Management, best practices

10 Level 5 Optimized 186 Level 4 We kunnen het altijd beter doen Managed and Meassurable Level 3 Defined Process We meten hoe goed we het doen Level 2 Repeatable but Intuitive We doen allemaal hetzelfde Level 1 Initial/Ad Hoc We weten wat iedereen doet Figuur 1 PM3-audit van Ordina PMBoK zijn achtereenvolgens: Integratiemanagement Scopemanagement Tijdmanagement Kostenmanagement Kwaliteitsmanagement Human resource management Communicatiemanagement Risicomanagement Leveranciersmanagement. De kennisgebieden zijn van eminent belang binnen het organiseren van projecten en programma s. De audit die PM3 uitvoert toont op welk ontwikkelingsniveau deze kennisgebieden zich binnen de organisatie bevinden (zie figuur 1). Dat gebeurt door elk kennisgebied ook nog eens onder te verdelen in een aantal componenten. Op deze manier ontstaat een gedetailleerd beeld over projectmanagement. Waarom duren veel projecten langer dan gepland, zijn de kosten hoger en blijft het resultaat achter? Een antwoord op deze vraag luidt: omdat projectmanagement bijzonder gecompliceerd is en afhankelijk van talrijke variabelen, die vaak onvoldoende beheerst worden. Veel organisaties realiseren zich deze complexiteit niet, of te laat. Nog steeds wordt projectmanagement er bij gedaan door iemand die dat al een keer eerder gedaan heeft (of niet). Zowaar geen goede basis voor fpfdfr-projecten. PM3 toont aan waar verbeterd kan worden: op welk niveau bevindt men zich en naar welk niveau zou een organisatie zich willen ontwikkelen. Veel organisaties bevinden zich op het eerste niveau, dat zich kenmerkt door ad hoc processen en sterk afhankelijk is van de individuele kwaliteiten van een projectleider. Het management ruikt onraad en is niet tevreden over de wijze waarop projecten worden uitgevoerd en gerapporteerd. Hier begint de roep om professionalisering. Het belang van die individuele kwaliteiten blijft groot (zoals blijkt uit het voorgaande) maar de afhankelijk ervan neemt af naarmate het ontwikkelingsniveau van de organisatie stijgt. Op het tweede niveau is er sprake van enige structurering in processen en standaards. Doch deze worden niet overal en voor alle projecten gebruikt. Verder is het management ondersteunend en moedigt ze het gebruik van processen en standaards aan: Informatie is voorhanden in een mix van detailzaken en hoofdzaken.

11 Besturen van IT-dienstverleners door de klant Schattingen en planningen zijn gebaseerd op de expertmethode of algemene planningstools. Op niveau 3 is sprake van uitgewerkte organisatorische standaards en processen: Alle processen zijn standaard voor alle projecten, en repeteerbaar. Voor het management zijn geïnstitutionaliseerde processen aanwezig. De informatie is voorhanden op hoofdpunten en op detailpunten. Projecten zijn gebaselined en de werkelijke bestedingen worden geregistreerd. Schattingen en planningen zijn gebaseerd op standaardkengetallen en organisatie specifieke kengetallen. Er is gericht aandacht voor de organisatie. Projecten worden geanalyseerd op hun effectiviteit (performance). Op niveau 4 kunnen we spreken over beheerste processen en wel op de volgende manier: De processen zijn geïntegreerd met de processen van de organisatie. Management neemt verantwoordelijkheid voor de gestelde opdracht. Management neemt het beeld aan van de organisatie. Er is een degelijke analyse van de projecteffectiviteit (performance). Schattingen en planningen zijn in het algemeen gebaseerd op organisatiespecifieke kengetallen. Management maakt gebruik van informatie om beslissingen te nemen. Het ultieme doel is niveau 5. Op dit niveau kunnen we spreken van een goed georganiseerde projectenomgeving waarbinnen men vindt dat het altijd nog beter kan: Er zijn processen voorhanden die de effectiviteit en efficiency van projecten meten. Er zijn processen aanwezig die de effectiviteit van projecten verbeteren, in een lerende organisatie. Management is gericht op continue verbeteren. Verbeteraanpak Niveau 5 is niet voor elke organisatie geschikt. Elke organisatie dient te bepalen welk niveau voor haar geschikt is. Daarbij is het belangrijk te beseffen dat de niveaus een evoluerend karakter hebben. Ze dienen als een groeipad te worden gezien. Algemeen wordt organisaties geadviseerd een verbeterprogramma met specifieke focus en meetbaar resultaat op te zetten, waarbij de doelstelling in een relatief korte periode kan worden bereikt. Daarbij hanteren we een termijn van 6 tot 12 maanden. Het is ook aan te raden verbeteringen voor projectmanagement te combineren met andere procesverbeteringen zoals software engineering of financieel management. Zo zal het invoeren van de Earned-Value tracking methodiek binnen projectmanagement zinloos zijn, als de organisatie geen tijdregistratiesysteem invoert. De ervaringen hierbij zijn dat, indien projectmanagement vooruit loopt op andere bedrijfsprocessen, dit onrust en misverstanden oproept. Er zijn twee mogelijkheden om het geschikte ontwikkelniveau voor een organisatie te bepalen: een onafhankelijke audit - gebruikmakend van ondersteunende tools en processen (zoals PM Solutions, PM3 assessment en HealthCheck ), kunnen experts bepalen op welke niveau de organisatie zich bevindt. Het managementteam en de auditors kunnen vervolgens gezamenlijk een strategie bepalen om een hoger niveau te bereiken. Deze onafhankelijke benadering is aan te raden indien het senior management overtuigd moet worden van het belang van het verbeteren van projectmatig werken. een gefaciliteerde audit - een klein team van ervaren auditors komt de organisatie ondersteunen in het uitvoeren van een ontwikkelaudit. Daarbij zal dezelfde procedure worden gevolgd, met dien verstande dat de organisatie zelf bepaalt op welk niveau ze zich bevindt. Het is ook de organisatie zelf die een plan opstelt voor verbeterin IT Service Management, best practices

12 188 gen. Het team van ervaren auditors begeleidt het traject en stuurt waar nodig bij. De belangrijkste taak daarin is het anoniem houden van de vragenlijsten. Een gefaciliteerde audit heeft meer draagvlak in de organisatie en zal vaak succesvoller zijn bij het implementeren van voorgestelde verbeteringen. Met de PM3-audit is een instrument ontwikkeld dat organisaties kan ondersteunen in het bepalen van hun strategie m.b.t. projectmatig werken. Welk niveau wil het bereiken en welke weg kan daartoe bewandeld worden. De voordelen zijn vooral te behalen door de professionalisering te sturen, prioriteiten te stellen aan acties en een start te maken met een cultuuromslag. Het voordeel moet niet gezocht worden in het verklaren van het huidige ontwikkelingsniveau. Herhaling van de audit is aan te bevelen. Consistentie in de metingen en resultaten maakt vergelijkingen mogelijk met eerdere metingen en andere organisaties. Een van de grondbeginselen van auditing ten behoeve van verbeterprojecten is dat er gericht vooruitgang moet worden gemeten, met een logische volgende stap tot gevolg. CONCLUSIES Het reduceren van risico s in Service Management projecten bijkt geen exacte wetenschap te zijn. Zelf als het gaat om een verandering in de organisatie die goed te definiëren en te beheersen is, dan nog zijn er andere parallelle veranderingsprocessen die zich niet storen aan de regels van projectmanagement. Vaak gaat het om machtsstrijd, relaties tussen mensen, competenties en het leereffect binnen de organisatie. Die effecten kunnen positief of negatief zijn. De projectmanager zal ze moeten onderkennen en hanteren en beïnvloeden. Het succes van een Service Management project is daarmee afhankelijk van de ervaring en talenten van de projectmanager op dit gebied. Bij projecten met een fpfdfr-karakter zijn twee zaken altijd essentieel: Risicomanagement Perceptiemanagement Hierbij gaan we ervan uit dat projecten complex zijn door onvoorspelbare invloeden van buiten. Dit betekent dat er niet alleen planmatig moet worden gewerkt (methode, discipline, management, e.d.) maar ook improviserend (beïnvloeden, overtuigen, escaleren, e.d.). Risicomanagement moet ervoor zorgen dat de resources van het project zoveel mogelijk worden geconcentreerd op die zaken (specificaties) die de tevredenheid van de klant bepalen. Daarnaast moet perceptiemanagement ervoor zorgen dat die tevredenheid niet te veel onder druk wordt gezet door mogelijke risico s op die zaken (specificaties) die er minder toe doen. Ook het contract is hierbij van wezenlijk belang. Wordt de projectmanager afgerekend op de letter van het contract of op de tevredenheid van de klant? De klant moet hier zowel gezien worden vanuit het perspectief van het bedrijf c.q. de business als vanuit het perspectief van de gebruiker. Het opdelen van projecten in overzichtelijke en beheersbare brokken is een beproefde methode waarin onder andere de projectmanagementmethode Prince2 voorziet. Zo wordt men gedwongen om de onderlinge samenhang tussen de brokken goed te definiëren. Voor alle betrokkenen levert dit grote voordelen op ten aanzien beheersing, bijsturing en rapportage. Niet iedere organisatie is toe aan projecten met een fpfdfr-karakter. Een scan op basis van het Capability Maturity Model biedt uitkomst. Er zijn op dit moment diverse CMM scans op de markt die zich richten op Projectmanagement of Service Management. Een daarvan is PM3 van Ordina. Het moge duidelijk zijn dat een organisatie waar geen afspraken gemaakt kunnen worden over bijvoorbeeld communicatie, kwaliteit en kosten, grote risico s in zich draagt op het gebied van projectmanagement. In termen

13 Besturen van IT-dienstverleners door de klant van PM3 levert niveau 3 pas een redelijke omgeving om projecten te kunnen managen: het projectmanagementproces is gestandaardiseerd en herhaalbaar en rollen zijn benoemd. Is de organisatie daar nog niet aan toe, dan zullen vooral problemen op het gebied van onderlinge samenhang de organisatie parten spelen. Die samenhang is bij Service Management essentieel. Het streven zal zijn dat een organisatie voortdurend resultaten van z n projectmanagementactiviteit meet en daarvan leert (niveau s 4 en 5). Pas dan zal de afhankelijkheid van de individuele kwaliteiten van de projectmanager minder worden. Echter, de organisaties die daar aan toe zijn kennen wij niet of nauwelijks. Het blijkt dat analyses en hier gegeven handreikingen rond risico s op het gebied van tijd, geld en resultaat niet alleen voor projecten gelden. Ook bij het sluiten van een service contract gelden afwegingen van risicomanagement, perceptiemanagement, opdelen en volwassenheid van de organisatie. Het is - gezien de markomstandigheden - noodzakelijk voor Service Managers om balls te tonen en met hun klant te praten in termen van fpfdfr: fixed price, fixed date en fixed result. Maar dan wel op een manier waar de klant werkelijk baat bij heeft. model). In: J van Bon (ed.), The Guide to IT Service Management Volume I. London UK: Addison-Wesley, Niessink, Frank (in ontwikkeling). IT Service Capability Maturity Model. Utrecht: Software Engineering Research Centre, Ordina Finance Consulting. Projectmanagement Maturity Model Poppendieck, Tom. The Agile Customer s Toolkit. Poppendieck LLC 2003, Project Management Body of Knowledge is een algemeen aanvaarde standaard die een groot aantal best practices bevat, zie Schneider, Benjamin and David E. Bowen. Winning The Service Game. Boston USA: Harvard Business School Press, DANKWOORD Met dank aan Jack Gijsbert, consultant bij Ordina LITERATUUR EN NOTEN Caluwé, Léon de, en Hans Vermaak. Leren veranderen, een handboek voor de veranderkundige. Alphen aan den Rijn: Samson, Smit, Herman de. Veranderstrategieën toegepast in de IT Service Management praktijk. In: IT Beheer Jaarboek 2002 (pag ). Den Haag: Ten Hagen Stam, Haagsma, Dick. Sturen op afspraken. In: J. van Bon (ed.), IT Beheer Jaarboek 2002 (pag ). Den Haag: Ten Hagen Stam, Meesters, Barry J.M.A. and Jan F. Bouman. Beauty is in the eye of the beholder (A Service Management polder IT Service Management, best practices

14