Automatiseringsprojecten gaan niet van een leien dakje. In de woorden van de Rekenkamer: ‘Ict-projecten bij de overheid blijken veel duurder te worden dan gedacht, vragen meer tijd dan gepland of leveren niet het gewenste resultaat op.‘ In de remedies die worden voorgesteld neemt de stuurgroep een centrale plaats in. Deze zal ambities en complexiteit moeten beheersen. Daarmee wordt de stuurgroep een soort kop van jut. Als iets niet goed is gegaan moet de stuurgroep het gewoon beter beheersen. Maar is het voldoende zo sterk alle hoop te richten op de centrale besturing door de stuurgroep? Is dit niet gewoon (deels) wishful thinking, waarin een sterke man met bijzondere kwaliteiten het allemaal in de hand houdt? Zouden we ook niet wat moeten zeggen over hoe een stuurgroep dan intern moet werken, en welke kennis en andere eigenschappen de leden moeten hebben?
In verschillende methoden en adviezen komt een gelijk beeld naar voren. Enerzijds wordt gehamerd op elementen vanuit goed projectmanagement: er moet een plan zijn, financiële overzichten, business cases, etc. Anderzijds ligt een grote rol bij de stuurgroep, die veel wijsheid bezit en altijd het goede besluit neemt.
In Prince2 heeft de stuurgroep, ofwel Project Board, een centrale rol in de besluitvorming. Deze besluit over onder andere start, business case en volgende fases of stages. In de aan Prince2 gelieerde Gateway-projectreviewmethode moeten peers van de opdrachtgever een project doorlichten en nagaan of het project klaar is om naar een volgende fase door te gaan. Daarnaast moet natuurlijk ook gewoon goed projectmanagement worden uitgevoerd en moet goed worden gerapporteerd aan de stuurgroep. En ook in het Rekenkamer rapport deel A worden als aanbevelingen gegeven: ‘de minister heeft de sleutel' en ‘wees als minister een volwaardige gesprekspartner'.
Wat vragen we daarmee wel niet van de opdrachtgever en de stuurgroep? Hebben de leden van de stuurgroep altijd genoeg kennis en ervaring met ict-projecten? Hoe reëel is het te veronderstellen dat zij gordiaanse knopen kunnen ontwarren waar de ict-experts het zelf niet kunnen? Besturen de seniore gebruikers en de seniore leveranciers gezamenlijk met de uitvoerende het project en mobiliseren ze hun eigen organisaties daarbij of behartigen ze vooral de belangen van hun eigen organisaties in het project? En hoe kunnen peers in enkele dagen genoeg overzicht en inzicht in risico's krijgen van een complex project om zich een beter oordeel te vormen dan de opdrachtgever zelf?
Laat ik proberen om vijf vragen te formuleren die de leden van een stuurgroep zich zouden kunnen stellen vóórdat ze samen gaan werken in een stuurgroep. Deze vragen komen gedurende elk project aan de orde. Ze kunnen het beste vroegtijdig worden beantwoord. Daarmee kan de stuurgroep ervoor zorgen dat ze zich niet alleen actief met het project bemoeit, maar ook de blik op zichzelf richt om zo effectiever het project en de -manager aan te kunnen sturen.
Hebben we onszelf goed samengesteld?
In veel stuurgroepen zit volgens klassiek Prince2-model een sponsor, seniore gebruiker en seniore leverancier. Kunnen deze rollen goed worden aangewezen in de stuurgroep? En zijn er daarnaast ook genoeg verbindende stuurgroepleden? Deze kunnen strategisch en tactisch een brug slaan tussen ict en de business. Deze mensen hebben vaak functies als controller, informatiemanager of cio. Ze kunnen helpen om het project op koers te houden door te letten op relatie tussen organisatiedoelen, reikwijdte, planning en inzet.
Daarbij komt ook de vraag naar de sfeer in de stuurgroep. Komen we vaker bij elkaar dan alleen als stuurgroep? Kennen we elkaar ook als mens? Zijn we bereid naar elkaar te luisteren en samen tot een goed oordeel te komen voor het project en de organisatie?
Begrijpen we het nut en de noodzaak van het project?
Kunnen we elkaar uitleggen wat het project moet opleveren en wat daarvoor reële en acceptabele kosten zijn? En vinden we dan hetzelfde? Weten we waarom het project juist nu moet worden gestart? Als we geen business case hebben opgesteld, komt dat dan omdat hij niet te maken is, omdat we allemaal een ander beeld hebben of is er een andere reden? Als we verschillende zaken belangrijk vinden, hoe kunnen we dan toch samen het project besturen?
Wat is de toegepaste methode en terminologie voor dit ict-project?
Het ict-wereldje gebruikt veel jargon en dat is soms onbedoeld verwarrend. Zo kan een projectleider in de stuurgroep uitleggen: ‘We maken in elke iteratie een functioneel ontwerp en detailleren dat verder in een detailontwerp. Wijzigingen worden daarna met een change request afgehandeld.' Hier worden woorden uit vier methoden samen gebruikt: iteratie (RUP), functioneel ontwerp (SDM I), detailontwerp (SDM II) en change request (ITIL). Beseft de projectleider dat wel? En hoe moet een stuurgroeplid dit begrijpen?
Binnen ieder project zou aan het begin moeten worden afgesproken welke methode wordt gebruikt. Alle stuurgroepleden zouden een algemene basis moeten hebben voor besturing van ict-projecten en onderlegd moeten zijn in de aanpak en terminologie die wordt gebruikt.
Begrijpen we de reikwijdte en hebben we genoeg marge om te sturen?
Weten we precies wat de grenzen van het project zijn, en ligt dat duidelijk vast? En weten we hoe de begroting is opgebouwd? Veel projecten worden begroot door alles wat bekend is te begroten en daarna alle posten op te tellen. Doordat alleen het vooraf bekende wordt begroot, ontstaan systeemfouten in de begroting:
a. Sommige functionele zaken zijn bij aanvang nog niet bekend, maar wel essentieel voor een goed werkend eindresultaat. Deze worden bij aanvang niet mee begroot.
b. Technisch lastige zaken worden te optimistisch ingeschat. Dat kan te maken hebben met werk om technisch lastige zaken werkend te krijgen of met werk om te zorgen dat er een beheeromgeving wordt gecreëerd waarin mensen goed hun werk kunnen doen.
c. Extra werk ontstaat door communicatieproblemen en verschillende beelden over doelen en de weg ernaar toe tussen verschillende groepen mensen die een gemeenschappelijk eindresultaat moeten bereiken.
d. Tijdens het traject ontstaat uit verschillende hoeken druk om wat meer te vragen dan strikt nodig is. Gebruikers willen uitzonderingen netjes afgehandeld zien. Beheerders willen weinig werk hebben aan installatie en beheer. Architecten willen een hoge mate aan flexibiliteit en uitwisselbaarheid.
Weten we in hoeverre er rekening is gehouden met deze factoren? Hoeveel marge is opgenomen voor elk van deze posten? Begrijpen we dat deze factoren niet optellen maar elkaar vermenigvuldigen? En hoe gaan we dit gedurende het project in de hand houden?
Hoe komen we aan een goede en onafhankelijke informatievoorziening?
De stuurgroep neemt tenslotte besluiten op basis van informatie die de stuurgroep bereikt. Weten we wat we willen krijgen aan reguliere informatievoorziening uit het project? Voorziet de projectmanager daarin? Is er daarnaast een interne, controlerende functie die er op toeziet dat deze informatie niet te rooskleurig is? Is standaard een audit-functie ingericht die onafhankelijk van de projectleider, ter zake kundig en zonder nevendoelen het project regelmatig beoordeeld op effectiviteit en beheersing?
De ict-stuurgroep heeft een centrale rol bij projectbesturing. De verwachtingen zijn groot. De onderwerpen voor de vijf vragen liggen voor de hand, maar in de praktijk zijn ze zeer actueel. Voor een goede projectbesturing is een goed werkend besturend orgaan essentieel.
Ik val bij Computable regelmatig in herhaling. Ook nu weer.
De schrijver verwijst naar PRINCE2 en hierop enkele reacties.
1. Terecht heeft de schrijver het over het belang van de Business Case. Dit is de Business Case van de klant en hier wordt de verwachte verbetering beschreven. ICT is een middel en geen doel (tenzij je een ICT-er bent) en daarmee bestaan ICT projecten niet. Wel verbeterprojecten met een ICT component. Het label ICT project zorgt ervoor dat doel en middel verward worden, gebruikers afhaken en er slechts focus is op de techniek. Andere punten uit het betoog van de schrijver bevestigen dit, zie punt 3!
2. Weer terecht gaat de schrijver in op de juiste samenstelling van de Project Board. Echter, zoals bij zoveel organisaties, wordt bij overheid vaak een interne leverancier benoemd tot opdrachtgever: de CIO. Hiermee wordt het belang van de Business Case ondergraven, wordt het middel (ICT) een doel en gaat de focus weg van business products naar technische products.
3. Wanneer het met de twee bovenstaande punten misgaat, komt er technobabble terug als een van de symptomen. Een goede project board praat niet over techniek of technisch fases. Men praat in het business jargon en beslist over management stages. Terminologie in de board zoals de schrijver beschrijft (RUP, SDM, ITIL, etc) duidt op een project board met een focus op techniek, geen focus op verbetering en business products/management stages. De gebruikte terminologie zit bij PRINCE2 op Work Package niveau.
Overigens is de term Change Request ook een PRINCE2 term en niet slechts, zoals de schrijver stelt, een ITIL term.
Zucht,
Ik reageer ook niet meer. Weer dezelfde discussies en prinselijke oplossingen.
Als we thuis zouden verbouwen zoals we bedrijfsprojecten doen dan moeten de doe-het-zelfwinkels en herstelbedrijven de meest lucratieve werkbronnen zijn. Dan zou 80% aan mislukte thuisprojecten hersteld moeten worden.
Het gekke is dat als ik het vraag in een training dat je de meest perfecte voorbereidingen en plannnen hoor en dat elke verbouwing een succes ofwel verbetering is geworden.
Waarom doen we het dan niet op ons werk?
Inderdaad, waarom doen wij op ons werk van die rare dingen die we buiten ons werk niet eens zouden overwegen?
Overigens, zucht, inderdaad weer veel gepraat over PRINCE2 zonder te weten waar het echt om gaat.
Voorbeeld 1: Sponsor? Bestaat niet in PRINCE2. Een sponsor heeft geen verantwoordelijkheden (het belang van semantiek), een eigenaar (wel in PRINCE2) wel.
Voorbeeld 2: “Een vraag Hoe komen we aan een goede en onafhankelijke informatievoorziening?” Een audit functie, stelt de schrijver voor. RTFM, graag! Dit heet Project Assurance (Borging).
Diepe zucht.