Een automatiseringsproject, een kwestie van alleen een systeem plaatsen? Organisatie
Projectmanagement
Procesmanagement
Waarom de organisatie, projectmanagement en procesmanagement een belangrijke rol spelen.
2
Naam student : Wendy Kiel Opleiding
: Master of Crisis and Disaster Management (MCDM)
Begeleider
: Marc Otten
Datum
: mei 2010
3
Voorwoord Deze scriptie is geschreven in het kader van de opleiding Master of Crisis and Disaster Management (MCDM). Bij het bepalen van het onderwerp heb ik mij laten leiden door mijn huidige werkzaamheden als Programmamanager Informatiemanagement bij Brandweer Amsterdam-Amstelland. Informatiemanagement is een nieuw vakgebied voor mij waar ik het nodige over wilde leren. Dit heeft er toe geleid dat ik mezelf de vraag stelde: ‘Wat moet je doen om van een automatiseringsproject een succes te maken?’
Toen ik aan mijn scriptie begon had ik niet kunnen vermoeden hoe leerzaam dit traject zou worden. Enerzijds leerzaam vanwege de verdieping in de theorie en de gesprekken met mijn begeleider Marc Otten en met collega’s, anderzijds leerzaam vanwege de zelfreflectie die tegelijkertijd plaatsvond. Gedurende het schrijven van mijn scriptie was ik binnen mijn eigen organisatie bezig met de implementatie van het systeem AG5 (gericht op incidentregistratie en oefenregistratie) en dan kan de ontdekkingstocht naar succesfactoren van automatiseringsprojecten erg confronterend zijn. Ondanks deze confrontatie heb ik geprobeerd om open te staan voor alle ontwikkelpunten en waar mogelijk deze gelijk toe te passen in de praktijk (zo heb ik me voorgenomen om in ieder geval nooit meer een project te starten, voordat geheel duidelijk is wie mijn opdrachtgever is).
De literatuurstudie en gesprekken hebben er uiteindelijk toe geleid dat ik een beter zicht heb gekregen op de componenten die spelen bij het succesvol neerzetten van een project. Gevoelsmatig vond ik het ‘alleen’ toepassen van een projectmanagementmethodiek altijd al te mager. Dit gevoel is bevestigd door de eindconclusie dat je de driehoek van verbondenheid nodig hebt (oftewel de combinatie van de componenten: organisatie, projectmanagement en procesmanagement).
Het schrijven van de scriptie was een leuke en boeiende zoektocht. Ik wil een ieder graag meenemen op mijn zoektocht naar de succesfactoren van automatiseringsprojecten en veel leesplezier toewensen, maar niet voordat ik een aantal personen bedankt heb.
Mijn dank gaat uit naar: -
mijn begeleider Marc Otten; bedankt voor de inspirerende gesprekken en verkenningen;
-
mijn werkgever Brandweer Amsterdam-Amstelland; bedankt voor de kans om deel te nemen aan de MCDM;
-
Luud Verheijen en Désirée Bolsius; bedankt voor het delen van jullie ervaringen met automatiseringsprojecten;
4 -
Annemijn Poot en Bart van Leeuwen; bedankt voor de inspirerende gesprekken over informatiemanagement en verandermanagement;
-
mijn ouders Ab en Trijnie en mijn vriend Ilan; voor de steun en ruimte die ze me hebben gegeven om aan deze scriptie te werken;
-
mijn vrienden die het woord scriptie vast niet meer kunnen horen.
Wendy Kiel (Amsterdam, mei 2010)
Samenvatting
Samenvatting In deze scriptie staat de volgende probleemstelling centraal:
‘Waarom slagen sommige automatiseringsprojecten wel en andere niet; wat zijn de succesfactoren en hoe breng je deze in de praktijk?’
Onder automatiseringsproject wordt verstaan: het proces waarbij een geautomatiseerd systeem tot stand wordt gebracht c.q. wordt aangeschaft en geïmplementeerd in de organisatie. Rekening houdend met de impact op de strategie, processen, taken en gebruikers van de desbetreffende organisatie. Een succesvol automatiseringsproject is vervolgens een project dat: vanuit de invalshoek van de opdrachtgever en gebruiker voldoet aan de verwachtingen en is afgerond binnen de tijd en het budget. (Kritieke) Succesfactoren zijn ten slotte factoren die beslissend zijn voor het al dan niet behalen van een vooraf gesteld doel.
Op basis van de theorie en casus wordt geconcludeerd dat de componenten: organisatie, projectmanagement en procesmanagement gezamenlijk moeten worden toegepast om van een automatiseringsproject een succes te maken. Deze samenhang komt tot uitdrukking in de driehoek van verbondenheid:
Organisatie
Driehoek van Verbondenheid
Projectmanagement
Procesmanagement
Figuur 1 Driehoek van Verbondenheid (Kiel 2010, gebaseerd op ‘Duivelsdriehoek van Noordam)
5
Samenvatting
Organisatie; het automatiseringsproject moet aansluiten bij de strategie, processen en/of taken van de organisatie. Het moet een bijdrage leveren aan (het verbeteren) van de doelstellingen van de organisatie c.q. het eenvoudiger maken van de werkzaamheden.
Projectmanagement; deze component geeft invulling aan de projectmatige aanpak die noodzakelijk is. De opdrachtgever die betrokken is, het toepassen van een projectmethodiek, de aanwezigheid van duidelijke doelstellingen, planning, sturing etc.
Procesmanagement; deze component geeft invulling aan het sociale aspect van een automatiseringsproject. Het tijdig betrekken van de gebruikers, rekening houdend met de cultuur van een organisatie, managen van verwachtingen etc.
Om te beoordelen of een project succesvol is en de factoren te onderkennen die van invloed zijn op een eventueel succes, kan een project op twee niveaus worden geanalyseerd: 1. de beheersfactoren; voldoet het project aan de gestelde beheerscomponenten tijd, geld en kwaliteit; 2. de succesfactoren; welke succesfactoren zijn aanwezig binnen het project. De succesfactoren worden – conform de driehoek der verbondenheid – onderverdeeld in de drie componenten: organisatie, projectmanagement en procesmanagement.
De succesfactoren voor automatiseringsprojecten zijn weergegeven in bijlage drie en worden bij het beoordelen van de projecten samengevat tot de volgende punten:
Organisatie: o het systeem wordt als beter beschouwd dan de praktijk die het moet vervangen; o het systeem sluit goed aan bij de uit te voeren taken/werkprocessen; o het systeem is eenvoudig te begrijpen en niet ingewikkeld in het gebruik; o het systeem is beschikbaar en betrouwbaar.
Projectmanagement: o er wordt een projectmethodiek toegepast; o de opdrachtgever is betrokken bij het project (ziet het belang van het project); o er is een duidelijke opdrachtnemer die de touwtjes in handen heeft (die zorgt voor sturing); o doelstellingen en opdracht zijn duidelijk en bekend; o er is een planning met mijlpalen; o taken, verantwoordelijkheden en bevoegdheden van betrokken actoren zijn bekend; o er is sprake van een goede communicatie over: de werking, het doel en de voortgang;
6
Samenvatting o er is voldoende en juiste capaciteit beschikbaar voor het project; o er vindt één verandering tegelijkertijd plaats in de organisatie (de verschillende projecten zijn op elkaar afgestemd).
Procesmanagement o gebruikers zijn tijdig bij het project betrokken; o gebruikers zijn voldoende en gestructureerd bij het project betrokken; o de gebruiker heeft invloed gehad op het proces; o de gebruikers zijn goed opgeleid voor het systeem; o de verwachtingen zijn bij alle betrokkenen goed gemanaged; o er is voldoende ruimte/tijd voor: gewenning, het testen van het systeem, bijsturingmogelijkheden tijdens de rit (goede voorbereiding en begeleiding); o wilskracht, vertrouwen, openheid, eerlijkheid, respect zijn centrale waarden binnen het project.
De belangrijkste conclusies zijn:
Een automatiseringsproject is meer dan alleen het ‘neerzetten van een systeem’; het is altijd belangrijk om invulling te geven aan de drie componenten: organisatie, projectmanagement en procesmanagement.
Om de kans op projectsucces te vergroten moet je investeren in de driehoek van verbondenheid.
‘Projectenwerk blijft mensenwerk’; je hebt betrokken en enthousiaste medewerkers nodig die van het project een succes willen maken.
Aanbevelingen:
Leid de projectleiders in de organisatie op conform het principe van de driehoek van verbondenheid (dus niet alleen opleiden in het toepassen van een projectmanagementmethodiek).
Stuur als opdrachtgever/manager op de drie componenten (sluit het doel van het project aan bij de werkzaamheden/processen van de organisatie, wordt een juiste projectmanagementmethodiek toegepast en wordt er aandacht besteed aan procesmanagement), dit kan middels het toepassen van de checklist succesfactoren.
Zet de juiste medewerkers (ervaring en motivatie) in op een project (niet iedere medewerker is geschikt voor projectmatig werken).
7
Inhoudsopgave
Inhoudsopgave Voorwoord .............................................................................................................................................. 3 Samenvatting........................................................................................................................................... 5 Inhoudsopgave ........................................................................................................................................ 8 Inleiding ................................................................................................................................................. 10 Deel I
Het theoretisch kader ........................................................................................................... 12
Hoofdstuk 1
Wat is een automatiseringsproject ............................................................................... 13
1.1
Automatiseringsproject ......................................................................................................... 13
1.2
Definitiebepaling ................................................................................................................... 16
Hoofdstuk 2
Bredere kijk op een project ....................................................................................... 17
2.1
Projectmanagement op basis van Prince2 ............................................................................ 17
2.2.
Projectmanagement breder bekeken ................................................................................... 18
2.3.
Conclusie ............................................................................................................................... 22
Hoofdstuk 3
Theoretisch kader van project succes ........................................................................... 23
3.1
Het begrip succes .................................................................................................................. 23
3.2
Kritieke succesfactoren ......................................................................................................... 26
3.2.1
Positionering succesfactoren in het negenvlaksmodel ................................................. 27
3.2.2
De driehoek van verbondenheid ................................................................................... 30
Deel II
De praktijk ............................................................................................................................. 33
Hoofdstuk 4
Basisvoorziening Handhaving (BVH).............................................................................. 34
4.1 Het project Basisvoorziening Handhaving ................................................................................... 35 4.2 Succes en falen ............................................................................................................................ 37 4.3 Analyse ........................................................................................................................................ 45 4.4 Conclusie ..................................................................................................................................... 46 Hoofdstuk 5
C2000 ............................................................................................................................. 47
5.1 Het project C2000........................................................................................................................ 48 5.2 Succes en falen ............................................................................................................................ 50
8
Inhoudsopgave
5.3 Analyse ........................................................................................................................................ 57 5.4 Conclusie ..................................................................................................................................... 58 Hoofdstuk 6
De Virtuele kijkdoos...................................................................................................... 60
6.1 Het project Virtuele kijkdoos ....................................................................................................... 61 6.2 Succes en falen ............................................................................................................................ 62 6.3 Analyse ........................................................................................................................................ 66 6.4 Conclusie ..................................................................................................................................... 66 Hoofdstuk 7
TIS totaal ....................................................................................................................... 67
7.1 Het project TIS totaal................................................................................................................... 67 7.2 Succes en falen ............................................................................................................................ 68 7.3 Analyse ........................................................................................................................................ 72 7.4 Conclusie ..................................................................................................................................... 73 Hoofdstuk 8
Conclusie casus .......................................................................................................... 74
Hoofdstuk 9
De brandweer en automatiseringsprojecten ................................................................ 78
9.1 Brandweer, de organisatie .......................................................................................................... 78 9.2 De brandweer en automatisering ............................................................................................... 80 9.3 Brandweer en project- en procesmanagement .......................................................................... 81 9.4 Conclusie ..................................................................................................................................... 82 Deel III
Conclusie en aanbevelingen .................................................................................................. 86
Hoofdstuk 10
Conclusie ................................................................................................................... 87
Hoofdstuk 11
Aanbevelingen ........................................................................................................... 93
Bijlagen .................................................................................................................................................. 94 Bijlage I
Literatuurlijst ................................................................................................................. 95
Bijlage II
Lijst met afkortingen ..................................................................................................... 98
Bijlage III
Succesfactoren van (ICT) projecten .............................................................................. 99
Bijlage IV
Vragenlijst interviews .................................................................................................. 105
9
Inleiding
Inleiding Aanleiding van het onderzoek Om de studie Master of Crisis and Disastermanagement (MCDM) af te ronden, moet onder andere een individuele scriptie worden geschreven. Bij de start van de opleiding is door de schrijver van deze scriptie de overstap gemaakt naar een nieuwe functie binnen de brandweer. Om zoveel mogelijk te leren over deze ‘nieuwe werkomgeving’ is ervoor gekozen om een scriptie te schrijven over de succesfactoren binnen automatiseringsprojecten.
Doel- en probleemstelling onderzoek
Doel onderzoek Ondanks het feit dat er in het verleden al veel kennis is verzameld over de succes- en faalfactoren van automatiseringsprojecten, leidt dit in de praktijk niet altijd tot de gewenste resultaten. Nog steeds verloopt de uitvoering van automatiseringsprojecten niet optimaal en zijn negatieve resultaten eerder regel dan uitzondering. Om hier op een positieve manier lering uit te trekken welke daadwerkelijk toepasbaar is in de praktijk, wordt gezocht naar de succesfactoren van automatiseringsprojecten en de mogelijkheden om deze ook daadwerkelijk toe te passen in de praktijk.
Gezien het feit dat de onderzoeksperiode voor deze scriptie vrij kort is, bestaat niet de verwachting dat er baanbrekend onderzoek wordt verricht. De doelgroep – voor wie dit onderzoek van belang kan zijn – zal vooral liggen binnen de eigen organisatie en voor de ervaring van de onderzoeker in het bijzonder. De relevantie van het onderzoek zal daartoe eerder praktisch dan theoretisch van aard zijn.
Uit deze doelstelling komt de volgende probleemstelling voort: ‘Waarom slagen sommige automatiseringsprojecten wel en andere niet; wat zijn de succesfactoren en hoe breng je deze in praktijk?’
Onderzoeksvragen Om een gedegen antwoord te kunnen geven op de geformuleerde probleemstelling, is de probleemstelling onderverdeeld in een aantal onderzoeksvragen. Door deze onderzoeksvragen te beantwoorden, ontstaat een beeld op basis waarvan de probleemstelling beantwoord kan worden.
10
Inleiding 1. Wat is een automatiseringsproject? 2. Wat is een succesfactor en welke succesfactoren worden in de theorie beschreven op het gebied van automatiseringsprojecten? 3. Welke automatiseringsprojecten zijn in de praktijk goed gegaan en waarom? 4. Welke discrepantie is zichtbaar tussen theorie (de kennis) en de praktijk (de daadwerkelijke toepassing)? 5. Hoe zorg je ervoor dat de theoretische kennis daadwerkelijk in de praktijk wordt toegepast?
Begrenzing van het onderzoek De nadruk van dit onderzoek ligt op het invoeren c.q. implementeren van een automatiseringsproject. Het daadwerkelijke ‘doen’. Dit betekent dat de focus niet ligt op ‘het systeem’, maar meer op de ‘sociaalorganisatorische’ aspecten van een automatiseringsproject.
Aanpak onderzoek Bij de dataverzameling voor dit onderzoek wordt gebruik gemaakt van twee methoden:
gebruik van bestaande gegevens;
interviews.
De deelvragen één t/m drie worden (grotendeels) beantwoord op basis van het gebruik van bestaande gegevens. Te denken valt hierbij aan bestaande literatuur, casus, maar ook artikelen en rapporten op internet. Voor het beantwoorden van vraag drie wordt tevens een aantal interviews gehouden om achter de succesfactoren van automatiseringsprojecten te komen (voor een overzicht van de vragen, zie bijlage vier). Op basis van de beantwoording van de deelvragen één t/m drie, worden de vragen vier en vijf beantwoord.
Leeswijzer Deze scriptie bestaat uit drie delen; deel I richt zich op het theoretisch kader van dit onderzoek, deel II behandelt ‘de praktijk’ (empirische deel) en in deel III worden conclusies getrokken en aanbevelingen gedaan.
11
Deel I
Deel I
Het theoretisch kader
Het theoretisch kader
In dit deel worden de begrippen ‘automatiseringsproject’, ‘project’ en ‘succes’ nader beschreven. Daarnaast wordt ingegaan op projectmanagement, een procesmatige benadering en succesfactoren.
12
Hoofdstuk 1
Hoofdstuk 1
Wat is een automatiseringsproject
Wat is een automatiseringsproject
In de vraagstelling van dit onderzoek staat het begrip ‘automatiseringsproject’ centraal. Dit hoofdstuk geeft weer wat hieronder wordt verstaan. De focus ligt op het begrip automatisering, in hoofdstuk twee zal specifiek worden ingegaan op het begrip project en de daarbij behorende kenmerken.
1.1
Automatiseringsproject 1
Beers geeft in zijn proefschrift de volgende beschrijving van het begrip automatiseringsproject: ‘Een automatiseringsproject betreft in het algemeen een eenmalige actie in een organisatie, vandaar dat het een project is. In een dergelijk project streeft men naar de ontwikkeling en invoering van een computersysteem. Zo is er steeds sprake van software (computerprogrammatuur) die moet worden ontwikkeld en geïnstalleerd op een stuk hardware; de computers met hierbij behorende apparatuur. In een automatiseringsproject gebeurt eigenlijk niets anders dan dat deze beide componenten worden klaargemaakt voor gebruik.’ Waar Beers sterk lijkt uit te gaan van het aspect project en dan met name de technische component, heeft Springer2 het over een proces. Hij beschrijft een automatiseringsproject als: ‘een complex besluitvormingsproces, waarbij verschillende participanten zijn betrokken. Een dergelijk proces kent diverse beslispunten, waar keuzen worden gemaakt die gevolgen hebben voor de inhoud van taken en de structuur van een organisatie. Een automatiseringsproject heeft tot doel een geautomatiseerd systeem tot stand te brengen en in te voeren in de organisatie. Een geautomatiseerd systeem is het met behulp van automatische stuur- en regelsystemen doen uitvoeren van verrichtingen in het kader van de bedrijfsvoering, administratie en productie van een bedrijf, zodat de gehele organisatie effectiever, betrouwbaarder en beter aanstuurbaar wordt en producten en diensten van hogere kwaliteit levert.’
De gehanteerde definities liggen niet op één lijn. Waar je uit de door Beers gehanteerde definitie kunt concluderen dat het om een eenvoudig traject gaat: er gebeurt eigenlijk niets anders dan de software en hardware klaar te maken voor gebruik, kan uit de definitie van Springer geconcludeerd worden dat het gaat om een complex besluitvormingsproces. Juist dit verschil in definitie van een 1
Beers, 1990, pagina 2;
2
Springer, 1989, pagina 20;
13
Hoofdstuk 1
Wat is een automatiseringsproject
automatiseringsproject, kan van invloed zijn op het succes van een automatiseringsproject. Iemand die een automatiseringsproject ziet als een eenvoudig traject en daarbij voorbij gaat aan het complexe besluitvormingsproces, zal hooguit de middelen inzetten die benodigd zijn voor een eenvoudig traject. Gezien het belang van het verschil in definitiebepaling, gaan we hier nog iets dieper op in. Engelenburg3 ondersteunt de procesmatige benadering van Springer door aan te geven dat: ´automatisering is geëvolueerd van een technisch specialisme naar informatisering: het met geautomatiseerde hulpmiddelen modelleren van organisaties.’ In hetzelfde boek bevestigd Risseeuws4 (president-directeur Gertronics) dit beeld: ‘automatiseren is nu informatiseren, het continu doorvoeren van wezenlijke veranderingen opdat de gehele organisatie effectiever, betrouwbaarder en beter aanstuurbaar wordt en producten en diensten van hogere kwaliteit levert.’ Bouwman e.a.5 omschrijven technologie ‘als een hulpmiddel dat het mogelijk maakt om zaken anders te organiseren, processen beter op elkaar af te stemmen, taken makkelijker uit te voeren.’ Ook zij onderkennen het feit dat het hier gaat om meer dan een technisch systeem en beschrijven dat ‘bij de invoering van nieuwe technologie binnen een organisatie de volgende processtappen spelen: 1. adoptie: de beslissing een toepassing te gaan gebruiken; 2. implementatie: de invoering van deze toepassing in de organisatie; 3. gebruik: het feitelijk gebruik van de toepassing; 4. effecten: de effecten op taakuitvoering en de strategische positionering van de organisatie.’
Uit de definities kun je concluderen dat het gaat om meer dan alleen “een systeem neerzetten”, het gaat om een proces dat invloed heeft op de taken, processen en positie van een organisatie. Qua impact kan onderscheid gemaakt worden in de mate waarop een automatiseringsproject de organisatie beïnvloedt. De invoering van een e-mailsysteem heeft andere effecten dan de invoering van bijvoorbeeld een gemeenschappelijk meldkamer systeem. Noordam e.a.6 gaan hier nader op in, zij maken onderscheid met betrekking tot de aard van een project.
3
Engelenburg, 1993, voorwoord;
4
Risseeuws, 1993, pagina 97;
5
Bouwman e.a., 2002, voorwoord en pagina 19;
6
Noordam e.a., 2008, pagina 55, 87,88, 89 en 90;
14
Hoofdstuk 1
Wat is een automatiseringsproject
De aard van het ICT-project bepaalt de invloed die het project heeft op de organisatie. ‘Zo kan ICT als hulpmiddel worden ingezet, waarbij bedrijfsprocessen weinig veranderingen ondergaan. Maar ICT kan ook als zogenaamd strategisch wapen worden gebruikt, waarbij bedrijfsprocessen een flinke transformatie ondergaan. De ene verandering kan worden uitgevoerd met behulp van eenvoudige projectmanagementmethodieken. Terwijl de andere verandering een methodiek vereist die ondersteunt bij complete organisatietransformaties, inclusief veranderingen in de organisatiecultuur. Projecten met informatietechnologie als kenmerk kunnen worden ingedeeld naar vier typen informatietechnologieprojecten. De typen projecten hebben alle vier een verschillende impact op de organisatie.
IT als hulpmiddel (uitgaande van bestaande werkprocessen en organisatiestructuren) voor het beter organiseren van de werkprocessen.
IT als beheersinstrument, een hulpmiddel bij het beter laten verlopen van de werkprocessen en bij het besturen en beheersen van de werkprocessen. Systemen worden in deze fase aan elkaar gekoppeld ter verbetering van de informatievoorziening voor en over het werkproces. Het doel is het beter organiseren en optimaliseren van de werkprocessen.
IT als verbeterinstrument, de ontwikkeling van geïntegreerde informatiesystemen, bestaande bedrijfsprocessen vergaand te verbeteren, te stroomlijnen of soms zelf volledig te herontwerpen. Niet alleen de processen worden anders ingericht, maar ook structuren, verantwoordelijkheden en functies moeten anders gedefinieerd worden.
IT als strategisch wapen. Met IT een concurrentievoordeel behalen.’
Op basis van de voorgaande theorieën wordt geconcludeerd dat de theorie van Springer ondersteund wordt en dat een automatiseringsproject meer is dan alleen het aanschaffen van harden software en het ‘plaatsen van een systeem’ in een organisatie. Het implementeren van een dergelijk project kent meer onderdelen en heeft meer invloed op de organisatie dan over het algemeen gedacht wordt. Dit heeft gevolgen voor de manier waarop je een automatiseringsproject aan moet pakken om er een succes van te maken. In hoofdstuk twee over projecten wordt hier verder op ingegaan. De volgende paragraaf geeft een definitie van het begrip ‘automatiseringsproject’ waarbij rekening wordt gehouden met hetgeen in deze paragraaf is geconcludeerd.
15
Hoofdstuk 1
1.2
Wat is een automatiseringsproject
Definitiebepaling7
Om ervoor te zorgen dat iedereen hetzelfde verstaat met betrekking tot het onderwerp van onderzoek – automatiseringsprojecten – wordt in deze paragraaf weergegeven wat hiermee precies bedoeld wordt.
Onder automatiseringsproject wordt verstaan: Het proces waarbij een geautomatiseerd systeem tot stand wordt gebracht c.q. wordt aangeschaft en geïmplementeerd in de organisatie. Rekening houdend met de impact op de strategie, processen, taken en gebruikers van de desbetreffende organisatie.
Aanvullend geldt dat een geautomatiseerd systeem wordt gezien als ‘het met behulp van automatische stuur- en regelsystemen doen uitvoeren van verrichtingen in het kader van de bedrijfsvoering, administratie en productie van een bedrijf, zodat de gehele organisatie effectiever, betrouwbaarder en beter aanstuurbaar wordt en producten en diensten van hogere kwaliteit levert.’
Er lijkt in deze definitiebepaling een contradictie te zijn tussen het begrip project en proces. De ‘tweestrijd’ tussen deze begrippen zal in deze notitie meer aan de orde komen. Voor nu wordt deze keuze als volgt gemotiveerd: het is belangrijk te beseffen dat een automatiseringsproject meer is dan alleen het ‘neerzetten van een systeem’.
7
Ondanks het feit dat het begrip automatiseringsproject nog regelmatig wordt gehanteerd, lijkt het begrip zich verder ontwikkeld te hebben naar ICT, IT etc. Zonder al deze begrippen te willen beschrijven en volledig af te kaderen, worden deze projecten wel gezien als onderdeel van het onderzoek. In deze notitie zullen dan ook de diverse benamingen worden gehanteerd.
16
Hoofdstuk 2
Hoofdstuk 2
Bredere kijk op een project
Bredere kijk op een project
Waar we in hoofdstuk één hebben geconcludeerd dat een automatiseringsproject meer is dan alleen het plaatsen van een systeem in een organisatie en dat het gaat om een proces, dient vervolgens de vraag beantwoord te worden hoe een dergelijk traject het beste benaderd kan worden. Kunnen we uitgaan van standaard technieken om het project op te pakken (zoals Prince2) of vraagt het meer om invulling te geven aan het procesmatige karakter van een automatiseringsproject? In dit hoofdstuk worden de componenten project en proces naast elkaar gelegd.
2.1
Projectmanagement op basis van Prince2
Een veel gebruikte methodiek om projecten op te pakken is Prince28. Binnen deze methodiek wordt een project door Hedeman e.a.9 als volgt gedefinieerd: ‘een tijdelijke managementomgeving die is opgezet met als doel één of meer bedrijfsproducten op te leveren volgens een gespecificeerde Business Case’. Zonder inhoudelijk op de werking van Prince 2 in te willen gaan (de gebruikte methodieken), wordt in deze paragraaf kort weergegeven wat de uitgangspunten zijn van Prince2. Zodat we een beeld krijgen hoe tegen het begrip project wordt aangekeken.
‘Prince2 richt zich op het:
managen van een project;
managen van de inzet van mensen en middelen in een project;
managen van de samenhang en de interactie tussen het project en haar omgeving.
En formuleert de volgende grondbeginselen voor goed projectmanagement:
een project is een proces met een duidelijk begin en einde;
projecten moeten altijd gemanaged worden om succesvol te zijn;
voor een optimale betrokkenheid van de belanghebbenden moeten zij: o weten waarom het project noodzakelijk is; o wat het doel van het project is;
8
Graham (2010, pagina 8): ‘Prince2 staat voor PRojects IN Controlled Environments. Prince is aan zijn tweede versie toe vandaar Prince2’; Van Onna e.a. (2007, pagina 26 en 27): ‘Prince2 is een gestructureerde projectmanagementmethode. Prince2 beschrijft acht hoofdprocessen. Ieder project komt in meer of mindere mate in aanraking met de activiteiten die binnen deze processen beschreven zijn’; 9
Hedeman e.a., 2004, pagina 1, 2, 9 en 11;
17
Hoofdstuk 2
Bredere kijk op een project
o hoe het resultaat wordt verwezenlijkt; o wat hun verantwoordelijkheden daarbij zijn. Hierbij gelden de volgende uitgangspunten:
projecten worden uitgevoerd in een veranderende omgeving; projecten initiëren zelf veranderingen en deze veranderingen hebben weer effect op het project;
een project is pas succesvol als alle betrokken partijen tevreden zijn met het projectresultaat, managen van de verwachtingen is een wezenlijk onderdeel;
succesvolle projecten zijn ‘business driven’, er moet een zakelijke rechtvaardiging zijn om een project te starten;
samenwerking van alle bij het project betrokken partijen leidt tot meer succesvolle projecten’.
In de theorie over Prince2 wordt aangegeven dat Prince2 zijn beperkingen kent en niet bedoeld is om alle aspecten van projectmanagement af te dekken. De sociale en communicatieve vaardigheden, technieken, software ondersteunende pakketten en technische activiteiten vallen niet binnen de scope van Prince2. Ook binnen deze theorie kan men geen eenduidige oorzaak geven waarom projecten mislukken, maar men ziet het hanteren van een effectieve projectmanagementmethode wel van essentieel belang.
2.2.
Projectmanagement breder bekeken
Waar in de theorie van Prince2 wordt aangegeven dat deze methode zijn beperkingen kent en in de huidige theorie steeds meer aandacht komt voor de organisatorische en sociale componenten, zie je dit ook terugkomen in de theorie over projectmanagement. Bosschers10 past hiervoor de TIPI approach toe: Totally Integrated Project Management Approach of ISES International. Deze systematiek integreert de denkwijzen, werkwijze en de middelen van de moderne projectmanagementmethode (zoals Prince2) en de ‘ik-wij-het benadering’. ´Projecten kunnen nooit slagen als de harde kant ervan niet goed geregeld is. Vastgelegde afspraken, procedures en plannen zijn noodzakelijk, maar geen voldoende voorwaarde voor succes. Wie factoren voor falen of slagen van projecten inventariseert, ontdekt dat veel van die factoren juist aan de zachte kant liggen: interactie van mensen in een project en rollen van individuen.’ De ik-wij-het benadering heeft betrekking op het feit dat een projectleider om moet kunnen gaan met verschillende belangen van mensen (wij), zichzelf gemotiveerd moet houden (ik) en regelmatig over de harde cijfers moet rapporteren (het).
10
Bosschers, 2000, pagina 4;
18
Hoofdstuk 2
Bredere kijk op een project
Het alleen toepassen van projectmanagementtechnieken lijkt niet voldoende te zijn, er moet ook aandacht zijn voor de procesmatige kant. Maar hoe verhouden beide invalshoeken zich tot elkaar? De Bruijn en Ten Heuvelhof11 gaan er vanuit dat een organisatie het karakter krijgt van een netwerk: ‘veel relatief autonome eenheden met soms verschillende belangen, die wederzijds afhankelijk zijn, waarbij sturing van bovenaf sterk bemoeilijkt wordt.’ Een automatiseringsproject zal binnen een dergelijke organisatie vorm moeten krijgen. Projectmanagement wordt gezien als niet effectief voor een netwerk, gezien de wederzijdse afhankelijkheden. De besluitvorming in een dergelijk proces verloopt grillig door strategisch gedrag, machtsverhoudingen en andere belangen die spelen. ‘Modellen (zoals de plan-do-check-act cyclus) die besluitvorming voorstellen als een volgtijdelijk en fasegewijs proces, zijn misleidend. Feitelijk verloopt de besluitvorming echter geheel anders. Wie projectmatig tot besluitvorming wil komen in een netwerk, veronderstelt dat er overeenstemming is over problemen, doelen en oplossingen en dat is in een netwerk bijna per definitie niet het geval.’ De Bruijn,Ten Heuvelhof en In ‘t Veld12 geven aan dat de laatste jaren in de wereld van bestuur en management steeds meer aandacht is ontstaan voor de procesmatige aspecten van sturing en verandering. ‘Vaak wordt geconstateerd dat de inhoudelijke aspecten van verandering dermate complex zijn, dat een nadrukkelijke en gerichte aandacht voor de procesaspecten noodzakelijk is om een veranderproces met succes te kunnen doorlopen.’ Zij constateren dat een projectbenadering in een netwerk van afhankelijkheden (je bent van anderen afhankelijk en kunt een verandering nooit eenzijdig opleggen) een beperkte betekenis heeft. ‘Pas wanneer andere partijen betrokken worden bij de verandering, is er een kans dat ze de eigen opvattingen herkennen in de definitie van een probleem en een oplossing. En dan pas zullen zij hier hun steun aan verlenen.’ Volgens De Bruijn en Ten Heuvelhof is hiermee de argumentatie gegeven waarom procesbenadering een noodzaak is. Het gegeven dat andere partijen betrokken moeten worden, vergt een proces van interactie tussen deze partijen. Zij moeten overleggen en onderhandelen over het bepalen van de problemen en oplossingen. Een procesbenadering van verandering betekent dan ook:
‘het accent bij de verandering verschuift van de inhoud van de verandering naar de manier waarop deze tot stand zal komen;
dat er vooraf tussen de betrokken partijen afspraken worden gemaakt over de manier waarop de het besluitvormingsproces zal verlopen;
11
De Bruijn en Ten Heuvelhof, 2007, pagina 2 en 46;
12
De Bruijn, Ten Heuvelhof en In ’t Veld, 2008, pagina 1 en 3;
19
Hoofdstuk 2
Bredere kijk op een project
20
dat deze procesafspraken voor elk van de betrokken partijen voldoende ruimte bieden om de eigen belangen te dienen.’
De Bruijn en Ten Heuvelhof13 hebben een vergelijking gemaakt tussen de projectmatige en procesmatige benadering. Deze vergelijking is in onderstaand overzicht weergegeven.
Figuur 2 Vergelijking project- en procesbenadering (De Bruijn en Ten Heuvelhof) Projectbenadering
Procesbenadering
Eerste constatering dat er een probleem
Een actor die een probleem definieert zal zich ervan bewust moeten zijn
is, dit probleem wordt afgebakend
dat er sprake is van ‘slechts’ een probleemperceptie. Het geeft het
(pagina 76).
perspectief van de betreffende actor weer (pagina 76). De aandacht verschuift hierdoor van inhoudelijke probleemanalyse naar strategieën om de probleemperceptie van actoren te beïnvloeden. Een te scherpe probleemafbakening kan in een proces disfunctioneel zijn (pagina 77).
In de projectbenadering is de logische
In een netwerk kan de volgorde ook andersom zijn. Solutions, looking for
volgorde dat eerst een probleem wordt
problems.
gedefinieerd en dat daarna de oplossing
Het moment waarop een probleem wordt geformuleerd, is een
wordt gezocht (pagina 79).
strategische keuze (window of opportunity) (pagina 79).
In een projectbenadering is een
In een netwerk is een doelstelling vaak een momentopname. Partijen
doelstelling het referentiepunt in een
formuleren een doelstelling, maar het is goed mogelijk dat er in een
besluitvormingsproces (pagina 80).
volgende besluitvormingsronde een andere doelstelling wordt geformuleerd. Partijen leren immers (pagina 81).
In een projectbenadering wordt het
In een procesbenadering wordt de framing van een doelstelling bepaald
framen van de doelstelling bepaald door
door de vraag of hiervoor steun kan worden verworven bij andere actoren
de inhoud van een probleem (pagina
(pagina 82).
82).
In een netwerk is enige terughoudendheid vereist met het stellen van randvoorwaarden die als een muur om het besluitvormingsproces heen staan (pagina 83).
13
De Bruijn en Heuvelhof 2007, paginaverwijzing wordt in het schema per onderdeel aangegeven;
Hoofdstuk 2
Projectbenadering
Bredere kijk op een project
21
Procesbenadering
Bij een projectbenadering van
In een procesbenadering zijn informatievergaring en – voorziening sterk
besluitvorming is informatie een
actorgebonden, hetgeen een aantal belangrijke gevolgen heeft.
cruciale machtsbron. Zonder tijdige en
goede informatie, is goede
De informatie die aan de probleemanalyse ten grondslag ligt, is altijd discutabel of vatbaar voor geschillen (pagina 87).
besluitvorming onmogelijk. Deze
Informatie is een belangrijk machtsmiddel.
informatie zal worden vergaard volgens
In een netwerk is nice to know effectiever. Een actor probeert via
het principe van need to know (pagina
zijn relaties zo veel mogelijk informatie uit het netwerk te krijgen,
86).
ook wanneer niet meteen duidelijk is waar deze informatie toe dient (pagina 89).
Actoren in een netwerk zullen op bepaalde momenten ontvankelijk zijn voor informatie en op andere momenten zich afsluiten voor informatie (pagina 90).
Bij iedere stap in de besluitvorming doet zich een belangrijk strategisch vraagstuk voor: kiezen de partijen voor bevriezing van een situatie of willen ze deze ontdooien (unfreezing) (pagina 91)?
In een projectbenadering is een besluit
Besluitvorming in een netwerk is het resultaat van een proces, waarin
een belangrijk moment. De
partijen over een groot aantal issues hebben onderhandeld. De formele
besluitvorming zal het verdere verloop
vaststelling van de package zal veelal geen verrassing meer zijn voor de
van het project sterk beïnvloeden; het is
partijen (pagina 92).
een go of een no go moment (pagina
Formele besluitvorming is een kwestie van aftikken; het reeds
92).
uitonderhandelde besluit moet formeel worden bevestigd. De formele besluitvorming zal hiermee, anders dan in een projectbenadering niet meer richtinggevend zijn (pagina 93).
Een projectbenadering is erg krachtig.
Achter een besluit gaat een onderhandelingslogica schuil: partijen hebben
Wie een besluit verdedigt in de taal van
een proces van interactie doorlopen, met een Multi-issueagenda, hebben
projectmanagement – gedegen
koppelingen gemaakt tussen problemen en oplossingen en uiteindelijk een
probleemanalyses, heldere doelen,
package deal samengesteld. Het probleem is nu dat de communicatieve
goede informatie zal niet snel het
kracht van deze onderhandelingslogica beperkt is (pagina 95).
verwijt krijgen van opportunisme (pagina 95). Evaluatie in een projectbenadering is
Bij een evaluatie van processen in een ander netwerk passen andere
een doelrationele activiteit. Zijn de
criteria: zijn partijen tevreden, zijn problemen opgelost, hebben partijen
vooraf geformuleerde doelstellingen
geleerd, zijn duurzame relaties ontstaan, Is het proces fair verlopen (pagina
zijn gehaald (effectiviteit) en wat de
104 en 105)?
kosten hiervan waren (efficiency) (pagina 103 en 104).
Hoofdstuk 2
Bredere kijk op een project
Ondanks hun betoog dat netwerken een procesbenadering vereisen, ontkomen De Bruijn en Ten Heuvelhof14 er niet aan dat projectmanagement ook zijn meerwaarde heeft. Zelf zeggen ze hierover: ‘Duidelijk is gemaakt dat een projectbenadering weinig kans van slagen heeft in een netwerk van interdependenties. Tegelijkertijd geldt dat deze benadering communicatief erg krachtig is. Het omgekeerde geldt voor een procesbenadering: wel geschikt voor netwerken, maar een beperkte communicatieve kracht. Hoe om te gaan met dit dilemma? Het meest eenvoudige antwoord op deze vraag is om de kracht van beide benaderingen te gebruiken; het handelen in een netwerk is procesmatig, het communiceren over de resultaten van het proces geschiedt in projectmatige taal.’
2.3.
Conclusie
Uit voorgaande paragrafen kan geconcludeerd worden dat projectmanagement meer is dan alleen het toepassen van de standaard projectmanagementtechnieken, maar dat je ook niet zonder deze technieken kunt. Om een project goed aan te pakken heb je zowel je linker als je rechterhand nodig. Zowel de projectmanagementtechnieken, als technieken op het gebied van procesmanagement.
Op basis van hoofdstuk één en twee ontstaat het beeld dat een automatiseringsproject meer is dan alleen het plaatsen van een systeem, het is een proces. Waarbij zowel projectmanagement als procesmanagement van belang is.
14
De Bruijn en Ten Heuvelhof, 2007, pagina 95 en 96;
22
Hoofdstuk 3
Hoofdstuk 3
Theoretisch kader van project succes
Theoretisch kader van project succes
‘Succes is van mislukking naar mislukking gaan, zonder je enthousiasme te verliezen.’ Winston Churchill
We weten nu wat we onder een automatiseringsproject verstaan en welke managementtechnieken een belangrijke rol spelen. De vraag is echter wanneer we een automatiseringsproject als succes zien en welke factoren hierbij een rol spelen. Om te beoordelen wanneer een automatiseringsproject een succes genoemd kan worden en de succesfactoren te bepalen, is het van belang dat duidelijk is wat wordt verstaan onder succes. In dit hoofdstuk wordt dit begrip nader gedefinieerd en worden de (mogelijke) kritische succesfactoren beschreven.
3.1
Het begrip succes
Noordam e.a.15 geven aan dat een succesvol project voldoet aan drie criteria: 1. het levert de vooraf overeengekomen functionaliteit op; 2. het levert op tijd; 3. het levert binnen budget.
Daarbij wordt opgemerkt dat er bijna geen ICT-project is dat conform deze drie pijlers resultaten oplevert. Er wordt dan ook gesproken van de zogenaamde duivelsdriehoek.
Functionaliteit
Duivelsdriehoek
Tijd Figuur 3 Duivelsdriehoek van Noordam
15
Noordam, 2008, pagina 13;
Budget
23
Hoofdstuk 3
Theoretisch kader van project succes
Deze beschrijving van succes wordt ondersteund door de Algemene Rekenkamer16. Bij de beschrijving van niet succesvolle ICT-projecten bij de overheid spreken zij over projecten die: veel duurder worden dan gedacht, meer tijd vragen dan gepland of die niet het gewenste resultaat opleveren. Beers17 omschrijft een succesvol project als een project dat niet gefaald heeft. ‘Een gefaald project wordt gekenmerkt doordat hierin verschillen bestaan tussen de verwachtingen die men van het project heeft gehad en het uiteindelijke resultaat (duurder dan verwacht, later opgeleverd dan verwacht, dit heb ik niet besteld).’ Beers18 stelt derhalve succes en falen synoniem met het verschil tussen plan en realisatie van het plan. Volgens Beers zijn twee symptomen synoniem voor het mislukken van een automatiseringsproject: 1. het project is gestaakt voordat een eindproduct is opgeleverd; 2. het product is veel duurder dan voorzien en/of wordt veel te laat opgeleverd. Door Hedeman e.a.19 wordt een project als succesvol gezien als ‘alle betrokken partijen (opdrachtgever, gebruikers, leveranciers en projectmedewerkers) tevreden zijn met het bereikte resultaat.’ Engelenburg20 heeft gekeken naar het succes van tien excellente IT-projecten. Projecten die worden gezien als succesvol, worden omschreven als: ‘afgezien van het feit dat alle projecten vrijwel binnen het budget en tijd zijn gebleven, worden de systemen naar tevredenheid gebruikt en hebben ze de kostenbesparingen en efficiency verhogingen opgeleverd die ervan verwacht werden. Als extra toegift is vaak ook nog sprake van waardevolle ‘spin-off’ effecten.’
Waar Beers de definitie van Noordam e.a. uitbreidt door het niet te hebben over het afleveren van een vooraf overeengekomen functionaliteit, maar over het voldoen aan verwachtingen en het niet staken van een project voordat een eindproduct is opgeleverd ziet als een succesfactor, gaan Morris
16
Algemene Rekenkamer, 2008;
17
Beers, 1990, pagina 59 en 60;
18
Beers, 1990, pagina 4;
19
Hedeman e.a., 2004, pagina 15 en 16;
20
Engelenburg, 1993, pagina 13;
24
Hoofdstuk 3
Theoretisch kader van project succes
and Hough21 nog een stap verder. Zij onderscheiden vier onderdelen om te bepalen of een project een succes is. 1. ‘Project functionality; does the project perform financially, technically or otherwise in the way expected by the project’s sponsors? 2. Project management; was the project implemented to budget, on schedule, to technical specification? 3. Contractors’ commercial performance: did those who provided a service for the project benefit commercially (in either the short or long term)? 4. In the event that a project needed to be cancelled, was the cancellation made on a reasonable basis and terminated efficiently?’
Deze punten komen niet als ‘nieuw’ naar voren, eerder als een uitbreiding van de reeds besproken punten. Een nieuwe invalshoek wordt door Morris en Hough22 wel gegeven door in hun boek (The anatomy of major projects) te spreken over ‘many levels of measurement for evaluating project success. The evaluation of project success varies through time. Partly this is because a projects success criteria vary according to the stage of the project, and partly because conditions change over time.’
De definitie van Morris en Hough scherpt de overige definities aan, door te veronderstellen dat succes een relatief karakter heeft. Enerzijds kun je succes definiëren als een objectief begrip (binnen de tijd, het budget en conform functionele eisen), maar de manier waarop je naar de gegeven situatie kijkt, bepaalt mede of er daadwerkelijk sprake is van een succesvol project. De waardering of een project een succes is of niet is afhankelijk vanuit welke invalshoek en op welk moment je de situatie beoordeeld:
in de tijd, wat in het begin geen succesvol project was, kan het in de loop der tijd nog worden;
in analyseniveau, het niveau van het individu (individuele taakuitvoering) en van de organisatie (strategische positie van de organisatie);
per fase van een project, de ene fase kan succesvoller zijn dan de andere;
21
Morris and Hough, 1987, pagina 193;
22
Morris and Hough, 1987, pagina 194 en 251;
25
Hoofdstuk 3
Theoretisch kader van project succes
in doelstelling, wellicht is het primaire doel niet behaald maar heeft het wel bijgedragen aan het bereiken van andere (secundaire) doelen (serendipiteit23).
Op basis van bovenstaande theorieën wordt in deze notitie de volgende definitie van succes gehanteerd.
Een succesvol automatiseringsproject is een project dat: vanuit de invalshoek van de opdrachtgever en gebruiker voldoet aan de verwachtingen en is afgerond binnen de tijd en het budget.
Waarbij het element verwachtingen geïnterpreteerd moet worden als een variabele die verder gaat dan de gestelde functionele eisen en van invloed kan zijn op de definitie van ‘binnen de tijd’ en ‘binnen het budget’. Hiermee wordt tegemoet gekomen aan het gegeven dat behoeftes in de loop van de tijd kunnen veranderen en dat er sprake kan zijn van serendipiteit. Nu we weten wat een succesvol project is, is het belangrijk om te weten hoe we dit doel (een succesvol project) behalen. Hierbij spelen kritieke succesfactoren een rol. De wikipedia24 omschrijft kritieke succesfactoren als: ‘factoren die beslissend zijn voor het al dan niet behalen van een vooraf gesteld doel. Om het doel te behalen (“succes”) zijn bepaalde factoren een noodzakelijke voorwaarde.’
3.2
Kritieke succesfactoren
In deze paragraaf wordt gekeken naar factoren die een automatiseringsproject succesvol kunnen maken. In bijlage drie wordt een weergave gegeven van de belangrijkste succes- en faalfactoren die in de loop der jaren zijn beschreven. In de probleemstelling van deze notitie wordt alleen gesproken over succesfactoren en niet over faalfactoren. Gedurende de zoektocht naar de succesfactoren is gebleken dat bepaalde factoren duidelijker worden door ook de faalfactoren te benoemen. Daarom worden de succesfactoren (waar nodig) in samenhang met de erbij behorende faalfactoren beschouwd.
23
Wikipedia omschrijft serendipiteit als: het vinden van iets onverwachts en bruikbaars terwijl je op zoek bent naar iets totaal anders. 24
www.wikipedia.nl
26
Hoofdstuk 3
Theoretisch kader van project succes
3.2.1 Positionering succesfactoren in het negenvlaksmodel In voorgaande paragrafen is omschreven wat we onder succes verstaan en in bijlage drie is beschreven welke factoren van invloed zijn op het bereiken van dit succes. Het is belangrijk dat we deze gegevens in een kader kunnen plaatsen, zodat zichtbaar is waar de mogelijkheden voor succes liggen in een organisatie en een vertaalslag kan worden gemaakt naar de praktijk. Om dit duidelijk te maken wordt gebruik gemaakt van het negenvlaksmodel van Maes. Dit model kan het best worden gezien als een kaart voor het identificeren en positioneren van vraagstukken op het gebied van informatiemanagement in ruime zin. Dit vlak impliceert geen werkwijze, maar wijst alleen op de belangrijkste aandachtsgebieden van business en ICT. Hetgeen betekent dat het ook kan worden toegepast met betrekking tot de succesfactoren van automatiseringsprojecten. Belangrijk voordeel van het toepassen van het negenvlaksmodel, is het feit dat invulling wordt gegeven aan het belang om een automatiseringsproject te zien als een verandering die invloed heeft op de gehele organisatie (los laten van technology-fix denken). Allereerst wordt hieronder in het kort het negenvlaksmodel toegelicht, waarna de succes- en faalfactoren van automatiseringsprojecten in het schema worden weergegeven.
Het negenvlaksmodel Maes25 geeft de volgende toelichting op het negenvlaksmodel: 1. Het raamwerk stelt ons in staat om de verschillende vraagstukken van informatiemanagement in hun onderling verband te positioneren. Informatiemanagement wordt gedefinieerd als het gebalanceerd managen van de (relaties tussen de) verschillende componenten van dit raamwerk. 2. Informatiemanagement vraagstukken hebben betrekking op strategie (richten), structuur (inrichten) en operations (verrichten). Dit wordt gerepresenteerd in de verticale dimensie van het raamwerk. 3. Informatiemanagement relateert de processen van en de ondersteunende technologie voor (intern en extern) informeren en communiceren aan algemene bedrijfsaspecten. Dit wordt in het raamwerk aangeduid middels de drie domeinen van de horizontale dimensie.
4. De twee centrale assen (middelste rij en kolom) zijn kernaandachtsgebieden voor informatiemanagement. Vooral de middelste kolom (de technologieonafhankelijke beschouwing van informatie- en communicatieprocessen) wordt in veel organisaties verwaarloosd.’
Bedrijfsvoering Organisatie 25
www.rikmaes.nl, onderdeel ‘visie’;
Informatievoorziening Vraag
ICT Services Aanbod
27
Hoofdstuk 3
Strategie Richten
Structuur Inrichten
Uitvoering Verrichten
Theoretisch kader van project succes
28
Bepalen strategie informatievoorziening Strategische analyse en besturing IV
Bepalen strategie ICTservices Strategische analyse en besturing ICT
Ontwerpen bedrijfsvoering
Ontwerpen informatievoorzieningen
Ontwerpen ICT-services
Plannen bedrijfsvoering
Plannen IV
Plannen ICT-services
Beheren bedrijfsvoering (Procesbeheer)
Beheren IV (Functioneel beheer)
Beheren ICT-services (Technisch beheer)
Exploitatie
Gebruik IV
Exploitatie ICT-services
Bepalen strategie bedrijfsvoering Strategische analyse en besturing
Figuur 4 Negenvlaksmodel van Maes
Succes- en faalfactoren toegepast in het negenvlaksmodel Om een goed overzicht te krijgen van de succesfactoren, worden ook de faalfactoren in het negenvlaksmodel geplaatst. Over het algemeen wordt gesteld dat het tegenovergestelde van een faalfactor een succesfactor oplevert. Echter bij het plaatsen van de succes- en faalfactoren in het negenvlaksmodel is gebleken dat het totaalplaatje te kort wordt gedaan door alleen uit te gaan van de succesfactoren.
Faalfactoren De belangrijkste faalfactoren die van invloed (kunnen zijn) op het falen van een project, worden hieronder in het negenvlaksmodel geplaatst.
Hoofdstuk 3
Theoretisch kader van project succes
29
Aansluiting tussen beide kolommen ontbreekt (IV moet meer tegen de Business kant aanschuiven dan tegen de technische kant). Bedrijfsvoering Organisatie
Informatievoorziening Vraag
ICT Services Aanbod
Verschuiving macht
ICT wordt niet herkend als strategic resource. Doel en strategie onduidelijk. Te hoge ambitie.
Doel en strategie onduidelijk.
Doel en strategie onduidelijk. ICT past niet bij structuur en cultuur van de organisatie.
Geen evenwicht tussen ambitie en beschikbare middelen.
Gebruikers: Worden niet (tijdig) betrokken. Formuleren vraag/ informatiebehoefte niet of kunnen dit niet. Wensen/behoeften gebruiker zijn niet leidend (de mogelijkheden qua techniek zijn leidend). Geen goede afstemming tussen ICT en gebruiker.
Geen beschikking over voldoende middelen: financiële middelen; capaciteit & expertise; tijd (niet voldoende tijd (kunnen) nemen).
Procesbeheer is niet georganiseerd.
Functioneel beheer is niet georganiseerd.
Techneut koppelt zijn activiteiten niet aan visie: waar doen we het voor?
ICT projecten worden alleen vanuit dit vlak benaderd. De automatiseringsspecialist is alleen deskundig op het gebied van automatisering.
Figuur 5 Faalfactoren uit bijlage drie toegepast in het negenvlaksmodel van Maes
Succesfactoren De belangrijkste succesfactoren die van invloed (kunnen zijn) op het falen van een project, worden hieronder in het negenvlaksmodel geplaatst.
Hoofdstuk 3
Theoretisch kader van project succes
30
Goede begeleiding verandering & invoering
Bedrijfsvoering Organisatie
Duidelijke visie/strategie. Gebruik businesscase. Management is betrokken. Goede analyse huidige en gewenste situatie
Gebruikers: Worden tijdig betrokken. Worden opgeleid zodat ze de toepassing zinvol kunnen gebruiken. Zijn bereid om te veranderen. Kunnen los komen van de huidige situatie. Worden betrokken bij de analyse van de huidige situatie en de zoektocht naar oplossingen.
Uit te voeren taak is ingericht. Organisatie(processen) zijn beschreven. Taak/organisatie zijn geïntegreerd onderdeel IT project. Juiste mensen voor uitvoering beschikbaar
Informatievoorziening Vraag
Duidelijke visie/strategie.
Goede communicatie
Beheer is geregeld. Beheer is geregeld. Uit te voeren taak
Zijn goed op elkaar afgestemd. Techniek faciliteert gedrag gebruiker
ICT Services Aanbod
Duidelijke visie/strategie.
Goede projectbegeleiding. Consequent naar eindresultaat werken. Samenwerken. Gekozen systeem in verhouding tot problemen die men op wil lossen
Technologie is: beschikbaar en betrouwbaar; gebruiksvriendelijk/eenvoudig in de omgang Beheer is geregeld. Mogelijkheden techniek zijn niet leidend.
Figuur 6 Succesfactoren uit bijlage drie toegepast in het negenvlaksmodel van Maes
3.2.2 De driehoek van verbondenheid Op basis van de conclusies in hoofdstuk één en twee dat een automatiseringsproject een proces is dat de gehele organisatie raakt, waarbij zowel een project- als procesmatige aanpak nodig is en op basis van de succes- en faalfactoren (in bijlage drie), kan een model ontwikkeld worden waarin wordt weergegeven welke componenten noodzakelijk zijn voor projectsucces. Als aanvulling op de duivelsdriehoek (de beschrijving van succes aan de hand van beheersfactoren), is de driehoek van verbondenheid vorm gegeven (bestaande uit de componenten: organisatie, projectmanagement en procesmanagement). Centraal staan de componenten die van invloed zijn op projectsucces en die in
Hoofdstuk 3
Theoretisch kader van project succes
verbondenheid toegepast moeten worden. Het alleen toepassen van één van de componenten (organisatie, projectmanagement, procesmanagement) zal niet tot succes leiden. Dit model is weergegeven in figuur zeven.
Organisatie
Driehoek van Verbondenheid
Projectmanagement
Procesmanagement
Figuur 7 Driehoek van Verbondenheid (Kiel 2010, gebaseerd op ‘Duivelsdriehoek van Noordam)
De component ‘organisatie’ staat voor het gegeven dat het automatiseringsproject aan moet sluiten bij de strategie, processen en taken van de organisatie. Het moet een bijdrage leveren aan (het verbeteren) van de doelstellingen van de organisatie c.q. het eenvoudiger maken van de werkzaamheden. Kortom het moet meerwaarde hebben voor de organisatie. De Algemene Rekenkamer26 geeft een duidelijke beschrijving met betrekking tot hoe de leiding van een organisatie zich op moet stellen. ‘Bestuur en ambtelijke leiding van de organisaties moeten ervan doordrongen raken dat ICT-vraagstukken geen puur technische vraagstukken zijn. Het zijn informatieen communicatievraagstukken en die zijn op hun beurt organisatievraagstukken. Voordat gesproken wordt over een ICT-project, zou eerst aandacht besteedt moeten worden aan het organisatievraagstuk dat aan de orde is en de informatievoorziening die daarvoor nodig is.’ Springer27 omschrijft dit als het gegeven dat automatisering niet als iets op zichzelf staand moet worden beschouwd, maar dient altijd ter ondersteuning, als een hulpmiddel, om de organisatiedoelstelling te bereiken. Automatisering is niet een op zichzelf staand proces, maar heeft invloed op en wordt beïnvloed door taken, structuur en mensen.
26
De Algemene Rekenkamer, deel B, 2008, pagina 60;
27
Springer, 1989, pagina 27;
31
Hoofdstuk 3
Theoretisch kader van project succes
Tenslotte blijkt uit het negenvlaksmodel dat alle activiteiten op het gebied van informatiemanagement samen moeten hangen met de strategie en bedrijfsvoering van een organisatie.
De component ‘projectmanagement’ geeft invulling aan de projectmatige aanpak die noodzakelijk is. De opdrachtgever die betrokken is, de aanwezigheid van duidelijke doelstellingen, de planning en mijlpalen die gehaald moeten worden, de sturing die nodig is etc.
Tenslotte geeft de component ‘procesmanagement’ invulling aan het sociale aspect van een automatiseringsproject: het tijdig betrekken van de gebruikers, rekening houden met de cultuur van een organisatie, managen van verwachtingen etc.
32
Deel II De praktijk
Deel II
De praktijk
Om een eerste stap te maken van de theorie naar de praktijk (zien we hetgeen in de theorie is beschreven ook daadwerkelijk terug in de praktijk?), worden in deel II een viertal casus over automatiseringsprojecten behandeld. De volgende projecten komen aan bod:
Basisvoorziening Handhaving (BVH) politie Nederland;
C2000;
Virtuele Kijkdoos;
Technische Infrastructuur Brandweer Midden en West Brabant (TIS totaal).
De praktijk wordt aan de theorie gekoppeld door de projecten op twee (in de theorie beschreven) niveaus te analyseren: 1. de beheersfactoren; voldoet het project aan de gestelde beheerscomponenten tijd, geld en kwaliteit; 2. de succesfactoren; welke succesfactoren zijn aanwezig binnen het project. De succesfactoren worden – conform de theorie – onderverdeeld in drie componenten: organisatie, projectmanagement en procesmanagement.
33
Hoofdstuk 4
Hoofdstuk 4
Basisvoorziening Handhaving (BVH)
Basisvoorziening Handhaving (BVH)
In het coalitieakkoord van 2007 geeft het kabinet aan een extra impuls te willen geven aan het veiliger maken van Nederland. Als onderdeel hiervan is afgesproken dat de Nederlandse politie één landelijke informatiehuishouding gaat gebruiken, waardoor er geen belemmeringen meer bestaan voor het uitwisselen van operationele informatie. Een onderdeel van deze landelijke informatiehuishouding is het systeem Basisvoorziening Handhaving (BVH). Dat de implementatie van de BVH niet vlekkeloos is verlopen, geven onderstaande teksten weer. Waar de ene partij het project als een succes bestempeld, geeft de andere partij aan dat er sprake is van ‘chaos’.
Wat is er aan de hand? Is het project BVH een succes of niet en waarom wordt hier door de diverse partijen verschillend naar gekeken? De manieren waarop naar dit project wordt gekeken en de aandacht die het project landelijk heeft gekregen, maakt het tot een interessante casus. Na een korte
34
Hoofdstuk 4
Basisvoorziening Handhaving (BVH)
(feitelijke) beschouwing van het project, wordt gekeken naar het succes en falen en de mogelijke succesfactoren28. Waarna het hoofdstuk wordt afgesloten met een analyse en conclusie.
4.1 Het project Basisvoorziening Handhaving De basisvoorziening handhaving (hierna te noemen BVH) is een systeem dat de drie ‘vroegere’ handhavingsystemen van de politie (te weten: BPX, Xpol en Genesis) moet vervangen. Hierdoor zal heel Politie Nederland met één systeem werken zodat de informatie-uitwisseling en de samenwerking tussen de korpsen verbetert. Het systeem Xpol vormt het fundament van de BVH. De genoemde systemen ondersteunen de belangrijkste bedrijfsprocessen van de politie: registreren, meldingen, verwerken aangiftes en het afhandelen van incidenten.
Opdrachtgever en opdrachtnemer De regie van het project BVH ligt bij de Raad van Hoofdcommissarissen en de vtsPN. Waarbij de Raad van Hoofdcommissarissen de opdrachtgever is en vtsPN de opdrachtnemer. Zij hebben de software in eigen beheer ontwikkeld en hebben de regie op de landelijke uitrol. De korpsen zorgen zelf voor de organisatie van de implementatie, de opleidingen en het inpassen van het systeem in de werkprocessen.
Doel Zoals reeds is beschreven, heeft het project BVH als doel om toe te werken naar één systeem per taak in heel Nederland. Dit moet er toe leiden dat de informatievoorziening binnen de politie verbeterd en uniform plaatsvindt. Hierdoor kunnen de korpsen beter informatie met elkaar uitwisselen en effectiever en efficiënter met elkaar samenwerken. Samengevat beoogt de BVH de volgende doelen te bereiken: verbetering van de mogelijkheden tot bovenregionale samenwerking, een basis leggen voor verdere vernieuwingen in de informatiehuishouding, een verbetering van de kwaliteit van de informatie en gegevensuitwisseling en efficiencyverbetering op het gebied van beheer en onderhoud (Scope juni/oktober 2008).
28
Voor de analyse is gebruik gemaakt van de diverse documenten en reacties die op internet beschikbaar zijn, te weten: advies van de werkgroep gebruik basisvoorzieningen (november 2009), zwartboek BVH (politievakorganisatie ACP, januari 2010) en de voorlopige resultaten SP-politie enquête (22 juli 2009). Daarnaast is gebruik gemaakt van diverse internetpagina’s, zie literatuurlijst;
35
Hoofdstuk 4
Basisvoorziening Handhaving (BVH)
36
Opdracht De opdracht betreffende het project BVH is terug te vinden in de samenwerkingsafspraken politie 200829. Hierin is door de ministers van BZK en Justitie en korpsbeheerders het volgende afgesproken over de BVH: ‘De invoering van de Basisvoorziening Handhaving start in 2007 conform een door het bestuur van de VTSPN vastgesteld implementatieplan. Eind 2008 hebben minstens 13 korpsen de implementatie afgerond, een aantal korpsen is met de implementatie gestart en de resterende korpsen zullen in 2009 volgen. Eind 2008 kan met zekerheid worden gesteld dat de implementatie in 2009 wordt afgerond’.
Verloop project Het project start in 2008 en de eerste implementatie vindt plaats in de pilotregio Limburg-Zuid. Zij nemen in juni 2008 de BVH als eerste in gebruik. Om de gestelde opdracht in de samenwerkingsafspraken te kunnen behalen, wordt gewerkt met een strakke planning. Alle politiekorpsen moeten binnen twee jaar (voor 2010) kunnen beschikken over de BVH. Het gaat hierbij om zo’n dertig à veertigduizend werkplekken. Naast een strakke planning wordt veel capaciteit ingezet voor de implementatie. Ruim honderd ICT-ers van de vtsPN zijn betrokken bij de gefaseerde implementatie. Daarnaast zijn er in totaal nog eens drie- tot vierhonderd ICT-ers op de diverse regiokorpsen bij het project betrokken. Bovendien heeft de politie zes rekencentra waar ICTers werken aan het systeem.
2008 Januari
Februari
Maart
April
Mei
Start project
Juni 18/06 Limburg-Zuid neemt BVH in gebruik.
Juli
Augustus
September
Oktober
November
December
2009 Januari
Februari
Maart
April Eerste update van het systeem verschijnt. Met 175 verbeteringen.
29
Samenwerkingsafspraken politie 2008, pagina 2;
Mei
Juni
Hoofdstuk 4
Juli
Augustus
September
Basisvoorziening Handhaving (BVH)
37
Oktober
November
December
16/7 Invoering ligt op
15/10 Korps-
Bij 24 korpsen is
31/12 Het is VTSPN
schema. Systeem is bij
beheerdersraad en Raad
BVH
gelukt om alle 26
21 korpsen ingevoerd.
van Korpschefs stellen een
operationeel.
korpsen te migreren
werkgroep in voor het
naar BVH. Project is op
SP houdt een enquête
gebruik van de ict-
tijd en volgens
onder
basisvoorzieningen.
30
politiefunctionarissen
afspraak met kabinet afgerond. Januari 2010 verschijnt het zwartboek BVH.
De implementatie van BVH loopt gelijktijdig met de implementatie van de nieuwe systemen Basisvoorziening opsporing en Basisvoorziening capaciteitsmanagement.
4.2 Succes en falen Nu we op hoofdlijnen weten hoe het project eruit ziet, gaan we bekijken of het project een succes is en zo ja, wat mogelijke succes- en/of faalfactoren zijn. Om te beoordelen of het om een succesvol project gaat en welke factoren van invloed zijn op het eventuele succes, wordt het project op twee niveaus geanalyseerd: 1. de beheersfactoren; voldoet het project aan de gestelde beheerscomponenten tijd, geld en kwaliteit (geformuleerd bij aanvang van het project); 2. de succesfactoren; welke succesfactoren zijn aanwezig binnen het project. De succesfactoren worden – conform de theorie – onderverdeeld in drie componenten: organisatie, projectmanagement en procesmanagement.
De beheersfactoren Om te beoordelen of het project een succes is, wordt gekeken naar de drie zogenaamde beheersfactoren31:
30
tijd (T): is het project binnen de tijd (planning) afgerond;
geld (G): is het project binnen het budget afgerond;
Bij de opdrachtverstrekking aan de werkgroep is gesteld dat het behalen van de samenwerkingsafspraken een randvoorwaarde is; 31 Leidend bij de bepaling van deze drie componenten is de definitie van een succesvol automatiseringsproject (zie hoofdstuk één): een project dat vanuit de invalshoek van de opdrachtgever en gebruiker voldoet aan de verwachtingen en is afgerond binnen de tijd en het budget;
Hoofdstuk 4
Basisvoorziening Handhaving (BVH)
38
kwaliteit (K): levert het project de kwaliteit c.q. voldoet het aan de eisen die gesteld zijn aan het begin van het project.
Er wordt gekeken naar de formulering van de componenten T, G en K bij aanvang van het project en de daadwerkelijke invulling van de T,G en K bij het einde van het project.
Aanvang project Tijd (T)
Einde project
Invoering BVH start in 2007. Eind 2008
De implementatie is voor eind 2009 afgerond,
hebben minstens 13 korpsen de
alle korpsen zijn over gegaan op BVH.
implementatie afgerond, een aantal korpsen is met de implementatie gestart en de resterende korpsen zullen in 2009 volgen. De implementatie wordt in 2009 afgerond. Geld (G)
Geraamd budget is niet terug te halen uit de
Binnen budget afgerond
aanwezige stukken. Kwaliteit (K)
Verbetering van de mogelijkheden tot bovenregionale samenwerking. Basis leggen voor verdere vernieuwingen in de informatiehuishouding. Verbetering van de kwaliteit van de informatie en gegevensuitwisseling. Efficiencyverbetering op het gebied van beheer en onderhoud.
Korpsen werken met hetzelfde systeem en kunnen hierdoor effectiever samenwerken. Er ligt een basis voor verdere vernieuwing in de informatiehuishouding. Reacties vanuit het veld: Toename administratieve rompslomp. Cruciale informatie komt niet bij de agent op straat. Systeem gebruiksonvriendelijk. Veel werk moet dubbel verricht worden.
Op basis van de beheersfactoren kun je concluderen dat het project een succes is. Het is binnen de tijd en budget afgerond en het voldoet aan de gestelde kwaliteit. De reacties vanuit het veld laten echter een ander beeld zien.
Scoren op succesfactoren In bijlage drie wordt een overzicht gegeven van de succesfactoren van (ICT) projecten. Aan de hand van een aantal stellingen wordt bekeken of de belangrijkste succesfactoren goed zijn opgepakt c.q. toegepast binnen het project BVH.
Hoofdstuk 4
Basisvoorziening Handhaving (BVH)
De stellingen met betrekking tot de succesfactoren zijn ondergebracht in de drie componenten van de driehoek van verbondenheid, te weten:
Organisatie; het automatiseringsproject moet aansluiten bij de strategie, processen en/of taken van de organisatie. Het moet een bijdrage leveren aan (het verbeteren) van de doelstellingen van de organisatie c.q. het eenvoudiger maken van de werkzaamheden.
Projectmanagement; deze component geeft invulling aan de projectmatige aanpak die noodzakelijk is. De opdrachtgever die betrokken is, het toepassen van een projectmethodiek, de aanwezigheid van duidelijke doelstellingen, planning, sturing etc.
Procesmanagement; deze component geeft invulling aan het sociale aspect van een automatiseringsproject. Het tijdig betrekken van de gebruikers, rekening houden met de cultuur van een organisatie, managen van verwachtingen etc.
De succesfactoren worden weergegeven middels stellingen en gewaardeerd met een score (1 t/m 5) om aan te geven of de succesfactor goed is opgepakt binnen het project.
De waardering van de scores is als volgt: 1: volledig mee oneens 2: mee oneens 3: niet mee eens/niet mee oneens 4: mee eens 5: volledig mee eens
Toelichting ‘scoren stellingen’ De score (1 t/m 5) die een stelling krijgt, wordt bepaald door de auteur van deze scriptie. Dit gebeurt op basis van de aanwezige literatuur. Na het ‘scoren van de stellingen’ wordt per onderdeel (met behulp van de literatuur) toegelicht waarom een stelling de desbetreffende score heeft gekregen. Met de scores 1 t/m 5 wordt getracht een indicatie te geven in welke mate de (kritieke) succesfactoren goed zijn opgepakt binnen het project. Als een succesfactor niet of slecht is opgepakt, krijgt het de score één. Een succesfactor welke wel is opgepakt, maar niet voldoende, scoort een twee. Een stelling waarvan de situatie onbekend is c.q. niet goed en niet slecht is opgepakt (‘hangt er tussen in’) scoort een drie. Indien een succesfactor voldoende goed is opgepakt, dan krijgt deze de score vier. Tenslotte scoort een succesfactor die zeer goed is opgepakt een vijf (het gaat hier niet om ‘de perfecte situatie’, maar meer om een optimale invulling van de succesfactor).
39
Hoofdstuk 4
Succesfactor
Basisvoorziening Handhaving (BVH)
1
2
3
4
5
Organisatie Het systeem wordt als beter beschouwd dan de praktijk die het moet vervangen Het systeem sluit goed aan bij de uit te voeren taken/ werkprocessen Het systeem is eenvoudig te begrijpen en niet ingewikkeld in het gebruik (gebruiksvriendelijkheid) Het systeem is beschikbaar en betrouwbaar Projectmanagement Er wordt een projectmethodiek toegepast De opdrachtgever is betrokken bij het project (ziet het belang van het project) Duidelijke opdrachtnemer die de touwtjes in handen heeft (zorgt voor sturing) Doelstellingen en opdracht zijn duidelijk en bekend Er is een planning met mijlpalen Taken, verantwoordelijkheden en bevoegdheden van betrokken actoren zijn bekend Er is sprake van een goede communicatie, over: de werking, het doel en de voortgang. Voldoende en juiste capaciteit is beschikbaar voor het project Er vindt één verandering tegelijkertijd plaats in de organisatie (de diverse projecten zijn op elkaar afgestemd) Procesmanagement Gebruikers zijn tijdig bij het project betrokken Gebruikers zijn voldoende en gestructureerd bij het project betrokken De gebruiker heeft invloed gehad op het proces De gebruikers zijn goed opgeleid voor het systeem De verwachtingen zijn bij alle betrokkenen goed gemanaged Voldoende ruimte/tijd voor: gewenning, het testen van het systeem, bijsturingmogelijkheden tijdens de rit (goede voorbereiding en begeleiding). Wilskracht, vertrouwen, openheid, eerlijkheid, respect zijn centrale waarden binnen het project. Toelichting score succesfactoren Per component wordt hier onder beschreven waarom de succesfactoren een bepaalde score hebben gekregen.
Organisatie Alle stellingen van de component organisatie scoren ‘mee oneens’. Dit betekent dat niet wordt voldaan aan de succesfactoren op het gebied van organisatie. Oftewel de invoering van het systeem
40
Hoofdstuk 4
Basisvoorziening Handhaving (BVH)
BVH sluit niet voldoende aan bij de processen en taken van de organisatie en/of maakt het werken niet eenvoudiger. De opdrachtnemer – vtsPN – geeft dit zelf ook weer in een reactie in hun organisatieblad32: ‘We ontdekten tijdens de rit dat de werkprocessen per korps flink kunnen verschillen. Dit probleem is fors onderschat.’ De portefeuillehouder van de korpschefs verwoord dit als volgt: ‘de invoering betreft niet alleen een technisch aspect, van de gebruikers wordt ook een nieuwe werkwijze verwacht met allerlei nieuwe formulieren en nieuwe volgorden. Behalve wat kinderziektes moeten de gebruikers ook wennen aan een nieuwe werkwijze.’
De gebruikers uiten hun ongenoegen over het systeem onder andere op internet en via het Zwartboek BVH (ACP, januari 2010). Veel voorkomende klachten zijn:
toename van de administratieve rompslomp, men doet twee tot drie keer zo lang over een administratief proces dan in het verleden;
veel meer invoer dan in het oude systeem BPS;
minder functionaliteit met BVH dan met Xpol en BPS;
cruciale informatie komt niet terecht bij de agenten op straat;
systeem is gebruiksonvriendelijk;
aangiftes gaan verloren;
het systeem sluit niet aan bij de praktijk;
systeem zit niet logisch in elkaar;
systeem loopt veelvuldig vast of je wordt eruit gegooid.
Het is duidelijk dat deze succesfactoren niet goed terugkomen in het project. Aangezien de problematiek echter wel wordt onderkend en er geen sprake is van het feit dat de BVH in het geheel niet aansluit bij de werkzaamheden, scoren deze onderdelen een twee.
Projectmanagement Uit de stukken is niet te herleiden of er een projectmethodiek is toegepast en zo ja welke. Wel is er sprake van een betrokken opdrachtgever die het belang van BVH inziet. De betrokkenheid van de opdrachtgever (Raad van Hoofdcommissarissen) blijkt uit de reacties die gegeven worden in diverse interviews. De korpschef die als portefeuillehouder optreedt namens de hoofdcommissarissen geeft aan dat: ‘ze vertrouwen hebben in de verdere implementatie van het systeem.’ Daarnaast geeft de 32
Scope, juni 2009, pagina 18;
41
Hoofdstuk 4
Basisvoorziening Handhaving (BVH)
korpschef aan dat ‘hij zich niet herkent in het gegeven dat BVH niet gebruiksvriendelijk is, niet zou werken en te snel wordt ingevoerd. De invoering van het systeem gebeurt in nauw overleg met de Korpsbeheerdersraad en de Raad van Hoofdcommissarissen en het betrokken korps.’ De opdrachtnemer (vtsPN) is bekend, zij werken met een strakke planning en zetten veel capaciteit in. Er is tevens gekozen voor een scherpe afbakening van de taken die thuishoren bij de vtsPN en welke thuishoren bij de korpsen zelf. Door deze strakke sturing en afbakening is het project afgerond binnen de gestelde planning en budget. Er zijn echter een aantal kanttekeningen te plaatsen, waardoor op deze stellingen geen vijf gescoord wordt, te weten:
Er is voor gekozen om een deel van de werkzaamheden te beleggen bij vtsPN en een deel bij de korpsen zelf (met name het opleiden en begeleiden van de gebruikers). De vraag is of er hierdoor voldoende en juiste capaciteit beschikbaar is geweest op het juiste moment. Bij de opleiding en begeleiding zijn een aantal problemen naar voren gekomen.
De Werkgroep gebruik basisvoorzieningen33 constateert dat: opleiding en begeleiding van de gebruiker intensiever, langduriger en meer op maat had mogen plaatsvinden. Met name lijkt behoefte te bestaan aan begeleiding op de werkvloer waardoor gebruikers tijdens het gebruik van de systemen geholpen worden bij onduidelijkheden.’
De succesfactoren doel, opdracht en planning komen goed aan bod in het project. Dit komt met name doordat er duidelijke (samenwerkings)afspraken zijn gemaakt tussen de ministers van BZK en Justitie en korpsbeheerders en dat deze gezien worden als een harde randvoorwaarde. Vandaar dat deze onderdelen een vijf scoren.
In paragraaf 4.1 bij de beschrijving van het project, is het doel van het project reeds beschreven. Ondanks dat de doelstelling duidelijk is beschreven, is de communicatie over deze doelstelling niet goed verlopen. De werkgroep gebruik basisvoorzieningen34 beschrijft dit als volgt: ‘Het feit dat een gebruiksverbetering van de systemen nooit onderdeel uitmaakte van de doelstelling (niet vernieuwing maar standaardisatie) is niet duidelijk gecommuniceerd en/of niet duidelijk aangekomen bij de gebruiker.’ Daarnaast constateert de werkgroep dat niet goed gecommuniceerd wordt over de voortgang naar aanleiding van klachten en signalen. ‘Er zijn geen concrete acties en verbeteringen zichtbaar.’ De werkgroep adviseert dan ook om ‘richting de gebruiker concrete resultaten op korte termijn merkbaar en zichtbaar te laten zijn.’
33
Werkgroep gebruik basisvoorzieningen, 2009, pagina 7;
34
Werkgroep gebruik basisvoorzieningen, 2009, pagina 8 en 10;
42
Hoofdstuk 4
Basisvoorziening Handhaving (BVH)
Het gegeven dat er wel aandacht is besteed aan communicatie (in het blad Scope van vtsPN wordt – gedurende de looptijd van het project – in elke nummer aandacht besteed aan BVH), maakt dat deze succesfactor geen één scoort, maar een twee. Een hogere score kan niet worden gegeven gezien het belang van de communicatie over de doelstelling en de voortgang van het project. Daarnaast lijkt de ‘formele’ communicatie op sommige onderdelen tegenstrijdig te zijn aan de geluiden die in het land gehoord worden. In de inleiding van dit hoofdstuk zijn een aantal koppen geciteerd die duiden op ontevredenheid met het systeem (‘Chaos’ bij politie door nieuw computersysteem, BVH: “het houdt je van de straat”, ‘Nieuw computersysteem politie werkt niet goed’), terwijl vtsPN communiceert dat het project een succes is.
Tenslotte scoort de stelling van één verandering tegelijkertijd niet goed omdat gezien de grootte van het project BVH het niet verstandig lijkt om naast dit project nog een aantal grote projecten uit te rollen. Dit is echter wel gebeurd. De implementatie van BVH loopt gelijktijdig met de implementatie van de nieuwe systemen Basisvoorziening opsporing en Basisvoorziening capaciteitsmanagement.
Procesmanagement De betrokkenheid van de gebruikers bij het project scoort slecht. Enerzijds blijkt dit uit het late tijdstip waarop het Korpsbeheerdersberaad en de Raad van Korpschefs een werkgroep instellen voor het gebruik van de ICT-basisvoorzieningen (15 oktober 2009, terwijl het project is gestart in januari 2008). Anderzijds blijkt dit uit het gevoel dat de gebruikers zelf hebben35:
het systeem is te snel ingevoerd, de gebruikers zijn hier te weinig bij betrokken;
de gebruiker heeft het gevoel dat er weinig tot niets is gebeurd met de afgegeven klachten, signalen en verbetervoorstellen over het gebruik van de systemen;
lijkt of alleen ICT-ers zijn betrokken bij de ontwikkeling en geen gebruikers;
korpsen zijn niet voldoende voorbereid op de komst van BVH en wat ervan verwacht moest worden.
Doordat de gebruikers het gevoel hebben dat ze niet voldoende zijn betrokken, scoren deze onderdelen een twee.
Er heeft een opleiding plaatsgevonden, maar zoals reeds eerder is aangegeven wordt deze niet als voldoende ervaren. Wel is er structurele aandacht en voorbereiding voor dit onderdeel zichtbaar. Waardoor deze stelling een drie scoort.
35
Bron: advies werkgroep gebruik basisvoorzieningen (november 2009)
43
Hoofdstuk 4
Basisvoorziening Handhaving (BVH)
Een punt dat als belangrijke oorzaak wordt aangegeven voor de ontstane hectiek is het gegeven dat de verwachtingen niet goed gemanaged zijn. De werkgroep gebruik basisvoorzieningen36 geeft in haar advies aan dat: ‘gebruikers hadden hogere verwachtingen bij de introductie van de nieuwe systemen, dan waargemaakt konden worden. Veel gebruikers verwachten een aanzienlijke verbetering van de systemen. Er is onvoldoende aandacht besteed aan het managen van verwachtingen. Dit valt te verklaren vanuit de opdracht. Deze was om vanuit een bestaand systeem te werken en dit als gestandaardiseerd systeem bij de korpsen te introduceren. Het verbeteren van de gebruiksvriendelijkheid heeft de implementatie nooit als primair doel gehad. Deze innovatieslag zal en kan pas plaatsvinden nadat alle korpsen hetzelfde werkproces hanteren en hiervoor hetzelfde systeem hanteren. Het feit dat een gebruiksverbetering van de systemen nooit onderdeel uitmaakte van de doelstelling (niet vernieuwing maar standaardisatie) is niet duidelijk gecommuniceerd en/of niet duidelijk aangekomen bij de gebruiker.’ Aangezien er een dergelijk groot verschil is geconstateerd tussen de verwachtingen van de gebruikers en de doelstelling van het project, scoort deze succesfactor een één.
Bij de waarden van het project lijkt vooral de beeldvorming die de functionaris op straat heeft van de vtsPN parten te spelen. Uit de bronnen op internet blijkt dat het beeld over vtsPN niet positief is:
het vertrouwen in de organisatie (vtsPN) is in het verleden al meerdere keren opgezegd;
de vtsPN wordt binnen de politie niet voor niets Voorziening tot Sabotage Politie Nederland genoemd. ICT moet ondersteunend zijn en daarvan is bij de politie sinds de oprichting van het ISC al geen sprake meer. Alles wordt groot en mega bureaucratisch en het kost bovendien bakken met geld;
grote lijn in het geheel is dat er een centrale club, vtsPN is ontstaan, die wellicht op papier grote efficiencyslagen maakt, maar in de praktijk een naar binnen gekeerde focus heeft op technieken, systemen en processen, waarbij het volslagen irrelevant is of het werk er beter van wordt.
Door het gebrek aan vertrouwen in de opdrachtnemer, scoort dit onderdeel een twee.
Op basis van bovenstaande analyse van de succesfactoren binnen het project BHV, kunnen de succesfactoren van het project samengevat worden in de driehoek van verbondenheid. In dit model wordt een waardering op twee niveaus gegeven:
groen: een component welke goed is opgepakt en van invloed is op het succes van een project;
36
Werkgroep gebruik basisvoorzieningen, 2009, pagina 7;
44
Hoofdstuk 4
Basisvoorziening Handhaving (BVH)
rood: een component waarbij problemen zijn opgetreden en welke van invloed zijn op het falen van een project.
Voor het BVH project ziet dit er als volgt uit:
Organisatie
Driehoek van Verbondenheid Projectmanagement
Procesmanagement
Figuur8 Driehoek van Verbondenheid toegepast op BVH project (Kiel 2010, gebaseerd op ‘Duivelsdriehoek van Noordam)
4.3 Analyse Als naar de beheersfactoren tijd, budget en kwaliteit wordt gekeken, dan kan geconcludeerd worden dat het project BVH een succes is. Het project is binnen de tijd en het budget afgerond en heeft een eerste basis gelegd voor één systeem binnen politie Nederland dat op termijn zal leiden tot verbetering van de informatiehuishouding. Ondanks het feit dat het project als succesvol geclassificeerd kan worden, is de beleving – in vooral de media en bij de gebruikers – dat het project niet succesvol is. Politieagenten klagen steen en been over de performance van het systeem en men maakt zich ongerust over de eigen veiligheid. Om dit te verklaren, moet gekeken worden naar de succes- en faalfactoren van het project.
De belangrijkste reden voor deze andere beleving moet gezocht worden in het verwachtingenmanagement, wat zich vervolgens uit in een slechte waardering voor de componenten organisatie en procesmanagement.
Het gevolg van het niet goed managen van de verwachtingen bij de gebruikers is dat men een gebruiksverbetering van het systeem verwachtte, terwijl dit nooit onderdeel uitmaakte van de doelstelling. Door deze verwachting zijn er veel klachten gekomen over de component organisatie. Een automatiseringsproject moet aansluiten bij de strategie, processen en taken van de organisatie.
45
Hoofdstuk 4
Basisvoorziening Handhaving (BVH)
Het moet een bijdrage leveren aan (het verbeteren) van de doelstellingen van de organisatie c.q. het eenvoudiger maken van de werkzaamheden. BVH wordt niet ervaren als een systeem dat de werkzaamheden eenvoudiger maakt. Veel klachten vanuit de politiefunctionarissen zijn hiernaar toe te herleiden: administratieve rompslomp, je doet er nu twee tot drie keer langer over, het systeem is gebruiksonvriendelijk, niet alle benodigde informatie komt beschikbaar, dubbele werkzaamheden etc. Doordat het systeem de (huidige) werkzaamheden niet voldoende ondersteunt (in de beleving van de gebruiker) is een versterkte reactie binnen de component procesmanagement zichtbaar. Gebruikers voelen zich niet gehoord, geven aan niet tijdig betrokken te zijn en weinig vertrouwen in de organisatie te hebben. Men klaagt over de begeleiding, opleiding, snelheid van implementatie en de gebruiksvriendelijkheid van het systeem.
Was aan het begin van het project duidelijk gemaakt dat eerst de nadruk zou liggen op standaardisatie (wat tijdelijk kan leiden tot ongemak) en daarna toegewerkt wordt naar een systeem dat de werkzaamheden beter ondersteund, dan was de kans aanwezig geweest dat men in het land met meer begrip had gereageerd. Al geldt hierbij dat dan ook voldoende duidelijk moet worden gemaakt wanneer men wel een verbetering van het systeem kan verwachten.
4.4 Conclusie Op basis van de casus BVH kunnen twee conclusies getrokken worden, te weten: 1. Om een automatiseringsproject in zowel de beleving van de opdrachtgever als van de gebruiker succesvol te laten zijn, ben je er niet door alleen een kwalitatief hoogwaardige projectorganisatie neer te zetten. Ook de componenten organisatie en procesmanagement spelen een belangrijke rol. 2. Binnen de componenten organisatie en procesmanagement ligt vooral binnen procesmanagement een belangrijke uitdaging: het managen van de verwachtingen waarbij goede communicatie zeer belangrijk is. Daarnaast is het belangrijk om de gebruikers tijdig en voldoende te betrekken bij het project.
46
Hoofdstuk 5
Hoofdstuk 5
C2000
C2000
C2000 is een landelijk communicatienetwerk voor de hulpverleningsdiensten dat het oude analoge netwerk moet vervangen. De politie, ambulancediensten, de brandweer en de marechaussee maken gebruik van dit systeem. De bestaande netwerken hadden te weinig gesprekscapaciteit, daarnaast worden ze slecht beveiligd en boden te weinig functionaliteit. Bovendien waren ze niet bedacht op communicatie tussen de verschillende diensten en zaten ze in de laatste fase van hun economische en technische levensduur.
Projectbeheersing C2000 was onder de maat Informatie aan Tweede Kamer geeft te rooskleurig beeld Persbericht | 17-06-2003 De Algemene Rekenkamer verwacht dat het C2000-project niet op 1 januari 2004 klaar is. Ook de staatssecretaris van BZK heeft dit zeer onlangs aan de Tweede Kamer gemeld.
Communicatienetwerk C2000 en Geïntegreerd Meldkamersysteem Gepubliceerd op: 24 maart 2005
De minister van BZK is zijn toezeggingen over het project C2000/GMS grotendeels nagekomen. Uit de bevindingen van de Audit Dienst van BZK blijkt onder meer dat de opzet van de huidige projectorganisatie toereikend wordt geacht om de projectdoelstellingen te realiseren. Ook de informatievoorziening aan de Tweede Kamer voldoet nagenoeg aan alle in de Procedureregeling Grote Projecten gestelde eisen.
Weer kritiek op C2000 (september 2009, bron: parool.nl) TE
AMSTERDAM - Politievakbond ACP wil dat er direct een alternatief communicatiesysteem voor hulpverleners in gebruik wordt genomen. Dat zei voorzitter Gerrit van de Kamp vrijdag naar aanleiding van het rapport van de Inspectie Openbare Orde en Veiligheid over de aanslag in Apeldoorn. Hierin staat dat het communicatienetwerk C2000 na de aanslag haperde. Het is de vierde keer in korte tijd dat er ernstige tekortkomingen aan het systeem worden gemeld. ''We maken ons ernstige zorgen over de problemen met C2000'', aldus Van de Kamp. ''Het is de afgelopen tijd diverse keren voorgekomen dat het systeem er op cruciale momenten uit ligt.
47
Hoofdstuk 5
C2000
Het project C2000 is een project dat de gemoederen reeds lange tijd bezighoudt. Tijdens de implementatie van het project, maar ook nu nog wordt kritisch gekeken naar het functioneren van het netwerk. De grootte van het project en het aantal jaar dat het project geduurd heeft, maakt het project tot een interessante casus. Welke tussentijdse leermomenten zijn er geweest en welke acties zijn ondernomen om het project te verbeteren? Na een korte (feitelijke) beschouwing van het project, wordt gekeken naar het succes en falen en de mogelijke succesfactoren37. Waarna het hoofdstuk wordt afgesloten met een analyse en conclusie.
5.1 Het project C2000 Opdrachtgever en opdrachtnemer Het ministerie van BZK was coördinerend opdrachtgever voor C2000 en heeft om invulling te geven aan zijn rol als opdrachtgever, een ambtelijk projectbureau ingericht. BZK vervulde een dubbelrol als opdrachtgever en opdrachtnemer. De opdracht voor het realiseren en beheren van de beoogde C2000 infrastructuur werd belegd bij het agentschap ITO.
Doelstelling De Algemene Rekenkamer38 omschrijft het doel als volgt: ‘Het oplossen van bestaande knelpunten in de communicatievoorzieningen van de verschillende overheidsdiensten in de veiligheidsketen waardoor een sneller en effectievere hulpverlening aan burgers mogelijk wordt; Het versterken van de samenhang tussen de brandweer, ambulancediensten en politie; Het scheppen van nieuwe grensoverschrijdende mogelijkheden.’ In het Rapport eindevaluatie C200039 wordt de doelstelling van het project C2000 als volgt omschreven:
‘Definitie, selectie en inrichting van het C2000 netwerk voor hulpverleningsdiensten. Het moet een oplossing bieden voor de problemen die in de analoge situatie ten aanzien van capaciteit en functionaliteit bestonden.
37
Voor de analyse is gebruik gemaakt van diverse documenten die op internet beschikbaar zijn, te weten: Rapport eindevaluatie C2000 (BZK, 2006), Communicatienetwerk C2000 en Geïntegreerd meldkamersysteem (Tweede Kamer, 2002/2003), Multidisciplinaire Slotscenario C2000, eindrapportage (Veiligheidsregio Rotterdam-Rijnmond, 2006), Eindrapportage expertgroep C2000 (BZK, 2009); 38
Algemene Rekenkamer, 2003, pagina 9 en 10;
39
Ministerie van BZK, 2006, pagina 9 en 10;
48
Hoofdstuk 5
C2000
49
Daarnaast moet het voldoen aan de eisen van de dagelijkse hulpverlening en bijdragen aan de handhaving van de openbare orde en veiligheid.’
Verloop project 1996 -1999 April 1996: start project. 1996: Functioneel Programma van Eisen opgesteld door BZK. 1999: Landelijke stuurgroep (LSG) opgericht (eerste vertegenwoordiging van de gebruikers).
2000 Planning: dit jaar gaat de startregio operationeel. Projectorganisatie is op een aantal punten verbeterd (personele versterking, verbetering risicomanagement, afstemming BZK en LSG), maar communicatie blijft onvoldoende.
2001 9 November: formele go voor de landelijke uitrol van C2000. November: een eerste, goed onderbouwde schatting van de kosten is beschikbaar. Oprichting gebruikersraad.
1999: eerste projectplan opgesteld. 1999: de ramingen (projectbegroting) worden bijgesteld. 2003 Doorstart C2000 Invoering C2000 in Limburg Zuid en de startregio. Oprichting Projectdirectie C2000. Doelstelling van 1996 verder geconcretiseerd. De regionale en landelijke planningen zijn op elkaar afgestemd. Maart: Algemene Rekenkamer houdt enquête onder de gebruikers. December: intentieverklaring C2000 getekend en oprichting OBO (Operationeel Bestuurlijk overleg).
2004 1 januari: de implementatie, uitrol en in gebruik name van C2000 door de regio’s moeten – volgens de planning – zijn afgerond.
Eind 2004: het merendeel van de regio’s start met operationeel gaan.
2005 1 januari: volgens de bijgestelde planning zou het merendeel van de regio’s operationeel zijn. 1 juli: TetraNed heeft het landelijke C2000 netwerk opgeleverd. 31 december: alle regio’s met uitzondering van Haaglanden gebruikt C2000.
2002 Instelling BIR (bestuurlijke informatieronde). Oprichting van de Samenwerkende Landelijke Opleidings Instituten (SLOI). De informatievoorziening en rapportages verbeteren. December: Tweede Kamer geeft de Algemene Rekenkamer opdracht een onderzoek in te stellen naar het C2000 project. 2006 Eerste maanden 2006: Haaglanden operationeel gegaan. Voorjaar: OBO wordt getransformeerd in de Raad MIV. Mei: rapport eindevaluatie C2000 (BZK). 8 juni: Multidisciplinair Slotscenario C2000 (MDS) in Rotterdam. 1 Juli: opheffing projectdirectie C2000. DMD wordt ondergebracht bij vtsPN. Alle C2000 opleidingen zijn geëvalueerd.
Hoofdstuk 5
2007
2008
2009
C2000
50
2010
22 December:
Mei: eindrapportage
eindrapportage
DMO NVBR/BZK.
expertgroep C2000 – BZK
Opvallend in het verloop van het project is de knip die zichtbaar is in 2003 (‘Doorstart C2000’). De projectmatige aanpak in de periode van 1996 tot 2003 verliep niet goed. Onder andere doordat verschillende projectorganisaties gebruik maakten van verschillende projectmanagement methodieken. Om deze situatie te verbeteren is in 2003 de projectdirectie C2000 opgericht.
5.2 Succes en falen Nu we op hoofdlijnen weten hoe het project eruit ziet, gaan we bekijken of het project een succes is en zo ja, wat mogelijke succes- en/of faalfactoren zijn. Om te beoordelen of het om een succesvol project gaat en welke factoren van invloed zijn op het eventuele succes, wordt het project op twee niveaus geanalyseerd: 1. de beheersfactoren; voldoet het project aan de gestelde beheerscomponenten tijd, geld en kwaliteit; 2. de succesfactoren; welke succesfactoren zijn aanwezig binnen het project. De succesfactoren worden – conform de theorie – onderverdeeld in drie componenten: organisatie, projectmanagement en procesmanagement.
De beheersfactoren Er wordt gekeken naar de formulering van de componenten tijd, geld en kwaliteit bij aanvang van het project en naar de daadwerkelijke invulling aan het einde van het project.
Aanvang project Tijd (T)
Einde project
De implementatie, uitrol en in gebruik name
Het project heeft over de gehele looptijd een
van C2000 door de regio’s moet op 1 januari
vertraging opgelopen van twee jaar.
2004 zijn afgerond.
Opheffing projectdirectie C2000 per 1 juli 2006.
Geld (G)
Geraamde investeringskosten: € 598,5
Daadwerkelijke kosten: € 765,3 miljoen.
miljoen.
Het budget is overschreden met € 166,8 miljoen.
Hoofdstuk 5
Aanvang project Kwaliteit (K)
Definitie, selectie en inrichting van het
C2000
51
Einde project De doelstelling van het project C2000 is
C2000 netwerk voor hulpverlenings-
behaald. Het netwerk is gedefinieerd,
diensten.
geselecteerd en ingericht en door alle regio’s
Oplossing bieden die in de analoge
en de landelijke diensten operationeel in
situatie bestaan ten aanzien van capaciteit gebruik genomen. Het netwerk heeft de en functionaliteit. Voldoen aan de eisen van de dagelijkse hulpverlening. Versterken van samenhang tussen brandweer, ambulancediensten en politie.
problemen van analoge netwerken ten aanzien van capaciteit, informatie-uitwisseling, functionaliteit en beveiliging opgelost. Ook grensoverschrijdende communicatie is mogelijk.
Scheppen van grensoverschrijdende mogelijkheden.
Op basis van de beheersfactoren kun je concluderen dat het C2000 project geen succesvol project is. Het project voldoet wel aan de gestelde kwaliteit, maar is niet binnen het budget en de geplande tijd afgerond.
Scoren op succesfactoren In bijlage drie wordt een overzicht gegeven van de succesfactoren van (ICT) projecten. Aan de hand van een score wordt bekeken of de belangrijkste succesfactoren goed zijn opgepakt c.q. toegepast binnen het project C200040.
De succesfactoren worden weergegeven met stellingen. Middels een score van 1 t/m 5 kan per stelling worden aangegeven of deze goed zijn opgepakt of niet. 1: volledig mee oneens 2: mee oneens 3: niet mee eens/niet mee oneens 4: mee eens 5: volledig mee eens
40
C2000 is veelvuldig in het nieuws. Bij het beoordelen van de succesfactoren worden de huidige ontwikkelingen echter niet meegenomen. Er wordt bij de beoordeling alleen gekeken naar de projectperiode (1996 – 2006).
Hoofdstuk 5
C2000
Opmerking: aangezien er binnen het project een duidelijke knip is waar te nemen op het gebied van projectmanagement (de periode voor 2003 en vanaf 2003), wordt dit onderscheid ook toegepast bij het scoren op de succesfactoren. De situatie voor 2003 wordt aangegeven met de oranje vakjes, de periode vanaf 2003 wordt aangegeven met de blauwe vakjes.
Succesfactor
1
2
3
4
5
Organisatie Het systeem wordt als beter beschouwd dan de praktijk die het moet vervangen Het systeem sluit goed aan bij de uit te voeren taken/ werkprocessen Het systeem is eenvoudig te begrijpen en niet ingewikkeld in het gebruik (gebruiksvriendelijkheid) Het systeem is beschikbaar en betrouwbaar Projectmanagement Er wordt een projectmethodiek toegepast De opdrachtgever is betrokken bij het project (ziet het belang van het project) Duidelijke opdrachtnemer die de touwtjes in handen heeft (zorgt voor sturing) Doelstellingen en opdracht zijn duidelijk en bekend Er is een planning met mijlpalen Taken, verantwoordelijkheden en bevoegdheden van betrokken actoren zijn bekend Er is sprake van een goede communicatie, over: de werking, het doel en de voortgang. Voldoende en juiste capaciteit is beschikbaar voor het project Er vindt één verandering tegelijkertijd plaats in de organisatie (de diverse projecten zijn op elkaar afgestemd) Procesmanagement Gebruikers zijn tijdig bij het project betrokken Gebruikers zijn voldoende en gestructureerd bij het project betrokken De gebruiker heeft invloed gehad op het proces De gebruikers zijn goed opgeleid voor het systeem De verwachtingen zijn bij alle betrokkenen goed gemanaged Voldoende ruimte/tijd voor: gewenning, het testen van het systeem, bijsturingmogelijkheden tijdens de rit (goede voorbereiding en begeleiding). Wilskracht, vertrouwen, openheid, eerlijkheid, respect zijn centrale waarden binnen het project. Toelichting score succesfactoren Per component wordt hieronder beschreven waarom de succesfactoren een bepaalde score hebben gekregen.
52
Hoofdstuk 5
C2000
Organisatie Bij de oplevering van het project voldoet C2000 grotendeels aan de geformuleerde functionele eisen en zijn de gebruikers tevreden. Uit de eindrapportage van het multidisciplinair slotscenario C200041 blijkt dat ‘een groot deel van de gebruikers (75%) neutraal of positief reageert op de vraag of C2000 hem of haar goed ondersteunt bij zijn of haar werkzaamheden’. Men ziet het als een prima middel ter ondersteuning van de werkzaamheden in de dagelijkse praktijk (er is op de meldkamers meer overzicht in de aansturing, er is een betere dekking, de werkprocessen worden beter ondersteund en multidisciplinaire communicatie tussen de hulpverleningsdiensten is geen probleem meer). De enige beperking – waardoor op dit punt een vier wordt gescoord – is het feit dat op sommige locaties in Nederland nog sprake is van verminderde dekking en feit dat er problemen zijn met de pagers.
Projectmanagement Het onderdeel projectmanagement kent ‘twee gezichten’ binnen het project C2000. Enerzijds is er de situatie voor 2003, die zich kenmerkt doordat verschillende organisaties verschillende projectmanagementmethodieken toepassen. Anderzijds is er de situatie vanaf 2003, het jaar waarin de projectdirectie C2000 wordt opgericht. In het rapport eindevaluatie C200042 wordt geconcludeerd dat het toepassen van verschillende projectmanagementmethodieken (voor 2003) tot gevolg had dat:
‘de taken en verantwoordelijkheden van de diverse partijen niet helder belegd waren;
partijen verschillende rollen vervulden;
de centrale projectorganisatie ver af stond van de bestuurlijk verantwoordelijke, wat een beperkte betrokkenheid van laatst genoemde tot gevolg had;
er geen sturing op het proces en de resultaten was.’
Aangezien het toepassen van verschillende projectmanagement methodieken de afstemming en de overall sturing op het project belemmerde (maar de toepassing van een projectmethodiek wel zichtbaar was), scoort dit onderdeel voor 2003 tussen de één en drie.
Zowel in het rapport eindevaluatie C2000 (BZK, mei 2006) als in het onderzoek van de Algemene Rekenkamer (2003) wordt geconcludeerd dat de aanvankelijke doelstelling van het project C2000 41
Veiligheidsregio Rotterdam-Rijnmond, 2006, pagina 3;
42
Ministerie van BZK, 2006, pagina 9;
53
Hoofdstuk 5
C2000
veel ruimte voor interpretatie liet. Tussen 1996 en 2003 is de doelstelling niet verder geconcretiseerd en geformaliseerd. In de voortgangsrapportages en kamerbrieven is de projectdoelstelling in de loop van de jaren zelfs op verschillende wijze geformuleerd. Dit heeft geleid tot ruimte voor interpretatie, waardoor de verwachtingen die de verschillende partijen in C2000 hadden, uiteen liepen. De Rekenkamer constateerde in 2003 dat de projectdoelstelling gaandeweg een andere inhoud heeft gekregen. Geconcludeerd kan worden dat er een doelstelling bekend was, maar dat deze niet door iedereen hetzelfde geïnterpreteerd werd. Daarom scoort dit onderdeel een drie.
Met de oprichting van de projectdirectie C2000 verbeterde de projectmatige aanpak. Daarom scoort dit onderdeel (vanaf 2003) op bijna alle onderdelen een vijf. De projectdirectie C2000 heeft in 2003 is de doelstelling verder uitgewerkt en meetbaar gemaakt. In december 2003 is een intentieverklaring Project C2000 getekend door de minister van BZK, bestuurders en voorzitters van de koepelorganisaties van de hulpverleningsdiensten. De reden voor deze verklaring was om bij alle betrokken partijen helderheid en overeenstemming te hebben over nut en noodzaak van C2000. Ook bracht het duidelijkheid over de verdeling van de verantwoordelijkheden. Daarnaast is een spoorboekje ontwikkeld met betrekking tot de activiteiten die nog gedaan moesten worden door het veld en/of de projectdirectie C2000. BZK geeft in het rapport eindevaluatie C200043 aan dat ‘met de oprichting van de projectdirectie C2000, het instellen van diverse overlegvormen en het tekenen van een intentieverklaring door het Rijk, gebruikers en bestuurders, ontstond een duidelijke organisatiestructuur en verbeterde de afstemming tussen het centrale en decentrale deel van het project.’
In dezelfde rapportage wordt tevens gesteld dat de informatievoorziening voor 2003 aan de Tweede Kamer onder de maat was. In de rapportages naar de Tweede Kamer is soms verwarring ontstaan over de scope van C2000 en de woordkeuze over het beoogde resultaat. Daarnaast verliep de informatie-uitwisseling met de gebruikers ook niet goed. Uit de in maart 2003 gehouden enquête van de Algemene Rekenkamer onder gebruikers blijkt dat 70% niet tevreden is met de communicatie door ITO, terwijl dit bij communicatie met BZK nog hoger ligt (85%). Hierdoor scoort communicatie (voor 2003) een één.
Met de start van de projectdirectie C2000 is de overlegstructuur met de gebruikers aangepast en verbeterd. In 2006 zijn er echter nog steeds een groot aantal zorgpunten bij de gebruikers en laat de 43
Ministerie van BZK, 2006, pagina 9;
54
Hoofdstuk 5
C2000
communicatie over het project te wensen over. Er is onvoldoende harde informatie over bijvoorbeeld nieuwe softwareversie, de planning van opleidingen van personeel en de gebruiker krijgt ook vaak geen antwoord op aan ITO en BZK gestelde vragen. Ondanks dat met de komst van de projectdirectie C2000 de overlegstructuur verbeterd is, kan niet gezegd worden dat er sprake is van een goede communicatie. In de eindevaluatie wordt geconcludeerd dat ‘de communicatie activiteiten hebben niet het beoogde effect gesorteerd, te weten het creëren van draagvlak en het (tijdig en volledig) informeren van gebruikers over C2000’. Vandaar dat dit onderdeel vanaf 2003 een twee scoort.
De vraag of er voldoende en goede capaciteit is ingezet, is moeilijk in te schatten op basis van de aanwezige gegevens. Wel is duidelijk dat de personele bezetting van het projectbureau na 2003 versterkt is (de projectbeheersing was in de beginfase niet goed onder andere door onvoldoende gekwalificeerd personeel) en dat de aansturing van ITO door BZK onvoldoende was onder andere door een tekort aan expertise. Tevens is niet duidelijk of er één verandering tegelijkertijd plaatsvindt. Hooguit kan geconcludeerd worden dat de invoering niet per discipline plaatsvindt, maar bij alle disciplines tegelijkertijd. Beide onderdelen scoren daarom een drie.
Procesmanagement Uit het rapport van de Tweede Kamer44 blijkt dat bij het project C2000 de gebruikers in eerste instantie aan de zijlijn stonden. Enerzijds omdat BZK in 1996 het Functioneel Programma van Eisen heeft opgesteld en de gebruikers toekeken. Anderzijds zou C2000 eerst op beperkte schaal operationeel beproefd worden in de startregio. Pas als dat tot een goed resultaat zou leiden, zou er sprake zijn van een definitieve go beslissing om het netwerk in de rest van Nederland in te voeren. Dit heeft tot gevolg gehad dat de regio’s en bestuurders zich lange tijd afwachtend hebben opgesteld. De inbreng vanuit het gebruikersveld vond uiteindelijk plaats vanuit een klankbordgroep waarin personen zitting hadden op persoonlijke titel. De betrokken partijen waren dus niet georganiseerd om invulling te geven. Geconcludeerd kan worden dat de betrokkenheid van de gebruikers niet tijdig, voldoende en gestructureerd heeft plaatsgevonden. Daarnaast zijn er geen uitgebreide operationele tests van het systeem geweest waarbij de gebruikers input konden leveren. Aangezien er uiteindelijk wel een zekere mate van betrokkenheid is geweest, scoren deze onderdelen een twee.
44
Tweede Kamer, 2003, pagina 26;
55
Hoofdstuk 5
C2000
Tevens wordt in de eindevaluatie C200045 aangegeven dat er structurele aandacht is geweest voor het opleiden van de gebruikers. ‘In 2002 is besloten om de Samenwerkende Landelijke Opleidingsinstituten (SLOI) op te richten. Deze organisatie had ten doel om voor de regio’s de opleidingen van centralisten en kerninstructeurs voor C2000 te verzorgen. De SLOI heeft het bestaande opleidingsmateriaal opgepakt en verfijnd. In de loop van 2005 is de SLOI afgebouwd. Het opleidingsmateriaal voor C2000 is opgenomen in het reguliere aanbod van de individuele opleidingsinstituten. ITO heeft in deze periode de opleiding van de lokale beheerders op zich genomen. De regio’s hebben via de kerninstructeurs zelf de eindegebruikers opgeleid voor het gebruik van C2000’. Geconcludeerd kan worden dat vanuit het project C2000 voldoende aandacht is besteed aan het organiseren van de opleidingen. Hoe de opleiding binnen de regio’s is verlopen is niet geheel duidelijk, vandaar dat dit onderdeel een vier scoort. BZK geeft in haar rapport Eindevaluatie C200046 weer dat het managen van de verwachtingen niet optimaal is verlopen. ‘Doordat in de praktijk van C2000 vanaf het begin een maximum aan functionaliteit is gedefinieerd, waren de verwachtingen van de gebruikers hoog. Daarnaast liepen de verwachtingen van C2000 sterk uiteen. Dit werd onder andere veroorzaakt door een nog niet uitgekristalliseerde techniek en haar mogelijkheden. Dit leidde tot inconsistente communicatie. ‘ De gebruikers zijn onvoldoende op de hoogte welke functionaliteiten wel en welke niet in C2000 worden geleverd. Ook worden volgens de gebruikers de gewekte verwachtingen ten behoeve van datacommunicatie, vanwege de beperkte bandbreedte van C2000, niet waargemaakt. In een notitie van de Tweede Kamer47 wordt geconcludeerd dat ‘de communicatie activiteiten niet het beoogde effect hebben gesorteerd, te weten het creëren van draagvlak en het (tijdig en volledig) informeren van gebruikers van C2000’. Kortom de verwachtingen zijn niet goed gemanaged. Dit onderdeel scoort dan ook een één.
Ondanks de genoemde problemen is het project uiteindelijk toch tot een goed einde gebracht. Dit is vooral te danken aan de goodwill en inzet die partijen hebben getoond. Verder is niet goed te achterhalen welke waarden nog meer een rol hebben gespeeld binnen het project. Vandaar dat dit onderdeel een drie scoort.
45
Ministerie van BZK, 2006, pagina 53;
46
Ministerie van BZK, 2006, pagina 14 en 79;
47
Tweede Kamer, 2003, pagina 26;
56
Hoofdstuk 5
C2000
Driehoek van verbondenheid Op basis van bovenstaande analyse van de succesfactoren binnen het project BHV, kunnen de succesfactoren binnen het project samengevat worden in driehoek van verbondenheid. In dit model wordt een waardering op twee niveaus gegeven:
groen: een component welke goed is opgepakt en van invloed is op het succes van een project;
rood: een component waarbij problemen zijn opgetreden en welke van invloed zijn op het falen van een project.
Voor het C2000 project ziet dit er als volgt uit:
Organisatie
Driehoek van Verbondenheid Projectmanagement
Procesmanagement
Figuur9 Driehoek van Verbondenheid toegepast op C2000 project (Kiel 2010, gebaseerd op ‘Duivelsdriehoek van Noordam)
5.3 Analyse Als naar de beheersfactoren tijd, budget en kwaliteit wordt gekeken, kan geconcludeerd worden dat het project C2000 geen succes is. Het project voldoet aan de gestelde kwaliteitseisen, maar is niet binnen de tijd en het budget afgerond. Daarnaast kan op het gebied van de geformuleerde kwaliteitseisen gesteld worden dat – gezien de lange looptijd van het project – deze in de loop van de tijd veranderd zijn. De eindevaluatie van BZK48 zegt hierover: ‘Wat de functionaliteit betreft, doet het systeem waar het in 1996 voor bedoeld was. Hierbij moet opgemerkt worden dat de verwachtingen over de gewenste functionaliteit in de jaren is veranderd. Dit als gevolg van de technologische ontwikkelingen. Het gebruikersveld heeft overigens 48
Ministerie van BZK, 2006, pagina 45;
57
Hoofdstuk 5
C2000
nooit om dergelijke aanvullende functies gevraagd. De eisen van de dagelijkse hulpverlening zijn door de maatschappelijke en technologische ontwikkelingen veranderd.’ Deze veranderingen met betrekking tot de gewenste kwaliteit zijn zichtbaar geworden bij de incidenten Poldercrash, Apeldoorn en Hoek van Holland. Naar aanleiding van deze incidenten is door BZK een expertgroep in het leven49 geroepen om het functioneren van C2000 te onderzoeken. Deze groep kreeg de volgende doelstelling mee: ´ Voor het C2000 systeem aan te geven welke acties en maatregelen noodzakelijk zijn om de organisatie, infrastructuur en het gebruik te laten aansluiten bij enerzijds de verwachtingen en eisen van de gebruikers anno 2009 en anderzijds de mogelijkheden en beperkingen van C2000 voor zowel mono- als multidisciplinair gebruik’. Waar de beheersfactor kwaliteit in 2006 nog voldoende scoorde, kan worden geconcludeerd dat in de loop van de tijd de behoefte veranderd is en de gestelde kwaliteitseisen niet meer voldoen.
Door de interventie op het gebied van projectmanagement wordt duidelijk hoe belangrijk het is om een aantal onderdelen op dit gebied goed te organiseren (een eenduidige manier van werken (projectmethodiek), betrokkenheid opdrachtgever en opdrachtnemer, duidelijke doelstelling en duidelijke toebedeling van taken, verantwoordelijkheden, bevoegdheden, goede communicatie etc.).
De aandachtspunten liggen daarnaast vooral op het gebied van procesmanagement. Gebruikers die te laat en/of niet goed betrokken worden bij het project. Hierdoor ontstaat er niet of nauwelijks draagvlak voor het project. Verwachtingen die niet goed gemanaged worden waardoor je nooit kunt voldoen aan het beeld dat de gebruikers hebben.
5.4 Conclusie Op basis van de casus C2000 kunnen de volgende conclusies getrokken worden: 1. Naast de component projectmanagement spelen inderdaad de componenten organisatie en procesmanagement een rol. Dit neemt echter niet weg dat projectmanagement ook serieus moet worden genomen en dat je dit goed moet organiseren. Zonder projectmanagement ontstaat chaos en weet men niet waarom een project er is, hoe het gestelde doel bereikt gaat worden en wie wat doet. 2. De mate waarin een project succesvol is, kan in de loop van de tijd veranderen. Waar de kwaliteitseisen voor C2000 aan het begin van het project (1996) nog voldeden, zijn deze anno nu achterhaald (en waren ze dit eigenlijk ook al aan het einde van het project in 2006).
49
Ministerie van BZK, 2009, pagina 7;
58
Hoofdstuk 5
C2000
3. Ook bij deze casus geldt dat binnen de componenten organisatie en procesmanagement de ‘problemen’ zich voornamelijk voordoen binnen procesmanagement, te weten op het gebied van: het managen van de verwachtingen en het tijdig en goed betrekken van de gebruikers.
59
Hoofdstuk 6
Hoofdstuk 6
De Virtuele kijkdoos
De Virtuele kijkdoos
Naast de twee casus over de grote landelijke projecten, is ook gezocht naar succesvolle automatiseringsprojecten binnen de brandweer. Ondanks het feit dat dit niet eenvoudig is gebleken, worden in dit hoofdstuk en in hoofdstuk zeven twee casus behandeld over automatiseringsprojecten binnen de brandweer.
Enschede: Twee jaar na de ramp (Bron: Nova.nl) De rechtbank haalde in haar vonnis tegen beide directeuren fel uit naar de ambtenaren van de gemeente Enschede en naar het Rijk. Die zijn ernstig tekortgeschoten in het verlenen van vergunningen aan en het controleren van S.E. Fireworks. Zij waren verkeerd geïnformeerd, lieten geconstateerde misstanden voortbestaan en volgden elkaars adviezen niet op, aldus de rechtbank.
1 januari 2001: Cafébrand Volendam (Bron: zwaailichten.org) Kort na middernacht op 1 januari 2001 werden er sterretjes afgestoken in café Het Hemeltje aan de Haven in Volendam. De gortdroge kerstversiering aan het plafond raakt in bra nd. De brand is kort, maar zeer intens. De vluchtwegen in het overvolle café zijn niet voldoende om de in paniek geraakte bezoekers snel naar buiten te krijgen
Naar aanleiding van de rampen in Enschede en Volendam neemt de politieke druk en belangstelling toe voor de vergunningen. In de gemeente Den Haag wordt gewerkt aan een inhaalslag vergunningen (Prevap 1,2,3 en 4). Om dit traject goed vorm te geven is onder andere een systeem nodig waarin de gegevens van de verschillende diensten beschikbaar zijn. Dit deelproject wordt de Virtuele kijkdoos genoemd. In deze casus wordt bekeken hoe het project is verlopen om dit systeem (Virtuele kijkdoos) tot stand te brengen. Na een korte (feitelijke) beschouwing van het project, wordt gekeken naar het succes en falen en de mogelijke succesfactoren50. Waarna het hoofdstuk wordt afgesloten met een analyse en conclusie.
50
De beschrijving en analyse van deze casus vindt plaats op basis van een gesprek dat heeft plaatsgevonden met het hoofd Informatiemanagement & Automatisering van Veiligheidsregio Haaglanden en een notitie van de Bestuursdienst, De voortgang rond de verbetering van de brandveiligheid in Den Haag, juni 2002, Den Haag;
60
Hoofdstuk 6
De Virtuele kijkdoos
6.1 Het project Virtuele kijkdoos Opdrachtgever en opdrachtnemer Het project Virtuele kijkdoos is onderdeel van een groter project binnen de gemeente Den Haag, te weten: het project Brandveiligheid. De projectleider van het project Brandveiligheid werkt rechtstreeks onder de directeur Bestuurszaken. Bestuurlijke aansturing gebeurt door het College van Burgemeester en Wethouders. Door middel van voortgangrapportages houdt de projectleider de Burgemeester en Wethouders op de hoogte van de voortgang van het project. Op ambtelijk niveau is een regiegroep ingesteld die bestaat uit vertegenwoordigers van: de Bestuursdienst, de Brandweer, Dienst Stedelijke Ontwikkeling en de Dienst Stadsbeheer. De regiegroep kent een aantal werkgroepen rondom de verschillende thema’s (het project Virtuele kijkdoos is één van deze thema’s, met het Hoofd Vastgoedinformatie als opdrachtnemer). Voorstellen uit de werkgroepen worden in de regiegroep besproken en vervolgens aan het bestuur voorgelegd ter goedkeuring.
Doelstelling Het doel van het project Virtuele kijkdoos is tweeledig, te weten:
een goede (interne) registratie en overzicht van de vergunningen;
een goede uitwisseling van gegevens tussen de verschillende gemeentelijke diensten (Dienst Stadsbeheer, Dienst Stedelijke Ontwikkeling en Brandweer).
Oftewel de gegevens over objecten moeten beschikbaar zijn voor de verschillende betrokken (gemeentelijke) diensten.
Verloop project Om ervoor te zorgen dat er snel resultaat wordt geboekt en vooral de brandweer over de juiste gegevens kan beschikken (de handhavers), wordt gekozen voor een korte termijn oplossing. Uitgangspunt is een pragmatische benadering waarbij de resultaten snel zichtbaar worden. Hierbij wordt bewust meegenomen dat de kans bestaat dat het gekozen systeem over een jaar vervangen moet worden. Daarnaast is er sprake van een succesvol voorbeeld project (infodesk WOZ) dat als basis wordt gebruikt voor de format van het te ontwikkelen systeem. Op basis van deze format is een prototype gebouwd (hiervoor is een functioneel plan van eisen opgesteld). De planning is om de virtuele kijkdoos vanaf september 2002 in gebruik te nemen.
61
Hoofdstuk 6
De Virtuele kijkdoos
62
6.2 Succes en falen Nu we op hoofdlijnen weten hoe het project eruit ziet, gaan we bekijken of het project een succes is en zo ja, wat mogelijke succes- en/of faalfactoren zijn. Om te beoordelen of het om een succesvol project gaat en welke factoren van invloed zijn op het eventuele succes, wordt het project op twee niveaus geanalyseerd: 1. de beheersfactoren; voldoet het project aan de gestelde beheerscomponenten tijd, geld en kwaliteit; 2. de succesfactoren; welke succesfactoren zijn aanwezig binnen het project. De succesfactoren worden – conform de theorie – onderverdeeld in drie componenten: organisatie, projectmanagement en procesmanagement.
De beheersfactoren Er wordt gekeken naar de formulering van de componenten tijd, geld en kwaliteit bij aanvang van het project en de daadwerkelijke invulling van de tijd, geld en kwaliteit bij het einde van het project.
Aanvang project
Einde project
Tijd (T)
Operationeel september 2002.
Het systeem was operationeel in 2003.
Geld (G)
Het is moeilijk om precies te achterhalen wat
De kosten voor de virtuele kijkdoos zijn
het geraamde budget voor dit project is,
ongeveer € 285.000, hiermee is project binnen
omdat het een onderdeel uitmaakt van het
het budget opgeleverd.
grotere project brandveiligheid. Kwaliteit (K)
Goede interne registratie en overzicht van de vergunningen.
Het systeem voldeed aan de verwachtingen:
Goede uitwisseling van gegevens tussen de verschillende gemeentelijke diensten.
goede interne registratie en overzicht van de vergunningen;
goede uitwisseling van gegevens tussen de diensten.
Het project is qua planning enigszins uitgelopen, maar op de beide andere oordelen scoort het project goed. Op het moment dat het systeem werd opgeleverd, waren de gebruikers tevreden over de kwaliteit van het systeem. In de loop van de tijd zijn er wel meer wensen bij gekomen.
Scoren op succesfactoren In bijlage drie is een weergave gegeven van de succesfactoren van (ICT) projecten. Aan de hand van een score wordt bekeken of de belangrijkste succesfactoren goed zijn opgepakt c.q. toegepast binnen het project Virtuele kijkdoos.
Hoofdstuk 6
De Virtuele kijkdoos
De succesfactoren worden weergegeven met stellingen. Middels een score van 1 t/m 5 kan per stelling worden aangegeven of deze goed zijn opgepakt of niet. 1: volledig mee oneens 2: mee oneens 3: niet mee eens/niet mee oneens 4: mee eens 5: volledig mee eens
Succesfactor Organisatie Het systeem wordt als beter beschouwd dan de praktijk die het moet vervangen Het systeem sluit goed aan bij de uit te voeren taken/ werkprocessen Het systeem is eenvoudig te begrijpen en niet ingewikkeld in het gebruik (gebruiksvriendelijkheid) Het systeem is beschikbaar en betrouwbaar Projectmanagement Er wordt een projectmethodiek toegepast De opdrachtgever is betrokken bij het project (ziet het belang van het project) Duidelijke opdrachtnemer die de touwtjes in handen heeft (zorgt voor sturing) Doelstellingen en opdracht zijn duidelijk en bekend Er is een planning met mijlpalen Taken, verantwoordelijkheden en bevoegdheden van betrokken actoren zijn bekend Er is sprake van een goede communicatie, over: de werking, het doel en de voortgang. Voldoende en juiste capaciteit is beschikbaar voor het project Er vindt één verandering tegelijkertijd plaats in de organisatie (de diverse projecten zijn op elkaar afgestemd) Procesmanagement Gebruikers zijn tijdig bij het project betrokken Gebruikers zijn voldoende en gestructureerd bij het project betrokken De gebruiker heeft invloed gehad op het proces De gebruikers zijn goed opgeleid voor het systeem De verwachtingen zijn bij alle betrokkenen goed gemanaged Voldoende ruimte/tijd voor: gewenning, het testen van het systeem, bijsturingmogelijkheden tijdens de rit (goede voorbereiding en begeleiding). Wilskracht, vertrouwen, openheid, eerlijkheid, respect zijn centrale waarden binnen het project.
1
2
3
4
5
63
Hoofdstuk 6
De Virtuele kijkdoos
Toelichting score succesfactoren Per component wordt hier onder beschreven waarom de succesfactoren een bepaalde score hebben gekregen.
Organisatie Het systeem maakt de werkzaamheden van de vergunningverleners/handhavers gemakkelijker, omdat de medewerkers op deze manier sneller over de benodigde gegevens kunnen beschikken. Door de medewerkers wordt het systeem dan ook gezien als een goede aanvulling op hun werkzaamheden. Daarnaast is de virtuele kijkdoos een expliciete stap geworden in het werkproces. De beschikbaarheid van het systeem werd al tijdens de uitrol van het project aangetoond. Er vond een explosie plaats op de markt in Den Haag. Tijdens dit incident waren de benodigde gegevens snel beschikbaar (voor onder andere de brandweercommandant) via de virtuele kijkdoos. Aangezien het ontwikkelde systeem de werkzaamheden van de brandweer daadwerkelijk en goed ondersteunt, scoort dit onderdeel een vijf op de meeste stellingen. Uitzondering is de stelling ‘het systeem is beschikbaar en betrouwbaar’. Het systeem zelf is betrouwbaar (qua functioneren), maar voor de inhoudelijke kwaliteit van de data is het afhankelijk van gegevens uit achterliggende backoffice systemen. Deze data is niet in alle systemen optimaal, vandaar dat dit onderdeel een drie scoort.
Projectmanagement Er is geen expliciete projectmanagementmethodiek toegepast. Deze methodiek is ook niet gemist. Wel werd meegelift op de projectmethodiek van het grotere project Brandveiligheid. Met name op het gebied van planning en mijlpalen. Daarom scoort dit onderdeel een drie. De rollen van opdrachtgever en opdrachtnemer zijn duidelijk binnen het project. Er vond structureel overleg plaats tussen de opdrachtgever en opdrachtnemer. Daarnaast is er een stuurgroep opgericht met de directeur Bestuurszaken (rechterhand burgemeester) als voorzitter. Op het niveau van de opdrachtgever is veel draagvlak en betrokkenheid bij het project gezien het politieke belang (en de aanleiding) van het project (deze betrokkenheid kwam ondermeer tot uitdrukking bij een oefening met het systeem waar de burgemeester langs kwam om te kijken). Het ‘grote politieke belang’ zorgde ervoor dat er voldoende financiële middelen en capaciteit voor het project beschikbaar waren. Het hoofd van de afdeling Vastgoedinformatie van de dienst Stedelijke Ontwikkeling (DSO) was de opdrachtnemer/projectleider. Hij pakte zijn rol goed op door vooral te sturen op: consensus, motivatie en de verschillende betrokkenen/ belanghebbenden bij elkaar te brengen. Daarnaast bestond bij het Hoofd Preventie en de informatiemanager van de brandweer een grote
64
Hoofdstuk 6
De Virtuele kijkdoos
betrokkenheid om het project tot een goed eind te brengen (men zag het belang van het project en ondersteunde het). Het hoofd Preventie heeft een sterk trekkende rol op zich genomen. Tevens waren de juiste personen op de juiste plek aanwezig (met de juiste expertise). Het doel van het project was voor iedereen snel duidelijk, hier bestond gedurende het project geen onduidelijkheid over. Er was tevens een duidelijke sturing op mijlpalen. De taken, verantwoordelijkheden en bevoegdheden waren vooraf niet duidelijk. Dit is geleidelijk gegroeid. Aangezien aan de meeste succesfactoren van projectmanagement is voldaan, scoort dit onderdeel op veel onderdelen een vijf.
Procesmanagement De gebruikers zijn goed bij het project betrokken. Er zijn prototypesessies gehouden waar de gebruikers het systeem konden testen. Bij deze sessies waren alle drie de diensten betrokken, waardoor ook op dit niveau samenwerking plaatsvond. De gebruikers waren enthousiast over het feit dat ze alle gegevens nu bij elkaar hadden zonder dat ze hier langer achteraan moesten rennen. Vooral de grote betrokkenheid van het Hoofd preventie en de informatiemanager en de motivatie om gezamenlijk iets tot stand te willen brengen, zorgde ervoor dat er concrete stappen werden gezet. Daarnaast stuurde de projectleider procesmatig, hij zorgde ervoor dat de partijen betrokken waren, ‘masseerde’ het proces waar nodig (knopen doorhakken, rol oppakken naar de regiegroep, sterk betrokken, stimulerend, niet te beroerd om te helpen, relationeel sterk) en hij werd door iedereen geaccepteerd. De grote betrokkenheid van diverse medewerkers was een succesfactor voor het project; men wilde iets met elkaar bereiken. Door deze sterke procesmatige aansturing en aanpak, scoort dit onderdeel een vijf op alle stellingen.
Model van verbondenheid Op basis van bovenstaande analyse van de succesfactoren binnen het project Virtuele Kijkdoos, kunnen de succesfactoren van het project samengevat worden in de driehoek van verbondenheid. In dit model wordt een waardering op twee niveaus gegeven:
groen: een component welke goed is opgepakt en van invloed is op het succes van een project;
rood: een component waarbij problemen zijn opgetreden en welke van invloed zijn op het falen van een project.
65
Hoofdstuk 6
De Virtuele kijkdoos
Voor het project Virtuele Kijkdoos ziet dit er als volgt uit: Organisatie
Driehoek van Verbondenheid Projectmanagement
Procesmanagement
Figuur10 Driehoek van Verbondenheid toegepast op project Virtuele kijkdoos (Kiel 2010, gebaseerd op ‘Duivelsdriehoek van Noordam)
6.3 Analyse Zowel op het niveau van de beheersfactoren als op het niveau van de succesfactoren scoort het project Virtuele Kijkdoos goed, oftewel het project is een succes te noemen. De praktische benadering (het product sluit goed aan bij de werkzaamheden van de organisatie) en de kleinschaligheid van het project maken het mogelijk om op korte termijn resultaten te boeken. Daarnaast hebben de omstandigheden, waaronder het project plaatsvond, invloed gehad op het succes van het project. Hierbij gaat het om:
het politieke belang, waardoor er voldoende capaciteit en geld beschikbaar was;
de grote betrokkenheid bij de medewerkers van de afdelingen;
de wil om er gezamenlijk een succes van te maken.
6.4 Conclusie Op basis van de casus Virtuele kijkdoos kunnen de volgende conclusies getrokken worden: 1. Ook in deze casus blijkt dat de kwaliteitseisen, gesteld aan het begin van het project, in de loop van de tijd kunnen veranderen. 2. Binnen de componenten projectmanagement en procesmanagement, komt in deze casus sterk ‘het willen’ naar voren. Er moet iemand zijn die het project belangrijk genoeg vindt om uit te (laten) voeren en hier als opdrachtgever aandacht en steun aan te verlenen. En er moeten mensen zijn die het project tot een goed einde willen brengen. Een opdrachtnemer die ervoor zorgt dat proces goed verloopt en medewerkers die er alles aan doen (enthousiast zijn) om gezamenlijk een goed resultaat neer te zetten.
66
Hoofdstuk 7
Hoofdstuk 7
TIS totaal
TIS totaal
Voor de nieuwe (regionale) organisatie Brandweer Midden en West Brabant is het noodzakelijk om per 1 maart 2010 een operationeel computernetwerk te hebben, waar alle 26 gemeentelijke brandweerkorpsen (gaat om ongeveer 450 werkplekken) gebruik van kunnen maken. Het project om dit vorm te geven heet ‘Technische infrastructuur Brandweer Midden en West Brabant’ (hierna te noemen TIS totaal). In deze casus wordt bekeken hoe het project TIS totaal is verlopen. Na een korte (feitelijke) beschouwing van het project, wordt gekeken naar het succes en falen en de mogelijke succesfactoren51. Waarna het hoofdstuk wordt afgesloten met een analyse en conclusie.
7.1 Het project TIS totaal Opdrachtgever en opdrachtnemer De opdrachtgever is het managementteam van Brandweer Midden en West Brabant. Van dit team treedt één van de leden op als portefeuillehouder. Er is een interne projectleider. Daarnaast levert het bedrijf Siemens ook een eigen projectleider.
Doelstelling De doelstelling van TIS totaal is: de gemeentelijke brandweerkorpsen van Midden- en West-Brabant aan te sluiten op een operationeel computernetwerk waarbij alle medewerkers plaats- en tijdonafhankelijk gebruik kunnen maken van dezelfde gemeenschappelijke functionaliteiten, te weten: kantoorapplicaties, agenda, mailsysteem, bedrijfsvoeringsystemen en operationele systemen.
Het netwerk zal één op één overgaan. Dit betekent dat er in deze fase niet wordt gekeken naar de doorontwikkeling en eventuele verbeterpunten.
Verloop project Uitgangspunten die centraal staan bij het project zijn:
51
het netwerk zal één op één overgaan;
werkzaamheden blijven goed ondersteund;
De beschrijving en analyse van deze casus vindt plaats op basis van een gesprek dat heeft plaatsgevonden met de strategisch beleidsadviseur informatievoorziening van Veiligheidsregio Midden- en West-Brabant;
67
Hoofdstuk 7
TIS totaal
68
er wordt niet gekeken naar de doorontwikkeling en eventuele verbeterpunten (applicaties migreren één op één vanuit de huidige 26 (gemeentelijke) netwerken naar de nieuwe infrastructuur);
sanering van het applicatielandschap komt op een later tijdstip aan de orde en vormt geen onderdeel van het project.
De reden voor deze aanpak is om het project niet te belasten met langdurige discussies over de keuze welke applicatie de voorkeur zou moeten verdienen met het risico van een (forse) uitloop van het project. Via een Europese aanbesteding is een leverancier (Siemens) uitgekozen.
7.2 Succes en falen Nu we op hoofdlijnen weten hoe het project eruit ziet, gaan we bekijken of het project een succes is en zo ja, wat mogelijke succes- en/of faalfactoren zijn. Om te beoordelen of het om een succesvol project gaat en welke factoren van invloed zijn op het eventuele succes, wordt het project op twee niveaus geanalyseerd: 1. de beheersfactoren; voldoet het project aan de gestelde beheerscomponenten tijd, geld en kwaliteit; 2. de succesfactoren; welke succesfactoren zijn aanwezig binnen het project. De succesfactoren worden – conform de theorie – onderverdeeld in drie componenten: organisatie, projectmanagement en procesmanagement.
De beheersfactoren Er wordt gekeken naar de formulering van de componenten tijd, geld en kwaliteit bij aanvang van het project en de daadwerkelijke invulling van de tijd, geld en kwaliteit bij het einde van het project. Aanvang project Tijd (T)
De oorspronkelijke planning is niet bekend.
Einde project Het project is binnen de geplande tijd afgerond.
Geld (G)
Het oorspronkelijke budget is niet bekend.
Het project is binnen het budget afgerond.
Kwaliteit (K)
Applicaties vanuit de huidige gemeentelijke
Het project voldoet aan de gestelde eisen
netwerken migreren naar de nieuwe
en functionaliteiten. De opdrachtgevers
infrastructuur.
en gebruikers zijn tevreden.
Alle medewerkers kunnen plaats- en tijdonafhankelijk gebruik maken van dezelfde gemeenschappelijke functionaliteiten.
Hoofdstuk 7
TIS totaal
Op basis van de beheersfactoren kan geconcludeerd worden dat het project een succes is.
Scoren op succesfactoren In bijlage drie is een overzicht gegeven van de succesfactoren van (ICT) projecten. Aan de hand van een score wordt hier bekeken of de belangrijkste succesfactoren goed zijn opgepakt c.q. toegepast binnen het project TIS totaal.
De succesfactoren zijn ondergebracht in de drie componenten van de driehoek van verbondenheid, te weten:
Organisatie; het automatiseringsproject moet aansluiten bij de strategie, processen en/of taken van de organisatie. Het moet een bijdrage leveren aan (het verbeteren) van de doelstellingen van de organisatie c.q. het eenvoudiger maken van de werkzaamheden.
Projectmanagement; deze component geeft invulling aan de projectmatige aanpak die noodzakelijk is. De opdrachtgever die betrokken is, het toepassen van een projectmethodiek, de aanwezigheid van duidelijke doelstellingen, planning, sturing etc.
Procesmanagement; deze component geeft invulling aan het sociale aspect van een automatiseringsproject. Het tijdig betrekken van de gebruikers, rekening houden met de cultuur van een organisatie, managen van verwachtingen etc.
De succesfactoren worden weergegeven met stellingen. Middels een score van 1 t/m 5 kan per stelling worden aangegeven of deze goed zijn opgepakt of niet. 1: volledig mee oneens 2: mee oneens 3: niet mee eens/niet mee oneens 4: mee eens 5: volledig mee eens
69
Hoofdstuk 7
Succesfactor
1
2
TIS totaal
3
4
5
Organisatie Het systeem wordt als beter beschouwd dan de praktijk die het moet vervangen Het systeem sluit goed aan bij de uit te voeren taken/ werkprocessen Het systeem is eenvoudig te begrijpen en niet ingewikkeld in het gebruik (gebruiksvriendelijkheid) Het systeem is beschikbaar en betrouwbaar Projectmanagement Er wordt een projectmethodiek toegepast De opdrachtgever is betrokken bij het project (ziet het belang van het project) Duidelijke opdrachtnemer die de touwtjes in handen heeft (zorgt voor sturing) Doelstellingen en opdracht zijn duidelijk en bekend Er is een planning met mijlpalen Taken, verantwoordelijkheden en bevoegdheden van betrokken actoren zijn bekend Er is sprake van een goede communicatie, over: de werking, het doel en de voortgang. Voldoende en juiste capaciteit is beschikbaar voor het project Er vindt één verandering tegelijkertijd plaats in de organisatie (de diverse projecten zijn op elkaar afgestemd) Procesmanagement Gebruikers zijn tijdig bij het project betrokken Gebruikers zijn voldoende en gestructureerd bij het project betrokken De gebruiker heeft invloed gehad op het proces De gebruikers zijn goed opgeleid voor het systeem N.v.t. De verwachtingen zijn bij alle betrokkenen goed gemanaged Voldoende ruimte/tijd voor: gewenning, het testen van het systeem, bijsturingmogelijkheden tijdens de rit (goede voorbereiding en begeleiding). Wilskracht, vertrouwen, openheid, eerlijkheid, respect zijn centrale waarden binnen het project. Toelichting score succesfactoren Per component wordt hieronder beschreven waarom de succesfactoren een bepaalde score hebben gekregen.
Organisatie Doordat alle organisaties binnen de regio op hetzelfde netwerk gaan werken, is het gemakkelijker om bestanden/informatie te delen. Tevens zijn de functionaliteiten beter toegankelijk voor de
70
Hoofdstuk 7
TIS totaal
medewerkers. Het project levert daartoe een bijdrage aan het eenvoudiger maken van de werkzaamheden en scoort op dit onderdeel een vijf.
Projectmanagement Er is (binnen de brandweer) niet voor een projectmethodiek gekozen. Wel werkt de leverancier conform zijn eigen methodieken. Aangezien de leverancier wel gebruik maakt van een projectmethodiek scoort deze stelling een drie. Er is een duidelijke opdrachtgever aanwezig en er is een stuurgroep in het leven geroepen. Men onderkent het belang en is betrokken. Daarnaast zijn er twee projectleiders: één intern en één van de leverancier. De eisen zijn duidelijk beschreven in de benodigde documenten voor de aanbesteding en Siemens heeft zijn werkzaamheden in diverse documenten vastgelegd. Hierin is ook de planning (mijlpalen) meegenomen. Het doel is duidelijk. Tevens wordt hierbij duidelijk aangegeven wat het verschil is tussen de huidige en nieuwe situatie. Aangezien deze punten goed zijn opgepakt, scoren ze een vijf.
Het was grotendeels bekend wie waarvoor verantwoordelijk was (wie welke taken, verantwoordelijkheden en bevoegdheden heeft). Tevens is er veel aandacht besteed aan communicatie. Hierbij is wel het aandachtspunt naar voren gekomen dat je goed moet aangeven: wanneer je wat gaat doen, wat het betekent voor betrokkenen, je zaken extra moet toelichten (voor ‘leken’ is niet alles zo vanzelfsprekend) en je tijdig moet communiceren. Dit is binnen het project niet altijd even goed gegaan, waardoor er ruis (verkeerde beelden/verwachtingen) op de lijn kwam. Beide stellingen zijn grotendeels goed opgepakt, maar niet volledig. Vandaar dat ze een vier scoren.
De capaciteit voor het project was te beperkt, het project is daardoor onderbezet geweest. Dit heeft ook tot gevolg gehad dat andere werkzaamheden op de afdeling bleven liggen. Er lopen teveel projecten tegelijkertijd. Hierdoor is het niet mogelijk om alle zaken goed op te pakken en tot een goed einde te brengen. Gezien deze situatie scoren deze onderdelen een twee.
Procesmanagement De stakeholders (gebruikers) zijn betrokken in de project overleggen. Op deze manier maakten ze onderdeel uit van het project en werd de betrokkenheid vergroot. Daarnaast is aan de gebruikers gecommuniceerd wat ze kunnen verwachten. Aangezien de gebruikers goed zijn betrokken, scoren deze onderdelen een vijf. Het is moeilijk om te beoordelen of de gebruikers veel invloed hebben gehad op het traject en welke waarden centraal hebben gestaan. Doordat de gebruikers betrokken zijn in de project overleggen,
71
Hoofdstuk 7
TIS totaal
kun je er van uitgaan dat ze invloed hebben gehad. Er wordt voor deze onderdelen een drie gescoord omdat niet geheel duidelijk is, welke mate van invloed de gebruiker heeft gehad op het traject en welke waarden centraal hebben gestaan. De verwachtingen bij de gebruikers zijn goed gemanaged, al zat er wel een valkuil in de gedachte dat het doel voor iedereen vanzelfsprekend was. Voor een aantal medewerkers was het belangrijk om zaken extra toe te lichten. Vooral het gegeven dat de migratie van applicaties één op één plaatsvond en dat de sanering van het applicatielandschap op een later tijdstip aan de orde komt.
Model van verbondenheid Op basis van bovenstaande analyse van de succesfactoren binnen het project Virtuele Kijkdoos, kunnen de succesfactoren van het project samengevat worden in de driehoek van verbondenheid. In dit model wordt een waardering op twee niveaus gegeven:
groen: een component welke goed is opgepakt en van invloed is op het succes van een project;
rood: een component waarbij problemen zijn opgetreden en welke van invloed zijn op het falen van een project.
Voor het project TIS totaal ziet dit er als volgt uit:
Organisatie
Driehoek van Verbondenheid Projectmanagement
Procesmanagement
Figuur11 Driehoek van Verbondenheid toegepast op project TIS totaal (Kiel 2010, gebaseerd op ‘Duivelsdriehoek van Noordam)
7.3 Analyse Zowel op het niveau van de beheersfactoren als de succesfactoren is dit project een succes te noemen. Het project is binnen de tijd en het budget afgerond en voldoet aan de gestelde eisen/functionaliteiten.
72
Hoofdstuk 7
TIS totaal
Het succes is met name bereikt doordat:
het netwerk aansluit bij de organisatie en meerwaarde heeft voor de werkzaamheden;
de opdracht duidelijk is;
de opdrachtgever betrokken is;
het project stapsgewijs is uitgevoerd (eerst netwerk één op één overnemen en daarna iets te roepen over de applicaties), op deze manier houd je het project hanteerbaar.
Belangrijk aandachtspunt blijft de communicatie bij een automatiseringsproject. Waar voor de specialist bepaalde zaken en ontwikkelingen duidelijk zijn, kunnen deze voor de ‘leek’ andere beelden en verwachtingen oproepen. Daarnaast is het goed een project stapsgewijs uit te voeren, maar dit betekent dat er extra aandacht moet zijn voor het managen van de verwachtingen (wat valt wel binnen het project en wat niet?). Een ander aandachtspunt is de beperkte capaciteit die op een afdeling aanwezig is om een dergelijk project te begeleiden en daarnaast de dagelijkse werkzaamheden te blijven doen. Door intern een projectmethodiek toe te passen en strakker te plannen, kun je hier beter op sturen.
7.4 Conclusie Op basis van de casus TIS totaal kunnen de volgende conclusies getrokken worden:
Door een project in stukken te knippen en stap voor stap uit te voeren vergroot je de kans op succes.
Ook bij dit project blijkt dat communicatie (en daarmee het managen van verwachtingen) belangrijk is.
Het blijft altijd belangrijk om het project aan te laten sluiten bij de organisatie en de gebruikers goed te betrekken. Wel lijkt het erop dat als je bij kleinere projecten het projectmanagement goed vorm geeft, je al een deel van het succes binnen hebt. Door een duidelijke doelstelling te formuleren, een betrokken opdrachtgever te hebben, een goede sturing op het project neer te zetten ben je een heel eind op de goede weg. Gezien de omvang van het project is het minder van belang om meer energie te zetten op het procesmanagement dan op projectmanagement. Bij de grote projecten die zijn besproken, zie je dat (gezien de omvang en duur van deze projecten) het juist van belang is om (naast goed projectmanagement) veel energie te steken in procesmanagement.
73
Hoofdstuk 8
Hoofdstuk 8
Conclusie casus
Conclusie casus
Door de casus met elkaar te vergelijken en in verband te brengen met de theorie, kunnen een aantal conclusies geformuleerd worden, te weten:
een automatiseringsproject is meer dan alleen het ‘neerzetten van een systeem’, het is altijd belangrijk om invulling te geven aan de drie componenten: organisatie, projectmanagement en procesmanagement;
je bent afhankelijk van anderen en kunt een verandering nooit eenzijdig opleggen;
stuur een project gerust, maar stuur het wel bewust.
De conclusies worden hieronder nader toegelicht.
Een automatiseringsproject is meer dan alleen het ‘neerzetten van een systeem’ Waar in hoofdstuk één van deze scriptie al een ‘discussie’ zichtbaar is over het begrip automatisering (is het een eenvoudig traject of juist een complex besluitvormingsproces) zie je dit verschil ook in de praktijk terugkomen. Bij de kleinere projecten (Virtuele Kijkdoos en TIS compleet) is het gemakkelijker om het project vorm te geven en zou je kunnen spreken van een eenvoudig traject. Terwijl bij de grote projecten (BVH en C2000) niet gesproken kan worden over een eenvoudig traject, maar juist een complex besluitvormingstraject. Niettemin moet de boodschap zijn (blijven) dat het bij de implementatie van een automatiseringssysteem altijd om meer gaat dan ‘alleen een systeem neerzetten’. De in hoofdstuk één geformuleerde conclusie; ‘Op basis van de aangehaalde theorieën wordt geconcludeerd dat de theorie van Springer ondersteund wordt en dat een automatiseringsproject meer is dan alleen het aanschaffen van hard- en software en het ‘plaatsen van een systeem’ in een organisatie. Het implementeren van een dergelijk project kent meer onderdelen en heeft meer invloed op de organisatie dan over het algemeen gedacht wordt’, is terecht en wordt onderbouwd door de casus. Hoe groot of klein het project ook was, bij alle projecten was het van belang om invulling te geven aan de drie componenten: organisatie, projectmanagement en procesmanagement. Dit blijkt ook uit onderstaand overzicht van de conclusies per casus.
74
Hoofdstuk 8
Casus
BVH
C2000
Virtuele kijkdoos
TIS totaal
Conclusie casus
Conclusies Om een project succesvol te laten zijn, ben je er niet alleen door een kwalitatief hoogwaardige projectorganisatie neer te zetten. Ook de componenten organisatie en procesmanagement spelen een belangrijke rol. Binnen de componenten organisatie en procesmanagement zijn het managen van verwachtingen en goede communicatie zeer belangrijk. Daarnaast is het belangrijk om de gebruikers tijdig en voldoende te betrekken. Naast projectmanagement spelen inderdaad organisatie en procesmanagement een rol. Dit neemt echter niet weg dat projectmanagement ook serieus genomen moet worden en dat je dit goed moet organiseren. De mate waarin een project succesvol is (aan de gevraagde kwaliteit voldoet), kan in de loop van de tijd (en dus ook gedurende het project) veranderen. De ‘problemen’ doen zich – binnen de component procesmanagement – vooral voor op het gebied van: managen van de verwachtingen en het tijdig en goed betrekken van de gebruikers. Ook in deze casus blijkt dat de kwaliteitseisen in de loop van de tijd kunnen veranderen. Binnen de componenten projectmanagement en procesmanagement, komt in deze casus sterk ‘het willen’ naar voren. Door een project in stukken te knippen en stap voor stap uit te voeren vergroot je de kans op succes. Communicatie (en daarmee het managen van verwachtingen) is belangrijk. Sluit goed aan bij de organisatie, betrek de gebruikers er goed bij en geef projectmanagement goed vorm, dan ben je een heel eind op de goede weg.
‘Je bent afhankelijk van anderen en kunt een verandering nooit eenzijdig opleggen’ Deze conclusie begint met een uitspraak van De Bruijn, Ten Heuvelhof en In ‘t Veld52. Zij geven aan dat: ‘Pas wanneer andere partijen betrokken worden bij de verandering, is er een kans dat ze de eigen opvattingen herkennen in de definitie van een probleem en een oplossing. En dan pas zullen zij hier hun steun aan verlenen.’ Deze afhankelijkheid van anderen blijkt in de casussen ondermeer uit het gegeven dat:
52
De Bruijn, Ten Heuvelhof en In ’t Veld, 2008, pagina 3;
75
Hoofdstuk 8
Conclusie casus
een opdrachtgever nodig is die het project goed ondersteunt (het belang van het project inziet);
gebruikers tijdig en structureel bij het project betrokken moeten worden om voldoende draagvlak te krijgen;
de verwachtingen van de gebruikers ‘sterker zijn’ dan de geformuleerde (en wellicht gecommuniceerde) doelstelling en dit van grote invloed is op de vraag of de gebruikers het project als een succes ervaren.
Om een project daadwerkelijk succesvol te laten zijn, is het belangrijk om de betrokkenen – op wie de verandering van toepassing is – vroegtijdig en structureel bij het project te betrekken (zowel de opdrachtgever als de gebruikers).
Stuur een project gerust, maar stuur het wel bewust In hoofdstuk twee wordt de projectmanagementmethodiek Prince2 besproken. Met behulp van deze methodiek wordt uitgelegd hoe je een project aan moet pakken. Veel projectleiders zullen de feitelijkheden kennen, maar het lijkt erop dat de valkuil ligt in de daadwerkelijke toepassing van deze kennis. Als een doel duidelijk omschreven is, wordt al snel verondersteld dat deze duidelijk is voor iedereen en door iedereen op dezelfde manier geïnterpreteerd wordt. Op basis van de casus wordt duidelijk dat deze veronderstelling niet terecht is en er meer energie moet worden gestoken in verwachtingenmanagement. Zo zijn er meer vooronderstellingen, die maken dat de daadwerkelijke feiten niet altijd overeen komen met de beelden die leven bij de gebruikers. Bij de omschrijving van projecten in hoofdstuk twee wordt door middel van een aantal uitgangspunten aangegeven wat belangrijk is om een project tot een succes te maken. Gezien het belang van deze uitgangspunten en de raakvlakken die ze hebben met de casus, worden ze hier nog een keer aangehaald:
projecten worden uitgevoerd in een veranderende omgeving; projecten initiëren zelf veranderingen en deze veranderingen hebben weer effect op het project;
een project is pas succesvol als alle betrokken partijen tevreden zijn met het projectresultaat, managen van de verwachtingen is een wezenlijk onderdeel;
succesvolle projecten zijn ‘business driven’, er moet een zakelijke rechtvaardiging zijn om een project te starten;
samenwerking van alle bij het project betrokken partijen leidt tot meer succesvolle projecten.
76
Hoofdstuk 8
Conclusie casus
Op basis van de theorie en de casus, ontstaat het beeld dat meer bewust moet worden omgegaan met bepaalde onderdelen: Wees bewust van het feit dat een project op zich zelf al zorgt voor verandering binnen de organisatie. Daarnaast kunnen de geformuleerde wensen/eisen in de tijd veranderen. Wees bewust van het feit dat verwachtingen echt gemanaged moeten worden (hoe duidelijk de doelstelling ook is, een ieder denkt vanuit zijn/haar eigen kader en ervaringen en ziet de randvoorwaarden/uitgangspunten van het project snel over het hoofd). Wees ervan bewust dat nut en noodzaak van het project (voor de organisatie) voor iedereen duidelijk moet zijn (het moet aansluiten bij de werkzaamheden van de organisatie). Wees ervan bewust dat enthousiastelingen nodig zijn, mensen die willen, mensen die er een succes van willen maken.
77
Hoofdstuk 9
Hoofdstuk 9
De brandweer en automatiseringsprojecten
De brandweer en automatiseringsprojecten
In de eerste paar hoofdstukken van deze scriptie is beschreven wat een automatiseringsproject is en welke factoren een rol spelen om een dergelijk project tot een succes te maken. Aan de hand van een viertal casus is bekeken hoe dit in de praktijk verloopt. Om daadwerkelijk een vertaalslag te maken van wat we geleerd hebben naar de praktijk, moet nog één verdiepingsslag worden gemaakt. Naar de organisatie waarbinnen een automatiseringsproject wordt geïmplementeerd, hoe zal de organisatie omgaan met automatiseringsprojecten? Gezien het feit dat in de inleiding is aangegeven dat de doelgroep vooral zal liggen binnen de eigen organisatie van de onderzoeker, wordt in dit hoofdstuk de brandweerorganisatie nader belicht. Wat is de brandweer voor organisatie en wat kan over de brandweer worden gezegd in relatie tot automatiseringsprojecten? In samenhang met de driehoek van verbondenheid, wordt de brandweer nader beschouwd op de componenten: organisatie, projectmanagement en procesmanagement53.
9.1 Brandweer, de organisatie Bij de vraag hoe de brandweer om zal gaan met automatiseringsprojecten en de daarbij behorende componenten, speelt de cultuur van de organisatie een belangrijke rol. Welke normen en waarden staan centraal en ‘welke manier van werken’ zijn we gewend om binnen deze organisatie toe te passen? Uit de MCDM scriptie van Versleijen54 blijkt waarom het belangrijk is om de cultuur van een organisatie te kennen. Op basis van Sanders en Neuijen (2005) komt hij tot de volgende uitleg van cultuur. ‘Een cultuur wordt in wezen bepaald door de aangeleerde, impliciete veronderstellingen waarop de leden van een groep of organisatie hun dagelijks gedrag baseren. De impliciete veronderstellingen zijn het resultaat van een gemeenschappelijke leerervaring.’ Wil je voorspellen hoe de medewerkers van een organisatie om zullen gaan met een automatiseringsproject (zowel het managen van het project als het omgaan met de veranderingen door de gebruikers), oftewel wil je de cultuur van een organisatie begrijpen, dan moet je kennis en inzicht hebben in de geschiedenis van de organisatie (de gemeenschappelijke leerervaringen). Het gaat hier te ver om in de geschiedenis van de brandweerorganisatie te duiken. Wel kunnen we een aantal in het oogspringende (cultuur) elementen behandelen.
53
Gezien de doelgroep/lezers van deze scriptie wordt voorbij gegaan aan een algemene beschrijving van de brandweerorganisatie. Deze wordt verondersteld bekend te zijn bij de lezers; 54
Versleijen, 2007, pagina 12;
78
Hoofdstuk 9
De brandweer en automatiseringsprojecten
Versleijen55 heeft het over de brandweerfamilie die gezien kan worden als een gesloten familie, die de leden geborgenheid biedt. ‘Een familie met een sterke eigen organisatiecultuur: er zijn veel gedeelde opvattingen over wat belangrijk is, wat de groep bij elkaar houdt en succesvol maakt. Dit warme nest brengt wel de noodzaak van stabiliteit met zich mee. Zogeheten verandermanagers of erger nog, interim-managers met de taakopdracht om ‘de bezem er door te halen’ zijn een regelrechte aanslag op het sociale veiligheidsgevoel in de organisatie.’ Wat Versleijen betreft zal de leidinggevende een cruciale rol spelen als aanjager bij een veranderingsproces. Dit vraagt volgens hem de aanwezigheid van een grote mate van emotionele robuustheid bij de leidinggevende.
De brandweer wordt ook wel een zogenaamde ‘Front-line’ organisatie genoemd. Cozijnsen en Vrakking56 omschrijven een dergelijke organisatie als: ‘organisaties waarin de leden op het uitvoerende niveau zich een grote handelingsvrijheid hebben toegeëigend om daarmee het hoofd te kunnen bieden aan de problemen die in onvoorspelbare en vaak nogal ‘vijandige’ situaties dienen te worden opgelost. Het gevolg van een dergelijke werksituatie is dat er een bijzondere mentaliteit wordt ontwikkeld, als onderdeel van de beroepscultuur, waarin solidariteit met collega’s in een gelijke positie een belangrijke rol speelt. Andere elementen van de beroepscultuur aan de basis van de organisatie zijn: geslotenheid, actiegerichtheid en cynisme. De leiding zal gebruik moeten maken van overtuigings- en onderhandelingsstrategieën.’ Van Lochem en Verhallen57 hebben het over een zeer sterke culturele component welke je voornamelijk terug ziet komen in het repressieve deel van de brandweerorganisatie. Dit kan blokkerend werken als de organisatie veranderingen door wil voeren, of zoals Van Lochem en Verhallen het omschrijven: ‘een soepele aanpassing aan de maatschappelijke werkelijkheid. Het repressieve brandweervak wordt vaak beschouwd als een roeping, waarbij men een zeer grote betrokkenheid heeft bij het werk. Enerzijds is het een absolute kracht van de repressieve brandweerorganisatie, anderzijds maakt het de vaak emotionele geladenheid dat de organisatie buitengewoon kwetsbaar is in de zin dat er (te) weinig ruimte is voor afstandelijkheid en zakelijkheid die nodig is voor de noodzakelijke veranderingen.’
55
Versleijen, 2007, pagina 28 en 29;
56
Cozijnsen en Vrakking, 1986, pagina 219;
57
Van Lochem en Verhallen, 2007, pagina 387;
79
Hoofdstuk 9
De brandweer en automatiseringsprojecten
Een eerste conclusie kan zijn dat de brandweerorganisatie, vooral op het operationele niveau, een sterke cultuur heeft die zich kenmerkt door: geslotenheid, cynisme, emotionele geladenheid en weinig zakelijkheid/afstandelijkheid.
Een ander kenmerkend verschijnsel is het zogenaamde ‘gat’ tussen de leiding (strategisch niveau) en het veld (operationele niveau). Van Lochem en Verhallen beschrijven de cultuur en dit ‘gat’ als dat de uitrukdienst zich niet meer herkent in de top van de organisatie. ‘Terwijl de brandweer tot de jaren ’80 een sterk gesloten, naar binnen gekeerde organisatie was die weinig met anderen te maken had en deze grote zelfstandigheid koesterde, wijzigde dat de laatste jaren fors. De verschillen tussen het management van de brandweer – bezig met overleg, onderhandelingen, papierwerk en beleidsnota’s (de politiek-bestuurlijk geëngageerde managers die vooral extern georiënteerd zijn) en degenen die de uitrukposten bemensen, wordt steeds groter. De basis herkent de top van de organisatie vaak niet meer. In hun ogen zijn zij met veel bezig, maar niet met datgene wat vroeger het primaire brandweerproces was.’ Versleijen58 heeft het met betrekking tot het ‘gat’ tussen strategisch en operationeel niveau over ‘de fysieke en gevoelsmatige nabijheid van het werkterrein enerzijds en de fysieke en gevoelsmatige afstand tot de centrale organisatie anderzijds.’
Combineer bovenstaande met de eerste conclusie en het gegeven dat een automatiseringsproject over het algemeen een verandering betekent, ‘ver weg staat’ van de dagelijkse werkzaamheden van de uitrukdienst en wordt ingegeven door de centrale organisatie. Als het vervolgens gaat om een automatiseringsproject dat geïmplementeerd moet worden op operationeel niveau, heb je de eerste contouren waar je bij de procesmatige benadering rekening mee moet houden. Wantrouwen van de gebruiker jegens de centrale organisatie, een gesloten cultuur die niet van veranderingen houdt, emotionele geladenheid en weinig zakelijkheid.
9.2 De brandweer en automatisering Waar binnen de ene bedrijfstak automatisering als strategisch product wordt gezien, staat de automatisering binnen een andere bedrijfstak nog in de kinderschoenen en wordt automatisering ingezet als ondersteuning van (enkele) werkzaamheden. De brandweer lijkt op dit gebied nog in de kinderschoenen te staan.
58
Versleijen, 2007, pagina 25;
80
Hoofdstuk 9
De brandweer en automatiseringsprojecten
Op het gebied van informatiemanagement zijn diverse onderzoeken verschenen, zoals van de Adviescommissie Coördinatie ICT Rampenbestrijding en de Inspectie Openbare Orde en Veiligheid. IOOV59 komt in haar onderzoek wellicht met de meest concrete conclusie: ‘De aandacht voor en het gebruik van ICT binnen de brandweer is van kleuterniveau.’ Van de Looij60 concludeert in zijn MCDM scriptie dat ‘de automatisering en informatisering van veel brandweerorganisaties zich nog bevindt in een relatief prille fase van ontwikkeling. Veelal wordt nog gewerkt op het niveau van eenvoudige procesondersteuning, waarbij slechts in zeer beperkte mate sprake is van koppeling van systemen binnen de eigen organisatie, laat staan tussen organisaties. Binnen het merendeel van de brandweerorganisaties wordt nu nog onvoldoende gebruik gemaakt van al beschikbare informatiesystemen en hulpmiddelen. Voor hetzelfde probleem wordt op verschillende plaatsen in het land verschillende oplossingen bedacht en ingevoerd.’
De afgelopen jaren is deze situatie (nog) niet veel veranderd, hier lijkt echter verbetering in te komen. De Nederlandse Vereniging voor Brandweerzorg en Rampenbestrijding (NVBR) is de ‘Strategische reis’ gestart. Onderdeel hiervan is de werkgroep die zich bezighoudt met informatie en ICT. In hun notitie geeft de werkgroep61 aan dat brandweer Nederland op het terrein van ICT een volgende rol heeft en de korpsen nog steeds versnipperd actief zijn. ‘In feite is het aanbod leidend voor wat de brandweer aan ICT implementeert. Veel brandweermanagers die een probleem ervaren zoeken een oplossing bij een ICT leverancier “om de hoek” om dat specifieke probleem op te lossen. Hierdoor ontstaat een onbeheersbaar, gefragmenteerd en duur arsenaal aan applicaties en van ICT systemen die onderling geen informatie kunnen uitwisselen (of tegen excessieve meerkosten)’. De NVBR wil (met behulp van de strategische reis) deze manier van werken aanpakken en de volgende rol richting leveranciers omdraaien.
9.3 Brandweer en project- en procesmanagement Binnen de brandweer is het besef aanwezig dat projectmanagement een belangrijke rol speelt bij het vormgeven van een project. Vooral de theorie van Prince2 wordt aangehangen. Hierbij ontstaat een sterke neiging om het toepassen van Prince2 als oplossing te zien voor de problemen die ontstaan bij het managen van projecten, waardoor er nauwelijks aandacht lijkt te zijn voor procesmanagement. Dat de toepassing van projectmanagement niet altijd zo simpel is als het lijkt, blijkt uit onderstaand voorbeeld. 59
Adviescommissie Coördinatie ICT rampenbestrijding, 2005, pagina 27;
60
Van de Looij, 2007, pagina 31;
61
NVBR, 2009, pagina 3;
81
Hoofdstuk 9
De brandweer en automatiseringsprojecten
Een afdelingshoofd van een grote brandweerorganisatie62 beschrijft in een notitie (2009) het onvermogen van de brandweer om invulling te geven aan het opdrachtgeverschap. ‘De opdrachtgever is de eigenaar van een project of opdracht. In theorie hecht hij dus veel waarde aan het bereiken van de opdracht en ligt er mogelijk zelfs wakker van. De opdrachtgever is bovendien verantwoordelijk voor de verstrekking van middelen en bevoegdheden. De opdrachtnemer is verantwoordelijk voor het behalen van het projectresultaat. Hij vraagt en krijgt van de opdrachtgever de middelen en bevoegdheden die hij daartoe nodig heeft.
Op basis van deze simpele definities zie je het in de brandweer praktijk al vaak misgaan. Als de opdracht eenmaal verstrekt is, lijkt het daarna een zaak van de opdrachtnemer te zijn geworden: niet zelden moet hij op zoek gaan naar financiering, hij moet vreselijk zijn best doen om participatie vanuit de lijn te krijgen en wezenlijke interesse vanuit de opdrachtgever is vaak ver te zoeken. Het lijkt er vaak op dat het project ten behoeve van de opdrachtnemer wordt uitgevoerd.’
9.4 Conclusie Op basis van de bevindingen zal de vraag ‘Hoe de brandweer om zal gaan met automatiseringsprojecten’ als volgt beantwoord kunnen worden:
Op de werkvloer (operationeel niveau) zal in eerste instantie weinig draagvlak zijn voor een automatiseringsproject. Men staat niet open voor veranderingen en veel medewerkers ervaren automatisering (c.q. de huidige stand van de techniek) als de ver van hun bed show. Daarnaast worden initiatieven vanuit de centrale organisatie met argwaan bekeken.
Op het niveau van de projectleider en opdrachtgever zal de nadruk meer liggen op projectmanagement dan op procesmanagement. Al is het de vraag of het projectmanagement (bijvoorbeeld qua opdrachtgeverschap) voldoende goed ingevuld wordt.
Het uitrollen van de kleinere automatiseringsprojecten, welke praktisch zijn en waarvan de meerwaarde duidelijk is (welke goed aansluiten bij de werkzaamheden en processen van de organisatie), lijkt haalbaar te zijn (ook op basis van de behandelde casus). Mits voldoende capaciteit hiervoor vrijgemaakt wordt.
De brandweer staat op het gebied van automatisering nog in de kinderschoenen en heeft de neiging zelf het wiel uit te vinden. De kans is groot dat het gebrek aan voldoende kennis en expertise over het hoofd wordt gezien en daardoor de (grotere) automatiseringsprojecten
62
In verband met de privacy van het desbetreffende afdelingshoofd wordt hier geen naam van de persoon in kwestie en/of de organisatie genoemd;
82
Hoofdstuk 9
De brandweer en automatiseringsprojecten
niet goed opgepakt en begeleid worden c.q. aansluiten bij de behoefte in de organisatie. Tevens zal men zich niet of nauwelijks bewust zijn van de impact (de verandering) die een automatiseringsproject op de organisatie kan hebben c.q. welke inspanning het kost om een dergelijk project binnen een organisatie als de brandweer vorm te geven.
De reden waarom automatiseringsprojecten wel zullen slagen binnen de brandweerorganisatie, zal vooral liggen in de bij het project betrokken medewerkers. Een goede en enthousiaste medewerker heeft een zogenaamd ‘brandweerhart’ en zal zich (persoonlijk) inzetten om het beoogde resultaat hoe dan ook te bereiken.
Zou je bovenstaande conclusie verwerken in de driehoek van verbondenheid, dan zou de verwachte score als volgt zijn (vooral bij de grotere projecten):
Organisatie
Driehoek van Verbondenheid Projectmanagement
Procesmanagement
Figuur12 Driehoek van Verbondenheid toegepast op (grote) projecten binnen de brandweer (Kiel 2010, gebaseerd op ‘Duivelsdriehoek van Noordam)
Om hetgeen we uit de theorie en de casus hebben geleerd, daadwerkelijk toe te kunnen passen in de (brandweer)praktijk, zal het vooral van belang zijn om het model van verbondenheid toe te passen (men moet zich bewust zijn van het feit dat je invulling moet geven aan de drie componenten: organisatie, projectmanagement en procesmanagement) en hierbij de gehanteerde stellingen over succesfactoren als leidraad te nemen c.q. als checklist te gebruiken.
83
Hoofdstuk 9
Succesfactor Organisatie Het systeem wordt als beter beschouwd dan de praktijk die het moet vervangen Het systeem sluit goed aan bij de uit te voeren taken/ werkprocessen Het systeem is eenvoudig te begrijpen en niet ingewikkeld in het gebruik (gebruiksvriendelijkheid) Het systeem is beschikbaar en betrouwbaar
Projectmanagement Er wordt een projectmethodiek toegepast
De brandweer en automatiseringsprojecten
84
Toelichting Organisatie Zorg ervoor dat bij iedereen duidelijk is wat de meerwaarde van het nieuwe systeem is. Het systeem moet aansluiten bij de werkprocessen en niet vice versa. Hanteer het KISS principe: Keep It Simple en Stupid.
Zorg ervoor (voordat je operationeel gaat) dat het systeem goed functioneert en niet regelmatig uitvalt. Je hebt maar één keer om een goede indruk te maken. Projectmanagement Sla niet door in het toepassen van een projectmethodiek (voorkom papier schuiven), maar zorg wel voor een eenduidige werkwijze waarin de andere succesfactoren van project management goed zijn belegd.
De opdrachtgever is betrokken bij het project (ziet het belang van het project)
Zorg ervoor dat voor iedereen bekend is wie de opdrachtgever is, deze betrokken is en zijn rol goed oppakt.
Duidelijke opdrachtnemer die de touwtjes in handen heeft (zorgt voor sturing) Doelstellingen en opdracht zijn duidelijk en bekend Er is een planning met mijlpalen
Zorg voor een goede projectleider (één duidelijk aanspreekpunt) die zichtbaar stuurt. Zorg voor een eenduidige doelstelling en communiceer deze aan alle betrokkenen. Een planning met mijlpalen is onmisbaar. Het wordt echter pas nuttig als hier ook opgestuurd wordt. Van iedereen die bij het project betrokken is (of zou moeten zijn) moet duidelijk zijn wat zijn rol is (voor de buitenwereld, maar zeker ook voor de persoon in kwestie). Goede communicatie is onmisbaar. Het antwoord op de vraag of de communicatie goed is, kan alleen door de gebruiker/de betrokkenen beantwoord worden. Zorg ervoor dat je de juiste mensen (expertise) vrijmaakt voor het project en dat je ook daadwerkelijk voldoende capaciteit beschikbaar stelt (medewerkers vrijmaakt van andere werkzaamheden). Het goed implementeren van een automatiseringsproject kost tijd. Altijd meer tijd (en capaciteit) dan je in eerste instantie verwacht. Dit betekent dat je niet meerdere grote projecten naast elkaar uit kunt rollen, maar dat je deze in de tijd weg moet zetten.
Taken, verantwoordelijkheden en bevoegdheden van betrokken actoren zijn bekend
Er is sprake van een goede communicatie, over: de werking, het doel en de voortgang.
Voldoende en juiste capaciteit is beschikbaar voor het project
Er vindt één verandering tegelijkertijd plaats in de organisatie (de diverse projecten zijn op elkaar afgestemd)
Deel III Conclusie en aanbevelingen
Procesmanagement Gebruikers zijn tijdig bij het project betrokken
Gebruikers zijn voldoende en gestructureerd bij het project betrokken
De gebruiker heeft invloed gehad op het proces
85
Procesmanagement Weet wie je gebruikers zijn, ken hun belangen en zorg dat ze zo vroeg mogelijk bij het project betrokken worden. ‘Gedoe komt er toch’, dus zorg ervoor dat je dit zo snel mogelijk op tafel krijgt. Het betrekken van gebruikers is meer dan ‘ze een keer uit nodigen voor een bijeenkomst’. Dit moet je in voldoende mate en op een gestructureerde wijze doen. De gebruiker krijgt in zijn werkzaamheden te maken met de veranderingen en weet het beste van welke impact er sprake is. Geef hem dan ook de gelegenheid om zijn ervaring en expertise in te brengen in het project.
De gebruikers zijn goed opgeleid voor het systeem
Opleiding en begeleiding kost tijd. Maar het kan je ook veel tijd besparen. Door een goede opleiding en begeleiding te geven, kun je de weerstand tegen het nieuwe systeem wegnemen bij de gebruikers.
De verwachtingen zijn bij alle betrokken goed gemanaged
Houd er rekening mee dat de gebruiker vanuit een ander kader kijkt dan jij. Check regelmatig of de verwachtingen overeenkomen met de doelstelling van het project. Neem dit niet als vanzelfsprekend aan.
Voldoende ruimte/tijd voor: gewenning, het testen van het systeem, bijsturingmogelijkheden tijdens de rit (goede voorbereiding en begeleiding). Wilskracht, vertrouwen, openheid, eerlijkheid, respect zijn centrale waarden binnen het project.
Neem voordat je systeem operationeel gaat, voldoende tijd om het te laten testen door de gebruikers (stel bijvoorbeeld een testteam samen). Om in een organisatie als de brandweer veranderingen tot stand te brengen, moet je open zijn over je doel (neem het wantrouwen weg). Daarnaast heb je enthousiaste medewerkers nodig die de wilskracht hebben om ervoor te blijven gaan.
Deel III Conclusie en aanbevelingen
Deel III
Conclusie en aanbevelingen
In dit deel worden (op basis van deel I en II) de onderzoeksvragen en de probleemstelling beantwoord. Vervolgens worden conclusies getrokken en aanbevelingen gedaan.
86
Hoofdstuk 10 Conclusie
Hoofdstuk 10
Conclusie
Voordat een conclusie kan worden getrokken, dienen eerst de onderzoeksvragen en de probleemstelling beantwoord te worden. Hieronder volgt deze beantwoording, gevolgd door de conclusie.
Onderzoeksvragen en probleemstelling
Onderzoeksvraag 1:
Wat is een automatiseringsproject?
Een automatiseringsproject is het proces waarbij een geautomatiseerd systeem tot stand wordt gebracht c.q. wordt aangeschaft en geïmplementeerd in de organisatie. Rekening houdend met de impact op de strategie, processen, taken en gebruikers van de desbetreffende organisatie.
Aanvullend geldt dat een geautomatiseerd systeem wordt gezien als ‘het met behulp van automatische stuur- en regelsystemen doen uitvoeren van verrichtingen in het kader van de bedrijfsvoering, administratie en productie van een bedrijf, zodat de gehele organisatie effectiever, betrouwbaarder en beter aanstuurbaar wordt en producten en diensten van hogere kwaliteit levert.
Onderzoeksvraag 2:
Wat is een succesfactor en welke succesfactoren worden in de theorie beschreven op het gebied van automatiseringsprojecten?
Een succesvol project is een project dat: vanuit de invalshoek van de opdrachtgever en de gebruiker Voldoet aan de verwachtingen en is afgerond binnen de tijd en het budget.
Waarbij het element verwachtingen geïnterpreteerd moet worden als een variabele die verder gaat dan de gestelde functionele eisen en van invloed kan zijn op de definitie van ‘binnen de tijd’ en ‘binnen het budget’. Hiermee wordt tegemoet gekomen aan het gegeven dat behoeftes in de loop van de tijd kunnen veranderen.
(Kritieke) Succesfactoren worden omschreven als factoren die beslissend zijn voor het al dan niet behalen van een vooraf gesteld doel. De succesfactoren voor automatiseringsprojecten zijn weergegeven in bijlage drie en worden bij het scoren van de succesfactoren samengevat tot de volgende punten:
87
Hoofdstuk 10 Conclusie
Organisatie: o het systeem wordt als beter beschouwd dan de praktijk die het moet vervangen; o het systeem sluit goed aan bij de uit te voeren taken/werkprocessen; o het systeem is eenvoudig te begrijpen en niet ingewikkeld in het gebruik (gebruiksvriendelijkheid); o het systeem is beschikbaar en betrouwbaar.
Projectmanagement: o er wordt een projectmethodiek toegepast; o de opdrachtgever is betrokken bij het project (ziet het belang van het project); o er is een duidelijke opdrachtnemer die de touwtjes in handen heeft (die zorgt voor sturing); o doelstellingen en opdracht zijn duidelijk en bekend; o er is een planning met mijlpalen; o taken, verantwoordelijkheden en bevoegdheden van betrokken actoren zijn bekend; o er is sprake van een goede communicatie over: de werking, het doel en de voortgang; o voldoende en juiste capaciteit is beschikbaar voor het project; o er vindt één verandering tegelijkertijd plaats in de organisatie (de verschillende projecten zijn op elkaar afgestemd).
Procesmanagement: o gebruikers zijn tijdig bij het project betrokken; o gebruikers zijn voldoende en gestructureerd bij het project betrokken; o de gebruiker heeft invloed gehad op het proces; o de gebruikers zijn goed opgeleid voor het systeem; o de verwachtingen zijn bij alle betrokkenen goed gemanaged; o er is voldoende ruimte/tijd voor: gewenning, het testen van het systeem, bijsturingmogelijkheden tijdens de rit (goede voorbereiding en begeleiding); o wilskracht, vertrouwen, openheid, eerlijkheid, respect zijn centrale waarden binnen het project.
Verder wordt gesteld – middels de driehoek van verbondenheid – dat een project niet tot succes kan leiden als niet aan alle componenten (organisatie, projectmanagement en procesmanagement) invulling wordt gegeven.
88
Hoofdstuk 10 Conclusie
89
Organisatie
Driehoek van Verbondenheid
Projectmanagement
Procesmanagement
Figuur13 Driehoek van Verbondenheid (Kiel 2010, gebaseerd op ‘Duivelsdriehoek van Noordam)
Onderzoeksvraag 3:
Welke automatiseringsprojecten zijn in de praktijk goed gegaan en waarom?
Het is moeilijk om automatiseringsprojecten in de praktijk te vinden die volledig zijn goed gegaan. Wel kan gesproken worden van projecten met een succesvol resultaat, maar dit wil niet zeggen dat alle onderdelen goed zijn verlopen. De in deze scriptie behandelde projecten (BVH, C2000, Virtuele kijkdoos en TIS totaal) zijn verschillend van elkaar en hebben verschillende punten die goed zijn opgepakt. In onderstaand schema is per casus aangegeven wat er goed is gegaan en waarom het goed is gegaan.
Casus
Wat is er goed gegaan?
BVH
De beheersfactoren tijd, geld en kwaliteit zijn goed opgepakt. De opdrachtgever en opdrachtnemer pakken hun rol goed op. Taken, verantwoordelijkheden en bevoegdheden van betrokken zijn bekend. Het systeem sluit goed aan bij de behoefte van de gebruikers. Na de herstart C2000 is het projectmanagement sterk verbeterd. Op alle componenten heeft dit project goed gescoord: op organisatie, projectmanagement en procesmanagement.
C2000
Virtuele Kijkdoos
Waarom is het goed gegaan? De doelstelling van het project is duidelijk. Er zijn goede afspraken gemaakt, met een duidelijke planning en hier is ook op gestuurd.
De meerwaarde van C2000 t.o.v. het oude analoge systeem is zichtbaar voor de gebruiker. Er is gekozen voor één projectmethodiek waarbinnen ook daadwerkelijk gestuurd is. Het project was overzichtelijk (niet te groot) en sloot goed aan bij de werkzaamheden. Daarnaast speelden de omstandigheden een belangrijke rol: - het politieke belang waardoor er voldoende capaciteit en geld was; - de grote betrokkenheid van de medewerkers; - de wil om er gezamenlijk een succes van te maken.
Hoofdstuk 10 Conclusie
TIS totaal
Op alle componenten heeft dit project goed gescoord: op organisatie, projectmanagement en procesmanagement.
Onderzoeksvraag 4:
Het project was overzichtelijk (werd stapsgewijs uitgevoerd) en heeft meerwaarde voor de werkzaamheden. Er was sprake van een duidelijke opdracht en een betrokken opdrachtgever.
Welke discrepantie is zichtbaar tussen de theorie (de kennis) en de praktijk (de daadwerkelijke toepassing)?
De belangrijkste discrepantie tussen de theorie en de praktijk is, dat uit de theorie blijkt dat het belangrijk is om aandacht te geven aan alle drie de componenten van de driehoek van verbondenheid: organisatie, projectmanagement en procesmanagement. In de praktijk wordt dit principe bewust of onbewust niet toegepast. Met als gevolg dat maar aan één of twee onderdelen van de driehoek invulling wordt gegeven. De volgende situaties kunnen zich voordoen:
Projectmanagement en het toepassen van een projectmanagementmethodiek wordt gezien als het middel om een project tot een goed einde te brengen. Er wordt voorbij gegaan aan de meerwaarde voor de organisatie en procesmanagement (creëren draagvlak/betrokkenheid en het managen van de verwachtingen).
Er wordt niet nagedacht over het doel van een automatiseringsproject, waardoor het gevaar ontstaat dat er sprake is van een technology push63 in plaats van een systeem dat de werkzaamheden/processen van de organisatie ondersteunt.
De organisatie en procesmanagement krijgen de benodigde aandacht, maar het projectmanagement wordt onderbelicht. Hierdoor is niet duidelijk wie de opdrachtgever is, wat de opdracht precies is, hoeveel capaciteit beschikbaar is, welke planning gehanteerd wordt etc. Kortom het sturen van het project zal moeizaam gaan.
Onderzoeksvraag 5:
Hoe zorg je ervoor dat de theoretische kennis daadwerkelijk in de praktijk wordt toegepast?
Over het falen en succesvol zijn van automatiseringsprojecten is reeds veel geschreven. Het is niet moeilijk om hier op theoretisch niveau iets over te leren. De uitdaging ligt hem vooral op het gebied van:
63
-
ervaring;
-
bewustzijn;
-
motivatie.
90
Bouwman e.a. (2002) omschrijven technology push als: technologie wordt vaak niet zozeer ontwikkeld vanuit een behoefte van de markt maar eerder vanuit een technische innovatie.
Hoofdstuk 10 Conclusie Ervaring Om de dynamiek van de driehoek van verbondenheid te begrijpen, moet je ervaring opdoen met het werken in projecten. Een organisatie moet zich bewust zijn van dit gegeven en medewerkers dan ook laten groeien in de rol van projectleider. Heb je een groot project, zet hier dan een ervaren projectleider op die in het verleden heeft aangetoond een project tot een goed einde te kunnen brengen. De benodigde ervaring is echter ook nodig bij de opdrachtgever: weet wat het inhoudt om een automatiseringsproject op te zetten en weet wat cruciaal is voor je rol als opdrachtgever.
Bewustzijn Het zal menigeen zijn overkomen, dat je wel wist dat… maar je er niet naar handelde. Dat je de gebruikers tijdig moet betrekken is echt geen baanbrekend nieuws en toch doen we het niet altijd of niet op tijd. Dit kan te maken hebben met tijdgebrek, niet weten wie je gebruikers zijn, weerstand etc. Toch is het van belang om jezelf hierop kritisch te blijven benaderen, en het besef te hebben dat je, om een project succesvol af te ronden, meer nodig hebt dan alleen projectmanagement. Hierbij kan het lijstje met succesfactoren een helpende hand bieden, een checklist zijn. Wees je daarnaast ook bewust van de organisatie waarbinnen je een automatiseringsproject gaat uitvoeren. Heeft de cultuur bepaalde kenmerken waar je rekening mee moet en kunt houden?
Motivatie Bij een aantal casussen is het element van ‘de medewerker die wil’ naar voren gekomen. De gedreven opdrachtgever, de enthousiaste projectleider, het team dat gezamenlijk een product neer wil zetten. Het zijn deze medewerkers die het project uiteindelijk toch succesvol weten af te ronden. Dit maakt dat de motivatie (en het vermogen om door te zetten) van de betrokken medewerkers belangrijk is en dat je hier als organisatie ook naar moet kijken.
Probleemstelling:
‘Waarom slagen sommige automatiseringsprojecten wel en andere niet; wat zijn de succesfactoren en hoe breng je deze in praktijk?’
Met de beantwoording van de deelvragen is getracht een antwoord te geven op de probleemstelling. Voor het antwoord op deze deelelementen van de probleemstelling wordt dan ook verwezen naar de voorgaande vragen en antwoorden. Aanvullend hierop kan worden gesteld dat:
Het niet altijd eenvoudig is om een project te classificeren als een succes: o wat aan het begin van een project nog de juiste kwaliteitseisen zijn, kan aan het einde van het project geheel anders liggen;
91
Hoofdstuk 10 Conclusie o classificeer je een project op basis van de beheersfactoren (tijd, geld en kwaliteit), classificeer je het op basis van de succesfactoren of op basis van een combinatie van beiden; o wanneer in de tijd moet het project een succes zijn, een project dat nu niet succesvol is kan dit over een aantal jaar alsnog zijn (en vice versa).
Om de kans op projectsucces te vergroten moet je investeren in de driehoek van verbondenheid: organisatie, projectmanagement en procesmanagement.
‘Projectenwerk blijft mensenwerk’; je hebt betrokken en enthousiaste medewerkers nodig die van het project een succes willen maken.
92
Hoofdstuk 11 Aanbevelingen
Hoofdstuk 11
Aanbevelingen
Zo gemakkelijk als het woord project wordt gebruikt en toegepast in een organisatie, zo complex is het uitvoeren en implementeren van een project. Vooral een project op het gebied van automatisering, een vakgebied waarbinnen:
het voor menigeen moeilijk is om aan te geven welke behoeften hij/zij heeft;
het lastig blijft om een koppeling te maken tussen de techniek en de bedrijfsvoering (de rechter- en linkerkolom van het negenvlaksmodel van Maes);
de stand der techniek, oftewel de ontwikkelingen heel snel gaan;
de vakinhoud toch voor velen ‘een ver van mijn bed show is’;
het implementeren van het systeem en het begeleiden van de gebruikers altijd meer tijd kost dan menig opdrachtgever/manager verwacht.
Door het benoemen van de componenten: organisatie, projectmanagement en procesmanagement, wordt de omvang van een project duidelijker en hopelijk heeft dit ook gevolgen voor de manier waarop automatiseringsprojecten worden opgepakt.
Het verdient aanbeveling om:
de projectleiders in een organisatie op te leiden/te coachen conform het principe van de driehoek van verbondenheid (dus niet alleen op te leiden in het toepassen van een projectmanagementmethodiek);
als opdrachtgevers/managers te sturen op de drie componenten (sluit het doel van het project aan bij de werkzaamheden/processen van de organisatie, wordt een juiste projectmanagementmethodiek toegepast en wordt er aandacht besteed aan procesmanagement), dit kan middels het toepassen van de checklist succesfactoren;
de juiste medewerkers (ervaring en motivatie) in te zetten op een project (niet iedere medewerker is geschikt voor projectmatig werken).
93
Bijlagen
Bijlagen
Bijlage I:
Literatuurlijst
Bijlage II:
Lijst met afkortingen
Bijlage III:
Succesfactoren van (ICT) projecten (in samenhang met faalfactoren)
Bijlage IV:
Vragenlijst interviews
94
Bijlagen
Bijlage I
Literatuurlijst
Boeken Berg, E.J.T van den, Twaalf verhalen over het managen van projecten, Elsevier Bedrijfsinformatie, Den Haag, 1999; Bosschers, E., Handboek Projectmanagement; de TIPI Approach, Thema bedrijfswetenschappelijke en educatieve uitgeverij, Zaltbommel, 2000; Bouwman, H., J. van Dijk, B. van den Hooff, Lidwien van de Wijngaert, ICT in organisaties: adoptie, implementatie, gebruik en effecten, Boom, Amsterdam, 2002; Bruijn, H. de, E. ten Heuvelhof, Management in netwerken; over veranderen in een multi-actorcontext, Uitgeverij LEMMA, Den Haag, 2007; Bruijn, H. de, E. ten Heuvelhof, R. in ’t Veld, Procesmanagement over procesontwerp en besluitvorming, Sdu Uitgevers bv, Den Haag, 2008; Burnaby Lautier, E., 100 Gouden regels voor projectmanagement; voor projectleiders en opdrachtgevers, Academic Service, Den Haag, 2006; Cozijnsen, A.J., W.J. Vrakking, Handboek voor strategisch innoveren, een internationale balans, Kluwer/NIVE, Deventer,1986; Engelenburg, H., Bondgenoten in automatisering; succesfactoren van tien excellente IT-projecten, Ten Hagen & Stam, Den Haag, 1993; Gietema, J., D. Kotteman, De projectsaboteur; over succesvol manipuleren, Scriptum, Schiedam, 2007; Graham, N., Prince2 voor Dummies, Pearson Addison Wesley, Amsterdam, 2010; Hedeman, B., H. Frederiksz, G. Vis van Heemst, Projectmanagement; een introductie op basis van Prince2, Van Haren Publishing, Zaltbommel, 2004; Lochem, P.J.P.M. van, P.J.J.M. Verhallen in: Brandweer; studies over organisaties, functioneren en omgeving, redactie: I. Helsloot, E.R. Muller, J.D. Berghuijs, Kluwer, Deventer, 2007; Morris, Hough, The anatomy of major projects: a study of the reality of project management, London, 1987; Noordam, P., J. van Hulten, S. van der Horst, Projectrisicomanagement; meer grip op het resultaat van uw ICT-investeringen, Kluwer, Deventer, 2008; Onna, M. van, A. Koning, De kleine Prince2; gids voor projectmanagement, Academic Service, Den Haag, 2007; Springer, S.K., Automatiseren blijft mensenwerk; sociaal-organisatorische aspecten van automatiseren, Nelissen, Baarn, 1989.
95
Bijlagen
Scripties, rapporten en onderzoeken Algemene Rekenkamer, Lessen uit ICT-projecten bij de overheid, deel A, 2007; Algemene Rekenkamer, Lessen uit ICT-projecten bij de overheid, deel B, 2008; Beers, G., Problemen, planning en kennis: een onderzoek naar de processen achter succes en falen van een automatiseringsproject, proefschrift Erasmus Universiteit Rotterdam, Eburon, Delft, 1990; Bestuursdienst Den Haag, De voortgang rond de verbetering van de brandveiligheid in Den Haag, 2002; Brink, T. van der, Ketenarchitectuur: succes- en faalfactoren bij de invoering van het digitaal klantdossier, Universiteit Twente, 2008; Inspectie Openbare Orde en Veiligheid, Rapportage risicoanalyse domein brandweerzorg 2006, 2006; Kulk, G.P., IT risks in measure and number, Vrije Universiteit Amsterdam, 2009; Looij, S. van de, De Chief Information Officer (CIO) als Commandant Informatie Organisatie (CIO) bij de brandweer, MCDM 2007; Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, Rapport eindevaluatie C2000, 2006; Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, Eindrapportage expertgroep C2000, 2009; NVBR, Werkpakket 6 informatie en ICT, Arnhem, 2009; Politie, Samenwerkingsafspraken politie 2008, juni 2007; Stelstra, IJ., Projectvoorstel en PID nieuw SIS’, Hogeschool van Amsterdam, 2009; Tweede Kamer der Staten-Generaal, Communicatienetwerk C2000 en geïntegreerd Meldkamersysteem, 28970 nrs 1-2, Sdu Uitgevers, Den Haag, 2003; Veiligheidsregio Rotterdam Rijnmond, Multidisciplinair Slotscenario C2000, Eindrapportage, 2006; Versleijen, R., Over brandweer, snorren, apen en bananen; organisatiecultuur versus organisatieverandering, MCDM, 2007; Werkgroep gebruik basisvoorzieningen, Om te begrijpen moet je goed luisteren, 2009;
96
Bijlagen
Politievakorganisatie ACP, Zwartboek BVH, 2010; SP, SP politie enquête, 2009; Truijens, J., M. van Vechgel, Kardinale kwesties bij ERP-pakketimplementaties, PrimaVera Working Paper Universiteit van Amsterdam, 1998.
Artikelen en vakbladen Nieboer, M., Succesfactoren van een automatiseringsproject, in Informatie Professional, 1998; VTSPN, Scope, afleveringen: juni 2008, oktober 2008, januari 2009, juni 2009, september 2009; Nederlandse Organisatie voor Wetenschappelijk Onderzoek, IT gaat verstand gebruiken, IT risico’s kunnen met modellen goed ingeschat worden, op www.nwo.nl, 2009.
Internetpagina’s www.wikipedia.nl (serendipiteit en kritische succesfactoren); www.rikmaes.nl (negenvlaksmodel); www.computable.nl (casus BVH); www.nujij.nl (casus BVH); www.acp.nl (casus BVH); www.sp.nl (casus BVH); www.minbzk.nl (casus BVH); www.politie-nederland.nl (casus BVH); www.vtspn.nl (casus BVH).
Gehouden interviews
Désirée Bolsius, Veiligheidregio Haaglanden, Hoofd Informatiemanagement & Automatisering;
Luud Verheijen, Veiligheidsregio Midden- en West-Brabant, Strategisch beleidsadviseur informatievoorziening.
97
Bijlagen
Bijlage II Lijst met afkortingen
BVH
:
Basisvoorziening Handhaving
BZK
:
Ministerie van Binnenlandse Zaken en Koningkrijksrelaties
Component G :
component geld
Component K :
component kwaliteit
Component T :
component tijd
ICT
:
informatie- en communicatietechnologie
ISC
:
ICT-Service Centrum Politie, Justitie en Veiligheid
IT
:
informatietechnologie
ITO
:
Informatie en communicatie Technologie Organisatie
MCDM
:
Master of Crisis and Disaster Management
Prevap
:
Preventie activiteitenplan
SLOI
:
Samenwerkende Landelijke Opleidingsinstituten
SP
:
Socialistische Partij
TIS
:
Technische Infrastructuur
vtsPN
:
voorziening tot samenwerking Politie Nederland
WOZ
:
Waardering Onroerende Zaken
98
Bijlagen
Bijlage III Succesfactoren van (ICT) projecten (in samenhang met faalfactoren)
99
Bijlagen
Succesfactor Gebruikers tijdig en gestructureerd betrekken bij het project, zodat zij het systeem accepteren. Effectiviteit (E) = kwaliteit van de hard- en software (K) * de acceptatiegraad van de gebruiker (A) De acceptatie van een systeem is afhankelijk van: Relatief voordeel: de mate waarin het systeem als beter wordt beschouwd dan de praktijk die het moet vervangen. Compatibiliteit: de mate waarin het systeem consistent is met bestaande waarden, eerdere ervaringen en behoeften van de gebruikers (aansluiten bij de uit te voeren taken). Complexiteit: de mate waarin het systeem beschouwd wordt als moeilijk te begrijpen en ingewikkeld in het gebruik. Testbaarheid: de mate waarin een systeem zich laat uitproberen of leent voor experimenten op beperkte schaal. Observeerbaarheid: de mate waarin het gebruik en de effecten van een systeem zichtbaar zijn voor andere leden van het sociaal systeem. De mate waarin de gebruikers goed zijn opgeleid voor het systeem (veel aandacht voor opleidingen, in zowel de applicatie, de processen als nieuwe werkwijzen). Toegankelijkheid: beschikbaarheid en betrouwbaarheid van een technologie, goede afstemming tussen de uit te voeren taak en de mogelijkheden van de techniek, gebruiksvriendelijkheid, eenvoudig in de omgang en gebruikswijze transparant.
Bron ICT in organisaties – Bouwman e.a. (2002). Handboek voor strategisch innoveren. Automatiseren blijft mensenwerk. Bondgenoten in automatisering PID Hogeschool van Amsterdam/Atos Consulting. Succes- en faalfactoren bij de invoering van het digitaal klantdossier.
100
‘Bijbehorende’ faalfactor Veronachtzamen van de gebruiker. Gebrek aan betrokkenheid van de gebruiker vanaf de start van het project. De artificiële gebruiker, zoals de ontwerper deze definieert, komt vaak nauwelijks overeen met de uiteindelijke gebruiker. De organisatiecultuur kun je niet van de één op de andere dag veranderen. Normen en waarden bepalen of een bepaalde toepassing van ICT geaccepteerd wordt door de medewerkers. ICT die geen duidelijke meerwaarde heeft of die normen van anderen opdringt, wordt afgewezen. Niet luisteren naar de gebruikers; het in de wind slaan van terugkoppeling door gebruikers als de systemen worden getest. Onbetrouwbaarheid van het systeem: veelvuldig uitval/instabiel systeem. Gebruikersonvriendelijkheid: systeem niet gemakkelijk te doorgronden. Systeem is ontwikkeld vanuit de mogelijkheden van de techniek in plaats vanuit de wensen & behoeften van gebruikers. Onvoldoende ondersteuning voor gebruikers (opleiding, helpdesk). De voordelen die kunnen worden behaald door wel aandacht te besteden aan de inrichting van de organisatie en de gevoelens van de toekomstige gebruiker worden vaak niet benut. Aan mensen kunnen heel andere eisen worden gesteld, niet alleen in termen van kennis en ervaring, maar mogelijk ook ten aanzien van persoonlijke vaardigheden, houding en gedrag. Veranderingen kunnen daarom de nodige weerstand opleveren. Het is voor de gebruiker moeilijk om aan te geven wat
Bron ICT in organisaties. Projectrisicomanagement Problemen, planning en kennis. Projectmanagement/Princ e2.
Bijlagen
Participatie: de participatie van de betrokken en gebruikers bij: analyse van de bestaande situatie, het zoeken naar oplossingen en het maken van een zinvolle keuze (de mate waarin de gebruikers invloed hebben gehad op het proces). Analyse: een goede en zorgvuldige analyse wordt gemaakt van de huidige en gewenste situatie.
Draag zorg voor participatie die daadwerkelijk bijdraagt aan een beter systeem: Tussen de betrokkenen moet enige consensus zijn over de basisdoelstellingen. Begrenzingen en inhoud van participatie moet voor alle betrokkenen duidelijk zijn. Er moet nog voldoende speelruimte zijn, er moeten nog mogelijkheden aanwezig zijn om de beslissing te beïnvloeden. Goede coördinatie tussen afgevaardigde en achterban. Effectieve communicatie. Een succesvolle implementatie van een systeem is afhankelijk van: Juiste projectstructuur en – strategie. De business moet opdrachtgever zijn van een ICT-project en het project als zijn belang voelen. Aanwezigheid van duidelijke doelstellingen en deadlines (afgestemd op de
Automatiseren blijft mensenwerk.
ICT in organisaties – Bouwman e.a. (2002). Projectrisicomanagement. Twaalf verhalen over het managen van projecten. 100 gouden regels voor projectmanagement.
101
hun wensen/behoeften zijn. Veelal omdat men er geen idee van heeft hoe het systeem er in de praktijk uit zal zien. Persoonlijk nut van de verandering wordt niet ingezien. Een automatiseringsgeschiedenis met problemen zorgt voor tegenstand bij de introductie van automatisering. De organisatie gebruikt de opleiding vaak als sluitpost van de automatisering. Invoeringsprobleem: apparatuur niet direct beschikbaar, gebruikersorganisatie is onvoldoende voorbereid op de introductie van een nieuw systeem of systeem heeft tekortkomingen. Automatiseerders: gebruikersorganisatie weet niet wat ze wil. Gebruikersorganisatie: automatiseerders stellen hun vragen zo ingewikkeld. Bestaat de participatie alleen maar uit het krijgen van informatie over de voortgang van het project of houdt participatie in dat kiezers de gelegenheid krijgen om te kiezen voor een bepaald systeem?
Door toepassing van ICT worden toegang tot informatie, macht en status anders verdeeld over communicatiepartners. In de huidige automatiseringspraktijk is er maar al te vaak nooit tijd om het goed te doen en door noodzaak wel afgedwongen, tijd om het over te doen. Geen moment van rust, veel reorganisaties.
Automatiseren blijft mensenwerk.
ICT in organisaties. Automatiseren blijft mensenwerk. Projectrisicomanagement; meer grip op het resultaat van uw ICT-investeringen. 100 Gouden regels voor
Bijlagen
bedrijfsstrategie/business), welke voor iedereen meteen duidelijk zijn. Vier de successen (behalen van mijlpalen). De bestaande organisatiecultuur (houding t.o.v. het systeem). Communicatie met betrokkenen (optimale informeren). Heldere en duidelijke informatie over de werking, het doel van de automatisering en de voortgang. Het gebruik van een business case. De mate waarin de organisatie(processen) ingericht en beschreven zijn. Vaardigheden voor het sturen, begeleiden en beheersen van veranderingsprocessen (kwaliteit projectleiding). Resultaatgerichtheid. Unieke samenwerking van individuen. Belang van leiderschap (ambitie). Het verkrijgen van de juiste mensen voor de uitvoering van het project (ervaring, kennis, motivatie, beschikbaarheid, teamplayer). De componenten ambitie, mensen, middelen en tijd moet in balans zijn (en voldoende aanwezig). Mijlpalen om voortgang af te dwingen. Commitment (betrokkenheid en enthousiasme) van de opdrachtgever, bestuur, gebruikers, OR, ontwikkelaars. Organisatie moet de automatisering als een reorganisatieproces aanpakken en zich bewust zijn van de belangstellingen binnen een organisatie. Grootste investering niet in direct in de technologie, maar meer in de acceptatie van het systeem door het personeel. Het optimaal begeleiden van de verandering. Besteed ruimschoots aandacht aan de
Handboek voor strategisch innoveren. Automatiseren blijft mensenwerk. Problemen, planning en kennis. Bondgenoten in automatisering. Projectmanagement op basis van Prince2. Artikel: IT gaat verstand gebruiken, IT risico’s kunnen met modellen goed geschat worden. Lessen uit ICT-projecten bij de overheid; deel B. Lessen uit ICT-projecten bij de overheid; deel A. Projectrisicomanagement. Kardinale kwesties bij ERPpakketimplementaties. The anatomy of major projects. Artikel: succesfactoren van een automatiseringsproject.
102
Slecht projectmanagement: te weinig creëren van betrokkenheid van medewerkers, onvoldoende steun geven vanuit de directie, onduidelijke afbakening van het project, geen eenduidige doelstelling, geen realistische verwachtingen (geen evenwicht in ambitie, beschikbare middelen en tijd), slechte communicatie en spraakverwarringen. Ontbreken van een duidelijke Business Case. Leegloop; medewerkers met kennis vertrekken. Projecten zijn te ambitieus en te complex. De combinatie van politieke, organisatorische en technische factoren worden onvoldoende beheerst. Tijdens een IT-systeemontwikkelingstraject is een goede afstemming tussen enerzijds de automatiseerders en anderzijds de organisatie(processen) eerder uitzondering dan regel. Onnatuurlijke deadlines. Project managen is een vak. Het zou een heel groot toeval zijn als een gemiddelde goed functionerende lijnmanager ook projecten goed zou kunnen managen. Slechte formulering van het doel is de belangrijkste oorzaak van het falen van projecten. Vooral in de IT-projecten hebben de specialisten de prettige gewoonte om erg technische requirements op te stellen, die je als gebruiker niet kunt begrijpen. Eén van de meest voorkomende valkuilen is dat men aanneemt dat iedereen gelijktijdig klaar is om te gaan veranderen. Dat is nooit het geval. Innovatie en invoering gaan te snel en daardoor wordt niet genoeg tijd gegeven om er op voor te bereiden. Het management ziet vaak geen noodzaak om de organisatie bij de verandering te begeleiden. Het management heeft veelal onvoldoende kennis van het informatiebeleid waardoor het totaaloverzicht mist. Door deze kennisachterstand is het management geneigd de verantwoordelijkheden te delegeren aan
projectmanagement. De projectsaboteur. Handboek voor strategisch innoveren. Problemen, planning en kennis. Projectmanagement/Princ e2. Lessen uit ICT projecten bij de overheid, deel A & B. IT risks in Measure and Number Succes- en faalfactoren bij de invoering van het digitaal klantdossier. The anatomy of major projects.
Bijlagen
consequenties die de automatisering heeft voor: de arbeidsinhoud, de arbeidsomstandigheden, arbeidsvoorwaarden en arbeidsverhoudingen. Voldoende ruimte/tijd voor: gewenning, het testen van het systeem, bijsturingmogelijkheden tijdens de rit. Goede technische voorbereiding en technische kwaliteit van het systeem. Eén verandering tegelijkertijd. ICT- projecten moeten in samenhang met andere projecten in de projectenportfolio bezien worden. Nauwkeurige risico- en informatie analyse (en nemen van tegenmaatregelen). Extreme wilskracht er een succes van te maken en de opstelling om in de huid van de ander te kruipen. Wilskracht, vertrouwen, openheid, eerlijkheid, doen wat je zegt, wederzijds respect, teamwork, geen persoonlijke prioriteiten. Gelegenheid bieden voor het stellen van vragen en het voeren van discussies. Gedetailleerde draaiboeken. Samenwerking van alle bij het project betrokken partijen. Snel ingrijpen als het project uit de bocht dreigt te vliegen. Bestuurders/leiding moet het technology-fix denken (dat het puur gaat om technische vraagstukken) loslaten en zien dat het om informatie- en communicatievraagstukken en die zijn op hun beurt organisatievraagstukken. Bestuurders/leidinggevenden moeten goede informatie krijgen over de voortgang van het project, zodat ze er grip op houden. Beperk zoveel als nodig de organisatorische en technische complexiteit.
103
de technici. De manager is vaak alleen geïnteresseerd in de economische aspecten van de automatisering en laat zich pas horen als een automatiseringsproject uit de hand is gelopen. De Business en ICT zijn twee gescheiden werelden. De business ziet ICT als het wondermiddel voor het oplossen van vraagstukken. De realisatie van de ICToplossing is vervolgens ‘iets van de ICT-ers’. Er wordt te weinig rekening gehouden met de impact van een organisatieverandering op ICT. De relatie tussen ICT en organisatie worden over het hoofd gezien. De automatiseringsspecialist is veelal alleen deskundig op het gebied van automatisering. De OR wordt bij automatiseringsprojecten nog vaak niet als overlegpartner gezien. De OR doet de gevolgen bij de invoering van automatisering ook vaak af als niet belangrijk. Beschrijving van de bestaande situatie wordt bij automatiseringsprojecten vaak te snel gedaan. I.p.v. problemen te onderkennen, draagt men al oplossingen aan. Er is weinig oog voor de organisatiecultuur en de eventuele belangentegenstellingen. Gebrek aan betrokkenheid van de opdrachtgever en management van de organisatie. Het ontbreken van acceptatiecriteria. De grootste problemen die kunnen opdoemen, zijn de steeds weer nieuwe eisen die worden gesteld aan software. Voortschrijdend inzicht (‘organizational learning’) of veranderende wetgeving is daar vaak de oorzaak van. Start- en einddatum van de projecten zijn diffuus. De tijd die het kost om een systeem in beheer te nemen wordt nog wel eens onderschat. Onduidelijk, onzorgvuldig of onvoldoende gedetailleerde uitgewerkte doelen en eisen.
Bijlagen
Juiste belegging en uitvoering van taken en bevoegdheden. Houdt rekening met de invloed van (veranderingen in) wetgeving, beleid e.d. Maak een volledig financiële analyse van alle project risico’s. Houdt ook rekening met budget voor tussenliggende wijzigingen, beheer en doorontwikkeling. Er moet één persoon of groep zijn die de leiding heeft (strak de touwtjes in handen).
Flexibiliteit binnen het systeem. Bouw bij het ontwerpen van het systeem escape mogelijkheden in. Het systeem moet met veranderende situaties mee kunnen groeien. Aansluiting van het nieuwe systeem op reeds aanwezige communicatiestructuren en informatiemiddelen. Aansluiting bij de praktijksituatie (‘fit for use’). Systeem moet de bedrijfsprocessen en de gebruiker ondersteunen en niet andersom. Stap voor stap ontwikkelen en het op gezette tijden in de praktijk testen van de apparatuur. Begin klein. Freeze design once agreed.
Automatiseren blijft mensenwerk. Bondgenoten in automatisering. Lessen uit ICT-projecten bij de overheid; deel A. The anatomy of major projects.
104
Trage voortgang, waardoor enthousiasme en prioriteit afneemt. Geen sterke leiderschap. Technische onzekerheid.
Bijlagen
105
Bijlage IV Vragenlijst interviews Het project (algemeen)
Projectmatige aanpak
Procesmanagement
Conclusie
Wat was het doel/opdracht van het project? Is bij aanvang van het project gedefinieerd wat het project op moet leveren (Functioneel Plan van Eisen)? Wat dit doel voor iedereen duidelijk? Wat zijn de randvoorwaarden van het project? Wie is de opdrachtgever/opdrachtnemer? Zijn de opdrachtgever en opdrachtnemer voldoende betrokken bij het project? Sluit het doel van het project aan bij de organisatie (strategie, processen, werkzaamheden)? Is een projectmethodiek toegepast? Zo ja, in welke mate? Zo nee, waarom niet? Is het project conform planning & budget verlopen? Voldoet het opgeleverde resultaat aan de gewenste kwaliteit (functionaliteit, volgens de opdrachtgever en gebruiker)? Is het project daadwerkelijk gemanaged/gestuurd (planning/mijlpalen etc.)? Zijn de taken, verantwoordelijkheden en bevoegdheden van en voor iedereen duidelijk? Is er sprake van een goede projectleider? Zijn binnen het project voldoende medewerkers met de juiste capaciteiten (expertise) beschikbaar? Zijn de gebruikers bij het project betrokken? Zo ja, hoe zijn ze bij het project betrokken? Is er sprake van een realistische planning? Is een opleiding van gebruikers noodzakelijk? Zo ja, hoe is deze vorm gegeven? Zijn de verwachtingen goed gemanaged? Hoe is beheer/borging geregeld? Wat zijn de succesfactoren van het project? Welke leerpunten zijn er?
Noot: op basis van de analyse op het niveau van beheersfactoren en succesfactoren is aanvullende informatie gevraagd op die onderdelen waar de benodigde informatie ontbrak.