Principes & Richtlijnen voor goede IT-Projecten bij de overheid

Een nieuwe forumdiscussie
Hierbij wil ik een nieuwe forumdiscussie starten over principes en richtlijnen voor goede besturing en uitvoering van IT-projecten bij de overheid.

Het is in mijn ogen noodzakelijk dat we hier met collega-architecten over van gedachten wisselen. Waarom? Dat geef ik hieronder weer door te laten zien hoe wij allen en de politiek nu bezig zijn met IT-projecten bij de overheid.

Ik begin met kort te schetsen wat de positieve en negatieve ontwikkelingen zijn omtrent IT, innovatie en projecten bij de overheid.

Vervolgens toon ik vier stukken van overheidswebsites die aangeven dat de problematiek omtrent de besturing en de uitvoering van IT-projecten ons allen tot last is, ons allen aangaat en dat een oplossing er nu snel moet komen:
1. De onderzoeksopdracht van de rekenkamer naar het mislukken van IT-projecten

2. De antwoorden van de minister Ter Horst op de vragen van de tweede kamer over het mislukken van IT-projecten

3. De reactie van staatssecretaris De Jager richting de tweede kamer over aanbesteding van IT door de belastingdienst en de relatie met IBM naar de belastingdienst

4. Het resultaat onderzoek naar informatievoorziening en IT-Governance bij ministeries

Daarna volgt er een stukje over de Clinger Cohen wet die een Amerikaanse deeloplossing voor het probleem laat zien.
Ik sluit af met een aantal vragen en stellingen waar ik graag met anderen over van gedachten wil wisselen om te komen tot richtlijnen en principes voor betere projecten.

Ik denk namelijk dat wij als architecten vanuit ons architectuuroogpunt en met de kennis die we hebben over systemen, ontwikkeling, veranderingen, projecten en programma's een goede bijdrage kunnen leveren aan een oplossing. Architectuur is tenslotte een ander woord voor bouwkunde. De wijze waarop we bouwen door middel van een project, is in feite onderdeel van architectureren.
Wij kunnen een aanzet maken voor het formuleren van regels, richtlijnen en principes voor goede besturing en uitvoering van IT-projecten bij de overheid. In feite: een generieke projectarchitectuur schetsen. Of: zie het als tips en trucs voor managers bij de overheid.

1. Positieve ontwikkelingen
IT-projecten bij de overheid staan medio 2007 volop in de belangstelling. Ze zijn vaak in het nieuws, positief zowel als negatief. Het positieve is dat de overheid zeer veel tijd en geld steekt in innovatieve IT-projecten om de overheid efficienter te maken. De overheid ontwikkelt systemen zodat ambtenaren een goede digitale ondersteuning hebben voor bijvoorbeeld de uitbetaling van uitkeringen of het innen van belasting. Burgers en ondernemers krijgen diverse digitale toepassingen aangeboden via het internet om bijvoorbeeld sneller en eenvoudiger vergunningen en ontheffingen aan te vragen. Ook een Betuwelijn, een communicatiesysteem voor de politie en voor rampenbestrijding zijn voorbeelden van innovaties bij de overheid met een grote IT-component.

2. Negatieve ontwikkelingen
Naast deze positieve zaken zijn er ook negatieve ontwikkelingen die vragen om een oplossing.
Grote IT-projecten bij de overheid komen als onbestuurbaar over, regels omtrent uitbestedingen worden niet voldoende nageleefd, budget- en tijdsoverschrijdingen van projecten zijn niet uitlegbaar groot. En dat naast het maken van grove ontwerp- en programmeerfouten in software en slechte uitvoering van goed opgezette projecten.
De vele projecten bij centrale, regionale en lokale overheden hebben veel overlap en een actieve integrale besturing op zoiets als de ontwikkeling van de 'digitale Nederlandse overheid' ontbreekt. Op dit moment is er zelfs een onderzoek bij de overheid gaande waarom de meeste 'IT-projecten' bij de overheid zelf sinds 2000 mislukken. Het schadebedrag door het mislukken wordt geschat op vier tot vijf miljard euro per jaar.

3. Onderzoeksopdracht van de Rekenkamer
Op de site van de rekenkamer is het volgende te lezen (bron: http://www.rekenkamer.nl, september 2007): De Tweede kamer heeft de Algemene Rekenkamer verzocht onderzoek te doen naar de omvang van de verspilling door de rijksoverheid van IT-projecten en de achterliggende oorzaken hiervan. Wij zullen onder andere onderzoeken of er sprake is van professioneel opdrachtgeverschap en bezien in hoeverre de gekozen projectaansturing en -beheersing tot problemen met IT-projecten leiden. Het onderzoek bestaat uit twee delen. Als vervolg op het eerste deel van het verzoekonderzoek zullen wij een aantal nader aan te wijzen IT-projecten diepgaand te onderzoeken. Dit tweede deel wordt naar verwachting in juni 2008 gepubliceerd.

4. Antwoorden van de minister Ter Horst
Op 11 juni stond op de site van Binnenlandse Zaken het volgende te lezen (bron: http://www.minbzk.nl):
Minister Ter Horst reageert op kamervragen die op 5 juni zijn gesteld naar aanleiding van het artikel in Trouw van 4 juni over vermeende miljardenverspillingen aan mislukte IT-projecten bij de overheid.

Ik wil vooropstellen dat ik de stellige indruk heb dat hiervoor geen onderzoek is gedaan specifiek naar de Nederlandse overheid. Naar het zich laat aanzien, is er van niet meer sprake dan het projecteren van internationale statistische gegevens op Nederland. Dat zegt natuurlijk weinig. Om een beter beeld te krijgen zullen mijn medewerkers binnenkort een orienterend gesprek voeren met de betrokken hoogleraren.

Verder moet ik u melden dat mijn indruk is dat het hier gaat om een uiterst heterogeen geheel. Binnen de (rijks)overheid vinden IT projecten plaats rond alle denkbare beheers- en beleidsterreinen. IT is wijd verspreid. Dat impliceert ook dat er geen centrale administratie is van IT projecten of van het mislukken daarvan.

Het is evident dat de overheid als opdrachtgever lering moet trekken uit wat er misgaat in projecten, om herhaling te voorkomen. In de evaluaties van verschillende projecten en de bespreking hiervan door verantwoordelijke bewindspersonen met de Tweede Kamer zijn hierover conclusies getrokken. Daarnaast worden overheidsbreed ervaringen uitgewisseld over grote IT-projecten. Bij de uitvoering van dergelijke projecten worden zoveel mogelijk de erkende standaardmethodieken toegepast die de beheersing van IT-projecten verbeteren.

Overigens geldt dat voor IT-projecten binnen de rijksoverheid de beslissingsbevoegdheid niet centraal geregeld is. Er is niet een bewindspersoon verantwoordelijk, want IT is een integraal onderdeel op vrijwel alle beleidsterreinen. De verantwoordelijkheid voor de IT van projecten is daarmee onderdeel van de integrale verantwoordelijkheid van de betreffende bewindspersoon voor zijn of haar eigen beleidsterrein. Een rijksbreed debat hierover zou dus ook met alle betrokken bewindspersonen gevoerd moeten worden. Voor zover het projecten van andere overheidsorganisaties betreft moet het debat tussen de desbetreffende bestuurders en hun controlerende organen gevoerd worden.

5. Reactie van staatsecretaris De Jager over IT aanbesteding en de relatie IBM met de Belastingdienst
(bron: http://minfin.nl)
Jaarlijks controleert de departementale accountantsdienst (AdF) de
rechtmatigheid van de inkoop. In het verleden heeft deze controle een aantal
gevallen opgeleverd waarin de regels niet zijn gevolgd. Vanuit de optiek van de
rechtmatigheid werden de tolerantiegrenzen nooit overschreden. Over 2006
heeft de Algemene Rekenkamer in vervolg op de rapportage van de AdF
geconstateerd dat de Belastingdienst onvoldoende aandacht heeft gehad voor
de Europese aanbestedingsregels. Bij opdrachten met een waarde van in totaal
11 mln. was sprake van onrechtmatige aanbesteding. Bij opdrachten met een
waarde van in totaal 48,5 mln. was de rechtmatigheid onzeker. In reactie op
deze bevindingen heb ik in het Beheersverslag en tijdens een
wetgevingsoverleg van 12 juni jl. toegezegd dat naleving van de regels in de
toekomst strikt wordt bewaakt. Hier kom ik later in deze brief op terug.
Naar aanleiding van de berichtgeving over naleving van de Europese
aanbestedingsregels heb ik de Belastingdienst gevraagd een aanvullende
interne inventarisatie uit te voeren van gevallen waarin de aanbestedingsregels
(mogelijk) niet zijn nageleefd. De inventarisatie is naar eer en geweten
uitgevoerd. Desondanks sluit ik het niet uit dat, gezien de omvang van de
Belastingdienst en de termijn waarbinnen de inventarisatie heeft
plaatsgevonden, een enkele aanbesteding over het hoofd is gezien.......

...... de destijds gemaakte keuze voor IBM-producten komt vooral voort uit
toenmalige strategische architectuurkeuzes van de Belastingdienst voor een
aantal processen, waaronder de interne communicatie van de Belastingdienst
en de besturing van het ontwikkelproces......

...... eenmaal gemaakte en geimplementeerde architectuurkeuzes zijn in sterke mate
bepalend voor de te gebruiken software en het onderhoud daarvan. De IBM
software is nauw verweven met de IT-architectuur en op dit moment
noodzakelijk om de Belastingdienstprocessen te kunnen draaien. Dergelijke
keuzes werken altijd door op de lange termijn. Migratie naar nieuwe
architecturen is een zeer complexe, kostbare en risicovolle operatie. Uiteindelijk
is dit wel de weg die de Belastingdienst nu inslaat in het kader van de
vereenvoudigingsoperatie......

In deze brief van de staatssecretaris valt te lezen dat architectuur nu ook speelt en wordt herkend op topniveau. Maar we lezen tegelijkertijd dat architectuur op dit moment nog onvoldoende de complexiteit kan verlagen of beheersbaar maken.

6. Het resultaat onderzoek naar informatievoorziening en IT-Governance bij ministeries
(Bron: website van de rekenkamer, zoek op IT-Governance of download: http://www.rekenkamer.nl/9282000/d/ p387_tk30505_2.pdf)
We hebben onderzoek gedaan naar IT-governance bij de rijksoverheid. IT-governance is het bestuurlijk proces waarbij de top van de organisatie zich bij het inrichten van de informatievoorziening ook bezighoudt met de onderliggende technische voorzieningen, om zo tot een betere beleidsuitvoering te komen.
Voor dit onderzoek zijn we bij het Ministerie van Economische Zaken (EZ) en het Ministerie van Sociale Zaken en Werkgelegenheid (SZW) nagegaan hoe zij IT-governance in de praktijk brengen. Beide ministeries blijken volop bezig te zijn hun IT-governance vorm te geven en onderkennen dat het belangrijk is grip te hebben op hun informatievoorziening en ICT.

Aandachtspunten
Het doel van dit onderzoek is de verdere ontwikkeling van IT-governance binnen de rijksoverheid een impuls te geven. Het beschrijvingskader dat wij hebben ontwikkeld om IT-governance bij de Ministeries van EZ en van SZW in kaart te brengen kan daarbij een rol spelen. Ministeries kunnen het gebruiken om eventuele `blinde vlekken' in hun IT-governance op te sporen. Bovendien kunnen ministeries het gebruiken om in onderlinge discussies over IT-governance van elkaar te leren.
Voor de verdere ontwikkeling van IT-governance binnen de rijksoverheid zijn de volgende punten volgens ons cruciaal:
- Vermijd `blinde vlekken' bij de inrichting van IT-governance.
- Werk vanuit omgevingsbewustzijn.
- Zorg voor een goede aansluiting tussen beleid, organisatiestrategie en informatiestrategie.
- Beschouw het ministerie als een concern.
- Ontwikkel een gestandaardiseerde concern-informatiearchitectuur.
- Organiseer vraag en aanbod van de ICT-dienstverlening.
- Beschouw IT-governance als een groeitraject naar een permanent proces.
- Zorg voor leiderschap en centrale regie.

Reactie ministers
De minister van EZ en de minister van SZW hebben beiden laten weten zich te kunnen vinden in het rapport van de Algemene Rekenkamer. Beide ministers spreken hun waardering uit voor de aanpak van de Algemene Rekenkamer, die erop gericht is ministeries op weg te helpen bij het inrichten van hun IT-governance. Verder geven beide ministers aan structureler aandacht te zullen schenken aan de ICT-strategie binnen hun ministerie.

Reactie van Mark op dit onderzoek: In dit rapport staat veel goeds waar van ik we verwonder waarom ik er niet meer van in de praktijk terug zie. Bijvoorbeeld zoiets als een concern informatie architectuur waar men voor pleit.

7. Clinger Cohen
In Amerika is de Clinger Cohen Act onder andere in het leven geroepen om meer zicht te krijgen op de IT-investeringen. De regels van Clinger Cohen zijn:
- Plan major IT investments
- Revise processes before investment
- Enforce accountability for performance
- Use standards.
- Increase acquisition and incorporation of commercial technology
- Use modular contracting.

Met deze wet worden nu de grootste missers voorkomen, maar aanvullende regelgeving is toch nog nodig denk ik om echt het merendeel van de IT-projecten te laten slagen. En dat doe je niet alleen door minder IT-projecten op te starten.

8. Vragen en stellingen


Vragen
Op de volgende tien vragen zoek ik momenteel een antwoord:

1. Waarom mislukken IT-projecten bij de overheid in deze mate? Is dit in feite normaal of juist niet normaal? Wat is het problematische beheersaspect van een project: tijd, geld, kwaliteit, capaciteit, complexiteit, uitvoering of besturing? Waarom ziet men zelf geen oplossingen bij de overheid, die men dan ook succesvol implementeert? Waarom proberen we nu niet te leren van de projecten die wel zijn gelukt?

2. Waarom vinden we dat de overheid niet kan volstaan met het aanschaffen van standaard oplossingen? Waarom moet de overheid zoveel zelf (laten) ontwikkelen en bouwen aan IT?

3. Onderschatten we de complexiteit van de gemiddelde oplossing die we met een project willen realiseren?

4. Hebben we voldoende oog voor kwaliteit? Nemen we bijvoorbeeld voldoende de tijd om te testen?

5. Hebben we voldoende oog voor de menselijke maat bij het besturen en uitvoeren van projecten? Geven we de projectmedewerkers genoeg de ruimte om te kunnen excelleren? Een methode kan bijvoorbeeld ook teveel afremmen en inperken

6. Wordt er voldoende aan IT-portefeuillebeheer gedaan? Weten we welke projecten risicovol zijn? En wat doen we daar dan mee?

7. Wat zijn de gebruikte methoden, tools, technieken en certificeringen voor besturing en uitvoering van projecten bij de overheid? Hoe goed of strict wordt daarmee omgegaan?

8. Zijn we zorgvuldig genoeg in het maken van projectopdrachten, belanghebbenden analyses, SWOT-analyses, programma's van eisen, business cases, haalbaarheidsonderzoeken, plannen en impact analyses?

9. Wat zouden quickwins kunnen zijn in termen van principes en richtlijnen voor betere IT-projecten bij de overheid? Zou een soort project-principles-scan op de beheersaspecten van een project ons op korte termijn helpen?

10. Hoe kan architectuur van het te ontwikkelen systeem nog meer bijdragen aan het goed besturen en uitvoeren van projecten?


Stellingen
De volgende stellingen wil ik inbrengen:

1. Architecten dienen vaker als opdrachtgever of als projectleider op te treden om vanuit overzicht en inzicht een project te kunnen besturen.

2. Men is zich in projecten er vaak onvoldoende van bewust dat men soms helemaal niet conform een projectmethode werkt, maar hier juist sterk van af wijkt. Het ontbreekt vaak aan een early warning-system of iemand met overzicht die dit tijdig kan signaleren.

3. De traagheid van het nemen van beslissingen in overheidsorganisaties draagt niet bij aan het snel oplossen van problemen in projecten.

4. Goede architecturen, met A0-formaat-visualisaties die inzicht en overzicht bieden, dragen bij aan het beter besturen en uitvoeren van projecten. Architectuur kan namelijk zorgen voor beheersing en reductie van complexiteit en controle op kwaliteit.

5. De ambities van de politiek reiken soms kilometers verder dan de haalbare en realistische slagkracht van het ambtenaren-apparaat. De samenhang en afhankelijkheden van organisatorische bouwstenen en de ketens bij de overheid maken dat sommige veranderingen onmogelijk binnen enkele maanden gerealiseerd kunnen worden.

6. Vaak is een IT-oplossing geen echte oplossing voor een bedrijfskundig/organisatiekundig vraagstuk, maar een lapmiddel of symptoombestrijding. Men had beter niet het IT-project kunnen opstarten, maar aan de bedrijfskundige kant het probleem moeten proberen op te lossen.

7. Korte termijn IT-problemen los je doorgaans niet op met IT-architectuur maar wel met IT-governance.

8. Lange termijn IT-doelstellingen realiseer je doorgaans wel met IT-architectuur en niet met IT-governance.

9. Er bestaan geen IT-projecten. IT is altijd maar 1 van de vele domeinen in een projecten naast de domeinen mensen en organisatie.

10. De huidige gebruikte projectmanagementmethoden, -tools en -technieken passen onvoldoende bij de verschillende type overheidsorganisaties, de verschillende te ontwikkelen integrale systeemoplossingen en de verschillende te hanteren architectuurstijlen. Er dient een nieuwe hedendaagse methode te worden ontwikkeld.


Als u nog andere vragen of stellingen heeft die ons nog meer kunnen focussen in de richting van goede oplossingen, dan verneem ik dat graag.

Ik zie graag uw bijdrage in de vorm van principes, regels en richtlijnen vanuit architectuuroogpunt tegemoet.

Indien u wel wilt reageren, maar niet op dit forum, mailt u dan naar:
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

Post edited by: mpaauwe, at: 2007/09/07 15:07

Zeer goed initiatief van Mark om in deze discussie over overheidsarchitectuur een uitstapje te maken naar de wijze waarop de overheid haar projecten dient te managen.

Ik ben het in grote lijnen eens met de observaties en analyses van Mark. Ik had zelf ook al een dergelijke exercitie uitgevoerd ten behoeve van de Automatisering Gids. In de Automatisering Gids van 31 augustus stond een aandachttrekkend voorpagina-artikel: 'BV Nederland nog lang niet klaar is met ICT'. Een conclusie op basis van gesprekken met IT-ondernemers die door de redactie waren uitgenodigd alvast hun wensen uit te spreken richting Jan Peter Balkenende. Met als resultaat een nogal teleurstellend lijstje van 'Sinter Klaas'-wensen. Ik heb gemeend daar een reactie op te moeten geven in de Automatisering Gids van 7 september op pagina 12. Cruciaal daarbij is het lijstje van mijn adviezen aan Jan Peter Balkenende.

Advies 1: Herstel de IT-Governance en leg de overall regie neer bij het Ministerie van Algemene Zaken, dus binnen handbereik van JP zelf. Dit laat zien hoe belangrijk IT wordt gevonden.
Advies 2: Verbeter de NORA en scherp het verder aan. Architectuur is een noodzakelijk stuurinstrument voor de grootscheepse transformaties die de overheid moet doormaken naar een slanke, faciliterende, burgervriendelijke overheid.
Advies 3: Vereenvoudig de business processen door verregaande toepassing van IT, ook in de zorgsector.
Advies 4: Introduceer zakelijk programmamanagement. Verdeel programma's in kleine projecten, elk met een duidelijke businesscase, en pas benefit tracking toe tijdens realisatie.
Ten slotte nog drie adviezen waarop de informaticabureaus niet zitten te wachten:
Advies 5: Stop de 'uurtje-factuurtje'-relaties met externe bureaus, sluit alleen duidelijke resultaatverplichtingen af.
Advies 6: Stop met outsourcing. Zet de trend van het oprichten van shared services centra door, eventueel als joint ventures met externe providers.
Advies 7: Selectieve salarisverhoging van IT-personeel in overheidsdienst. De IT-problematiek bij de overheid is uitermate interessant. Salarisoverwegingen mogen geen beletsel zijn om bij de overheid te gaan werken. Deze maatregel kan zeer veel geld opleveren.

Deze zeven adviezen zijn de basis om de overheidsautomatisering weer gezond te krijgen. Daar bovenop kan dan echte innovatie starten.

Met deze zeven adviezen in het achterhoofd loop ik even langs de stellingen van Mark.

Stelling 1: Architecten dienen vaker als opdrachtgever of als projectleider op te treden om vanuit overzicht en inzicht een project te kunnen besturen.
Daan: Daar ben ik het absoluut niet mee eens. Een architect moet nooit op de stoel van de projectleider gaan zitten. Dat is een totaal andere rol met andere competenties. Ook is de architect niet de opdrachtgever, hoogstens speelt hij bouwheer namens de opdrachtgever.

Stelling 2: ... Het meeste geld wordt verdiend door mislukte projecten snel te stoppen.
Daan: Daar ben ik het roerend mee eens. Je ziet bij veel projecten, ook buiten de overheid, dat niemand de beslissing durft te nemen de stekker eruit te trekken terwijl het project in feite al lang is overleden.

Stelling 3: De traagheid van het nemen van beslissingen in overheidsorganisaties draagt niet bij aan het snel oplossen van problemen in projecten.
Daan: Die traagheid wordt veroorzaakt door de poldercultuur. Teveel deskundigen moeten meepraten over van alles en nog wat. Dat geeft je als projectleider het gevoel dat je probeert te rennen door een pot met stroop.

Stelling 4: Goede architecturen, met A0-formaat-visualisaties die inzicht en overzicht bieden, dragen bij aan het beter besturen en uitvoeren van projecten. Architectuur kan namelijk zorgen voor beheersing en reductie van complexiteit en controle op kwaliteit.
Daan: Helemaal mee eens! Als je geen overzicht hebt middels eenvoudige ontwerpschetsen kan je niet sturen. Kan je niet de consequenties overzien van mogelijke bijstuurmaatregelen.
Ik zie echter bitter weinig goede ontwerpschetsen of andere visualisatie op het niveau van de beslissers.

Stelling 5: De ambities van de politiek reiken soms kilometers verder dan de een haalbare en realistische slagkracht van het ambtenarenapparaat. De samenhang en afhankelijkheden van organisatorische bouwstenen en de ketens bij de overheid maken dat sommige veranderingen onmogelijk binnen enkele maanden gerealiseerd kunnen worden.
Daan: Dit geldt niet alleen voor de overheid. Ik zie dat ook bij grote commerciele instellingen. Er wordt in onvoldoende mate gerealiseerd dat de echte legacy zit in het gedrag van de medewerkers. We hebben het altijd zus en zo gedaan. Waarom moet het nu anders? Het kost tijd om een ingeslepen bedrijfscultuur te veranderen.

Stelling 6: Vaak is een IT-oplossing geen echte oplossing voor een bedrijfskundig/organisatiekundig vraagstuk, maar een lapmiddel of symptoom bestrijding. Men had beter niet het IT-project kunnen opstarten, maar men had aan de bedrijfskundige kant het probleem moeten proberen op te lossen.
Daan: Het oude adagio luidt: '(re)organiseer voor je automatiseer, anders automatiseer je de chaos'. Meer IT in een chaotische situatie werkt als het gooien van olie op het vuur. Zie ook mijn derde advies.

Stelling 7: Korte termijn IT-problemen los je doorgaans niet op met IT-architectuur maar wel met IT-governance.
Daan: Zie mijn eerste advies. Zet de IT-Governance krachtig neer!

Stelling 8: Lange termijn IT-doelstellingen realiseer je doorgaans wel met IT-architectuur en niet met IT-governance.
Daan: Daar hoort het verbeterde NORA om de hoek te komen kijken, zie mijn tweede advies.

Stelling 9: Er bestaan geen IT-projecten. IT is altijd maar een van de vele facetten in een project naast mensen en organisatie.
Daan: Dat is heel moeilijk voor de gemiddelde ITer. Dat vraagt dat hij/zij zich dienend gaat opstellen. Luisteren naar de echte behoefte.

Stelling 10: De huidige gebruikte projectmanagementmethoden, -tools en -technieken passen onvoldoende bij de verschillende typen overheidsorganisaties, de verschillende te ontwikkelen integrale systeemoplossingen en de verschillende te hanteren architectuurstijlen. Er dient een nieuwe hedendaagse methode te worden ontwikkeld.
Daan: Programmamanagement! Zie mijn vierde advies.

Resteert nog mijn adviezen vijf en zes die echt nodig zijn om het opdrachtgeverschap van de overheid te vereenvoudigen. En advies zeven is bitter hard nodig!

Adviezen bij grote (overheids)projecten

Als ik de grote overheidsprojecten die ik heb gedaan en de vele audits die ik heb afgenomen de revue laat passeren, kom ik tot het volgende lijstje adviezen:

1. Scope: Zorg voor een goede probleemdefiniering met een duidelijk contract. Saneer/rationaliseer desnoods eerst het business probleem alvorens tot automatisering over te gegaan.
Veel grote projecten starten als kleine projecten die groter groeien doordat alles en nog wat er tijdens het project aan wordt toegevoegd. Dat leidt meestal tot onmanagebare situaties.

2. Pas een strakke regie toe vanuit de opdrachtgever, ingebed in de IT-Governance.
Geeft de opdrachtgever een volwassen mandaat, pas op voor allerlei groepjes deskundigen die 'democratisch' willen meepraten: poldercultuur.

3. Elk project heeft een zakelijke business case.
Voorts hoort een programma/project te worden gestuurd op basis van 'benefit tracking'.
Durf mislukkingen tijdig te stoppen. Sommige overheidsprojecten zijn al lang dood, maar niemand durft de (politieke) verantwoordelijkheid te nemen om de stekker eruit te trekken.

4. Elk project/programma begint met een architectuur, met veel visualisatie voor het overzicht (Clinger Cohen act).

5. Elk project valt onder een gecertificeerd kwaliteitssysteem.

6. Gebruik een eenvoudige en transparante projectstructuur.

7. Selecteer een eenvoudige methodologie; duidelijke opsommingen van eenvoudig gedefinieerde (tussen)producten.

8. Gebruik uitsluitend bewezen tools en bewezen technieken.

9. Stel een eenhoofdige, zeer ervaren, nuchtere, zakelijke projectleider aan.
Bij veel overheidsprojecten krijgt je het gevoel dat je probeert te rennen door een pot met stroop, door de vele overleggremia. Dat is zeer vermoeiend.

10. Zorg dat het project volledig losgekoppeld is van de lijnorganisatie.
Je ziet bij veel grote projecten dat de lijnorganisatie zich er mee wil gaan bemoeien. Dat werkt zeer vertragend.

11. Zorg voor een 'losse' koppeling met stafafdelingen wat betreft regels en standaarden.
Grote projecten/programma's hebben de verleiding om allerlei nieuwe aanpakken, technieken en tools te gaan uitproberen. Deze nieuwe zaken worden dan ook nog vaak continue geevalueerd door stafafdelingen, die dan weer willen bijsturen in deze zogenaamde experimenten.

13. Gebruik met grote discipline een duidelijk audit schema:
- projectdiagnose voor dat het project begint;
- kwaliteitsinspecties, projectmanagement audits en product audits tijdens het project;
- projectevaluatie en systeem evaluaties na het project.

14. Inhuren van externe informaticabureaus alleen middels een resultaatverplichting.

15. Zorg voor een realistisch verwachtingsmanagement en pas veel PR toe.
Kijk uit voor politiek gekonkel.

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.