menu
Veel tijd en geld gaat er verloren aan het mislukken van IT-projecten, hoewel er gelukkig steeds meer slagen. In de media is veel aandacht voor de financiële gevolgen maar weinig aandacht voor de organisatorische, sociale en culturele dimensie. Klopt het bijvoorbeeld dat de overheid het alleenrecht heeft op IT-missers en presteert het bedrijfsleven zoveel beter? Zijn de immateriële kosten van de invoering van IT wel eerlijk verdeeld? Wie worden het vaakst de dupe van stress en overbelasting op de werkvloer, veroorzaakt door de kinderziektes en het gebrek aan beheersing van IT als vak? Wat zijn dat dan voor kinderziektes?
De bestaande literatuur noemt de globale conceptuele oorzaken voor het falen van IT-projecten: te grote complexiteit en slecht opdrachtgeverschap. Dit boek volgt en verklaart het stranden van projecten meer in detail, geïllustreerd door verhalen van betrokkenen en kranten- en tijdschriftenberichten, en doorbreekt daarmee een taboe. Hoewel techniek een niet onbelangrijke rol speelt, is dit boek goed te lezen voor een buitenstaander die wel eens wil weten wat er allemaal zo moeilijk aan IT is en waarom het vaak misgaat.
Carolien Schönfeld heeft meer dan twintig jaar ervaring in de IT, eerst als auditor en later als opdrachtgever van IT-systemen. Zij publiceerde een groot aantal artikelen over het onderwerp in verschillende tijdschriften zoals AutomatiseringGids, Binnenlands Bestuur en Informatie.
De subtitel is "Leren van pijnlijke ervaringen". Altijd interessant, zo'n boek over IT-mislukkingen, met de hoop om er iets nuttigs uit te leren; en leren van pijnlijke ervaringen heeft de sector altijd veel te weinig gedaan. In het voorwoord zegt de auteur dat het haar vooral gaat om de menselijke, organisatorische en sociale dimensie van ICT-projecten. Zeer interessant uitgangspunt, lijkt mij.
Dit boek is toch wel een aanklacht tegen het gebrek aan professionalisme in de sector, maar het wordt zo niet genoemd. Zwakke punten worden ruimschoots beschreven. Vermijdende maatregelen volgen wel hier en daar, maar enkel voor zover het probleem met projectmanagement te maken; het probleem van de "machten en eilandjes" (zie hoofdstuk 8) had voor mij wat meer belicht mogen worden.
Er worden in het boek regelmatig getuigenissen van anderen opgenomen. De auteur heeft de volledige zeggenschap hierover, dus mag je dergelijke getuigenissen gerust beschouwen als haar persoonlijke mening. In de bespreking hieronder wordt directe informatie uit het boek aangeduid als afgeleide inhoud of met "citaten". Ik bespreek elk hoofdstuk. Ook al geeft dit min of meer een samenvatting, het boek zelf blijft interessant leesvoer. Je kan het nog vinden in bibliotheken.
Alvast een goed begin. Een aantal feiten en waarheden passeren de revue:
– niet alleen IT-projecten falen; voorbeelden genoeg qua infrastructuurwerken;
– de mogelijkheid om op werk (en mensen!) te besparen is altijd aantrekkelijk, waardoor al te gemakkelijk aan projecten wordt begonnen;
– software is immaterieel, waardoor je er minder vat op hebt, zowel conceptueel als in projectopvolging;
– er zijn verschillende vormen van mislukken (te duur, te laat, minder tot helemaal niets opgeleverd, …);
– leren van fouten, zeker openlijk, blijft zeldzaam;
– publicaties alom over mislukte projecten; de Standish Group maakte er zijn specialiteit van (allicht goed voor de Standish Group, maar de faalcijfers blijven wel stabiel…);
– voornaamste problemen: te grote complexiteit, te grote ambitie, slecht opdrachtgeverschap, onvolwassen producten en een onvolwassen markt.
Ik voeg er zelf nog een paar oorzaken van problemen aan toe:
– programmeren is leuk;
– met de volgende versie van dit systeem zal het zeker beter gaan;
– we gaan toch geen oude technologie meer gebruiken…(wel de horizon achterna hollen)?
Hier worden de grote lijnen beschreven van een mislukt project waarin de auteur betrokken was als projectleider. Klassieke fouten. Niet echt relevant; mogelijk is dit project uiteindelijk een aanleiding geweest om het boek te schrijven.
In de inleiding wordt de ontwikkeling van een informatiesysteem vergeleken met het ontwerpen en bouwen van een gebouw. Eerst een business case definiëren, dan een ontwerp maken en aftoetsen …?! Geen sprake van "agile" hier; de term staat niet eens in de index achteraan… Interessant.
Het doel van IT-projecten is een ondersteunend geautomatiseerd systeem te bouwen waarin de wensen en ideeën die de organisatie heeft voor het verbeteren van haar processen, producten en/of diensten, met behulp van IT worden gerealiseerd. – Dit is niet ongewoon geformuleerd, maar de stelling is wel veel te simpel. In realiteit zijn er nog meer doelen, gebaseerd op de (vooral persoonlijke en evoluerende) wensen en ideeën van iedereen die bij de uitvoering van het project betrokken is, van programmeur tot opdrachtgever (eindgebruikers nauwelijks), en het zijn net die bedekte doelen die ervoor zorgen dat de ICT-industrie vooral zichzelf bedient. Menselijk, allicht, maar niettemin nefast, en het wordt tijd dat we dat eens inzien; dit aspect komt verderop nog aan bod.
Betrokkenen:
– Alle soorten eindgebruikers moeten bij het project betrokken zijn, omdat ze elkaars werk doorgaans weinig of niet kennen. > Zeer terechte opmerking.
– Opdrachtgevers mogen belangrijke beslissingen niet overlaten aan ICT'ers. > Die laatsten hebben daar overigens zelf doorgaans geen probleem mee. (Te) Veel invloed van ICT is echter nooit goed, omdat ICT andere belangen heeft dan de opdrachtgever. Met de "agile" stroming neemt die invloed wel nog toe, vermits meer beslissingen door het ontwikkelteam genomen worden.
– Projectleiders: niets schokkends hier.
– Leveranciers (ICT-bedrijven) verliezen aan machtspositie; meerwerk wordt niet meer automatisch geaccepteerd.
Samenwerking en communicatie – De auteur vermeldt de verzuchting van projectleiders "dat het lijkt alsof IT-collega's gemakkelijk dezelfde beelden delen, en dat het moeilijk, zo niet onmogelijk is, om met 'leken' te communiceren"… Ontbreekt er nog steeds een gemeenschappelijk taal? Ik vrees eerder dat de IT-industrie nog steeds niet geleerd heeft te spreken in de taal van de leek. IT'ers slagen er nog steeds in zich te wentelen in hun eigen technologische wereld, in plaats van te zien wat ze met slechte systemen aanrichten in de maatschappij. Projectmanagementtechnieken veranderen daar weinig aan (ze versterken vooral command-and-control, zeker als ze zonder interpretatie worden toegepast). En nee, ook de "agile" methoden hebben dit niet opgelost; integendeel, daarmee doen IT-ers nog meer hun zin. De klassieke cartoon met verschillende visies op een schommel aan een boom is hier wel op zijn plaats.
Systeemontwikkeling door de jaren heen – In grote lijnen: tot 1970 eenvoudige systemen, 1970-1990 het gebruik van ontwikkelmethoden (waar in Nederland vooral PRINCE2 van overblijft), daarna systeemontwikkeling als een sociaal proces. Hier zegt de auteur "Systeemontwikkeling is een proces van informatie-uitwisseling en besluitvorming van mensen onder elkaar. ICT komt pas in beeld wanneer er een uitkomst is van dat proces.", en hier schiet ze er dus glad naast. De dwingende rol van de ICT-industrie ("we moeten allemaal digitaliseren") wordt hier niet onderkend. Jammer dan dat dit aspect allicht ook verder niet aan bod zal komen.
Terecht wordt aangehaald dat ook PRINCE2 veel interactieaspecten niet afdekt, omdat "haken en ogen blijven kleven aan het invullen van de verschillende rollen". De auteur lijkt te suggereren dat een correcte invulling van rollen veel problemen vermijdt, maar tegelijk geeft ze toe dat "mensen ongelooflijk inventief zijn in het dienen van hun eigen belang". De auteur beschrijft verder op een heel realistische manier de dynamiek van de omgeving, de rol van de informatiearchitect, de omgang met risico's, het te veel aan projecten in één organisatie; bijvoorbeeld de gevolgen van het feit dat ICT-leveranciers ontwerp en bouw combineren, terwijl deze functies in bouwprojecten gescheiden zijn.
Veelbelovend, vermits de auteur een mislukt project beschreef waar ze projectleider was…
Belangrijk element: "problemen constateren en slecht nieuws brengen is nooit plezierig, dus zullen projectleiders en andere betrokkenen dit zo weinig mogelijk doen". Dit is wel in de roos. Dit aspect heb ik nog in geen enkel project weten aanhalen, maar het is wel essentieel; slechte communicatie over negatieve aspecten genereert altijd problemen (en positivisme versterkt dat fenomeen).
Affiniteit en kennis van de opdrachtgever – Veel leidinggevenden en bestuurders zijn nog niet mee met de ICT-tijd, (maar of dat slecht is weet ik nog zo niet) en het vakgebied is nog niet uitgekristalliseerd zoals HR en financiën (en dat is flauwe kul). Mensen met een ICT-achtergrond dienen vooral de ICT-industrie (omdat ze ervan leven), en het vakgebied heeft lang genoeg tijd gehad om te kristalliseren, maar dat gebeurt net niet omdat opdrachtgevers en ICT verschillende belangen hebben (wat met HR en financiën niet het geval is), en de technologie zich steeds verder ontwikkelt. Ook de rol van de eindgebruikers blijft problematisch. De auteur citeert een getuigenis van een bestuurder die het probleem onderkent, maar ook twijfelt "of je het wel altijd goed te horen krijgt van de gebruiker". Ook hier weer: slecht nieuws brengen is moeilijk, en positivisme maakt dat nog erger; wat meer aandacht voor de negatieve kantjes zou veel problemen vermijden.
De stuurgroep – Ook hier weer een terecht standpunt: alleen de opdrachtgever zou de beslissingen moeten nemen; immers: "… de stuurgroep als besluitvormend orgaan moet je bestrijden; dat zijn veelkoppige monsters, waarin ieder probeert zijn eigen stoepje schoon te vegen". Of nog: "in zo'n vergadering zonder goede leiding, waar moeilijke beslissingen moeten genomen worden op basis van een groot aantal onzekere factoren, heerst een negatieve sfeer van onduidelijkheid, angst voor verantwoordelijkheid, en de neiging om géén beslissingen te nemen". Ik voeg hier graag aan toe dat sommige typen zich in dergelijke situaties wel goed voelen, en het voortouw nemen, en de boel in hun richting gaan sturen. En het zijn doorgaans niet de meest bedachtzamen, niet de denkers, maar wel de doeners, die vinden dat een slechte beslissing beter is dan geen, en van anderen vragen dat ze niet met problemen afkomen, maar wel met oplossingen… De wereld zou gebaat zijn met een methode die persoonlijke invloeden kan uitsluiten, in (project)management, en vooral ook in politiek (in feite ook een kwestie van "stuurgroepen").
Wat als we politiek bestuur ook eens gingen zien als projectmanagement? Of er nu een bedrijf moet bestuurd worden, of een land, dat is toch ongeveer hetzelfde? Ik zie ineens heel veel parallellen, zowel in de positieve als de negatieve aspecten. Als we projecten in bedrijven beter kunnen besturen, bv. door de invloed van persoonlijke kenmerken van managers beter te beheersen, dan kan dat misschien ook in de politiek?
De projectleider – Hier klinkt iets door van het voorgaande; "… men denkt dat een projectleider die zich als een ondernemer gedraagt meer aandacht heeft voor het bedrijfsbelang, en beter is in het creëren van draagvlak onder de stakeholders". Eigenlijk is het vrij duidelijk: het werkt allemaal beter als de bedrijfsdoelstellingen collectief worden nagestreefd, in plaats van persoonlijke doelstellingen. Die laatste vergen van projectleiders extra competenties op het vlak van communiceren en onderhandelen, en juist daar liggen de meeste valkuilen. Als de nood aan "soft skills" kan beperkt worden, wordt het project er alleen maar beter van; meer duidelijkheid, minder complexiteit.
Klanttevredenheid in de ICT-sector – Mooie vergelijking: "een Amerikaans onderzoek constateerde dat automatisering betreffende betrouwbaarheid lager scoort dan de tweedehandsautomarkt". De eeuwige keuze tussen standaardpakketten (die doorgaans niet volledig passen) en maatwerk (met de nodige communicatieproblemen) knaagt aan de tevredenheid.
Leveranciers-enthousiasme voor nieuwe technologie – "Leveranciers zijn enthousiast over de nieuwste kunsten van de technologie en vragen zich soms te weinig af of die technologie al betrouwbaar is en of ze wel past op de situatie". Nagels met koppen geslagen.
Misplaatst optimisme – Leveranciers gaan soms dumpen om bij een klant binnen te komen, zeker als ze weinig werk hebben, wat gemakkelijk resulteert in een gevaarlijk verschil in verwachtingen tussen leverancier en klant.
Lageloonlanden als 'customer intimacy' essentieel is? – Communicatie met programmeurs in bv. China of India kan enkel met tussenstappen die problemen creëren.
'Lessons learned' aan de leverancierskant – Het kan gebeuren dat een klantorganisatie zelf niet genoeg ontwikkeld is om een project goed te beheren. Met een methode als CMMI kan een leverancier dat zelf ontdekken. Of hij dan het project weigert bij een slecht cijfer is weer iets anders.
Een speciale klant: de overheid – De overheid is qua behoeften niet anders dan een niet-overheidsorganisatie. Typisch is wel de sterke verdeel- en heerscultuur (in de zin van command and control), en het feit dat de overheid het geld van de burger uitgeeft, terwijl die laatste geen zeggenschap heeft over die uitgaven. Door het stimuleren van grote ambitieuze projecten roepen leveranciers zelf de risico's over zich af. Ja, dat geloof ik best. Maar ik volg de auteur dan weer niet als ze zegt (of laat zeggen door "het bedrijfsleven" ;-) dat de overheid te weinig visie heeft op innovatie. Een onvolwassen sector sponsoren, is dat innovatie? Ik dacht het niet. Zo zie je maar hoe een verwrongen idee zelfs bij kritische deelnemers kan wortel schieten.
Interessante inleiding over de flexibiliteit van softwaresystemen. Gemakkelijk te parametriseren, maar eens geparametriseerd zijn ze als in beton gegoten. "Business rules" zijn hier een (deel van de) oplossing, maar dergelijke systemen komen blijkbaar moeilijk van de grond.
De houvast van een duidelijke business case – Keiharde voorwaarde voor succes: een goede, door iedereen gedeelde beschrijving van de projectdoelen, waar ook regelmatig naar wordt gekeken. Zie ook mijn opmerking daarover bij hoofdstuk 3. Probleem is dat het voortschrijdend inzicht niet noodzakelijk slecht is, maar dat het zo verschillend is bij alle deelnemers, ook als de projectdoelen goed beheerd zijn. Plus het feit dat ICT-leveranciers graag ingaan op wijzigingen, omdat die geld opleveren.
Standaardisatie – Technische standaardisatie verloopt deels geregeld, deels spontaan (zoals het internetprotocol TCP/IP). Ook gegevensstandaardisatie is nodig, om verschillende systemen met elkaar te laten communiceren.
Het delen van kennis- en informatie-databases – Hier gaat het in feite over het standaardiseren van gegevensbanken voor bv. bibliotheken, het elektronisch patiëntendossier. Centrale initiatieven slagen niet altijd, zoals bv. met Esperanto. Onbegrensde verzameling van gegevens is mogelijk, maar juist door de onbegrensde beschikbaarheid van ICT zijn er op veel gebieden kennelijk al te veel ontwikkelingen om centrale actie nog succesvol te maken. […] In de praktijk zullen de verschillende databases wel degelijk naar elkaar toe blijven groeien. Dat eerste ja, dat tweede betwijfel ik sterk. Zoiets gaat ongetwijfeld gepaard met strijd en verlies; als er geen centrale actie is, overwint de sterkste. Voorbeelden genoeg (FaceBook, Amazon, Google, …).
Standaardiseren van processen – Informatiesystemen dwingen gebruikers, zeker in grote organisaties, tot een gestandaardiseerde manier van werken. We staan er veel te weinig bij stil hoe moeilijk het voor mensen is om hun autonomie te verliezen en hun werkwijze te veranderen. Zie je wel dat ICT een grote bron van stress is! We verhogen het abstractieniveau van het proces […] en vergeten dat goed te begeleiden. Verhoging van het abstractieniveau is altijd verlies van controle (en dus bron van stress); begeleiding verhelpt daar niets aan. En hoe hoger geschoold de gebruikers (juristen, medici, …) hoe moeilijker de standaardisering.
Standaardpakketten vs. maatwerk – Zelfde probleem: standaardpakketten zijn goedkoper (economischer!) maar moeilijker in te voeren (omdat de processen meestal moeten aangepast worden). Goed beschreven, met enkele voorbeelden erbij. Standaardisatie blijft meestal nodig, maar pakketten kunnen ook hoe langer hoe meer, dus de gaten in de functionaliteit worden kleiner. Standaardisatie-organisaties (bv. ISO, of overheden) zouden dit proces in verschillende sectoren kunnen vereenvoudigen door standaard bedrijfsprocessen te definiëren; dan kunnen enerzijds de klantorganisaties zich daar geleidelijk aan aanpassen, terwijl de pakketleveranciers hetzelfde doen. Op die manier zou informatisering met minder botsingen en kosten kunnen gebeuren.
"Open source" en "open standaard" – Wat het verschil is wordt niet uitgelegd… Ik heb de indruk dat men hier met "open source" ook "open standaard" bedoelt, te zien aan het betoog. Dat is wel iets anders dan open source software zoals Open Office kantoorapplicaties, of courante CMS-systemen als WordPress. In feite komt dit dus ook neer op het ontwikkelen van standaard bedrijfsprocessen, zoals hierboven bedoeld.
In de inleiding al dadelijk een kritische noot over het positivisme dat vanuit "business schools" doordrong in organisatiewetenschappen en informatiekunde. Positivisme, of de weigering om het negatieve onder ogen te zien, is een belangrijke oorzaak van de inflatie van veel belangrijke aspecten in de samenleving, zoals economische inflatie, groeiende ongelijkheid en de klimaatproblematiek. Door negatieve aspecten te negeren mis je ook de zelfstabilisatie in sociale systemen.
Een positivistisch model – Het is onduidelijk wat in deze sectie wordt bedoeld; er is geen verband met de inleiding.
Phronisme vs. positivisme – De Engelstalige Wikipedia biedt meer uitleg bij phronesis. In het kader van ICT-projecten zijn niet-phronetische elementen als het "strategisch verkeerd voorstellen van zaken" (of dus liegen), en "uit optimisme een verkeerde inschatting maken" (of dus misplaatst optimisme) de belangrijkste mechanismen waardoor foutieve informatie aan beslissingnemers wordt verstrekt.
De groep of het individu als schuldigen – Typisch in "westerse" organisaties is dat er bij een mislukking doorgaans gezocht wordt naar een schuldige (individu of groep). Typische kortzichtigheid, en vooral gebrek aan systeem- en procesvisie. Niemand is "schuldig"; wat gebeurt is altijd een gevolg van een proces, met een bepaalde input. Zie ook "A life in error).
De uitdagingen van het vak – Het is niet al goud wat blinkt. In de realiteit zijn er dikwijls mislukkingen. Het is moeilijk dat te begrijpen en het je niet persoonlijk aan te trekken. Bij ICT-projecten is sprake van wel erg veel externe en moeilijk te beïnvloeden factoren, waardoor ze vaker mislukken of onbevredigend aflopen.
Evaluaties en audits: post-mortem analyse – Je evalueert projecten om er iets van te leren. Met ICT leren veel organisaties hoe ze beter kunnen falen... "In de ICT is men het gewend dat dingen misgaan, of maanden te laat zijn, of niet werken". Verder volgen uit enkele voorbeelden een aantal nuttige tips. Veel geslaagde projecten blijken gebaseerd te zijn op wat geleerd is uit eerdere mislukkingen. Een gezonde dosis negativisme kan hier wonderen verrichten.
Second opinion, gateway review – Hier wordt een interessante controlemethode beschreven, waarin een opdrachtgever zijn project laat evalueren door verschillende mensen op gelijkaardige posities uit andere bedrijven. Je krijgt dan een onafhankelijke kijk, en iedereen leert ervan. Engelse rapporten vermelden een besparing van 3% op ICT-uitgaven, terwijl de methode zelf amper 0.01% daarvan uitmaakt.
Beter ten halve gekeerd – … dan ten hele verdwaald, zegt het spreekwoord. De definitie is eigenlijk simpel: als de business case niet meer geldt (m.a.w. als er geen toegevoegde waarde meer is) moet het project gestopt worden. Dan moet je wel de business case in de gaten houden (wat zowiezo goed is voor elk project). Struikelblokken in dat proces: de misvatting van de gezonken kosten, de aversie tegen verlies, en groepsdenken (zie ook The stupidity paradox en The intelligence trap).
Wie krijgt het vaakst de zwarte piet? – De internen natuurlijk; externen beginnen alsof er niks verkeerd gebeurd is elders aan een volgend project.
De gewaarschuwde organisatie: het belang en de baten van het leren – Er is veel aandacht voor de "lerende organisatie", maar dat lijkt weinig verschil te maken. Volgens mij komt dat door een gebrek aan negativisme. Als je niet wil of durft zien wat er niet deugt, dan leer je ook niet om zoiets te vermijden.
De auteur heeft veel kennis van en ervaring met de Nederlandse overheid in het kader van ICT-projecten. Met een gezonde dosis negativiteit wordt hier in feite een goed overzicht gegeven van wat er zoal mis kan gaan bij grote projecten. Te veel om in detail te bespreken, maar interessant genoeg om de kern te verwoorden:
– Nederland is goed op ICT-vlak, vergeleken met de rest van Europa. Bedrijven hebben niet minder mislukkingen, maar kunnen die wel beter verstoppen.
– Het gaat om grote projecten met hoge eisen.
– De overheid lijkt een geheel, maar is dat zeker niet.
– Politiek en wet dicteren, soms tegen praktische of organisatorische benaderingen in.
– De overheid moet verantwoording afleggen, wat de ondernemingslust beperkt.
– Ketens van organisaties vergroten de complexiteit.
– Verantwoordelijkheid is meestal verspreid.
– Rigide besluitvorming belemmert correcties.
– Heel andere economische afweging dan bij bedrijven.
– Zware aanbestedingsprocedures.
Elk van die punten wordt in het boek verder uitgewerkt. Hieronder nog enkele opmerkelijke gevallen.
– Het voorbeeld van het project P-Direkt is interessant; dit gaat over het centraliseren van de personeelsadministratie voor alle ambtenaren. De auteur zet de tendens in de media ("sabotage", "miljoenenverlies geen probleem") tegenover het feit dat men te veel ineens wilde realiseren (uniformiseren én centraliseren; was beter apart gebeurd, in die volgorde). De weerstand van de betrokkenen wordt m.i. te veel gezien (en hier ook beschreven) als sabotage en gebrek aan "draagvlak", en te weinig als een aspect dat in het te ontwikkelen systeem en in het projectmanagement moet geminimaliseerd worden. Verlies van controle is immers een belangrijk aspect in het ontstaan van de burn-out problematiek (zie ook het boek Systems thinking in the public sector). De tweede uitvoering van het P-Direkt project is wel gelukt, maar de negatieve commentaren op het resultaat zijn toch niet mals. De auteur wijt een deel van de problemen aan de invloed van de vakbonden, en verder lijkt het erop dat de besparing in mankracht neerkomt op minder efficiënt werken voor de resterende ambtenaren. En ook dit is weer een interessant aspect: meetbare grootheden als besparingen spelen een veel grotere rol in beslissingen dan onmeetbare grootheden als (verminderd) welbevinden van werknemers of het (bedenkelijke) nut voor de maatschappij (zie ook Managerialisme en burn-out)
– Ook het voorbeeld van de politie toont weer aan dat informatisering beter niet gezien wordt als een oplossing voor problemen die niets met informatisering te maken hebben (in dit geval i.v.m. de invoering van een nationale politie). Zeer dikwijls, en zeker in grote projecten, zijn er dergelijke achterliggende motieven, die doorgaans vermomd worden als economische of ICT-argumenten, en dan weet je in feite al dat het niet goed komt. En zelfs als het wel "goed" komt, m.a.w. het project volledig wordt uitgevoerd, was je waarschijnlijk beter af geweest met een ander project, of helemaal zonder. Maar dát aspect is nu net zo moeilijk te meten, en dat heeft geleid tot een ICT-sector die groter is dan goed is voor de maatschappij. Hoog tijd voor een gelukseconomie?
– Het voorbeeld van de gemeente Amsterdam is de kers op de taart. Versnipperd bestuur, drijvend op en gedreven door politieke spelletjes, en dan willen informatiseren… Stop ermee. Eerst de rommel uitkuisen in processen, dan pas informatiseren.
– Een systeem dat moet voldoen aan een bepaalde wetgeving, kan niet beter zijn dan de wetgeving zelf. Dit kan m.i. pas verbeteren als de wetgeving in bedrijfsregels wordt gegoten.
– De uitvoering zit vaak gekneld in het beleid. Een politieker wil scoren met beleid en zorgt voor budgetten, en de uitvoering moet dan maar kunnen volgen, hoewel dat vaak niet realistisch is.
– Het "taaie ongerief" zit niet in de concepten, maar in de machten en eilandjes.
– Politieke wil is vele malen groter dan echte aandacht voor projecten.
– Waar met budgetten gewerkt wordt, worden budgetten altijd overschreden.
Dit is een verderzetting van hoofdstuk 8, specifiek op het vlak van beveiliging en privacy.
Er mislukt nog altijd veel. We blijven geconfronteerd met te grote ambities, ontoereikend opdrachtgeverschap en een door innovaties en gebrek aan standaardisatie onrustige en ondoorzichtige markt. Het belangrijkste instrument dat daar tegenover kan gesteld worden is een goede voorbereiding. Lessen trekken uit het verleden (dat gebeurt doorgaans wel, na de ondergang), de leerpunten serieus nemen (da's iets moeilijker), en de geschiktheid en rijpheid van de eigen organisatie onderzoeken vóór de uitvoering van een project (en dat gebeurt veel te weinig omdat daardoor posities in het gedrang komen; zie ook The stupidity paradox en The intelligence trap). De technieken zijn er nochtans: "health-check" vooraf, "gateway-peer-reviews" en ICT-haalbaarheidstoets.
Maar één en ander gaat veel te traag. Cybersecurity is ondermaats, slecht opdrachtgeverschap bij grote organisaties blijft een probleem, en projectmanagementmethoden worden vaak louter als checklists gebruikt. Standaarden worden niet gebruikt, de macht van leveranciers is te groot, en onafhankelijke functies krijgen geen kans. Leveranciers zien zich nog te veel als renderende onderneming dan als dienstverlener. De negatieve rol van politieke haast en ambitie is veel te groot.
Mijn eigen bedenkingen:
– (1) Hoe groter een project, hoe groter de kans op "machten en eilandjes" die niet zomaar op elkaar af te stemmen zijn. (2) Er wordt op voorhand te weinig nagedacht over de definieerbare en ondefinieerbare risico's, waardoor een vacuüm ontstaat waarin later extra middelen verdwijnen. (3) Er is altijd wel een ICT-leverancier bereid om van dat vacuüm gebruik te maken om diensten te leveren en vooral te factureren.
– In de ICT-sector ontwikkelen verschillende spelers hun eigen producten (computers, netwerken, …) en methoden (softwareontwikkeling, projectmanagement, …) om toch maar hun eigen deel van de markt te veroveren. Gezien het gebrek aan standaardisatie kiest elke klant voor het systeem of de leverancier waarbij hij zich goed voelt. De versnippering die zo ontstaat creëert uiteraard technische en organisatieproblemen bij de ontwikkeling van overkoepelende systemen zoals die van de overheid. Diezelfde overheid zou nochtans standaarden kunnen opleggen of minstens promoten.