ICT-projecten managen is moeilijk

Een bekende stelregel bij ICT-implementaties heet de 2-2-½ regel: Ten opzichte van de oorspronkelijke plannen duren ICT-projecten tweemaal zo lang, zijn ze tweemaal zo duur en leveren ze maar de helft op van wat oorspronkelijk beloofd was. Voor ICT-projecten in het onderwijs is dat niet anders. Daarom heeft MBO2010 een publicatie onder de naam van ICT-implementator samengesteld waarin aandacht wordt besteed aan een groot aantal misvattingen, randvoorwaarden en valkuilen.

Om met het goede nieuws te beginnen: het is een goed leesbaar boekje geworden met een heldere indeling, veel tips en praktijkvoorbeelden. Er staan wat aardige schema’s in, die je helpen om de balans te bewaken tussen verschillende aspecten zoals zorgvuldigheid versus snelheid, complexiteit versus bestuurbaarheid, kosten versus resultaten. Ook bevat het boekje wat checklisten in die te gebruiken zijn tijdens het project om een beeld te krijgen van de stand van zaken (thermometer) en de te verwachten voortgang (barometer). Met name de aandacht, die besteed wordt aan een goede projectsturing, is me uit het hart gegrepen.

Toch ben ik een beetje teleurgesteld. Iedereen, die wel eens met een ICT-project bezig is geweest, zal (veel van) de voorbeelden herkennen. En dat is nou juist één van de zwakke kanten van het boekje: toch wel veel open deuren en weinig echt praktische oplossingen. Nou ja, er staan wel veel handreikingen in, maar die leiden weer aan het zelfde euvel als waar veel projectplannen aan leiden: open einden en wolligheden.

"De organisatie heeft invloed op de vraag wie betrokken moet worden in het project (stakeholders) en op de (in)richting van de gewenste functionaliteit. Is de besturingsfilosofie gericht op sterk decentraal besturen? Dan kan dit consequenties hebben voor de keuze voor een decentraal of centraal geleide ICT applicatie, voor de bekostiging van het project en voor het eigenaarschap van de applicatie. In de aansturing moet bijvoorbeeld rekening gehouden worden met de verantwoordingsvraag; “Wie is verantwoordelijk voor het slagen van het project?”

Klopt helemaal. Maar nu graag wat richtlijnen hoe je een antwoord op een dergelijke vraag krijgt! Het boekje geeft aan, dat er een ‘eigenaar’ benoemd moet worden maar niet wat die eigenaar eigenlijk moet doen. Eigenlijk staat er alleen maar, dat een eigenaar verantwoordelijk is voor de applicatie en de gebruikers.
In de praktijk komt die verantwoordelijkheid er echter op neer, dat die eigenaar in de besluitvorming in de organisatie de consequenties voor de applicatie moet bewaken (bijvoorbeeld omdat een verandering in een gekoppeld systeem door kan werken in zijn applicatie). Ook moet hij ervoor zorgen dat bepaalde besluiten vertaald worden in aanpassingen in de (inrichting en / of gebruik van de) applicatie.

Het boekje beschrijft ook allerlei verschillende cultuurvormen in organisaties, maar niet niet welke aanpak het beste past bij welke cultuur. Veel aandacht voor het opstellen van een businesscase. Maar ik kan me voorstellen, dat iemand op basis van de gegeven omschrijving nog steeds geen idee heeft hoe een businesscase wordt opgesteld.

Ondanks de kritische noot zou ik het boekje toch willen aanbevelen aan iedereen die in het onderwijs met ICT-projecten te maken heeft, al zou ik de aanbeveling willen doen om er ook wat andere literatuur naast te gebruiken zoals ‘de Kleine Prince II’ (let op: duur boekje).