rtikel Risico s van IT-outsourcingprojecten beperken met Transition Realtime IT-auditing De harde en zachte kant van een transitie IT-outsourcingprojecten verlopen lang niet altijd zoals gewenst. Onderzoek en publicaties tonen aan dat veel van deze projecten uiteindelijk tot een onbevredigende situatie leiden voor de betrokkenen. Een reguliere IT-audit stelt de oorzaken voor het niet-slagen van een IT-outsourcingproject achteraf vast. Doch het kwaad is dan geschied en (bijna) alle projectkosten zijn dan al gemaakt. Transition Realtime IT-auditing is een vorm van IT-auditing die het verloop van de transitiefase van een IT-outsourcingproject realtime toetst. Deze toetsing richt zich op zowel de harde kant als de zachte, meer menselijke, kant van het project. Hierdoor is het mogelijk om direct bij te sturen wanneer risico s dreigen te ontstaan. Risico s worden meteen weer teruggebracht tot een acceptabel niveau, waardoor de slaagkans van het project vergroot. Dit artikel legt aan de hand van een praktijksituatie uit wat een IT-outsourcingproject is en uit welke fasen dit project bestaat. Hierbij wordt ingezoomd op de transitiefase. Daarna volgt een beschrijving van wat Transition Realtime IT-auditing is en welke rol de IT-auditor hierbij speelt. Vervolgens komt aan de orde hoe het normenkader voor de harde en zachte kant van de transitiefase is bepaald en hoe de IT-auditor over de risico s rapporteert. fgesloten wordt met een conclusie. Een IT-outsourcingproject Het hierna beschreven IT-outsourcingproject handelt over een praktijkvoorbeeld rond het uitbesteden van IT-diensten op het gebied van: Het beheer van 2.200 P s & laptops. Het beheer van 8 servers voor bestand- en printerbeheer verdeeld over 8 locaties (kantoor- en productievestigingen). Helpdesk en werkplekondersteuning en de bijbehorende processen incident management, problem management en change management. Hierbij gaat het om outsourcing van IT-diensten van een interne IT-organisatie naar een externe IT-dienstenaanbieder. Dit project was onderdeel van een wereldwijde implementatie van een IT-outsourcingcontract. L. (Leon) Dohmen RI is senior IT Management onsultant bij LogicaMG en docent Management of Technology voor M en Master studenten aan de Rotterdam usiness School. Leon heeft veel ervaring op het gebied van organisatieveranderingen en de invloed van IT hierbij. Hij heeft hierover verschillende artikelen gepubliceerd. Figuur 1 onderscheidt vier fasen binnen IT-outsourcing. Tijdens de Initiation en de Negotiationfase worden de externe IT-dienstenaanbieder (leverancier) gekozen en het contract opgesteld. Onderdeel van het contract is het Service Level greement (SL) waarin de uit te besteden IT-diensten en overeengekomen kwaliteitsniveaus beschreven zijn. De Transitionfase (transitiefase) regelt de feitelijke overdracht van de uit te besteden IT-diensten naar Operations. De activiteiten binnen de transitiefase worden in projectverband uitgevoerd. Daar waar dit artikel spreekt over een IToutsourcingproject worden hiermee de activiteiten in de transitiefase bedoeld. De transitiefase Zoals gezegd regelt de transitiefase de voorbereiding en feitelijke overdracht van de uit te besteden IT-diensten. Volgens figuur 1 levert de transitiefase het operationele beheermodel en de technische oplossing. Vragenlijsten 40 de EDP-uditor nummer 4 2006
Figuur 1: Fasen in IT-outsourcing (bron: Halfhide 2004) zorgen voor het verzamelen van relevante gegevens van ITbeleidsrichtlijnen, IT-standaards, vestigingsspecifieke zaken zoals veiligheidsinstructies op productielocaties, gebruikers en vestigingen, gegevens van P s en servers, gegevens van processen, organisatiestructuren en overlegstructuren. Onder andere de MD (onfiguratie Management Data- ase) is een belangrijke gegevensbron voor het achterhalen van gegevens. Een analyse van de verzamelde gegevens brengt tekortkomingen in het operationele beheermodel en de technische oplossing in kaart. Tekortkomingen zijn van invloed op de kwaliteit van de uit te besteden IT-diensten. fhankelijk van de ernst van deze tekortkomingen worden deze voor het moment van overdracht opgelost of wanneer de tekortkomingen minder kritisch zijn, nadat de overdracht van ITdiensten heeft plaatsgevonden. De volgende stap in de transitiefase is de feitelijke overdracht van de uit te besteden IT-diensten. Een van de belangrijke succesfactoren in deze fase is de kennisoverdracht van de interne IT-organisatie naar de externe IT-dienstenaanbieder. De basis voor deze kennisoverdracht is eerder gelegd bij het verzamelen en overdragen van gegevens. In de praktijk wordt hier vaak te simpel over gedacht. Kennis opbouwen over de inhoud van IT-diensten maar ook over de processen waarmee deze IT-diensten geleverd worden, kost leertijd. Gedurende de overdracht is samenwerking tussen de interne IT-organisatie en de externe IT-dienstenaanbieder erg belangrijk om de overdracht soepel te laten verlopen. Een document waarin taken, bevoegdheden en verantwoordelijkheden gedurende de overdrachtsperiode zijn beschreven is hierbij behulpzaam. Het formeel maken van de overdracht van de uit te besteden IT-diensten gebeurt met behulp van acceptatiecriteria en een acceptatierapport. Dit acceptatierapport bekrachtigt de overdracht naar de Operationsfase volgens figuur 1. Een projectmanager leidt de transitiefase. De projectmanager is verantwoordelijk voor planning, kwaliteit en overdracht van de uit te besteden IT-diensten. Gangbare instrumenten voor de projectmanager zijn producten beheerplan, activiteitenplanning, resourceplanning en voortgangsrapportages over het verloop van de transitiefase. De projectmanager beschikt over een team van transitiemedewerkers die de noodzakelijke transitiewerkzaamheden in de verschillende deelfasen uitvoeren en ondersteunen. Transition Realtime IT-auditing Een reguliere IT-audit die de haalbaarheid van een IT-outsourcingproject tijdens de Initiation en Negotiationfase toetst is zeker waardevol, doch dit is een momentopname, voorafgaand aan de transitiefase. Een transitie voor het uitbesteden van het beheer van 2.200 werkplekken, 8 servers, helpdesk en werkplekondersteuning zoals deze eerder is beschreven, heeft al snel een doorlooptijd van 20 tot 24 weken. In deze periode kan er veel veranderen ten op - zichte van de IT-audit uit de Initiation en Negotiationfase. Daarom is het van belang een IT-auditor gedurende de gehele transitiefase continu het ontstaan van risico s te laten toetsen en wanneer deze risico s zich voordoen ze zo snel mogelijk weer terug te brengen tot een acceptabel niveau. Om risico s continu te toetsen is de IT-auditor regelmatig aanwezig bij reguliere projectmeetings, interviewt hij sleutelfunctionarissen uit het project en praat hij met management en medewerkers die het projectresultaat accepteren. Verder beoordeelt hij projectinstrumenten, documenten en voortgangsrapportages. Zo heeft de IT-auditor voortdurend een beeld van het verloop en de risico s van het project en rapporteert hier over. Deze activiteiten vallen onder de noemer van Transition Realtime IT-auditing. Transition Realtime IT-auditing beperkt daarmee het risico op verlies van projectinvesteringen. 41 de EDP-uditor nummer 4 2006
Een normenkader voor Transition Realtime IT-auditing Eén van de instrumenten bij Transition Realtime IT-auditing is de knelpuntenanalyse 1. Knelpunten zijn (beïnvloedbare) factoren die alleen of in combinatie doorslaggevend zijn voor het falen van een IT-outsourcingproject. Een knelpuntenanalyse is een periodieke inventarisatie en analyse van mogelijke knelpunten van een IT-outsourcingproject met als doel om inzicht te krijgen in de mogelijke risico s en de daartegen te nemen maatregelen. De knelpuntenanalyse kent vijf risicocategorieën: Financieel; Planning; Technische kwaliteit; & motivatie; Technologie. Tabel 1 toont per aandachtsgebied en risicocategorie voorbeelden van knelpunten die kunnen leiden tot belangrijke risico s. Om het gevaar van blinde vlekken te voorkomen onderscheidt de knelpuntenanalyse twaalf aandachtsgebie- RISIO TEGORIEËN NDHTSGEIEDEN Financieel Planning Technische Kwaliteit 1. Projectdoelstellingen Onvoldoende inzicht in de kosten en baten van een project Prioriteit van het project is onbekend Vage formulering van projectdoelen en motivatie Gebruikers hebben geen goed beeld van de baten van een project Technologie Slechte koppeling met het beleid inzake (toekomstige) infrastructuur 2. Projectresultaten Onvoldoende inzicht in (en bewaking van) de kosten en baten van de verschillende delen cq. functies van het projectresultaat Geen inzicht in (optimale) benodigde tijd en capaciteit voor het bereiken van het projectresultaat Slechte specificatie functioneel en kwalitatief van projectresultaten Ontbreken totaalbeeld bij gebruikers Onduidelijke koppeling tussen het projectresultaat (wat) en de projectdoelen (waarom) Eisen inzake infrastructuur zijn onbekend 3. Projectomgeving Onduidelijke randvoorwaarden Geen analyse en acceptatie van startcondities Onvoldoende ruimte voor effectieve kwaliteitscontrole eperkingen t.a.v. gebruikers die in het project kunnen en mogen participeren Geen analyse van de technologische beperkingen 4. Projectorganisatie Slechte afbakening van verantwoordelijkheden Onvoldoende afstemming en geen afspraken over periodieke rapportage Geen scheiding tussen ontwikkeling en controle (functie kwaliteitsbeheersing) Onvoldoende aandacht voor een adequate participatie fstemming met leveranciers onvoldoende geregeld 5. Projectbemanning Te hoge personeelskosten Kwalitatief en of kwantitatief onvoldoende personeel Onvoldoende kennis en ervaring inzake probleemgebied Geen opleiding participerende gebruikers Te laag kennis en ervaringsniveau m.b.t. technologie 6. Projectmethode Dogmatische aanpak Onvoldoende adequate planning en voortgangsrapportage Verificatie en validatie onvoldoende gepland Geen acceptatie van gekozen aanpak door gebruikers, ongestructureerde kennisvergaring Onvoldoende gebruik van geautomatiseerde hulpmiddelen Projectbeheersing 7. eheersing budget Geen inzicht in de status van het project in relatie tot de begroting 8. eheersing voortgang Geen regelmatige controle op de voortgang van het project. Onvoldoende aandacht voor potentiële verstoringen van de voortgang 9. eheersing kwaliteit Dogmatische aanpak. Slechte standaarden en richtlijnen. Procedures niet vastgelegd en geen controle op naleving ervan. 10. eheersing communicatie Onduidelijkheid over communicatielijnen (distributie van besprekingsverslagen en mijlpaalproducten) 11. eheersing hulpmiddelen Onvoldoende aandacht voor het tijdig beschikbaar zijn van infrastructurele voorzieningen 12. eheersing bedreigingen Geen open communicatie over twijfels van gesignaleerde tekortkomingen Tabel 1: Voorbeeld van knelpunten per aandachtsgebied en risicocategorie (bron: zie voetnoot 1) 42 de EDP-uditor nummer 4 2006
herkennen die het karakter hebben van het beheersen van de lopende activiteiten binnen een IT-outsourcingproject. Het per aandachtsgebied zoeken naar knelpunten en deze categoriseren brengt structuur in de beoordeling van mogelijke risico s van een IT-outsourcingproject. Figuur 2: Harde en zachte kant van een organisatieverandering (ron: Rotterdam usiness School 2 ) den waarbij de eerste drie zich richten op de relatie tussen het IT-outsourcingproject en de omgeving. De aandachtsgebieden vier tot en met zes hebben betrekking op de opzet en inrichting van het project. In de groep projectbeheersing, de aandachtsgebieden zeven tot en met twaalf, zijn de meer klassieke aandachtsgebieden van projectmanagement te De harde en zachte kant van een IT-outsourcingproject Een IT-outsourcingproject dat de overdracht van IT-diensten regelt van de interne IT-organisatie naar een externe IT-dienstenaanbieder moet gezien worden als een organisatieverandering. Een formelere werkwijze, anders werkende processen, de grotere afstand tussen de helpdesk en de gebruikers zijn kenmerken die deze verandering typeren. Figuur 2 maakt duidelijk wat het verschil is tussen de harde en zachte kant van een organisatieverandering. De knelpuntenanalyse richt zich vooral op de harde kant van een IT-outsourcingproject. Deze harde kant betreft processen, (meet)instrumenten, tooling, structuren en procedures die nodig zijn om de transitie te ondersteunen. De zachte kant komt in de knelpuntenanalyse beperkt aan de orde in de risicocategorie organisatie, acceptatie. Maar IT-outsourcingprojecten gaan niet alleen fout door oorzaken aan de harde kant. Weerstand tegen verandering, zelfleiderschap, attitude en betrokkenheid zitten vooral verborgen in de zachte kant van een IT-outsourcingproject. Doelvariabele Structuur Proces (Informatie) systemen ultuur ompetenties Definitie Delen van een organisatie en de relatie tussen deze delen (Een herhaling van) activiteiten Geautomatiseerde regels en procedures Gedrag van mensen in een organisatie Karakteristiek (gewenst) gedrag dat leidt tot effectieve of excellente prestaties Tabel 2: Veranderdoelen en definities PPROH HRTERISTI Tell & sell (Rooddruk) Directing (lauwdruk) Developing (Groendruk) Negotiating (Geeldruk) The success of project depends on onvincing and stimulating people Key people who make plans reate settings for (collective) learning ringing people with common interests together hange process Prescriptive (push) Planned (pull), rational Learning process Power game Interventions Judging, rewarding, social meetings Structured working (within projects), Strategic analysis Discussions, coaching, training Making coalitions Focus on Procedures and atmosphere Measuring is knowing Role type change leader HRM-expert ontent expert uilding and maintaining a learning culture Process manager supporting people feasible solution Process manager using power Project result was Foreseen but not guaranteed Described, predictable and guaranteed Envisioned, not guaranteed Partially unknown, shifting Tabel 3: veranderaanpakken en hun karakteristieken 43 de EDP-uditor nummer 4 2006
Nr. andachtsgebied Risico categorie Risico (knelpunt) Impact Probability 1 Projectdoelstelling Financieel Onvoldoende inzicht in de kosten en baten 2 Projectdoelstelling Planning Prioriteit van het project is onbekend 3 Projectdoelstelling Technische kwaliteit Vage formulering van projectdoelen 3 3 4 Projectdoelstelling Gebruikers hebben geen goed beeld van de baten 5 Projectdoelstelling Technologie Slechte koppeling van het beleid inzake (toekomstige) infrastructuur 6 Projectresultaat Financieel Onvoldoende inzicht in (en bewaking van) de kosten en baten van de verschillende delen cq. functies van het projectresultaat 7 Projectresultaat Planning Geen inzicht in (optimale) benodigde tijd en capaciteit voor het bereiken van het projectresultaat 2 2 8 Projectresultaat Technische kwaliteit Slechte specificatie functioneel en kwalitatief van projectresultaten 3 3 9 Projectresultaat Ontbreken totaalbeeld bij gebruikers 2 2 10 Projectresultaat Technologie Eisen inzake infrastructuur zijn onbekend 11 Projectomgeving Financieel Onduidelijke randvoorwaarden 12 Projectomgeving Planning Geen analyse en acceptatie van startcondities 13 Projectomgeving Technische kwaliteit Onvoldoende ruimte voor effectieve kwaliteitscontrole 14 Projectomgeving eperkingen t.a.v. gebruikers die in het project kunnen en mogen participeren 1 2 15 Projectomgeving Technologie Geen analyse van de technologische beperkingen 16 Projectorganisatie Financieel Slechte afbakening van verantwoordelijkheden 17 Projectorganisatie Planning Onvoldoende afstemming en geen afspraken over periodieke rapportage 18 Projectorganisatie Technische kwaliteit Geen scheiding tussen ontwikkeling en controle (functie kwaliteitsbeheersing) 19 Projectorganisatie Onvoldoende aandacht voor een adequate participatie 20 Projectorganisatie Technologie fstemming met leveranciers onvoldoende geregeld 21 Projectbemanning Financieel Te hoge personeelskosten 22 Projectbemanning Planning Kwalitatief en of kwantitatief onvoldoende personeel 23 Projectbemanning Technische kwaliteit Onvoldoende kennis en ervaring inzake probleemgebied 3 3 24 Projectbemanning Geen opleiding participerende gebruikers 25 Projectbemanning Technologie Te laag kennis en ervaringsniveau m.b.t. technologie 26 Projectmethode Financieel Dogmatische aanpak 27 Projectmethode Planning Onvoldoende adequate planning en voortgangsrapportage 28 Projectmethode Technische kwaliteit Verificatie en validatie onvoldoende gepland 29 Projectmethode Geen acceptatie van gekozen aanpak door gebruikers, ongestructureerde kennisvergaring 3 2 30 Projectmethode Technologie Onvoldoende gebruik van geautomatiseerde hulpmiddelen 31 Projectbeheersing eheersing budget Geen inzicht in de status van het project in relatie tot de begroting 32 Projectbeheersing eheersing voortgang Geen regelmatige controle op de voortgang van het project. Onvoldoende aandacht voor potentiële verstoringen van de voortgang 2 2 33 Projectbeheersing eheersing kwaliteit 34 Projectbeheersing 35 Projectbeheersing 36 Projectbeheersing eheersing communicatie eheersing hulpmiddelen eheersing bedreigingen Dogmatische aanpak. Slechte standaarden en richtlijnen. Procedures niet vastgelegd en geen controle op naleving ervan. Onduidelijkheid over communicatielijnen (distributie van besprekingsverslagen en mijlpaalproducten) Onvoldoende aandacht voor het tijdig beschikbaar zijn van infrastructurele voorzieningen Geen open communicatie over twijfels van gesignaleerde tekortkomingen Tabel 4a: Risicoregister voor de risicobeheersing van de harde kant van een IT-outsourcingproject 44 de EDP-uditor nummer 4 2006
Risico factor evindingen risico (knelpunt) Risicobeperkende maatregel Het is niet duidelijk welk doel wordt nagestreefd. etrokkenen in het project hebben het gevoel doelloos bezig te zijn. Formuleer duidelijke en concrete projectdoelen en communiceer deze. Projectplanning is een verzameling van losse acties waarbij de samenhang en logica van de acties moeilijk te begrijpen is. Niet duidelijk is welk resultaat wordt nagestreefd en aan welke kwaliteitseisen dit resultaat moet voldoen. Gebruikers snappen niet waar het project voor is, wat het vertrekpunt is en wat de bestemming moet zijn. Gebruikers vinden dat er muren zijn om het project en dat ze niet de kans krijgen om mee te mogen doen. reng overzicht en samenhang aan in noodzakelijke acties en schat de benodigde tijd in. Leg een duidelijke relatie tussen uit te voeren acties en het te behalen projectresultaat. Definieer het te behalen projectresultaat concreet en helder. Stel kwaliteitsnormen op waar het projectresultaat aan dient te voldoen. Stel een communicatieplan op hoe gebruikers geïnformeerd worden over het project en voer dit plan ook uit. Maak het project toegankelijk voor de gebruikers. Stimuleer en faciliteer een actieve bijdrage. Sommige betrokken sleutelfiguren zijn extern ingehuurd of komen van een andere afdeling. Hierdoor hebben ze niet de benodigde kennis om hun rol in te vullen. Train de betreffende projectmedewerker(s) of stel (een) nieuwe projectmedewerker(s) aan. Gebruikers vinden dat er teveel wordt gepusht en dat er te weinig rekening wordt gehouden met omstandigheden. Geen periodiek overleg over voortgang en ook is de voortgangsrapportage niet juist en compleet. Stem af over de gewenste aanpak en leg uit waarom deze eventueel anders is dan dat wat de gebruikers wensen. Stel eventueel de aanpak bij. Zorg voor structurele voortgangscontrole door bijv. het houden van een periodiek voortgangsoverleg. Zorg dat de voortgangsrapportage van een deugdelijke kwaliteit is. 45 de EDP-uditor nummer 4 2006
Nr. andachtsgebied Risico categorie Risico (knelpunt) Impact Probability 37 Developing change approach The succes of the project depends on No creation of settings for collective learning 3 3 38 Developing change approach hange process Hampering learning process 39 Developing change approach Interventions Wrong interventions. Not enough discussions, coaching, training 3 2 40 Developing change approach Focus on To less focus on building and maintaining a learning culture 41 Developing change approach Role type change leader Roletype not based on a process manager who is supporting people 3 3 42 Developing change approach Project result is The project resultshould be envisioned, not garanteed. The definition of the project result does not match the change approach. 43 Tell & sell change approach The succes of the project depends on To less attention for convincing and stimulating people 44 Tell & sell change approach hange process hange process is not prescriptive 45 Tell & sell change approach Interventions Wrong interventions. No judging, rewarding, social meetings 46 Tell & sell change approach Focus on To less focus on procedures and atmosphere 47 Tell & sell change approach Role type change leader Roletype not based on human resource manager expert 48 Tell & sell change approach Project result is The project result should be foreseen but not guaranteed. The definition of the project result does not match the change approach. Tabel 4b: Risicoregister voor de risicobeheersing van de zachte kant van een IT-outsourcingproject Een normenkader voor de zachte kant Deze zachte kant van een IT-outsourcingproject moet dus ook meetbaar worden gemaakt en in een normenkader worden uitgedrukt. Het artikel Wat is de beste veranderaanpak 3, legt uit hoe de best passende veranderaanpak voor een project wordt bepaald. De aanpak verdient afstemming op het veranderdoel. Het artikel onderkent vijf veranderdoelen (zie tabel 2). Er bestaat een sterk verband tussen het veranderdoel en de veranderaanpak. Tabel 3 onderscheidt een aantal veranderaanpakken. De kleuraanduiding van de verschillende veranderaanpakken refereert aan de kleurentheorie van Leon de aluwé 4. De aluwé hanteert bij zijn kleurentheorie voor organisatieveranderingen een palet van kleuren waarbij elke kleur een specifieke veranderaanpak voorstelt. Elke veranderaanpak kent zijn eigen karakteristieken. Een IT-outsourcingproject dat de overdracht van IT-diensten regelt van de interne IT-organisatie naar een externe IT-dienstenaanbieder, is een verandering waarbij vooral processen en cultuur veranderen. Zoals gezegd zijn een formelere werkwijze, anders werkende processen, de grotere afstand tussen de helpdesk en de gebruikers kenmerken voor het typeren van deze verandering. Volgens het artikel Wat is beste veranderaanpak 5 zijn de tell & sell en de developing aanpak de twee best passende veranderpakken voor het veranderen van processen en cultuur. De tell & sell aanpak stelt belonen centraal terwijl de developing aanpak het leerproces koestert. De gekozen veranderaanpak voor een IT-outsourcingproject zoals in dit artikel beschreven, dient dan ook vooral karakteristieken te vertonen van de tell & sell en de developing veranderaanpak. Veel voorkomende interventievormen zijn dus oordelen, belonen en sociale bijeenkomsten voor de tell & sell aanpak. ij de developing aanpak zijn dit interventievormen zoals discussiëren, coachen en trainen. De karakteristieken van de tell & sell en de developing veranderaanpak uit tabel 3 vormen het normenkader voor de zachte kant van een IT-outsourcingproject. Met de knelpuntenanalyse als normenkader voor de harde kant en de karakteristieken van de tell & sell en developing veranderaanpak als normenkader voor de zachte kant beschikt de IT-auditor over een complete set met normen voor het beheersen van de risico s van een IT-outsourcingproject. De Transition Realtime IT-auditing rapportage In tabel 4a en b zijn de normen voor het meten van de risico s van de harde en zachte kant van het beschreven IToutsourcingproject verwerkt tot een risicoregister. Naast de 46 de EDP-uditor nummer 4 2006
Risico factor evindingen risico (knelpunt) Risicobeperkende maatregel Mensen vinden dat ze geen tijd wordt geboden om te wennen aan de nieuwe situatie en dat ze ook geen tijd krijgen om zich de nieuwe dingen eigen te maken. Mensen vinden dat ze geen tijd krijgen om te wennen aan de nieuwe situatie en dat ze ook geen tijd krijgen om zich de nieuwe dingen eigen te maken. Ze moeten alles zelf uitzoeken. Mogelijkheden om te praten over de nieuwe situatie worden niet geboden en begeleiding is er niet of onvoldoende. De projectmanager roept alleen maar dat er achterstand is op de projectplanning. Projectmedewerkers geven aan dat ze niet goed begrijpen wat hun bijdrage moet zijn. reëer een interventiestructuur waarbinnen collectief leren wordt mogelijk gemaakt. Zorg ervoor dat dit ook zo wordt uitgevoerd. reëer een interventiestructuur waarbinnen collectief leren wordt mogelijk gemaakt. Zorg ervoor dat dit ook zo wordt uitgevoerd. egeleid of coach de projectmanager bij het hanteren van een meer participatieve stijl van transitiemanagement of stel een nieuwe projectmanager aan. elementen aandachtsgebied, risicocategorie en risico die structuur geven en de risico s beschrijven, bevat het register ook de elementen impact en probability (mogelijkheid van optreden). Impact en probability zijn in cijfers 1 (hoog), 2 (medium) en 3 (laag) uitgedrukt. Vermenigvuldiging van de cijfers van de impact en probability levert een risicofactor op. -risico s - de risicofactor is > 6 - zijn risico s van de hoogste categorie terwijl -risico s - risicofactor is < 4 - risico s van de laagste categorie zijn. Het rapportagevoorbeeld volgens tabel 4a en b is een momentopname tijdens de transitiefase van het IT-outsourcingproject waaraan wordt gerefereerd in dit artikel. Risico s 1 tot en met 36 komen voort uit de knelpuntenanalyse. Risico s 37 tot en met 48 zijn afgeleid van de karakteristieken van de developing en tell & sell veranderaanpak uit tabel 3. De kolom bevindingen geeft de risico s weer en de kolom risicobeperkende maatregel de uit te voeren corrigerende acties. het project in kaart. Hierdoor is het mogelijk om bij te sturen met risicobeperkende maatregelen en risico s terug te brengen tot een acceptabel niveau. Hiermee vergroot men de slaagkans van het IT-outsourcingproject. Noten 1 Swinkels G.J.P. en Gielen L.J.M.W. Knelpuntenanalyse projectmanagement: Handboek EDP-auditing. 2 Rotterdam usiness School: module Management of Technology voor M en Master studenten. 3 Reitsma E, Jansen P, Van der Werf E, Van den Steenhoven H. Wat is de beste veranderaanpak: Management Executive, juli / augustus 2004. 4 aluwé L. de & Vermaak H. (2003). Leren veranderen. lphen a/d Rijn: Kluwer. 5 Zie voetnoot 3 onclusie Een IT-outsourcingproject kent vele risico s en levert dan ook lang niet altijd het gewenste resultaat. Met een Transition Realtime IT-audit brengt de IT-auditor zowel de risico s van de harde als de zachte kant van de transitiefase van Reacties op het artikel zijn welkom via leon.dohmen@logicacmg.com. 47 de EDP-uditor nummer 4 2006