Sturing op IT in GWW-projecten

Eindopdracht Rijksprojectacademie Kernprogramma Bouw II

Sturing op IT in GWW-projecten “Het verschil tussen IT en CT is meer dan één letter”

Willem de Graaf december 2011

INLEIDING Deze eindopdracht is gemaakt als onderdeel van de afronding van het kernprogramma 2 van de Rijksacademie voor Projectmanagement. Het is een zoektocht1 geworden binnen Rijkswaterstaat naar de problematiek rondom realisatie van IT binnen GWW-projecten. Met IT wordt hier de zgn. industriële automatisering bedoeld, oftewel de beheersing van fysieke infrastructuur en complexe processen zoals het bedienen van tunnels, bruggen en sluizen en het besturen van de verkeersstromen. Het is kort gezegd de automatisering van de fysieke productieprocessen2. Vanuit het verwonderingsperspectief “het is toch te gek dat….”, valt het mij op dat het RWS zoveel moeite kost om projecten met een sterke IT-component zoals tunnels (nadruk op veiligheidsinstallaties), wegen (DVM - Dynamisch VerkeersManagement – het begeleiden van verkeer vanuit een verkeerscentrale), bruggen & sluizen (besturing op afstand vanuit verkeerscentrales), op tijd en binnen budget te realiseren, terwijl de organisatie toch al enkele tientallen jaren bezig is met industriële automatisering. Bovendien is de verwachting dat de afhankelijkheid van die automatisering in de nabije toekomst alleen maar groter zal worden. Observaties in de praktijk De praktijk van de projectmanager in de realisatiefase van het project is weerbarstig. De RWS-inkoopfilosofie bij projecten stelt dat de scope van het project in de uitvoeringsfase wordt geacht te zijn gebaseerd op de stand van de techniek van het moment van opdracht. Deze stand van de techniek is beschreven in de beschikbare kaders, richtlijnen en specificaties binnen de eigen organisatie. Iedere tussentijdse wijziging in deze specificaties vanaf dat moment is dan feitelijk een scopewijziging die ter acceptatie aan de opdrachtgever moet worden voorgelegd. In theorie een beheersbare situatie, zo lijkt het. In de praktijk van de projectmanager echter, blijkt deze aanpak door een aantal redenen zwaar beproefd te worden: •

De lifecycle van IT-componenten is met soms enkele jaren kort te noemen, zeker in vergelijking met civiele componenten in de GWW-sector waarmee RWS jaren lang ervaring heeft. In korte tijd worden nieuwe (betere) versies van IT-componenten geïntroduceerd, en zijn bestaande componenten steeds moeilijker te krijgen, of zijn deze componenten geheel overbodig geworden. Het effect daarvan is dat specificaties tijdens voorbereiding en realisatiefase van een project nog wijzigen. Binnen RWS is het voor de projectmanager niet altijd duidelijk wanneer kaders/specificaties/richtlijnen zijn geactualiseerd, en of deze dan alsnog van toepassing zijn voor zijn lopende project. Het “releasemanagement” is onduidelijk.

•

Waar 20-30 jaar geleden IT-componenten nog vaak losstaand werden toegepast, ligt de nadruk nu op werking in een lange keten. Een voorbeeld hiervan zijn spitsstroken, die pas open kunnen gaan als alle schouwcamera’s werken (camera, verbinding naar tussenstation, datatransmissie via glasvezelnet naar bedienapplicatie in verkeerscentrale, link bediening signalering boven de weg, etc.). Alle kaders en spec’s moeten dus niet alleen betrekking hebben op de individuele componenten, maar moeten zich ook richten op alle mogelijke ketens waarin deze componenten worden toegepast.

1

een overzicht van de gesprekken die tijdens deze zoektocht zijn gevoerd, zowel binnen RWS als daarbuiten, staan vermeld in bijlage 3. 2

definitie van Industriële Automatisering volgens het Bestuur RWS, vastgesteld op 18 maart 2011: “Informatievoorziening die functioneel verbonden is met infra”.

Eindopdracht RPA – Kernprogramma Bouw II – Willem de Graaf

pagina 1

Binnen RWS ondergaan nieuwe componenten in een eigen testcentrum wel een individuele goedkeuringstest, maar kunnen soms niet in de keten worden getest (faciliteiten daartoe ontbreken vooralsnog). De projectmanager moet in dat geval vernieuwde componenten binnen zijn project in een life-situatie op de weg/waterweg gaan uittesten……… •

Voor sommige gevraagde functionaliteiten ontbreken de kaders of specificaties, en die moeten dus alsnog ontwikkeld worden. In de praktijk wordt dit probleem soms binnen het project opgelost, omdat de urgentie/capaciteit/kennis in de lijn ontbreekt dan wel te traag inzetbaar is. De tijd en menskracht die voor ontwikkelen én testen nodig zijn worden vaak onderschat, met als gevolg extra druk op de te behalen mijlpalen.

•

Het aantal afdelingen/diensten binnen RWS dat betrokken is bij kaders/richtlijnen/specificaties van IT-systemen is groot, met als gevolg dat de verantwoordelijkheid gefragmenteerd is. Voor de projectmanager is het tijdrovend om beslissingen te organiseren.

•

De aansturing van de aannemers tijdens de realisatiefase van het project vraagt als gevolg van de hierboven beschreven situatie op zijn beurt weer veel aandacht van de projectmanager.

Verdere afbakening van het probleem De consequenties voor de organisatie zijn duidelijk: steeds grotere risico’s t.a.v. kosten- en tijdsoverschrijdingen van aanlegprojecten. Binnen deze opdracht wordt m.n. gekeken naar GWW-projecten met een belangrijke IT-component in de te realiseren scope. In een qua aandacht voor IT gefragmenteerde organisatie als RWS is de projectmanager in de praktijk de probleemeigenaar zodra die zijn handtekening onder de realisatieopdracht van een project zet. Binnen de grenzen van zijn project is hij daarmee verantwoordelijk om gegeven dit probleem de eindstreep te halen. Alleen wijzen naar “de organisatie” en de problemen als exogene risico’s benoemen brengt verbetering in de praktijk niet dichterbij. Vragen die dit alles oproept zijn: Wat kan je als projectmanager doen in mijn project om dit terugkerend patroon van immer groeiende risico’s te doorbreken? Waar in mijn projectaanpak, en hoe, kan je aandacht geven niet zozeer aan de symptomatische bestrijding van het hierboven beschreven “gedoe”, maar juist aan de onderliggende oorzaken die dit probleem zo structureel maakt? Gegeven de qua IT gefragmenteerde organisatie en dientengevolge onduidelijke belegging van verantwoordelijkheid binnen RWS, op welke wijze kan ik de lijnorganisatie hierbij betrekken?


pagina 2

ANALYSE:

CASE “REALISATIE VAN DVM-SYSTEMEN”

Om het probleem verder te kunnen duiden wordt een case beschreven waarin de realisatie van IT in de praktijk wordt toegelicht. Inleiding Een van de maatregelen binnen mijn project Mobiliteitsaanpak betreft het aanbrengen van een extra waarschuwing aan chauffeurs van te hoge vrachtwagens bij tunnels. Situatie nu is dat de tunnel wordt afgesloten zodra een te hoge vrachtwagen de tunnel nadert, en dan met de nodige moeite via dienstwegen moet worden omgeleid. Bovendien is de tunnel dan tijdelijk gestremd. Met een hoogtemeting nog voor de laatste afslag voor de tunnel kan de chauffeur tijdig worden geïnformeerd en via de afrit van de snelweg af geleid worden. Er zijn bij RWS in het verleden al verschillende onderzoeken en pilots uitgevoerd naar zo’n maatregel. Allemaal verschillend van uitvoering. Vraag is dus: volgens welke specificaties (ie.algemene waarschuwing, of specifieker nummerbordherkenning, of foto van vrachtwachten projecteren op scherm langs weg, etc. moet deze maatregel worden uitgevoerd. Onder leiding van de Dienst Verkeer en Scheepvaart van RWS is op verzoek van de projectorganisatie een functionele specificatie opgesteld, waarin omschreven wordt aan welke verkeerskundige eisen het systeem moet voldoen.

Probleem Opstellen van specificatie duur lang (1,5 jaar) doordat veel partijen binnen RWS met hun eigen invalshoek (aanleg, verkeersmanagement, beheer, ICT) betrokken moeten worden bij opstellen van specificatie. Uitkomst is nog steeds onderwerp van discussie, er komen nog steeds aanvullende eisen (bv. nummerbordherkenning zou eerst wel mogen, nu weer niet vanwege mogelijk privacygevoeligheid). Projectorganisatie heeft te maken met vertraging als gevolg van onduidelijkheid van de specificaties. Daarnaast loopt ze het risico dat tijdens realisatiefase nadere specificatie(wijzigingen) worden opgelegd, die de uitvoering verder vertragen en de uitvoeringskosten verhogen. Situatie met deze DVM-maatregel is representatief voor de praktijk binnen RWS. Hoe als project mee om te gaan? Urgentie van dit probleem Uit de evaluatierapportage van proef met een aangepast voorwaarschuwingssysteem bij de Velsertunnel blijkt dat meer dan honderd maal per maand een te hoog voertuig wordt gedetecteerd bij de ingang van de tunnel, en waarbij het verkeer wordt stilgezet met behulp van verkeerslichten. Verwachting is dat met de maatregel per jaar circa 2 ton aan voertuigverliesuren kan worden bespaard, naast enkele gemiste niet-monetaire baten, zoals de afname van de kans op vertraging voor ambulanceverkeer en de vermindering van ergernis voor weggebruikers (past in doelstelling RWS als publieksvriendelijke overheidsorganisatie). Daarnaast is de verwachting dat in geval de specificaties niet worden gevolgd, en ieder project zijn eigen systeem ontwikkeld, de beheerskosten zullen stijgen met circa 10.000 euro/jaar. Is de urgentie van het probleem daarmee voelbaar? Nee, want de kosten worden ofwel moeilijk gevoeld (voertuigverliesuren en bijbehorende niet-monetaire baten) dan wel moeilijk herkend (kosten tijdens beheersfase). Gevolg is dat er weinig prioriteit wordt gegeven aan goede specificaties, problemen met deze specificaties moet in ieder project opnieuw opgelost, en na langere tijd bestaat de kans dat de IT-boedel is verworden tot een lappendeken van verschillende technieken, wat in de toekomst alleen nog met de grootst mogelijke moeite kan worden onderhouden of uitgebreid. Rich Picture Deze case maakt duidelijk dat de omgeving binnen RWS die zich bezighoudt met IT-systemen gefragmenteerd is, met vele partijen die ieder vanuit hun eigen invalshoek een verantwoordelijkheid hebben bij de vaststelling van specificaties. Dit is nader geïllustreerd in een zogenaamd “Rich Picture” (zie bijlage 1).


pagina 3

Toch zijn er ook situaties denkbaar waarin de urgentie van het probleem wel beter voelbaar is. Een voorbeeld daarvan is de aanleg van spitsstroken in het programma Spoedaanpak. In dit programma werd duidelijk dat de DVM-systemen (camera’s om de vluchtstrook te kunnen schouwen, matrixborden boven de weg om de strook te openen of sluiten voor verkeer) als toprisico moest worden gezien. Vanuit de lijnorganisatie werden specialisten vrijgemaakt voor een speciaal Programmateam om te adviseren naar de verschillende aanlegprojecten binnen het Spoedaanpakprogramma over o.a. de technische realisatie van DVM-systemen. In een speciale scan van het toprisico3 werden o.a. de volgende aanbevelingen gedaan: - het verbeteren van de escalatielijnen zodat de aandacht niet vroegtijdig verzand in geval van geconstateerde problemen - gebruik van tijdelijke “hulpteams” naast het programmateam om technische problemen in de praktijk op te lossen zodat aansluiting in de verkeerscentrales tijdig konden worden gerealiseerd. - rolvastheid van alle stakeholders (“iedereen praat mee”, onduidelijke mandaten) De Spoedaanpak is inmiddels een succes geworden, en een groot aantal projecten zijn binnen de gestelde tijd gerealiseerd. Echter, op gebied van DVM zijn de problemen nog niet allemaal opgelost en wordt soms noodgedwongen gebruik gemaakt van dagelijkse schouwing ter plaatse door weginspecteurs in plaats van het gebruik van schouwcamera’s vanuit de Verkeerscentrale, zoals de bedoeling is. Ook bij de aanleg van tunnels is er aandacht voor de realisatie van de installaties. De urgentie is voelbaar door de politieke gevoeligheid van te late opleveringen. Bij de A73 werd zichtbaar dat de nadruk op het project lag bij de civieltechnische onderdelen, en dat de installaties en het besturingssysteem als sluitstuk in de planning werd opgenomen. Doordat de specificaties voor vele interpretaties vatbaar was, en alle betrokkenen daarover ook een uitgesproken mening hadden (zie ook DVM-case), is veel tijd verloren gegaan met het stabiel maken van de projectscope. Toen vervolgens de werkelijke complexiteit van de besturing en installaties zichtbaar werd en ook het uitgebreide testprogramma dat daarbij hoorde, waren vertragingen niet meer te voorkomen. De aanleg van de tunnel werd hoofdzakelijk als GWW-project aangestuurd omdat er historisch gezien nu eenmaal een ruime ervaring is opgebouwd met projecten met civieltechnisch karakter, en anderzijds dat financieel gezien het budget voor IT en installaties in verhouding tot het civieltechnisch deel met 10-20% vrij klein is (10-20%). Illustratief daarbij is overigens dat over de gehele levenscyclus van de tunnel gezien de kosten van de installaties wegens meerdere totale vervangingen gedurende die periode waarschijnlijk die van het civiele deel zullen overschrijden. Nieuwe tunnelspecificaties van de Landelijke Tunnelregisseur heeft dit jaar de ruimte voor verschillende interpretaties teruggebracht en daarmee is de scope van de te bouwen tunnels eenduidiger komen vast te liggen. Of daarmee de IT-systemen binnen de projecten beheerst worden gerealiseerd, moet in de praktijk nog blijken. Op structureel niveau pleit het eerder genoemde scanrapport “[...] voor meer regie op verkeersmanagement. Hiervoor is een RWS-brede en gedragen visie op verkeersmanagement nodig, doorvertaald naar ontwikkelkaders op tactisch niveau en uitgewerkt op operationeel niveau”. De structurele aanpak voor meer regie op verkeersmanagement krijgt momenteel aandacht in het kader van Operationeel Plan 2015, waarin sprake is van een nieuwe aparte dienst voor Operationeel Verkeersmanagement binnen RWS.

3

Eindrapportage Scanteam DVM, RWS, oktober 2010


pagina 4

VERKENNEN VAN OPLOSSINGSRICHTINGEN Is met de oplossingen zoals in het voorbeeld van de tunnels en de spitsstroken uit de Spoedaanpak er daadwerkelijk meer grip op een beheerste realisatie van IT-systemen in de GWW projecten? Is bijvoorbeeld met een “RWS-brede en gedragen visie op verkeersmanagement, doorvertaald naar ontwikkelkaders op tactisch niveau en uitgewerkt op operationeel niveau” de oplossing binnen handbereik? Voor het beantwoorden van die vraag is het belangrijk te realiseren waarom de aansturing van IT-projecten op een aantal punten fundamenteel afwijkt van GWW-projecten. Hieronder zijn de belangrijkste verschillen nader toegelicht. Verschillen in projectaanpak tussen IT en GWW • Verschil in begrenzing van project: IT-systemen in een project moet worden aangesloten op bestaande, vaak al oudere ITbesturingssystemen om werkend te kunnen worden opgeleverd. Civiele objecten (tunnels, bruggen, etc) daarentegen zijn vaak losstaand al functioneel (inbedding in bestaand systeem betreft Beheer & Onderhoud na functionele oplevering). Dit vraagt daarom om nauwere afstemming binnen eigen organisatie met IT-beheerafdelingen, maar ook bij ontwerp t.a.v. IT-architectuur gehele organisatie. •

Verschil in nadruk op keten: o IT-systemen zijn pas werkend op te leveren als alle componenten, zonder uitzondering, in de keten correct zijn gerealiseerd. Deze systemen zijn daarom een potentiële “showstopper” indien deze een onlosmakelijk onderdeel zijn van een groter civiel project. Bij de realisatie van IT-systemen wordt daarom een grotere nadruk gelegd op systeemintegratie. o Een raakvlak in civiele projecten is een gekozen grens tussen goed af te bakenen delen van de scope en de bijbehorende (organisatorische) verantwoordelijkheden, en waarbij de delen min of meer in afzonderlijkheid gereed/werkend kunnen worden opgeleverd. In IT-projecten spreekt men metafoor: technisch koppelvlak als van een zgn. “koppelvlak” bij een grens in de scheiding van verantwoordelijkheden? technische scope. De onderlinge afhankelijkheid van beide delen langs het koppelvlak is daarbij dermate groot dat het werkend opleveren van het geheel alleen mogelijk is met een actieve sturing “over het koppelvlak heen”. Met andere woorden, met splitsing van verantwoordelijkheden conform de civiele “raakvlakbenadering” worden de onderliggende problemen onderschat. Metafoor, zie afbeelding: een koppelvlak dwars door een tandwielkast (versnellingsbak) waarin bijna alle tandwielen op elkaar ingrijpen.

•

Verschil in levensduur: Levensduur van IT-producten is met 10-15 jaar korter dan civiele objecten (>30 jaar). Levensduur van componenten kan soms korter zijn dan de duur van project zelf! Dit vergt enerzijds strikter scopebeheer dan bij civiele projecten om te voorkomen dat een project door vele wijzigingen in technologie ongemerkt een testlab wordt voor nieuwe “unproven” IT-componenten. Anderzijds is het onderhoud van IT-systemen kwetsbaarder dan civiele objecten. Dit vraagt om meer aandacht voor onderhoudsfilosofie dan bij GWW-projecten, omdat gedurende de totale levensduur van een (civiel) object de IT-systemen meerdere malen vervangen zullen worden.


pagina 5

•

Verschil in aandacht voor testen: In tegenstelling tot civiele objecten zijn IT-systemen niet fysiek vast te pakken. Het wordt pas zichtbaar door uitgebreid testen. In IT-projecten bestaat een grotere aandacht op het testprogramma dan bij GWW-projecten. Testen bij IT-projecten is synoniem met kwaliteitsmanagement.

•

Verschil in fasering: Hoe langer de duur van IT-projecten (langer dan 1 jaar), hoe groter de kans op mislukken. IT-projecten worden daarom vaak opgeknipt in een serie kortere projecten achter elkaar. Dit gebeurt niet alleen bij toepassing van nieuwe, innovatieve ITtechnologie om zodoende via een stapsgewijze aanpak de complexiteit beter te kunnen doorgronden (zgn. “iteratieve methode”), maar ook al bij toepassing van relatief standaard IT-technologie.

•

Verschil in aanpak innovatie: Bij GWW-projecten zijn technische innovaties regelmatig onderdeel van de projectscope. In IT-projecten echter, wordt juist nadruk gelegd op het onderscheid tussen enerzijds “roll-out” (realisatie van standaard systemen – “proven technology”) en anderzijds nieuwe technologische ontwikkelingen. Vermenging van deze twee elementen binnen dezelfde scope wordt over het algemeen vermeden vanwege het relatief grote gevaar van vertraging die het innovatie-deel kan hebben op de overige roll-out.

Hardnekkige mythen Het bovengenoemde onderscheid tussen IT-projecten en CT-projecten dwingt de projectmanager zich rekenschap te geven van de noodzaak tot specifieke aandacht voor het IT-deel in zijn project. Dat dit in de praktijk binnen RWS nog niet in voldoende mate gebeurt, kan geïllustreerd worden aan de hand van een aantal hardnekkige “mythen” die voorkomen in de aanpak van projecten waarin IT een belangrijk onderdeel van de scope vormt: §

Mythe: er is een IT-architectuur, met specificaties voor de aan te leggen ITsystemen (lees: neerleggen van specificaties bij aannemer, einde probleem!). Realiteit: overkoepelende ITarchitectuur is niet aanwezig, en specs zijn er ten dele; afstemming van onderlinge afhankelijkheid van specificaties is niet gegarandeerd. De projectmanager die tekent voor de uitvoering wordt daarmee in de praktijk probleemeigenaar.


pagina 6

§

Mythe: met het definiëren van zgn. “koppelvlakken” kan je alles organiseren (lees: bij een ander neerleggen, einde probleem!). Realiteit: de verantwoordelijkheden zijn nauwelijks via een koppelvlak te scheiden (verantwoordelijkheden lopen over de hele keten dwars door elkaar).

§

Mythe: alle te realiseren IT-componenten zijn vooraf getest, zowel afzonderlijk als in de uiteindelijke keten waarvan zij onderdeel zullen maken (lees: bouwen, aansluiten, en stekker erin!). Realiteit: de meeste zijn niet getest, en sowieso niet als onderdeel van de gehele keten.

§

Mythe: systeemintegratie kan je als additionele rol beleggen bij de aannemer (lees: einde probleem!). Realiteit: systeemintegratie is geen additionele rol, maar de kern van het werkend opleveren van een IT-systeem. Dit moet dus centraal staan in contractfilosofie, contractbeheersing, etc. Daarnaast is systeemintegratie een vakmanschap dat wordt opgebouwd middels jarenlange ervaring o.b.v. trial&error tijdens de bouw van IT-systemen. Binnen RWS is deze ervaring schaars, en daarmee een risico binnen een project om de vakmanschap van de aannemer te kunnen toetsen?


pagina 7

IMPLEMENTATIE Door het inzicht in de specifieke verschillen in projectaanpak van IT en GWW, en ook in de hardnekkige mythen, is het mogelijk om oplossingsrichtingen te formuleren die deze mythen kunnen doorbreken, en die de specifieke aansturing van de IT-scope binnen civiele projecten op een meer beheersbaar niveau te brengen. Hierbij valt te denken aan: Planmatige aanpak: - Toetsen: om te kunnen volgen of de eerdergenoemde mythes tijdig worden doorgeprikt, om te zien of het specifieke IT-karakter in de aansturing van het project in toenemende mate de juiste aandacht krijgt, zou onderzocht kunnen worden of een soort lakmoesproef kan worden gedefinieerd waarmee door opdrachtgever en/of projectmanager de mate van grip op de realisatie van de IT-scope kan beoordelen. Een voorbeeld van zo’n lakmoesproef is gegeven in bijlage 2. - Kaders: de aandachtspunten uit de lakmoesproef kan worden vastgelegd in de “werkwijzer Aanleg” om daarmee het gedachtegoed te verankeren voor toekomstige projecten. Daarnaast kan aandacht worden gegeven aan een strakker releasemanagement van de IT-specificaties binnen RWS (afstemming van onderlinge afhankelijkheden, wanneer is welke specificatie voor welk project actueel, etc.) - Functies: het beleggen van de rol van “systeem integrator” binnen het IPM-model. - Risico’s: gegeven de verwachting dat veel risico’s bij de realisatie van IT-systemen in de huidige praktijk ook daadwerkelijk zullen optreden, zou de nadruk in het project niet alleen op de beheersmaatregelen ter voorkoming van het risico’s moeten liggen, maar juist ook op het vooraf uitwerken van scenario’s om de problemen snel en adequaat op te kunnen vangen zodra deze zich daadwerkelijk voordoen4. Opleiding: - Cursus: organiseren van specifieke modules binnen het LWT voor IT binnen RWS, voor technisch managers, projectmanagers en opdrachtgevers. Leerzaam daarbij kunnen voorbeelden zijn van negatieve ervaringen bij andere projecten. - Kennisuitwisseling: ProRail heeft vanuit zijn business meer ervaring gericht op IT voor het begeleiden van het treinverkeer op hun netwerk, en kan daarmee RWS helpen om een groei langs de “IT-leercurve”. Overig: - Dashboard : erken dat de realisatie van IT-systemen een cultuurverandering vereist binnen een organisatie die van oudsher gericht is op civiele werken. Maak de voortgang van deze verandering expliciet zichtbaar op het control-dashboard5 zowel binnen de gehele RWS-organisatie als zonodig binnen de eigen projectorganisatie. - Framing: realisatie van IT-systemen binnen projecten heeft nu een negatieve connotatie van “lastig”, “riskant”, “technische details op de projectwerklvoer”. Aandacht kan worden gegeven aan re-framing van dit beeld door te benadrukken dat het hier in eerste instantie gaat om de uitdaging van een aparte discipline binnen het vakgebied projectmanagement (zie: verschillen tussen projectsturing van IT en GWW). Van deze frame gaat, mits goed gedefinieerd, een meer uitnodigende werking uit. Het probleem is echter dat de meeste van deze oplossingen zo evident zijn, dat de vraag gerechtvaardigd is waarom ze niet eerder effectief geïmplementeerd zijn. De reden hiervoor is uiteindelijk dat het probleem, zoals de case eerder ook al uitwees, niet urgent genoeg is. Of nog scherper gedefinieerd, niet urgent genoeg om de sturing op de realisatie van IT binnen 4

Zie: presentatie W. Leendertse in seminar “het dilemma: risicomanagement voorbij, of voorbij risicomanagement”. 5 Zie: seminar “Cultuur en Projectmanagement”, RPA, prof. dr. Marcel Veenswijk.


pagina 8

RWS effectiever te organiseren. De verantwoordelijkheid rondom IT is gefragmenteerd binnen RWS, en de facto is niemand eindverantwoordelijk. Een belangrijke voorwaarde om de bovenstaande oplossingsrichtingen in de praktijk effectief te kunnen implementeren is een heldere eindverantwoordelijkheid voor het aanleg IT, met bijbehorend mandaat om deze oplossingen te organiseren. Maar vooral ook om de urgentie van het probleem op die plaats in de organisatie zodanig voelbaar te maken dat het mandaat daar kan worden ingezet om RWS-breed de oplossingen door te voeren. Er is een duidelijk stuur op het primaire proces “Aanleg” binnen RWS georganiseerd, met bijvoorbeeld een duidelijke verantwoordelijkheid voor de dienst Infrastructuur. Echter, in de praktijk leidt dit echter tot een situatie dat de IT-problematiek bij de realisatie in projecten wel wordt gevoeld, maar dat er niet voldoende mandaat is om veranderingen RWS-breed, dus bijvoorbeeld ook buiten de dienst Infrastructuur, door te voeren. Daardoor lijkt het erop dat de bovenstaande oplossingen tot op heden slechts geïmplementeerd kunnen worden in een spel van belangenafweging met de vele betrokken partijen die de (gefragmenteerde) verantwoordelijkheid voor IT wel gezamenlijk delen, maar niet gezamenlijk voelen. Ook de projectmanager is onderdeel van dat spel, en hij/zij zal, net als de overige betrokkenen, deze “verlammende complexiteit” van het IT-probleem bij tijd en wijle als “gedoe” willen bestempelen. Om dit gedoe structureel tegen te gaan kan door de projectmanager worden overwogen om samen met een groep collega-projectmanagers (i.e. . projectmanagementpool RWS), “als belangengroep”, de urgentie van het probleem breed in de organisatie zichtbaarder en voelbaarder te maken. Door zich in het zogenaamde kernmodel van politiek handelen 6 te richten op de elementen “positionering” en “inzet van macht en communicatie”, kan de groep projectmanagers de besluitvorming over sturing op IT effectiever beïnvloeden. In de praktijk vraagt dit ook om een grotere nadruk op de rolvastheid van de projectmanager, waarbij tekortkomingen in de ondersteuning vanuit de lijnorganisatie consequent worden teruggelegd bij diezelfde organisatie. Het gedoe wat hiermee op de korte termijn wordt veroorzaakt dient dus een hoger doel. Verder zou deze urgentie vooral onder de aandacht gebracht moeten worden bij degene binnen RWS die qua operationele verantwoordelijkheid dicht in de buurt van deze ITproblematiek zitten en voor wie de urgentie van het probleem het meest voelbaar is: § Directeur Techniek & Infrastructuur, dienst DI § Directeur ICT, dienst DID § Directeur Verkeersmanagement, dienst DVS. Deze directeuren hebben gezamenlijk al een overlegstructuur georganiseerd waarin de beschreven IT-problematiek onderwerp van bespreking is. Van belang is dat de groep van projectmanagers aansluiting zoekt bij hen, en in overleg met hen enerzijds pleiten voor een duidelijker stuur binnen de RWS-organisatie op de IT-problematiek, en anderzijds bespreken hoe ze gezamenlijk de eerder genoemde oplossingen in de tussentijd verder kunnen implementeren. Last but not least, de projectmanager zal zich er bewust van moeten zijn dat zolang de verantwoordelijkheid voor IT binnen RWS gefragmenteerd blijft, hij binnen zijn eigen project extra alert dient te zijn. Bewustwording van enerzijds de specifieke aansturing van IT-scope in GWW-projecten als een aparte discipline binnen het vakgebied projectmanagement, en anderzijds de aanwezigheid van hardnekkige mythen bij de realisatie van IT, is wellicht de grootste horde die genomen moet worden ! 6

Zie: RPA-seminar en boek “Macht en politiek handelen in organisaties”, van Martin Hetebrij


pagina 9

BIJLAGE 1: Rich Picture van case “realisatie DVM-maatregel”|


pagina 10

BIJLAGE 2: Lakmoesproef als toets op IT in projecten 1. 2

3.

4.

5.

RISICOMANAGEMENT OP ORDE Zichtbaar in project: operationalisering van IT-risico’s (geen hoog abstractieniveau zoals “DVM is risico”) VOORBEREIDING OP ORDE (KETENBENADERING): a. Zichtbaar in project: helderheid waar ieder onderdeel van IT-scope is belegd qua verantwoordelijkheid. (Zo niet, dan hoogstwaarschijnlijk helemaal niet belegd, en daarmee de zwakke schakel in de totale keten. Keten gaat dan niet werken) b. Zichtbaar in project: alle relevante IT-beheerspartijen binnen RWS expliciet aangehaakt bij project met schriftelijke afspraken. (IT-systemen kunnen pas functioneren indien deze zijn aangesloten op bestaande IT-infrastructuur, niet eerder. Indien niet alle relevante ITbeheerspartijen binnen RWS zichtbaar zijn aangehaakt bij de projectorganisatie, ontstaat daar waar een beheerspartij afwezig is een zwakke schakel in de te bouwen keten. Keten gaat dan niet werken). c. Zichtbaar in project: balans tussen de mate van sturing op alle partijen die een deel van de keten realiseren. (Kans is groot dat naast de hoofdaannemer via dikke beheersplannen en SCB, ook nog een RWS-lijnorganisatie betrokken is bij de realisatie van de keten. Indien er geen zwaar stuur op deze laatstgenoemde partij wordt georganiseerd vanuit het project (“interne-SCB”), ontstaat een zwakke schakel in de te bouwen keten. Keten gaat dan niet werken) d. Zichtbaar in project: geen discussie over raakvlakken/koppelvlakken waarbij wordt gesproken over “stekkers” als beeldspraak voor scheiding van verantwoordelijkheden in de totale keten. (Verantwoordelijkheden van projecten lijnorganisaties binnen RWS lopen onvermijdelijk langs en door elkaar over de gehele keten. Zonder goed begrip van het koppelvlak in die keten, is het koppelvlak dan de zwakke schakel. Keten gaat dan niet werken) e. Zichtbaar in project: verantwoordelijkheid eenduidig bij 1 partij voor afstemming/coördinatie van activiteiten van de betrokken partijen rondom een koppelvlak (anders is het koppelvlak de zwakke schakel. Keten gaat dan niet werken) f. Zichtbaar in project: integratie van alle te realiseren IT-componenten in de keten (“systeemintegratie”) is binnen project het belangrijkste strategische onderwerp van de IT-realisatie (projectplan, beleggen verantwoordelijkheden, contract, overdracht, etc.). SCOPEBEHEER OP ORDE a. Zichtbaar in project: alarmbellen gaan af in project als bediensystemen of bedienapplicaties binnen dat project moeten worden ontwikkeld (zolang er geen duidelijk, gedetailleerd en door alle betrokken partijen gedeeld beeld bestaat t.a.v. scope en specificaties, is dit een “mission impossible”). b. Zichtbaar in project: strak scope beheer bij m.n. Technisch Management . Ook zichtbaar: RWS-inkoopfilosofie als “firewall” in project: specificatiewijziging = scopewijziging = accordering door opdrachtgever. (Binnen RWS is niet altijd te herleiden of een specificatiewijziging voor een IT-component voldoende getest is, apart of in keten. Project wordt dan testlab voor nieuwe componenten, met vooral Tijdsconsequenties. Kan ook veroorzaakt worden door het feit dat de levensduur van sommige IT-componenten soms korter dan de realisatieduur van het project. KWALITEIT OP ORDE: Zichtbaar in project: aandacht voor testen, testen en nog eens testen. (Zonder een duidelijke testfilosofie is een kwaliteitsparagraaf voor het IT-deel per definitie onvoldoende. Pas bij testen wordt zichtbaar/voelbaar waaraan gewerkt wordt). PLANNING OP ORDE: a. Zichtbaar in project: ontwikkel-/bouwtrajecten van IT-systemen langer dan 1 jaar moeten om te slagen een duidelijke fasering in de planning hebben zoals proof-of-concept, tussenoplevermomenten, etc (ervaring in IT-wereld leert dat slagingskans snel afneemt met projecttijdsduur) b. Zichtbaar in project: ruime, goed gemotiveerde reserve in de planning voor realisatie IT. (zo niet, dan is de planning per definitie te krap).


pagina 11

BIJLAGE 3: Gevoerde gesprekken t.b.v. deze eindopdracht

Gesprekken t.b.v. deel 2 van opdracht (case “realisatie DVM maatregel”): -

2 mei 2011, Jaap ten Kate (marketing manager, JTEKT Europe, Japans bedrijf dat rollagers produceert voor m.n. auto-industrie) 10 mei 2011, Els Reinierse (adviseur afd. Verkeerssystemen, RWS dienst DVS), 11 mei 2011, Joop Bos (begeleider RPA) 6 juni 2011, Wim Anemaat (directeur RWS dienst DI) 7 juni 2011, Axel Zandbergen (projectleider, afd. IPM, RWS dienst DID) 8 juni 2011, Ben Harbers (adviseur afd.SWI, RWS dienst DI)

Gesprekken t.b.v. deel 3/4 van opdracht (oplossingsrichtingen & implementatie): -

4 juli 2011, Gerritjan vd Toorn (teamleider en projectmanager, afd. IPM, RWS dienst DID), onderwerp: verantwoordelijkheden DID bij realisatie IT-systemen binnen RWS 6 juli 2011, Ben Harbers (adviseur afd.SWI, RWS dienst DI), onderwerp: rol systeemintegrator 31 augustus 2011, Arjan Jonker (directeur KWD bv), onderwerp: verschil in projectaanpak tussen IT en GWW. 7 juli / 15 aug 2011, Edwin vd Walle (projectmanager afd. IPM, RWS dienst DID), onderwerp: rol systeemintegrator 25 aug 2011, Joop Bos (RPA), onderwerp: voortgangsgesprek 5 sept 2011, Carla Drijkoningen (adviseur afd. CT, RWS dienst DI), onderwerp: Spoedaanpak 7 sept 2011, Ben Harbers (adviseur afd.SWI, RWS dienst DI), onderwerp: A73 16 sept 2011, Dick Jonkers (projectdirecteur, RWS dienst DI), onderwerp: aanpak algemeen 28 oktober 2011, Joop Bos (RPA), onderwerp: implementatie van oplossingen 9 december 2011, Wim Anemaat (directeur RWS dienst DI), onderwerp: implementatie


pagina 12

Sturing op IT in GWW-projecten

Recommend Documents