Onderzoek naar IT-opdrachtgeverschap binnen de overheid. Een zoektocht naar balans in beheersmaatregelen

Transcriptie

1 Onderzoek naar IT-opdrachtgeverschap binnen de overheid Een zoektocht naar balans in beheersmaatregelen Auteur: George Leih Datum: 11 januari 2010

2

3 Inhoud 1. Inleiding Aanleiding Doelstelling Gevolgde aanpak Leeswijzer 4 2. Samenvatting unieke uitdagingen Kenmerkend risicoprofiel Kenmerkende uitdagingen 6 3. Samenvatting aangedragen oplossingen Vijf scholen van goed opdrachtgeverschap Afstemmen met belanghebbenden Selecteren en aansturen van de IT-leverancier Realiteitszin bij politieke ambities Conclusies op weg naar goed opdrachtgeverschap Huidige situatie Gewenste situatie Wat moet er veranderen Verdieping - unieke uitdagingen Omvang Organisatorische complexiteit Technologische ervaring Verdieping - aangedragen oplossingen (opstartfase) De management school De analytische school De sociologische school De governance school De agile school Verdieping - aangedragen oplossingen (uitvoeringsfase) De management school De analytische school De sociologische school De governance school De agile school Verdieping op weg naar goed opdrachtgeverschap De management school De analytische school De sociologische school De governance school De agile school 30 Bijlage 1. Gebruikte literatuur 31 1

4 1/ Inleiding Dit document bevat de resultaten van het onderzoek dat DNV heeft uitgevoerd naar IT-opdrachtgeverschap binnen de overheid. /1 Aanleiding In de afgelopen jaren is veel commotie ontstaan over mislukte IT-projecten bij de overheid. Dit heeft geleid tot een onderzoek door de Algemene Rekenkamer [Rekenkamer A, B]. Naar aanleiding van dit onderzoek heeft Minister ter Horst de Tweede Kamer beloofd het opdrachtgeverschap van IT-projecten bij de overheid te verbeteren [Horst A, B, C]. De Rijks-CIO, Maarten Hillenaar, geeft eveneens aan dat de prioriteit ligt bij het onder controle brengen van de grote IT-projecten [Rijks-CIO]. Goed opdrachtgeverschap wordt steeds vaker aangewezen als belangrijke factor voor het slagen van IT-projecten. Daarmee is nog niet duidelijk wat goed opdrachtgeverschap inhoudt en wat wel of niet werkt in de praktijk. Om het inzicht hierin te vergroten heeft DNV een onderzoek uitgevoerd onder ervaringsdeskundigen bij overheidsinstanties. Een tweede aanleiding voor dit onderzoek wordt gevormd door onze langdurige betrokkenheid bij IT-projecten bij de overheid. We zien dit onderzoek als een vervolg op een eerder door ons uitgevoerd onderzoek van begin Daarin was de onderzoeksvraag: waarom maakt men steeds dezelfde fouten in IT-projecten? Dit onderzoek resulteerde in een seminar getiteld 25 jaar stilstand in IT en in een oproep aan Nederland (overheid én bedrijfsleven) om professioneler met IT-projecten om te gaan [Seminar1]. In de jaren daarna hebben we ons ingespannen om de professionaliteit van opdrachtgevers in Nederland ook daadwerkelijk te verhogen middels bijdragen aan het CMMI-model voor opdrachtgeverschap [CMMI A, CMMI B], middels opleidingen en adviezen en middels publicaties [Leih1, Leih2, Maat, Otter, Raemaekers]. Onze interesse in het effect van goed opdrachtgeverschap op de slaagkans van projecten kent dus een lange historie. /2 Doelstelling Doel van ons onderzoek is het beantwoord krijgen van de volgende vragen: 1. Hoe staat het opdrachtgeverschap bij de overheid er in de praktijk voor? 2. Kent de overheid kenmerkende uitdagingen die het bedrijfsleven niet kent? Welke? 3. Welke maatregelen op het gebied van opdrachtgeverschap zijn effectief? 4. Zijn de maatregelen van de minister effectief? Essentieel uitgangspunt van het onderzoek is dat de primaire focus op oplossingen en successen dient te liggen, zie doelen 3 en 4. Er gaat immers ook heel veel goed in overheidsprojecten. De meeste publicaties kiezen een negatieve invalshoek, dat willen we in dit verslag vermijden. Een analyse van overheidsspecifieke factoren bij de mislukkingen achten we echter essentieel voor het waarderen van de effectiviteit van de oplossingen, vandaar doelen 1 en 2. De laatste jaren zijn diverse onderzoeken uitgevoerd naar opdrachtgeverschap van IT-projecten: het rekenkameronderzoek zelf, een onderzoek van de Viag [VIAG] gericht op gemeenten en een onderzoek van het Netwerk Betere Projecten binnen de rijksoverheid [VROM]. Ons onderzoek is het eerste dat niet alleen naar de gebruikelijke projectmanagementfactoren kijkt maar ook specifieke IT-factoren in ogenschouw neemt. Bovendien denken we vanuit onze analytische achtergrond en vanuit onze ervaring iets toe te kunnen voegen 2

5 aan de diepgang van de eerdere onderzoeken. /3 Gevolgde aanpak Het onderzoek is uitgevoerd door een groot aantal (38) gesprekken te voeren bij 26 verschillende overheidspartijen. Het onderzoek is breed van opzet, het richt zich op gemeenten, departementen, zelfstandige bestuursorganen, diensten en agentschappen, zie onderstaande tabel. Het onderzoek is anoniem, we hebben ervoor gezorgd dat uitspraken niet aan individuele personen, instellingen of projecten zijn te koppelen (tenzij gegevens reeds elders en door anderen zijn gepubliceerd). Eén persoon wilde niet dat zijn organisatie werd genoemd. Ministeries Diensten, directoraten, agentschappen ZBO s Gemeenten Overig BZK De Nederlandse Bank CBS Breda Algemene Rekenkamer EZ Belastingdienst DNB Den Haag Raad voor de Rechtspraak Justitie Dienst Justitiële Inrichtingen IBG Rotterdam LNV Raad voor de Kinderbescherming RDW 1x anoniem SZW Rijksdienst Cultureel Erfgoed UWV VWS SenterNovem VROM Stichting ICTU vtspn De gesprekken zijn met de volgende soorten functionarissen gehouden: Functie Aantal personen Directeuren, beleidsmakers (binnen de business) 8 Informatiemanagers, beleidsadviseur (binnen de business) 11 CIO, staf informatiseringsbeleid 7 Projectmanagers, programmamanagers, ketencoördinatoren 6 Interne leveranciers, shared service centra, regiebureaus 5 Onderzoeker 1 Het onderzoek had een exploratief karakter. Dat betekent dat er open en zonder restricties gezocht is naar factoren die een rol spelen bij opdrachtgeverschap bij de overheid; er zijn geen vooraf opgezette ideeën getoetst. Groot voordeel van exploratief onderzoek is dat je het speelveld (welke problemen zijn er, wat wordt onder opdrachtgeverschap verstaan, hoe draagt opdrachtgeverschap bij aan een oplossing) op onbevangen wijze in kaart brengt. Dit biedt nieuwe inzichten die vergelijkend onderzoek niet aan het daglicht zou brengen. Nadeel van exploratief onderzoek is dat je geen statistische analyses kunt uitvoeren op de onderzochte populatie, zoals bij vergelijkend onderzoek. 3

6 Het onderzoek is uitgevoerd door Arjen Uittenbogaard, Eline Bomhof, George Leih, Patrick Verheij, Pieter Verheugd, Pieter Verhoeven, Ruurd Portman, Sonja den Biggelaar, Sven van der Zee, Ton Tijdink en Wouter Raemaekers. De resultaten van het onderzoek zijn publiek toegankelijk, het doel was dat de overheid (en wijzelf) er van leren. De resultaten zijn eerder gepresenteerd op het DNV seminar van oktober 2009, zie [Seminar2]. /4 Leeswijzer Het document bestaat uit twee delen: een samenvatting (hoofdstuk 2 t/m 4) en een verdieping (hoofdstuk 5 t/m 8). Dit leidt tot de volgende opbouw: Deel I - samenvatting Hoofdstuk 2 bevat een samenvatting van de kenmerkende uitdagingen waarmee de overheid wordt geconfronteerd. Hoofdstuk 3 bevat een samenvatting van de aangedragen oplossingen vanuit de visies van de vijf scholen die binnen het onderzoek herkenbaar zijn. Hoofdstuk 4 bevat de conclusies: hoe kan goed opdrachtgeverschap worden vormgegeven? Deel II - verdieping Hoofdstuk 5 is een verdieping van hoofdstuk 2; het maakt duidelijk waarom IT-projecten bij de overheid falen. Hoofdstuk 6 behandelt aangedragen oplossingen voor de opstartfase van IT-projecten, de fase waarin de opdrachtgever een opdracht formuleert. Hoofdstuk 7 behandelt aangedragen oplossingen voor de uitvoeringsfase van IT-projecten, de fase waarin de opdrachtgever probeert grip te houden op de voortgang en de projectresultaten. Hoofdstuk 8 vat de kennis en kunde samen die een goede opdrachtgever bij de overheid volgens de vijf scholen moet hebben. Deel I kan zelfstandig worden gelezen. Het geeft op hoog abstractieniveau de conclusies weer die DNV aan het onderzoek verbindt. Deel II bevat een groot aantal quotes, termen en voorbeelden uit de interviews. Dit deel bevindt zich veel dichter bij de uitspraken van de geïnterviewden en is daarom uiterst interessant. We verwachten dat lezers veel zullen herkennen en leren bij het lezen van uitspraken van ervaringsdeskundigen. We kunnen ons daarom goed voorstellen dat er lezers zijn die liever eerst Deel II lezen om vervolgens voor zichzelf de conclusies te trekken. Dat kan, ook Deel II is zelfstandig leesbaar. 4

7 2/ Samenvatting unieke uitdagingen In dit hoofdstuk zullen we zien dat publieke IT-projecten een ander risicoprofiel hebben dan private ITprojecten (sectie 2.1). Als gevolg hiervan hebben opdrachtgevers binnen de overheid een aantal typerende uitdagingen (sectie 2.2) die in het bedrijfsleven niet of in mindere mate spelen. Opdrachtgevers kunnen deze nieuwe inzichten gebruiken om de aansturing van hun IT-projecten effectiever vorm te geven. /1 Kenmerkend risicoprofiel IT-projecten hebben bij de overheid een ander risicoprofiel dan in het bedrijfsleven. Met name de organisatorische complexiteit is groot, zie Figuur 1, doordat er meestal meer partijen met uiteenlopende belangen betrokken zijn bij de projecten. Mede hierdoor is de omvang soms uitzonderlijk groot, projecten van 20 miljoen euro of meer zijn bij de overheid vrij gebruikelijk maar komen in het bedrijfsleven nauwelijks voor. In de literatuur wordt aangegeven dat dit type megaprojecten zich boven de critical size range bevinden, de faalkans is 40% of hoger. Figuur 1 De technologische dimensie die vaak wordt onderscheiden in risicoprofielen [McFarlan] speelt minder prominent bij de overheid. Daar waar het bedrijfsleven voorop wil lopen door innovatieve projecten te doen is de noodzaak hiertoe binnen de overheid minder. We beschouwen nu twee projectsoorten uit Figuur 1 om het kenmerkende risicoprofiel van overheidsprojecten te illustreren. Afdelingsoverstijgende projecten. Dit zijn veelal projecten die tot doel hebben om de interne bedrijfsvoering van een organisatie te optimaliseren met behulp van IT. Je komt dit type projecten zowel bij gemeenten, in ZBO s, in agentschappen en op departementen tegen. Vaak zie je dat, zodra zo n organisatiebreed project is geïnitieerd, allerlei afdelingen hun aanvullende wensen inbrengen waardoor de oorspronkelijke scope snel verwaterd. Door de organisatorische complexiteit heeft dit type projecten de neiging om geleidelijk in omvang te groeien terwijl de doelstellingen vervagen. Een goede opdrachtgever is in staat om een dergelijk verwateringsproces te stoppen. Het aanwijzen van een opdrachtgever is echter lastig, afdelingshoofden staan hun mandaat ongaarne af aan een collega. Daarom wordt vaak naar boven gekeken, naar de DG, de SG of de gemeentesecretaris, die dan maar als opdrachtgever moet optreden. Of er wordt een hele hiërarchie aan gedelegeerde opdrachtgevers aangesteld, zie Figuur 2, die gezamenlijk de dienst uitmaken. Binnen een dergelijke kerstboom is het nemen van besluiten niet eenvoudig, het risico van scopeverhogende compromissen is hoog. In [McKinsey] wordt vanwege de verhoogde risico s de Belastingdienst ontraden om afdelingsoverstijgende systemen te ontwikkelen. Figuur 2 5

8 Beleidsprojecten. In zogenaamde beleidsprojecten (rechtsboven in Figuur 1) is de organisatorische complexiteit maximaal. Beleidsprojecten hebben tot doel iets in de samenleving te bereiken met behulp van IT: lastenverlichting, één loket, één digitaal dossier. Ze komen tot stand doordat een beleidsmedewerker op een departement de opdracht krijgt om politiek beleid of wetgeving door te voeren met de inzet van ITmiddelen. De uitvoering van het beleid is vaak bij meerdere uitvoeringsinstanties en/of gemeenten belegd. Hierdoor wordt de opdrachtgeverhiërarchie nog complexer dan in het vorige voorbeeld, zie de kerstboom in Figuur 3. Het aantal belanghebbenden bij het project neemt snel toe, waardoor het risico op scope-uitbreiding navenant stijgt. Het vaststellen van de maatschappelijke baten is uiterst lastig, voordelen in de samenleving zijn vaak moeilijk te kwantificeren. Dit biedt alle ruimte tot het oprekken van die baten gedurende het project (vergelijk het Betuwetraject dat door het honoreren van allerlei Figuur 3 lokale belangen vele malen duurder is geworden dan oorspronkelijk begroot). Daar waar opdrachtgevers in het bedrijfsleven verantwoordelijk kunnen worden gemaakt voor het incasseren van de baten binnen het eigen bedrijf is dat bij beleidsprojecten niet mogelijk. In de lijst van projecten boven de 20 miljoen bevinden zich veel beleidsprojecten. Bijkomend probleem van beleidsprojecten is dat ze een hoge politieke zichtbaarheid genieten. Politici laten zich in hun ambities zelden afremmen door IT-beperkingen, ze stellen vaak strakke politieke deadlines die Projecten met een verhoogd afbreukrisico onhaalbaar zijn. Als gevolg hiervan wordt er met de ITuitvoering begonnen terwijl het beleid nog aan wijzigingen onderhevig is. Dit leidt tot nog meer scopeuitbreiding tijdens het project, één van de bekendere faalfactoren van IT-projecten [Glass, Jones]. Concluderend kan gezegd worden dat diverse soorten overheidsprojecten een verhoogd afbreukrisico kennen. Zie het kader hiernaast. > megaprojecten: 20 miljoen euro of meer > beleidsprojecten: iets in de samenleving realiseren > ketenprojecten: processen over meerdere partijen > organisatieoverstijgende/bovendepartementale projecten: meerdere opdrachtgevers > fusieprojecten: bestaande belangen, weerstand > generieke projecten: één oplossing voor meerdere problemen (multi-wet, -subsidie & -sector) > innovatieprojecten: de wens om voorop te lopen /2 Kenmerkende uitdagingen Door het afwijkende risicoprofiel van overheidsprojecten, zie vorige sectie, hebben opdrachtgevers van ITprojecten bij de overheid specifieke uitdagingen die anders en moeilijker zijn dan in het bedrijfsleven. De drie uitdagingen die er uitspringen, behandelen we in deze sectie. Afstemmen met belanghebbenden. Door de verhoogde organisatorische complexiteit is het aantal belangen bij een project vaak talrijk en divers. Het afstemmen en prioriteren van die belangen is veelvuldig als complexe uitdaging genoemd. Ook is het uitvoeren van informatieanalyses vaak lastig doordat de daarvoor benodigde expertise (zowel van de bedrijfsprocessen als van IT-mogelijkheden) niet beschikbaar is. Gebruikers worden pas laat betrokken waardoor weerstand tegen de IT-vernieuwing ontstaat. Ook gebeurt het dat men de bestaande werkwijze heilig verklaard, elke verandering wordt als bedreigend ervaren. Procesvernieuwing komt hierdoor moeilijk van de grond, er wordt onvoldoende geprofiteerd van de mogelijkheden die IT biedt. Selecteren en aansturen van de IT-leverancier. Dit is een tweede probleem dat veelvuldig wordt genoemd. Bij interne IT-leveranciers wordt vaak getwijfeld aan de competenties, hun imago is slecht. Ook komen ze vaak met oplossingen die geen recht doen aan de oorspronkelijke vraag. Dit komt deels door het grote aantal schijven waarlangs gecommuniceerd wordt (chinese whisper), deels doordat IT ers voor de gebruikersorganisatie denken te kunnen spreken en deels door het ontbreken van een afrekencultuur. Bij externe leveranciers speelt het probleem van de aanbestedingsplicht. Veel organisaties worstelen met de vraag hoe ze, binnen de 6

9 aanbestedingsregels, een leverancier moeten selecteren die én kwaliteit levert én flexibel omgaat met de organisatorische complexiteit. Veel geïnterviewden constateren dat aanbestedingen in de praktijk meestal de goedkoopste leverancier opleveren en maar zelden de beste. Realiteitszin. De grootste uitdaging waarmee overheidsprojecten worstelen is wellicht het realiteitsgehalte. Velen constateren dat in het verleden projecten zijn opgestart met onrealistische doelstellingen: een generiek salarissysteem voor alle departementen, multi-wet systemen, systemen die 400 bestaande applicaties overbodig maken, systemen die een complete organisatiekanteling ondersteunen. Dit betreft vaak beleidsprojecten, zie vorige sectie, waarin politieke wensen één op één zijn omgezet in IT-behoeften. Vaak betreft dit ook de megaprojecten van 20 miljoen of meer. Veel geïnterviewden vragen zich af hoe je kunt voorkomen dat dit soort Kenmerkende uitdagingen voor de overheid > afstemmen met belanghebbenden: hoe krijg je alle betrokkenen op één lijn? > selecteren/aansturen van de IT-leverancier: hoe laat je de leverancier de juiste dingen doen, gegeven de aanbestedingsregels? > realiteitszin bij politieke ambities: hoe zorg je dat projectdoelen realistisch en haalbaar blijven? gedoemde projecten wordt opgestart. En hoe je zo n project als het ontspoord is tot stoppen kunt dwingen. Concluderend kan gezegd worden dat de overheid drie soorten kenmerkende uitdagingen kent, zie het kader hiernaast. In het volgende hoofdstuk gaan we na hoe aangedragen oplossingen deze problematiek adresseren. 7

10 3/ Samenvatting - aangedragen oplossingen In de interviews hebben we vijf scholen van goed opdrachtgeverschap herkend, zie sectie 3.1. Deze scholen bieden uiteenlopende oplossingen voor de drie kenmerkende uitdagingen uit de vorige sectie, zie secties 3.2 t/m 3.4. Een aantal scholen zoekt de oplossing in meer controle en toezicht, een aantal andere scholen hecht meer aan vertrouwen, flexibiliteit en vakmanschap. De bespiegelingen in dit hoofdstuk zijn er op gericht om de verschillende oplosrichtingen goed te kenschetsen en om te kijken of ze elkaar versterken of juist tegenwerken. /1 Vijf scholen van goed opdrachtgeverschap Een school is in dit verslag een stroming van personen die een gezamenlijk gedachtegoed hebben. De personen geloven in dezelfde doelen, oplossingen en waarden. Ze geven vergelijkbare voorbeelden, hanteren een vergelijkbare terminologie en hebben vergelijkbare kritiek op andere scholen. In de psychologie is het onderscheid tussen scholen (behavioral, cognitief, humanistisch, psychoanalytisch, gestalt) gebruikelijk, in de IT-wereld wordt het incidenteel gehanteerd [Pettichord]. DNV heeft binnen de geïnterviewde populatie vijf verschillende scholen herkend, zie Figuur 4. Figuur 4 1. Management school. Gelooft dat het gedisciplineerd volgen van het juiste proces en het nauwgezet verdelen van de rollen leidt tot succesvolle IT-projecten. De management school gelooft in PRINCE2 en aanverwante methoden. 2. Analytische school. Gelooft dat projecten succesvol verlopen als je je concentreert op de inhoud. De inzet van de juiste methoden en technieken bij is essentieel. 3. Governance school. Gelooft dat goed bestuur, goed toezicht en adequate verantwoording ervoor zorgen dat projecten succesvol verlopen. 4. Sociologische school. Gelooft dat software ontwikkelen een uitdaging is die eisen stelt aan de mensen, de teamsamenstelling, de samenwerking en het onderlinge vertrouwen. 5. Agile school. Gelooft dat systeemontwikkeling voortdurend dient te worden bijgestuurd naar aanleiding van wijzigende inzichten. Binnen de overheid is de management school veruit het populairst. Ook de governance school kent een toenemend aantal aanhangers, de maatregelen van minister Ter Horst richten zich primair op verbetering van de governance. Deze twee scholen vertegenwoordigen het perspectief waar managers en bestuurders zich van nature comfortabel bij voelen: de projectbeheersing. De drie andere scholen verzetten zich tegen de proces- en reguleeraanpak, in [Peters] treffend als intensieve menshouderij gekarakteriseerd. Ze vragen meer aandacht voor de inhoud (analytische school), de mens (sociologische school) en een flexibele ontwikkelaanpak (agile school). Dit soort aspecten wordt door managers over het algemeen gedelegeerd naar projectmanagers en opdrachtnemers. De aanhangers van deze drie scholen betogen dat het voor succesvolle IT-projecten noodzakelijk is dat opdrachtgevers ook bewuste keuzes maken 8

11 ten aanzien van de inhoud, mensen en flexibiliteit. Dit is niet persé strijdig met PRINCE2 maar doordat het buiten hun comfort zone ligt geven managers en bestuurders er weinig tot geen aandacht aan. We bekijken nu welke visie de vijf scholen hebben op de kenmerkende overheidsproblematiek, zoals in sectie 2.2 benoemd. /2 Afstemmen met belanghebbenden Hoe zorg je dat de talrijke en diverse wensen van alle betrokkenen bij een IT-project worden afgewogen en geprioriteerd? Hoe zorg je voor draagvlak en voorkom je weerstand? Hoe zorg je dat de volledige potentie van IT wordt uitgenut? De vijf scholen bieden hiervoor verschillende oplossingen, deels door belanghebbenden uiteenlopende rollen toe te kennen en deels door bevoegdheden op uiteenlopende plaatsen te beleggen. We vergelijken de aangedragen oplossingen. senior user B-IT-alignment informatieanalyse review & test management school proces analytische school inhoud governance school regels & toezicht juiste mensen samenwerking key users multi-disciplinair sociologische school mens & gedrag agile school flexibiliteit De agile school is het meest rigoureus. Het hanteert als uitgangspunt dat key users actief móeten participeren in IT-projecten. Elke gebruikersgroep moet vertegenwoordigd zijn door iemand met mandaat om besluiten over de systeemfunctionaliteit te nemen. Volgens velen is dit uitgangspunt binnen de overheid niet realistisch. De key users hebben het te druk met hun reguliere werk en ze krijgen bovendien het verlangde mandaat niet. De agile aanhangers zeggen daarop dat je zonder key users überhaupt niet aan een project moet beginnen. Bij dogmatisch doorvoeren van dit principe zal het aantal agile projecten binnen de overheid zeer beperkt blijven, het onderzoek heeft inderdaad nul praktijkvoorbeelden van volledig agile uitgevoerde overheidsprojecten opgeleverd. De analytische en management school kennen aan gebruikers een beperktere rol toe: die van reviewer. ITexperts worden geacht hun afwezigheid te compenseren door gedetailleerd op papier te zetten aan welke eisen het te ontwikkelen systeem zal voldoen. De gebruikers, al dan niet georganiseerd in een klankbordgroep, mogen de stukken reviewen. Vaak blijkt achteraf dat de gebruikers niet goed hebben begrepen waaraan ze goedkeuring hebben verleend; het communiceren over IT-systemen is inherent moeilijk. De agile school gelooft daarom dat alleen werkende prototypes als communicatiemiddel met gebruikers kunnen dienen. Door de vele uiteenlopende wensen die binnen de overheid worden ingebracht leidt de analytische aanpak regelmatig tot een explosie aan functionaliteit en uitzonderingen. Vooral wanneer de analyse door de leverancier wordt uitgevoerd is de neiging groot alle wensen te honoreren. Aanvullende besluitvorming vanuit een stuurgroep is daarom gewenst. Het managen van belanghebbenden is in de management school de taak van de stuurgroep (senior user en executive). De executive (opdrachtgever) stelt prioriteiten tussen alle ingediende wensen, zowel bij de originele opdrachtformulering als bij latere scope wijzigingen. Ook binnen de stuurgroep lukt het niet altijd om het mandaat van belanghebbenden af te staan aan één senior user en één opdrachtgever, zoals PRINCE2 voorschrijft. Hierdoor ontstaan veelvuldig projecten met meerdere opdrachtgevers of met stuurgroepen met wel 9

12 20 personen (Poolse landdagen). Bij een dergelijke bevelstructuur is de neiging groot om eerder tot compromissen te komen dan tot prioriteiten. De sociologische school gelooft dat alleen een standvastige opdrachtgever hieraan effectief sturing kan geven. Hij moet als probleemeigenaar ervoor waken dat de scope van het project niet gaat zwabberen, allerlei bijdoelen van belanghebbenden moeten netjes afgewimpeld worden. Ook moet hij een duidelijke visie op de toekomst hebben en op de rol die automatisering daarin speelt. In de praktijk wordt de scope bewakingsrol regelmatig naar de projectmanager gedelegeerd. Een goede projectmanager duwt echter de opdrachtgever terug in zijn rol in plaats van zijn gebreken te compenseren. Standvastigheid, visie en betrokkenheid zijn belangrijke eigenschappen van opdrachtgevers volgens de sociologische school. De governance school ten slotte gaat er vanuit dat de opdrachtgever ingekaderd moet worden in regels om ervoor te zorgen dat zijn project ook het organisatiebelang dient. In feite worden bevoegdheden bij de opdrachtgever weggehaald en belegd bij een centrale autoriteit (zoals de CIO). Die centrale autoriteit moet ervoor zorgen dat de opdrachtgever niet alleen het projectbelang dient maar zich ook aan de organisatiebrede kaders en richtlijnen houdt. Voordeel van die richtlijnen is dat niet ieder project opnieuw het wiel hoeft uit te vinden; nadeel is dat een project gebonden is aan regels. In de praktijk leidt dit regelmatig tot weerstand. Het onderzoek heeft ongeveer vijf voorbeelden van projecten opgeleverd die bewust op afstand bleven van de regelpolitie. Niet zelden is deze afstand in de ogen van de geïnterviewden een bepalende succesfactor geweest. Hoe deze lokale successen weer onder het algemene beleid zijn gebracht is echter minder duidelijk. /3 Selecteren en aansturen van de IT-leverancier Veel geïnterviewden geven aan dat het selecteren en aansturen van de IT-leverancier (de interne IT-afdeling of de externe leverancier) lastig is. Hoe selecteer je, binnen de geldende uitbestedingsregels, de beste leverancier (in plaats van de goedkoopste)? Hoe vertel je die leverancier wat hij moet doen, en hoe controleer je dat hij dat ook daadwerkelijk doet? De vijf scholen hanteren hiertoe uiteenlopende tactieken, waarbij formalisatie en vertrouwen recht tegenover elkaar lijken te staan. senior supplier highlight reports inkoop regels volledige specificaties meekijken management school proces analytische school inhoud governance school regels & toezicht partnership samenwerking multi-disciplinair proof of concept sociologische school mens & gedrag agile school flexibiliteit Met name de management en de governance school richten zich op het formaliseren van de relatie met de leverancier. De aanbestedingsregels zélf vormen een typisch voorbeeld van een governance maatregel. De management school geeft de leverancier de rol van senior supplier in de stuurgroep. Middels reguliere voortgangsrapportages en escalatieprocedures (exceptions) wordt bewaakt dat de leverancier zich aan afspraken houdt. In de praktijk blijkt echter dat hiermee niet de volledige waarheid boven water komt, het fenomeen 10

13 mooi weer rapportages wordt veelvuldig genoemd. Het escalatiemechanisme van PRINCE2, met toleranties, wordt in de praktijk nauwelijks toegepast. De analytische school geeft daarom aan dat de leverancier ook op inhoudelijke gronden bewaakt moet worden, bij voorkeur door een derde partij die tussen de opdrachtgever en de opdrachtnemer in is gepositioneerd. Deze derde partij heeft als rol om de kwaliteit en de risico s te bewaken: is de verstrekte opdracht duidelijk, snapt de leverancier wat hij moet doen, heeft de leverancier opgeleverd wat was afgesproken, voldoet de leverancier aan algemene best practices? Het is volgens de analytische school onvoldoende om te vertrouwen op de rapportages van de leverancier, een onafhankelijke meekijkrol is onontbeerlijk. De sociologische school ziet al deze maatregelen als compensatiegedrag voor een slechte samenwerking. De relatie met de leverancier moet op vertrouwen gebaseerd zijn, vergaande formalisatie en controle leidt tot allerlei oneigenlijk gedrag dat afleidt van een goed eindresultaat. De agile school voegt hieraan toe dat samenwerking alleen in multidisciplinaire teams mogelijk is die zich op één locatie bevinden. Middels een proof of concept tijdens de leveranciersselectie moeten leveranciers aantonen wat ze in huis hebben. Afstand tussen klant en de leverancier leidt onvermijdelijk tot misverstanden, samenwerken vereist voortdurende communicatie. /4 Realiteitszin bij politieke ambities Wellicht de grootste uidaging voor de overheid is het beheersen van de politieke krachten die opdrachten doen groeien en vervagen. De vijf scholen hanteren daartoe uiteenlopende tactieken, waarbij objectiveren en opknippen het meest voorkomen. We beschouwen de merites van deze aanpakken. business case tollgates stuurgroep portfoliomanagement werken onder architectuur haalbaarheidstoets volledige specificaties management school proces analytische school inhoud governance school regels & toezicht goede mensen opleiden incrementeel proof of concept sociologische school mens & gedrag agile school flexibiliteit Het objectiveren van de opdracht wordt door drie scholen gepropageerd. Zo schrijft de analytische school de specificaties zo gedetailleerd mogelijk uit om de haalbaarheid van het te bouwen systeem te toetsen. En de management school werkt de kosten en de baten volledig uit in een business case. De agile school gelooft niet in papieren exercities maar werkt de opdracht liefst uit in een tastbaar prototype. Idee achter deze objectiveringsaanpakken is dat je politici met de werkelijkheid achter een globaal idee moet confronteren om realistische besluitvorming af te dwingen. Bovendien zorgt de aanpak voor vertraging; en vertraging wil impulsieve politici nog wel eens terug op aarde brengen. In de praktijk blijkt dit niet altijd te werken. Met name bij beleidsprojecten zijn de baten in de maatschappij moeilijk vast te stellen. Bovendien blijkt dat de uitkomst van een haalbaarheidsstudie vrijwel altijd ja is, leveranciers hebben geen belang bij het aantonen van de onhaalbaarheid. Als rem op politieke ambities hebben business cases en haalbaarheidstoetsen beperkt nut, er is meer nodig om politieke impulsiviteit in te dammen. 11

14 Zowel de governance school als de agile school zetten daartoe in op het verkleinen van de opdracht. Zo geven aanhangers van de governance school aan dat je geen projecten van 20 miljoen euro moet doen maar complete architecturen voor dat bedrag moet ontwikkelen. Elke component binnen zo n architectuur mag bijvoorbeeld maximaal één miljoen euro kosten, zo krijg je meerdere kleine projecten waardoor de slaagkans toeneemt. De agile school omarmt het incrementele werken: kleine successen boeken en die langzaam maar zeker uitbouwen. Incrementeel werken is een belangrijke succesfactor geweest bij meerdere projecten. Diverse overheidsinstanties hebben ondertussen een grens gezet op de toegestane omvang van projecten, zie bijvoorbeeld [McKinsey]. De governance school haalt in aanvulling hierop bevoegdheden weg bij de opdrachtgever. Het opstarten van projecten is niet langer het alleenrecht van opdrachtgevers, er wordt een CIO aangesteld die op portfolioniveau bepaalt welke projecten de meeste waarde hebben voor de organisatie. Hiermee wordt effectief bestreden dat wethouders of beleidsmedewerkers bij projecten hun eigen belangen en ideeën doordrukken. Of de CIO in de praktijk voldoende macht heeft om weerstand te bieden aan ambitieuze politici zal de tijd moeten leren. De sociologische school verlangt leiderschap van opdrachtgevers. Een goede opdrachtgever snapt welke problemen in de samenleving leven en heeft een visie op de benodigde projectresultaten. Daar waar de politiek onrealistische verwachtingen heeft is hij in staat die terug te dringen door een onderbouwd nee te verkondigen. Opdrachtgevers moeten leiders zijn die het spel met de politici effectief kunnen spelen. Vanuit de management school is recent het idee gekomen om op vaste momenten tijdens een megaproject (meer dan 20 miljoen euro) gateway reviews te houden. Hierbij wordt door peers van de opdrachtgever de projectaanpak en voortgang getoetst waarna er een rapportage naar de minister gaat en, via Ter Horst, naar de Tweede Kamer. Deze onafhankelijke blik op projecten kan een opdrachtgever het vertrouwen geven om nee te zeggen. Een aantal geïnterviewden wijst er op dat reviews in het algemeen ook negatieve bijeffecten kunnen hebben, vaak gaat er veel aandacht uit naar relatief onbelangrijke zaken terwijl projectleden het gevoel kunnen krijgen niet vertrouwd te worden. Interessant is de casus van een succesvol beleidsproject bij een ministerie waarin diverse uitvoeringsinstanties en belangenorganisaties participeerden. In dit project is men erin geslaagd succesvol een IT-oplossing te implementeren die tot flinke lastendrukverlaging in het bedrijfsleven heeft geleid. Het succes was gestoeld op een onconventionele aanpak: incrementeel werken, een rigide selectie van vakmensen op alle niveaus, een brede stuurgroep met alle betrokkenen, besliskracht op SG-niveau plus een opdrachtgever die zes jaar lang actief betrokken bleef. Doordat veel management- en governance principes werden genegeerd heeft deze aanpak tot meerdere confrontaties met de staande organisatie geleid. Ook moeten we constateren dat een audit waarschijnlijk tot een negatief oordeel had geleid. Feit is echter dat het project succesvol is afgerond. Geconstateerd moet worden dat er de afgelopen twee jaar wel degelijk progressie is geboekt in het bereiken van meer realisme. Er is slechts één nieuw project van 20 miljoen gestart, daarnaast zijn er diverse projecten uit de lijst van 73 megaprojecten afgerond [Horst D]. Diverse instellingen hebben een bovengrens gesteld aan de omvang van op te starten projecten vanuit het besef dat megaprojecten te veel risico s kennen. Of dit een gevolg is van de maatregelen van de minister (CIO s, gateway reviews, portfoliomanagement) is niet met zekerheid te stellen. Het toegenomen bewustzijn rond IT-projecten heeft er ongetwijfeld ook invloed op gehad. Met de toegenomen realiteitszin is de hoop reëel dat het aantal IT-mislukkingen de komende tijd zal afnemen. 12

15 4/ Conclusies - op weg naar goed opdrachtgeverschap In dit hoofdstuk vatten we samen wat uiteenlopende betrokkenen bij IT-projecten bij de overheid van ons onderzoek kunnen leren. In sectie 4.1 schetsen we eerst het beeld dat we van de huidige stand van opdrachtgeverschap hebben opgemaakt, in sectie 4.2 wordt de gewenste situatie beschreven. In sectie 4.3 wordt beschreven wat er ons inziens moet veranderen om goed opdrachtgeverschap te bereiken. /1 Huidige situatie Opdrachtgeverschap binnen de overheid is nog geen volwassen discipline, constateren we aan de hand van ons onderzoek. Vaak is onduidelijk wie de opdrachtgever is of zijn er meerdere personen aan te wijzen die zich (gedelegeerd) opdrachtgever noemen. De rol van opdrachtgever in IT-projecten wordt vaak vrij afstandelijk en beperkt opgepakt: veel taken worden naar een projectmanager gedelegeerd die zijn weg maar moet zoeken binnen de geconstateerde organisatorische complexiteit. Het besef dat een goede opdrachtgever het verschil kan uitmaken tussen geslaagde en gefaalde projecten lijkt maar langzaam door te dringen. Het onderzoek laat zien dat een opdrachtgever binnen de overheid het extra moeilijk heeft, vergeleken bij het bedrijfsleven. De organisatorische en politieke context waarin hij moet manoeuvreren is complexer, het aantal belanghebbenden waarmee hij moet afstemmen is hoger, het zorgdragen voor het kwantificeren en verzilveren van maatschappelijke baten is moeilijker en de aansturing van een aanbestedingstraject is uitdagender. Het besef dringt langzaam door dat overheidsprojecten soms zo n hoog afbreukrisico kennen dat ze gedoemd zijn te mislukken. De opstartfase is cruciaal, opdrachtgevers hebben de plicht zinvolle, realistische opdrachten te formuleren die op draagvlak bij alle betrokkenen kunnen rekenen. /2 Gewenste situatie De gewenste situatie wordt beschreven aan de hand van de vijf onderscheiden scholen voor goed opdrachtgeverschap. Deze stellen ieder voor zich zware eisen aan de opdrachtgever. Dit onderzoek maakt vóór alles duidelijk dat binnen de overheid het mainstream denken gericht is op projectbeheersing en controle (management- en governance school). Er is weinig oog voor de achterliggende waarden in projecten: de inhoud, de mens en de ontwikkelaanpak. Opdrachtgevers zouden zich bewust moeten zijn van de noodzaak om het anders denken in hun projecten te organiseren, ze moeten zich bewust zijn van de zwaktes van het mainstream denken en wat de andere drie scholen hieraan kunnen toevoegen. De management school verlangt van de opdrachtgever dat hij kennis heeft van de rollen en processen die methodes als PRINCE2 voorschrijven. De governance school verlangt dat hij zich conformeert aan de bestuurlijke kaders. Bij dit type eisen, behorend tot het mainstream denken, voelen de meeste opdrachtgevers zich relatief comfortabel. In de praktijk vergt het voldoen aan deze eisen echter nog veel aandacht. Opdrachtgevers moeten gaan beseffen dat alleen zij verantwoordelijk zijn voor het regelen van de randvoorwaarden, voor het stellen van prioriteiten en voor het signaleren en bewaken van omgevingsrisico s. Opdrachtgeverschap is een taak die voortdurende betrokkenheid vereist. De eisen die de andere drie scholen stellen voelen in de publieke sector een stuk minder comfortabel aan. Zo verlangt de analytische school dat de opdrachtgever kennis heeft van de IT-inhoud (hij moet een IT-rijbewijs hebben) om de juiste besluiten te kunnen nemen. Ook moet de opdrachtgever aandacht hebben voor menselijke aspecten: teamsamenstelling, samenwerking, het onderlinge vertrouwen. Ten slotte moet de opdrachtgever zich bewust zijn van de ontwikkelaanpak die wordt gekozen. Hij moet snappen dat de afweging tussen een watervalaanpak en een incrementele aanpak (agile) aan hem is. Dit soort aspecten wordt vaak blindelings 13

16 overgelaten aan de projectmanager maar zijn zo bepalend voor het projectverloop dat de opdrachtgever er bewuste keuzes in moet maken. Niet alle geïnterviewden zijn het ermee eens dat de opdrachtgever zich ook met de inhoud, de mens en de ontwikkelaanpak moet bemoeien. Opdrachtgevers die overal verstand van denken te hebben vinden sommigen een gevaar op zich; die gaan juist foutieve besluiten nemen. Bovendien bestaat het schaap met de vijf poten (in iedere school een poot) niet. Opdrachtgevers moeten zich omringen met capabele mensen die hen van betrouwbare informatie voorzien op de terreinen waar ze onvoldoende verstand van hebben (de poten waarover ze zelf niet beschikken). Met name bij projecten met verhoogd risico (zie hoofdstuk 2) is het noodzakelijk dat de opdrachtgever zich niet alleen door de opdrachtnemer/projectmanager laat adviseren maar zich omringt met de juiste adviseurs, zodat alle vijf de scholen voldoende zijn vertegenwoordigd. Alleen dan is hij in staat om de grote risico s effectief te beheersen. /3 Wat er moet veranderen Wie moet er iets gaan doen met dit rapport? Opdrachtgevers moeten zich ontwikkelen van onbewust onbekwaam naar bewust onbekwaam. Dit begint bij het besef dat ze een grote verantwoordelijkheid dragen die ze niet zelfstandig kunnen invullen. Ze moeten beseffen dat IT-projecten risicovol zijn en daarom hun volle aandacht verdienen, dat het onvoldoende is om op afstand te managen. Ze moeten uit hun comfort zone stappen. Dit rapport kan hen helpen om meer bewust te worden van een aantal zaken. Ook opleidingen gericht op IT-bewustwording, zoals hier en daar ontstaan, kunnen hieraan bijdragen. Maar zoals dat vaak gaat met onbewust onbekwame personen zal niet iedereen zich aangesproken voelen. Opdrachtgevers vormen dan ook een zeer diverse doelgroep die lastig te bereiken is. Opdrachtnemers en projectmanagers moeten beseffen dat hun opdrachtgever niet altijd begrijpt wat zijn taak is en waarover hij besluiten moet nemen. Het compenseren van de opdrachtgever, door bijvoorbeeld de projectcontext namens hem te gaan regelen, kan contraproductief werken. Opdrachtnemers moeten rolvaster worden en zich weerbaar tonen: nee zeggen tegen onrealistische opdrachten, extra budget eisen bij scope wijzigingen, de voor- en nadelen van een incrementele aanpak uiteenzetten, eisen dat de juiste mensen beschikbaar komen voor het project. Het beter managen van de opdrachtgever is een serieuze taak voor opdrachtnemers waar nog een hoop winst is te boeken. Opdrachtgever en opdrachtnemer moeten uiteindelijk een soepel draaiende tandem vormen, zie [Hindriks]. Tenslotte is een rol weggelegd voor de informatiemanagers, CIO s en beleidsadviseurs die in uiteenlopende rollen betrokken zijn bij IT-projecten. Zij hebben de taak om opdrachtgevers en opdrachtnemers te wijzen op blinde vlekken in hun aanpak. Heb je wel de juiste mensen aan boord voor deze opdracht? Is het niet verstandiger om een onafhankelijke partij voor de kwaliteitsborging te laten zorgen? Kunnen we hen tijdens de opstartfase een opleiding aanbieden om het bewustzijn te verhogen? Zou het niet verstandig zijn om de projectscope te verkleinen? DNV zou uiterst tevreden zijn over de resultaten van dit onderzoek als de diverse betrokkenen in een project regelmatig bij elkaar zouden komen om te reflecteren op de status van een IT-project aan de hand van de vijf scholen. Bewust kiezen uit de oplosrichtingen die de vijf scholen aanreiken zou naar ons idee een grote stap vooruit zijn in opdrachtgeverschap. We verwachten dat deze insteek met vijf scholen effectief kan zijn bij het in kaart brengen en bespreekbaar maken van blinde vlekken en risico s in projecten. De zoektocht naar een balans in beheersmaatregelen moet gezien worden als een belangrijk, terugkerend agendapunt. 14

17 5/ Verdieping - unieke uitdagingen Bestaan er risicofactoren die specifiek zijn voor overheidsprojecten? Kunnen we types projecten aanwijzen met een verhoogd afbreukrisico? Heeft de overheid kenmerken die het onvermijdelijk maken dat ze zulke grote projecten opstart? Kortom: waarom falen overheidsprojecten? Dit hoofdstuk probeert op deze vragen een antwoord te geven. Hierbij hanteren we een risicoperspectief gebaseerd op drie dimensies (omvang, organisatorische complexiteit en technologische ervaring) die veelvuldig gebruikt worden bij het analyseren van projectenportfolio s (zie o.a. [McFarlan]). /1 Omvang Hoe groter een project, hoe groter het risico. Op dit bekende feit heeft professor Verhoef in een serie artikelen in Digitaal Bestuur reeds in 2006/2007 gewezen [Verhoef1]. Zelfs met zoveel tamtam dat zijn artikelen de directe aanleiding vormden voor kamervragen en het onderzoek van de Algemene Rekenkamer. Grote vraag was of de overheid inderdaad 4-6 miljard euro IT-geld verspilde (1 Betuwelijn per jaar), zoals Verhoef had berekend. Drie jaar later is dit bedrag stilzwijgend naar beneden bijgesteld. De boodschap dat omvang en risico direct correleren staat echter recht overeind. Groot, groter, kritiek In de literatuur wordt een omvang van functiepunten als de critical size range gezien [Jones]. Projecten die groter zijn lopen een kans van meer dan 40% om te mislukken. Een dergelijke omvang wordt bereikt bij projecten die zo n 15 miljoen euro kosten. Een inventarisatie van de IT-projecten van 20 miljoen of meer die binnen de overheid lopen beslaat 73 projecten met een gezamenlijke waarde van 2.2 miljard euro. Dit is exclusief de ZBO s waar naar schatting nog 1.1 miljard wordt gespendeerd [Digitaal Bestuur]. De overheid kent dus naar schatting ruim 100 IT-projecten boven de critical size range met een verwacht verlies van 1.32 miljard euro (40% van 3.3 miljard). Verhoef heeft al eens voorgerekend dat IT-projecten in de private sector substantieel kleiner zijn dan in de publieke sector [Verhoef2]. Daar waar de overheid de roemruchte lijst van 73 projecten kent die de 20 miljoen euro overschrijden, komt Verhoef in de private sector niet verder dan 12 projecten boven de 10 miljoen. Omvang blijkt dus een specifieke risicofactor voor de overheid te zijn. Een veelzeggende conclusie van de Algemene Rekenkamer is elk van de partijen heeft belang bij grote en ambitieuze projecten en ze hebben allemaal de natuurlijke neiging te denken aan grote oplossingen voor grote problemen. Zij vormen op dit punt geen tegenwicht voor elkaar. Politieke ambitie is een belangrijke oorzaak voor het verhogen van het omvangsrisico, lijkt de conclusie te zijn. Niemand heeft er belang bij om de projectomvang te verkleinen en daarmee de slaagkans te verhogen. Een vergelijkbare conclusie hebben we in ons onderzoek uit 2006 ook zelf getrokken [Seminar1]: wie heeft er eigenlijk belang bij dat projecten succesvoller verlopen? Alleen de belastingbetaler. Niet alle geïnterviewden herkennen zich overigens in het geschetste mensbeeld. Zij zien binnen hun organisatie wel degelijk professionals die werken aan het terugdringen van de ambitie. Wellicht is de tijd rijp om het risico van te hoge ambities binnen de overheid aan te pakken? /2 Organisatorische complexiteit In de oorspronkelijke indeling van McFarlan wordt organisatorische complexiteit aangeduid met project structuur. Hiermee bedoelt hij de kwaliteit en stabiliteit van de gestelde eisen aan het te ontwikkelen systeem. We zullen in deze sectie zien dat de kwaliteit van het eisenpakket direct afhankelijk is van de organisatorische complexiteit. We behandelen in deze sectie vier complexiteitsverhogende factoren: het aantal, de afstand, de ambitie en de diversiteit van belanghebbenden. 15

18 Overheidsinstellingen kennen vaak een complexe organisatiestructuur met veel afdelingen, sectoren of diensten die allen een belang denken te hebben bij een project. Al deze afdelingen brengen hun wensen en eisen in waardoor het oorspronkelijke doel van het project al snel verwatert. Bovendien wordt de bevelstructuur van het project vaak complex gemaakt (zie kader hiervoor) waardoor de besluitvorming moeizaam verloopt. In overheidsprojecten heeft men vaak moeite om te kiezen, de poldercultuur is ook hier herkenbaar. Dit heeft een negatief effect op de kwaliteit van het eisenpakket. Kerstbomen en Poolse landdagen Het benoemen van één van de afdelingsmanagers tot opdrachtgever is niet altijd acceptabel binnen overheidsorganisaties. Andere afdelingen laten zich niet zomaar vertegenwoordigen. Als alternatief wordt vaak een hiërarchie (kerstboom) aan gedelegeerde opdrachtgevers opgetuigd waardoor iedereen kán meesturen, maar dientengevolge niemand daadwerkelijk stuurt. Ook worden stuurgroepen van soms wel 20 personen ingericht. Op dit soort Poolse landdagen weet je zeker dat áls er al een besluit wordt genomen het met zekerheid een compromis betreft. De laatste jaren worden er steeds vaker bovendepartementale projecten uitgevoerd: projecten waarin meerdere departementen samenwerken om gezamenlijk een IT-systeem te ontwikkelen. Vaak stelt ieder van deze departementen een eigen opdrachtgever aan, waardoor de opdrachtnemer (een shared service centrum zoals ICTU) vanaf meerdere kanten wordt aangestuurd. Doordat alle departementen toch hun eigen wensen inbrengen zal de complexiteit van het eisenpakket toenemen. De strafrechtketen De strafrechtketen was prominent in ons onderzoek vertegenwoordigd. In deze keten participeren gemeentes, politie, rechtbanken het openbaar ministerie, het gevangeniswezen en de reclassering. Twee ministeries (Justitie en BZK) stellen het beleid vast. De laatste jaren is beleid gericht op het terugdringen van recidive (draaideurcriminelen). Ketenprojecten lopen tegen diverse problemen aan: partijen die hun eigen belang voorop stellen, beveiligingsregels die de uitwisseling van gegevens bemoeilijken, afwijkende begrippenkaders. Intensieve samenwerking is een cruciale factor in ketenprojecten. Ook zogenaamde ketenprojecten kennen meerdere opdrachtgevers en dus complexere eisenpakketten. Bij ketenprojecten kan het helpen om tijdelijk een ketenregisseur aan te stellen die bevoegdheden van de ketenparticipanten overneemt. Eén van de geïnterviewden denkt dat projectmatig werken in ketenprojecten niet de juiste werkvorm is. Hij noemt het stellen van eisen op de dwarsverbanden als alternatief. Ook procesmanagement wordt als werkvorm voor ketens voorgesteld. De organisatorische complexiteit wordt niet alleen bepaald door het aantal betrokkenen maar ook door de afstand tussen betrokkenen. Het ultieme voorbeeld hiervan speelt in zogenaamde beleidsprojecten: projecten die iets in de samenleving proberen te bereiken. Bij veel beleidsprojecten blijkt dat de beleidsmakers in Den Haag onvoldoende feeling hebben met de uitvoering in de ZBO s. Een groot aantal ZBO-vertegenwoordigers heeft in het onderzoek aangegeven dat dit voor zijn organisatie een belangrijke risicofactor is. In Den Haag zijn ze alleen gericht op innovatie en op het scoren van politieke agendapunten. Bovendien wordt wetgeving veelvuldig één op één omgezet naar een IT-project, zonder dat iemand zich afvraagt of het probleem wel is op te lossen met techniek. Bijkomend probleem met beleidsprojecten is dat het resultaat (een bijdrage leveren aan de samenleving) moeilijk is vast te stellen, het opstellen van een business case is ondoenlijk. Dit maakt dat beleidsprojecten vaak gaan schuiven gedurende de rit. In het kader van de Westerschelde-uitdieping kopte de Volkskrant recent dat het verlangen naar draagvlak de natuurlijke vijand van ambitie is. Dit kun je bij IT-projecten ook omdraaien, blijkt uit ons onderzoek: politieke ambitie gaat vaak voorbij aan het creëren van draagvlak. Niet zelden zijn de ambities zodanig hoog gespannen dat een project reeds wordt begonnen om een politieke deadline te halen, terwijl niet nagegaan is of er voldoende draagvlak is. Diverse personen zien hierin de belangrijkste faalfactor voor overheidsprojecten: door het ongeduld bij de beleidsmakers en door het gemak waarmee beleid wordt geamendeerd hebben overheidsprojecten te maken met uiterst instabiele opdrachten. In de literatuur wordt dit scope creep genoemd; het vormt een faalfactor die in de top 5 van de meeste risicolijsten staat (zie o.a. [Glass, Jones]). Een vierde factor (na aantal, afstand en ambitie) is de diversiteit van belanghebbenden. Veel overheidsorganisaties kennen relatief autonome koninkrijkjes die hun identiteit en macht niet zomaar willen afstaan bij het eerste het beste IT-project. Met name hoog opgeleide professionals hebben de neiging om voor zichzelf een uitzonderingspositie te claimen die het algemene projectbelang niet dient. In projecten Bewust afstand creëren Vijf personen geven aan dat er zeer bewust voor gekozen is om een project op afstand van de lijn uit te voeren (geen slapende honden wakker maken, weg van de regelpolitie). In één voorbeeld liep dit fout af, door onvoldoende gebruikersparticipatie faalde men in het realiseren van een werkbare oplossing. In vier voorbeelden bleek het juist een belangrijke succesfactor te zijn: door de relatieve rust kon een initiatief rustig opbloeien. Afstand is dus niet per definitie fout, het kan ook een positief effect hebben. 16