In veel overheidsorganisaties worden externen, veelal afkomstig van grote advieshuizen en system integrators, tijdelijk ingezet om projecten te leiden en te bemensen. Als een van de redenen wordt aangegeven dat alles beleggen bij een partij het implementatieproces optimaliseert omdat de projectleider de medewerkers goed kent en daardoor de juiste mensen op de juiste plaats kan zetten. In de praktijk blijkt een dergelijke aanpak zeker geen garantie voor succes: projecten lopen uit, budgetten worden overschreden en doelstellingen worden niet gerealiseerd.
De centrale vraag is dan ook: Waarom mislukken zoveel projecten binnen de overheid.? Hoewel hieraan meerdere oorzaken ten grondslag liggen blijft er een belangrijke factor veelal onderbelicht: Er is bij de opdrachtgever onvoldoende aandacht voor (centrale) regie zowel voor, tijdens als na een traject. Wanneer regie ontbreekt is het vaak in de voorfase al niet duidelijk wie de projectopdracht toetst. Hierdoor ontstaat een onduidelijke projectopdracht die veel ruimte overlaat voor interpretatie door externe partijen. Externe partijen dekken zich in doordat zij de onderkant van de aanwezige interpretatie ruimte opzoeken. Dit leidt van meet af aan tot een kloof in de wederzijdse verwachtingen waardoor bij de start van het project direct al wijzigingsverzoeken aangevraagd worden die leiden tot meerwerk.
Tijdens de uitvoering van het project is vaak het objectief toetsen van opgeleverde tussen- en eindprodukten onvoldoende geborgd. Dit leidt ertoe dat soms onder interne druk een ‘deliverable’ of project de status ‘opgeleverd / afgerond’ krijgt terwijl het resultaat zich niet in de buurt van de finish bevind. Bij de uitvoering van een project dient ook al aandacht te worden besteed aan de exploitatiekosten na ingebruikname. In veel projecten is dit vaak een onderbelicht aspect waardoor je voor onaangename verrassingen kunt komen te staan.
Een oplossing voor vermelde problemen is de opzet van een “regiebureau”. Een regiebureau heeft als doel het op beheersmatige wijze uitbesteden van ontwikkel- en/of implementatietrajecten in samenwerking met andere relevante organisatieonderdelen.
Voordat er uitbesteed wordt zal het regiebureau eerst de onderliggende businesscase beoordelen. In de business case moeten de te realiseren doelen en resultaten, risico’s en bijbehorende baten en lasten analyse, eventuele alternatieven en argumentatie voor een bepaalde keuze helder en eenduidig zijn beschreven. In de business case moet een paragraaf opgenomen zijn over de onderhoud en beheerfase, de zogenaamde post-project fase. Het regiebureau kan de organisatie ondersteunen bij het opzetten van een kwalitatief goede business case en het vinden van alternatieven op basis waarvan een weloverwogen keuze gemaakt kan worden. Naast de business case zal het regiebureau de projectopdracht en de interne projectplanning doornemen met de fases, risico’s, de wijze van afdekken van risico’s en de deliverables om het eindplaatje voor elke betrokkene zo helder mogelijk te krijgen. Wanneer de projectopdracht, het projectplan en de onderliggende businesscase voldoende helder is moet formeel de vraag gesteld worden: Gaan we het project zelf trekken of besteden we (delen) uit? Wanneer het uitbesteed gaat worden zal het regiebureau in combinatie met inkoopmanagement de selectie van leveranciers, het eventuele aanbestedingstraject en de contractvorming begeleiden.
Positie regiebureau
Het regiebureau toetst en schouwt en treedt niet in de plaats van de opdrachtgever, inkoopmanagement of projectleider op. Het regiebureau rapporteert aan de stuurgroep en de projectgroep en staat tussen organisatie en leveranciers. Bewaking van de kwaliteit van inhuur van externen geschied door een intakegesprek. Het regiebureau stelt samen met de projectleider de eisen vast waaraan ingehuurde externen per functie moeten voldoen. Hiermee kun je voorkomen, dat externe leveranciers proberen om (veel) junior consultants naar binnen te ‘schuiven’ (tenzij dat afgesproken is). Veel overheidsorganisaties zijn ‘te lief’ richting externe organisaties. De klant – leverancier relatie is een zakelijke, en zo moet je je contractpartner ook benaderen. Dit geldt overigens ook voor intern opdrachtgever- en nemerschap.
Bewaking van de kwaliteit van de eindprodukten kan gebeuren door het uitvoeren van (acceptatie)tests. Het regiebureau voert de tests zelf niet uit, want tests zijn een onderdeel van het project. Het regiebureau kan de partijen ondersteunen en faciliteren bij het opstellen van acceptatiecriteria en ontvangt na het testen de rapportgages van de test en kan toetsen of de uitkomsten in overeenstemming zijn met de op te leveren deliverables en de afgesproken kwaliteit.
De inzet van een regiebureau slaagt alleen wanneer het voldoende mandaat heeft en qua bezetting bestaat uit mensen die kennis hebben van de organisatie, kennis hebben van het domein waarvoor een project wordt opgezet en kennis hebben van projectmanagement inclusief de juiste ICT expertise. Het regiebureau kan zich voeden met informatie door regelmatig met verschillende mensen uit de organisatie en het projectteam formeel en informeel te overleggen en regelmatig de voortgang af te stemmen met de projectleider om te checken of het project nog op koers ligt en in hoeverre de deliverables voldoen aan afgesproken kwalitatieve criteria. Op basis van deze informatie kan het regiebureau de stuurgroep (onafhankelijk) informeren en adviseren over haar bevindingen. Op deze wijze kan tijdig worden ingegrepen waar nodig waardoor het risico op uitloop en/of overschrijding wordt gereduceerd.
Kees Groeneveld MBA QC RI & Henk van der Rijt
Partners bij XPerts-4U en werkzaam voor overheidsorganisaties bij het opzetten van regiebureau’s.
Waar vind ik toepasbare kennis en gedeelde ervaringen?
Probeer het Pro-abonnement een maand gratis
En krijg toegang tot de kennisbank. 110 onderwerpen, kritisch, wars van hypes, interactief en geselecteerd op wat wél werkt.
Word een PRO
ICT-Projecten leiden volgens mij tot een beter resultaat wanneer het ICT-project vanaf het begin afstemming en verbinding durft aan te gaan met de (latere) beheerders van de ICT-oplossing en de (latere) gebruikers van de ICT-oplossing. Hierbij dient het ICT-project zich niet te beperken tot alleen het leveren van de technische oplossing, maar het ontfermt zich ook over de veranderingen (processen, structuur) die het ICT-project teweeg brengt in de organisatie en het leerproces dat lijnmanagement en medewerkers doorlopen bij het zich eigen maken van de technische oplossing en organisatorische verandering.
Het probleem gaat naar mijn mening over het niet goed uitvoeren van de rollen die in een dergelijke omgeving spelen. Alle rollen zijn er al: alleen ze worden niet goed uitgevoerd.
Opdrachtgevers hebben vaak het probleem dat ze een overvolle agenda hebben. Een project is maar een klein onderdeel van hun problemen. Tijd voor het project hebben ze vaak niet en al helemaal niet voor het laten landen van de verandering die het gevolg is van het project in de organisatie.
De projectleider zit er vaak te methodisch in, heeft te weinig aandacht voor het doel achter het project en kijkt niet naar de gevolgen van een project. Dat ieder project van invloed is op processen, structuur, rollen en mensen en technologie is iets dat vaak over het hoofd wordt gezien. Daarnaast zijn veel projectmanagers niet voorzien van een zakelijkheid en duidelijkheid die nodig is om professionele marktpartijen strak te managen. Vaak is men zacht nar buiten en hard naar binnen, terwijl dat hard naar buiten en zacht naar binnen zou moeten zijn.
Daarnaast praten opdrachtgever en projectleider vaak niet over de inhoud van rollen. Aannames regeren, een goed gesprek over wie wat doet, kan en wil blijft vaak achterwegen. Hierdoor laat de projectleider eenmogelijkheid tot het leveren van toegevoegd waarde liggen. Want ja: ik vind dat het de projectleider moet zijn die dit onderwerp bespreekbaar maakt en erop acteert.
De oplossing: en regiebureau gat in mijn ogen te ver. We organiseren weer iets om het probleem heen zonder het probleem op te lossen: ervoor zorgen dat bestaande functionarissen hun rol effectief uitvoeren. Dan komt het allemaal goed.............
Rob Buijtendijk
InnerVisie BV
Er lijkt een link gelegd te worden tussen overschrijdingen en de inzet van externen. Zou het niet simpelweg zo zijn dat de inzet van externen nodig is bij grotere projecten waarbij de overschrijdingen meer expliciet worden omdat het grote projecten zijn? Hiermee pleit ik overigens niet voor kleinere projecten zoals er nu veel bij de overheid wordt geroepen. Een groot project opknippen in veel kleintjes kan en zal vaak het effect hebben van een clusterbom: veel kleine ongeleide projectielen die individueel niet veel schade aanrichten maar samen een groot drama bewerkstelligen. Ik pleit voor goed ontworpen projecten met duidelijke doelen.
Misschien toch ook wat technische en theoretische onderbouwing. Men gebruikt bij de overheid toch overal PRINCE2? Daarmee is toch al alles geregeld wat Henk en Kees beschrijven? Daar is toch geen nieuw, ander orgaan voor nodig?
Met PRINCE2 als richtlijn zou het toch duidelijk moeten zijn dat ICT geen doel maar middel is en dat het doel duidelijk zou moeten zijn voordat een project gestart wordt? Dat heet een Business Case. De realiteit is dat men blijft volharden in ICT projecten; het middel staat voorop en over het doel wordt onvoldoende nagedacht. Daardoor haakt de toekomstige gebruiker af (het is toch een puur technisch project?) en daarmee vervalt het project tot “trial and error”: de gebruiker laat zich pas horen als er al iets ligt en zal vervolgens afkeuren. We moeten dus af van technische projecten (ICT projecten) en naar projecten met een duidelijke zakelijke rechtvaardiging. Rob gaat hier terecht op in.
De zakelijke rechtvaardiging van opdrachtgever en (ook interne) opdrachtnemer staan haaks op elkaar: hoe meer de opdrachtgever besteedt, hoe meer het voor de opdrachtnemer oplevert. Daarom stelt PRINCE2 ook terecht dat de projectmanager van de opdrachtgever moet komen, niet van de opdrachtnemer. Zeker niet wanneer dit een technisch teammanager en geen projectmanager is.
Nu zie ik al de reacties voor me: PRINCE2 is toch een heel bureaucratisch model wat alleen gericht is op de structuur van het project zoals Rob dat terecht veroordeelt? Nee, dat is PINO: PRINCE In Name Only. Dit is vooral in Nederland dominant. Want geïntroduceerd door een typische ICT leverancier (daarmee niet geïnteresseerd in de Business Case en organisatie/opdrachtgever kant, duidelijke rollen zoals Rob dat noemt) met een ITIL achtergrond (en daarmee gefocust op stabiliteit en niet op verandering). Deze partij begrijpt PRINCE2 niet en zal als trainingspartij een onvolledig ITIL-achtig verhaal ophangen met nadruk op papierwerk en templates. Komt bekend voor? Wat ik hierboven en hieronder stel, zal in de PINO variant niet of nauwelijks terugkomen.
De borging zoals Kees en Henk beschrijven, wordt door PRINCE2 Assurance genoemd. Is daarmee, zoals Dirk-Jan terecht stelt, onderdeel van het opdrachtgeverschap. Maar ook de borging van het opdrachtgeverschap wordt door PRINCE2 benoemd (maar niet behandelt). Dit heet in PRINCE2 Quality Assurance. Dit is bij de overheid ook al (min of meer) belegd. Er is dus echt geen aparte club nodig zoals Henk en Kees voorstellen. Bij Binnenlandse Zaken is een afdeling ingesteld die zich bezighoudt met Gateway Reviews. Allen klinkt dit in theorie een stuk beter dan het in de praktijk waarschijnlijk zal zijn. De baas van deze club is namelijk afkomstig uit de zelfde hoek die PRINCE2 erg fout in de Nederlandse markt heeft gezet. Deze CIO (een interne leverancier dus) met een ICT focus heeft bij zijn aantreden al gesteld dat wat hem betreft de Gateway Reviews even populair moet worden als ITIL. Een teken aan de wand. Een slecht teken.
Inderdaad, Rob. Menselijke problemen. En die los je inderdaad niet op met meer structuren en procedures.
Hoe goed je oplossing ook bedoeld is, maar ik moet helaas meegaan in het relaas van mijn voorgangers.
Ik kan mij prima voorstellen dat een projectmanager ondersteuning verkrijgt van een soort Project Support Office, maar ik kan niet meegaan in jouw visie op het feit dat daarmee een oplossing is gevonden voor de door jou geschetste problemen en om zodoende projecten succesvol te verkrijgen.
Er is inmiddels al voldoende feedback gegeven, maar twee punten zou ik daar nog aan toe willen voegen.
Allereerst ben ik het eens met Nico's toegift aangaande PRINCE2. Een projectmethodiek die zeer goed tot zijn recht zou komen om de door jouw opgesomde problemen te tackelen. Let wel, projectmanagement is grotendeels mensenwerk. Veel is dus afhankelijk van de competenties die een projectmanager dient te hebben om een project goed uit te kunnen voeren.
Daarnaast is het inzetten van externen vaak zo gek nog niet. Naast het feit dat zij de nodige deskundigheid, ervaring en vaardigheden hebben om verandertrajecten te managen, hebben zij tevens een objectieve kijk op het probleem dat zich voordoet en zijn zodoende beter in staat de omgevingsvariabelen te managen. Ik wil daar wel een kanttekening bij plaatsen. Men is namelijk snel geneigd om op IT projecten een ICT man / vrouw in te zetten. Daarbij loop je al snel het risico dat de business uit het oog verloren wordt. Integratie van de business met IT is namelijk van groot belang om de business betrokken te krijgen en draagkracht te verkrijgen voor je veranderingsproces.
Gerard van Kilsdonk MBA QC
Van Kilsdonk Business Solutions
PS: Ik kan de titel van jouw artikel overigens niet plaatsen ten opzichte van de inhoud.
Fred
Kees Groeneveld & Henk van der Rijt
Xperts-4u BV (www.xperts-4u.nl)
Erik van Stokkom
IT-communicatieadviseur (www.itcommunicatie.nl)