Adviezen bij Grote IT-Projecten
(ing. Mark Paauwe, promovendus bij Prof. Dr. Daan Rijsenbrij, 20 september 2007)

Dit document is in aanvulling op de adviezen van Daan Rijsenbrij bij grote IT-Projecten, 19 september.

Een woord vooraf:
Ik ben van mening dat het goed is dat verschillende mensen zich met verschillende probleemaspecten bezighouden aangaande IT-projecten. Maar dat het is goed als een persoon zich focust op een probleemaspect. Daarom ga ik in dit stuk alleen in detail in op wat ik zie als fundamenteel probleem met betrekking tot grote IT-projecten bij de overheid, namelijk: de fasen voorafgaand aan het IT-project.


Mijn observaties en adviezen zijn:
1. Ik denk dat er geen grote fundamentele problemen zitten in de projecten bij de overheid. De besturing, uitvoering of ondersteuning van de projecten verloopt denk ik zoals dat nu kan bij de overheid en het kan natuurlijk altijd beter. Daarin ga ik volledig mee met de verbetervoorstellen van Daan Rijsenbrij. Ik heb zelfs nog diverse aanvullende verbetervoorstellen. Met al deze verbetervoorstellen zorgen we er volgens mij nog niet voor dat de resultaten van projecten revolutionair bruikbaarder worden zodat de projecten als een succes kunnen worden gezien. Ik ga nu verder in op wat ik denk dat het fundamentele probleem is.

2. Ik denk dat er maar een fundamenteel probleem is, en die ligt buiten het project en dat betreft de start en input voor een project. Het betreft het kader van probleemstellingen, opdracht en oplossingsrichting die wordt meegegeven aan het project. Of te wel het opstarten van een verandering of programma verloopt niet goed genoeg.
In dit kader zou men in projecten veel vaker de aandacht kunnen geven aan: wat was het oorspronkelijke kader en hoe kunnen we snel de impact van veranderingen op dat kader terugkoppelen aan de opdrachtgever?

3. In de bouwkunde noemt men vaak de fasen die voorafgaan aan het opstarten van projecten: 1) de initiatiefase en 2) de plan- en visievormingsfase van een verandering. Er is op dat moment vaak nog geen sprake van een project, laat staan een IT-project.

a. Een initiatiefase behelst het definieren van het probleem of de kans, het formuleren van een opdracht om het probleem op te lossen of de kans te grijpen, het maken van een ontwerpschets en tenslotte het geven van inspraakmogelijkheden via zienswijzen.

b. Een plan- en visievormingsfase behelst het maken van een programma van eisen, architectuur(visualisaties), impact analyse, investeringsvoorstel, masterplan, doelstellingen hierarchie, haalbaarheidsonderzoek, structuurplan, kaderplan, bestemmingsplan, beeldkwaliteitplan, bereikbaarheidsplan, etc..

4. Het probleem dat men dus nu creeert, het feit dat het project niet goed loopt, probeert men in het project op te lossen. En dat kan dus niet, omdat het niet aan de mensen in het project ligt. Een betere besturing, uitvoering of ondersteuning levert geen of te weinig resultaten op. Voorbeelden van problemen in IT-projecten:

a. Vertraging en uitloop, tegenwerking en niet in gebruiknemen - Stel dat men in een project een landelijke IT-oplossing maakt voor bepaalde type decentrale/lokale overheidsorganen. Alleen er is niet goed geregeld dat alle lokale en decentrale organisaties hun eigen oplossing gaan vervangen of goed aansluiten op de IT-oplossing. De kans is groot dat niet iedereen 100% meewerkt aan de aansluiting op het nieuwe systeem of overgaat op het nieuwe systeem. De ontwikkelen en implementatie van het systeem loopt dan vertraging en schade op. Dit is dan niet iets dat te wijten is aan het IT-project zelf, maar aan het opstarten van het project: het gesternte waaronder het project plaatsvindt. Een goede Enterprise-governance en IT-governance voorafgaand aan dit project kan een dergelijk probleem kunnen voorkomen.

b. Ontwikkelfouten en verkeerde keuze voor technologie - Stel dat men in een IT-project nieuwe IT-deeloplossingen ontwikkeld en gebruikt die in de kinderschoenen, staan waar nog geen ervaring mee is, en zich alleen in de theorie bewezen hebben. De kans is dan aanwezig dat de oplossing niet (goed) gaan werken. Een IT-architectuur die voorafgaand aan het project gemaakt had kunnen worden, had dit op basis van kwaliteitseisen dit nooit laten gebeuren. Als in het begin van een project eenmaal (zonder IT-architectuur) wordt gekozen voor een bepaalde leverancier of technologie dan is het bijna onmogelijk om in een project de boot te keren. Men kan dan alleen nog het project stoppen.

c. Onbeheersbare complexiteit - Stel dat men een complexe integrale oplossing in een IT-project is gaan ontwikkelen. Vanwege de complexiteit zag men wellicht geen kans om voorafgaand aan het project een programma van eisen op te stellen waarin alle belanghebbenden elkaar konden vinden. De kans is dan groot dat goed bedoeld en wellicht ook werkende oplossingen niet door alle belanghebbenden worden geaccepteerd of gebruikt. Een andere kans die men loopt is dat niet alle eisen voldoende in de integrale oplossing kunnen worden verwerkt, vanwege tegengestelde eisen. Dit is meestal niet meer op te lossen in een project. Het project moet dan gestopt worden. Een architectuur had een dergelijk probleem kunnen voorkomen door vanuit complexiteitsreductie kleinere IT-projecten te laten definieren die alleen met een programma van eisen van start mogen gaan.

5. Een project dient te worden gezien als een middel waarmee een deel van een integrale systeemoplossing of een complexe strategische verandering moet worden gerealiseerd. Daarom dient heel goed de kans of het probleem te worden geanalyseerd voordat er een project of IT-project wordt opgestart.

6. De oplossing of verandering dient altijd voorop te staan en niet het project.


7. Mijn pleidooi is het volgende

a. Onderzoek bij alle grote IT-projecten hoe de initiatiefase en plan- & visievormingsfase voorafgaand aan het grote IT-project zijn verlopen. Stel drie vragen voorop die zorgen voor zicht op het gelopen proces:

i. Wat zijn de betrokken partijen en belangen geweest bij het opstarten van het project en volgens of onder welke methode, werkwijze, model of fasering is het project opgestart?
ii. Welke feitelijke activiteiten zijn uitgevoerd en welke producten zijn opgeleverd in dit beginstadium voordat het project er was?
iii. Wat is de kwaliteit van de producten en hoe zijn of worden deze producten gebruikt in het project zelf? Wat stuurt of geeft een kader voor het project?

b. Formuleer, indien het onderzoek daartoe aanleiding geeft, verbetervoorstellen voor het opstarten van een IT-project. Hieruit kunnen bijvoorbeeld drie instrumenten voort komen:

i. Een quickscan voor het starten van IT-projecten om ervoor te zorgen dat essentiele mijlpalen niet zijn overgeslagen
ii. Een referentiemodel voor de fasering voor het uitvoeren van complexe programma's, waarbij projecten niet voorop staan, maar een middel zijn.
iii. Een training voor betrokkenen in de quickscan en het referentiemodel.

c. Zorg voor professionalisering in het opdrachtgeverschap van IT-projecten door bestuurders en directies te trainen en te coachen op het gebied van enterprise architectuur: het sturen van complexe strategische organisatieveranderingen vanuit kwaliteit.

d. Werk altijd vanuit governance en architectuur en met programma's van eisen om een complexe verandering of integrale oplossing dmv programma's en projecten te realiseren. De tijd en het geld dat wordt geinvesteerd in architectuur en programma's van eisen bij grote IT-Projecten wordt met een factor groter dan 10 terugverdient.

Extra opmerking:
Visualisaties creeren het noodzakelijke inzicht en overzicht als men dit kwijt is in een groot project, met name omtrent de impact van veranderingen op het oorspronkelijke kader. De opdrachtgever moet altijd snel door een programma-manager of stuurgroep van beelden kunnen worden voorzien die hij of zij snapt. Anders is de controle en sturing op het project onnodig laag en traag.
In deze visualisaties kan men 1 - de complexiteit tonen, 2 - de mogelijke of gerealiseerde complexiteitsreductie en 3 - de mogelijke of gerealiseerde complexiteitsbeheersing.