Als er gekeken wordt naar de verschillende soorten projecten en de vraag ‘in hoeverre de ict-sector hierin afwijkt ’ dan rijst de vraag of projecten te classificeren zijn. Dat blijkt mogelijk. Er zijn twee variabelen die in ieder type of soort project te herkennen zijn. Enerzijds spreekt men van projecten waar het 'doel' of 'product' duidelijk, of juist onduidelijk, gedefinieerd is. Anderzijds zijn binnen projecten de 'methoden van werken' of 'processen' duidelijk, of juist onduidelijk.
Om een onderscheid te kunnen maken tussen de verschillende typen projecten kan je een indeling maken op basis van methoden en gedefinieerde doelen. Het principe achter deze indeling is dat je deze punten als onderdeel naast andere meetpunten kan gebruiken om de kans te berekenen of een project het beoogde resultaat of gewenste effect kan halen. M.a.w. hoe beter de methoden en de doelen gedefinieerd zijn des te groter is de kans op voorspelbaarsucces. De meest voorkomende type projecten zijn dan als volgt te beschrijven:
Research en cultuurverandering
Dit zijn projecten waarbij de eisen en wensen van de gebruiker niet of nauwelijks concreet vast te leggen zijn. Deze moeten gedurende het project ontstaan.De projecten zijn tactisch of operationeel van aard en bij de start functiegericht. Bij dit type project is de betrokkenheid van de gebruiker beperkt. De uitvoering is voornamelijk in handen van specialisten. De techneuten doen het project zonder de gebruiker erbij te betrekken. Met een groot risico dat een resultaat wordt opgeleverd waar de gebruiker niet blij mee is en niet wil accepteren of gebruiken. Hiermee valt het project in de categorie mislukt. Het gewenste effect zal niet gehaald worden omdat de methoden goed gedefineerd zijn maar de doelen niet.
Productontwikkelprojecten
In dit type project is het doel goed gedefinieerd maar hoe dat doel te bereiken is vaak niet duidelijk. Hierbij kan gedacht worden aan productontwikkelingsprojecten die veelal multidisciplinair worden uitgevoerd. De doorlooptijd is een prioriteit omdat de 'time to market' bepalend is wat het project onder druk zet. Omdat er veel onzekerheden zijn over de methode van aanpak hebben deze projecten meestal eerst een functiegerichte aanpak. Dit soort projecten zullen door tijdsdruk concessies doen aan kwaliteit. Het doen van concessies in combinatie de vele onderzekerheden leiden vaak tot overschrijding van de afgesproken tijd en de daaraan gekoppelde kosten. Ook voldoet het eindresultaat meestal niet aan de klantverwachtingen. Het wordt niet geaccepteerd. Het project is daarom niet geslaagd. Het gewenste effect zal ook hier niet gehaald worden omdat de doelen en methoden niet goed zijn gedefinieerd.
Systeem ontwikkeling projecten
Kenmerkend voor dit soort projecten is dat er veel onzekerheden zijn: de ervaring met de uit te voeren werkzaamheden ontbreekt en de consequenties van de risico's zijn groot. Deze projecten laten zich slecht plannen en worden daarom vaak fase voor fase in detail uitgewerkt en gepland. De complexiteit is zeer hoog omdat soms nog vage ideeën concrete resultaten dienen op te leveren. Gezien de grote impact voor de gebruiker is zijn betrokkenheid het gehele project noodzakelijk. Dit is vooral herkenbaar in Research & Development projecten. De projectorganisatie en gebruikers moeten als het ware samen op pad om het gewenste resultaat te bereiken. Dit type project valt in een hoog categorie gehalte van mislukte projecten. De kans op slagen en om binnen de stuurkaders van scope, tijd, geld en kwaliteit te blijven is bij dergelijke projecten nihil. Ook hier zijn de doelen en methoden niet goed gedefinieerd.
Bouw en Engineering
Projecten zijn voornamelijk operationele projecten en worden ook wel klassieke projecten genoemd. Het zijn projecten met bekende aspecten die gestructureerd en volgens een vast stramien worden uitgevoerd.De projecten zijn over het algemeen product georiënteerd (PRINCE2 gedachte!) en de projectmedewerkers zijn door herhaling gespecialiseerd (juiste competenties !) in dit werk. Er zijn daardoor weinig onzekerheden en doordat de werkzaamheden al vaker zijn uitgevoerd is er een gedegen ervaring (geleerde lessen!) op basis waarvan de planning tot in de details van tevoren gemaakt kan worden. Ook zijn eventuele risico's qua kans en consequentie goed in te schatten en in te plannen. Vanwege veel standarisatie kan geconcentreerd gewerkt worden op efficiëncy. Deze projecten zullen de grootste kans hebben op succes. Daar zijn in de regel de doelen en methoden goed gedefinieerd.
Conclusie
Dan rijst het antwoordt op de vraag ‘in hoeverre de ict-sector afwijkt' met een ‘nee'. Het managen van projecten is in essentie gelijk ongeacht de sector waarin het project wordt uitgevoerd. In de praktijk blijkt wel per sector dat projecten verschillend worden ingevuld. Maar in alle gevallen is echter het projectbasisproces gelijk.
De oorzaak van projectfalen ligt (op basis van onderzoek) mijniziens dan ook op: een niet realistische en te maakbare business case, onvolwassen projectorganisaties, het ontbreken van veranderingsmanagement, niet methodisch werken of doelen stellen en niet in staat zijn om een en ander te beheersen en samen te vatten in een waterdicht contract. Uit onderzoek is gebleken dat bedrijven of projectorganisaties merendeel op de adhoc positie zitten met een beetje standaard (Pino, template management) en twee derde niet methodisch werken. Het geheel verklaart waarschijnlijk waarom projecten mislukken.
???
De Nederlandse publieke sector slaagt er nog steeds niet in om it-projecten tot een succes te maken. Ruim 80 procent van de grotere projecten kent budgetoverschrijdingen.
1 miljard minder klopt niet dus als je iets schrijft wees dan eerlijk en compleet. Mislukte (IT) projecten kosten de maatschappij wereldwijd 4,2 biljoen dollar, als je de indirecte kosten van mislukkingen meerekent. Dat komt overeen met bijna 9 procent van het bruto binnenlands product van alle landen opgeteld. Die schatting maakt Roger Sessions, een expert in complexiteitsvraagstukken. Om tot dat bedrag te komen moest Sessions natuurlijk de nodige aannames maken. Sessions gaat er, op gezag van cijfers van de World Technology and Services Alliance, van uit dat landen gemiddeld 2,75 procent van het bruto binnenlands product besteden aan hardware, software en diensten.
Om tot een schatting van het aantal mislukte projecten te komen gebruikt Sessions gegevens uit de Amerikaanse begroting. Daarin wordt geschat dat 66 procent van de investeringen in projecten met verhoogd risico zit. Sessions neemt vervolgens aan dat 65 procent van die projecten ook daadwerkelijk mislukt. Als die aannames kloppen wordt wereldwijd jaarlijks 825 miljard dollar geïnvesteerd via projecten die niets opleveren.
Maar deze verspilling geeft niet de volledige schade van mislukte projecten weer. Er is ook indirecte schade, zoals: het mislopen van begrote omzetten; de kosten van vervanging van het mislukte systeem; de tijd die binnen de organisatie verloren gaat door de problemen; en verlies aan marktaandeel. De indirecte schade zijn volgens Sessions een veelvoud van de projectkosten: hij schat dat de indirecte kosten de totale schade met een factor 7,5 opdrijven.
Er valt natuurlijk het nodige af te dingen op zijn cijfers. Je kan deze cijfers het beste zien als een poging om de omvang van het probleem van mislukkingen bij projecten inzichtelijk te maken. Zelfs als hij er 50 procent naast zou zitten, gaat het bij de directe kosten nog om een gigantisch bedrag. In NL wordt de kosten nu op 8 miljard geschat.
Maar stop nu eens met ICT projecten in een slecht daglicht te zetten!
Als er gekeken wordt naar de verschillende soorten projecten en de vraag ‘in hoeverre de ict-sector hierin afwijkt ’ dan rijst de vraag of projecten te classificeren zijn. Dat blijkt mogelijk. Er zijn twee variabelen die in ieder type of soort project te herkennen zijn. Enerzijds spreekt men van projecten waar het ‘doel’ of ‘product’ duidelijk, of juist onduidelijk, gedefinieerd is. Anderzijds zijn binnen projecten de ‘methoden van werken’ of ‘processen’ duidelijk, of juist onduidelijk.
Om een onderscheid te kunnen maken tussen de verschillende typen projecten kan je een indeling maken op basis van methoden en gedefinieerde doelen. Het principe achter deze indeling is dat je deze punten als onderdeel naast andere meetpunten kan gebruiken om de kans te berekenen of een project het beoogde resultaat of gewenste effect kan halen. M.a.w. hoe beter de methoden en de doelen gedefinieerd zijn des te groter is de kans op voorspelbaarsucces. De meest voorkomende type projecten zijn dan als volgt te beschrijven:
Research en cultuurverandering
Dit zijn projecten waarbij de eisen en wensen van de gebruiker niet of nauwelijks concreet vast te leggen zijn. Deze moeten gedurende het project ontstaan.De projecten zijn tactisch of operationeel van aard en bij de start functiegericht. Bij dit type project is de betrokkenheid van de gebruiker beperkt. De uitvoering is voornamelijk in handen van specialisten. De techneuten doen het project zonder de gebruiker erbij te betrekken. Met een groot risico dat een resultaat wordt opgeleverd waar de gebruiker niet blij mee is en niet wil accepteren of gebruiken. Hiermee valt het project in de categorie mislukt. Het gewenste effect zal niet gehaald worden omdat de methoden goed gedefineerd zijn maar de doelen niet.
Productontwikkelprojecten
In dit type project is het doel goed gedefinieerd maar hoe dat doel te bereiken is vaak niet duidelijk. Hierbij kan gedacht worden aan productontwikkelingsprojecten die veelal multidisciplinair worden uitgevoerd. De doorlooptijd is een prioriteit omdat de ’time to market’ bepalend is wat het project onder druk zet. Omdat er veel onzekerheden zijn over de methode van aanpak hebben deze projecten meestal eerst een functiegerichte aanpak. Dit soort projecten zullen door tijdsdruk concessies doen aan kwaliteit. Het doen van concessies in combinatie de vele onderzekerheden leiden vaak tot overschrijding van de afgesproken tijd en de daaraan gekoppelde kosten. Ook voldoet het eindresultaat meestal niet aan de klantverwachtingen. Het wordt niet geaccepteerd. Het project is daarom niet geslaagd. Het gewenste effect zal ook hier niet gehaald worden omdat de doelen en methoden niet goed zijn gedefinieerd.
Systeem ontwikkeling projecten
Kenmerkend voor dit soort projecten is dat er veel onzekerheden zijn: de ervaring met de uit te voeren werkzaamheden ontbreekt en de consequenties van de risico’s zijn groot. Deze projecten laten zich slecht plannen en worden daarom vaak fase voor fase in detail uitgewerkt en gepland. De complexiteit is zeer hoog omdat soms nog vage ideeën concrete resultaten dienen op te leveren. Gezien de grote impact voor de gebruiker is zijn betrokkenheid het gehele project noodzakelijk. Dit is vooral herkenbaar in Research & Development projecten. De projectorganisatie en gebruikers moeten als het ware samen op pad om het gewenste resultaat te bereiken. Dit type project valt in een hoog categorie gehalte van mislukte projecten. De kans op slagen en om binnen de stuurkaders van scope, tijd, geld en kwaliteit te blijven is bij dergelijke projecten nihil. Ook hier zijn de doelen en methoden niet goed gedefinieerd.
Bouw en Engineering
Projecten zijn voornamelijk operationele projecten en worden ook wel klassieke projecten genoemd. Het zijn projecten met bekende aspecten die gestructureerd en volgens een vast stramien worden uitgevoerd.De projecten zijn over het algemeen product georiënteerd (PRINCE2 gedachte!) en de projectmedewerkers zijn door herhaling gespecialiseerd (juiste competenties !) in dit werk. Er zijn daardoor weinig onzekerheden en doordat de werkzaamheden al vaker zijn uitgevoerd is er een gedegen ervaring (geleerde lessen!) op basis waarvan de planning tot in de details van tevoren gemaakt kan worden. Ook zijn eventuele risico’s qua kans en consequentie goed in te schatten en in te plannen. Vanwege veel standarisatie kan geconcentreerd gewerkt worden op efficiëncy. Deze projecten zullen de grootste kans hebben op succes. Daar zijn in de regel de doelen en methoden goed gedefinieerd.
Conclusie op het onderzoek
Dan rijst het antwoordt op de vraag ‘in hoeverre de ict-sector afwijkt’ met een ‘nee’. Het managen van projecten is in essentie gelijk ongeacht de sector waarin het project wordt uitgevoerd. In de praktijk blijkt wel per sector dat projecten verschillend worden ingevuld. Maar in alle gevallen is echter het projectbasisproces gelijk.
Het onderzoek en haar conclusies deel ik dan geheel niet. De oorzaak van projectfalen ligt (op basis van onderzoek) mijninziens dan ook op: een niet realistische en te maakbare business case, onvolwassen projectorganisaties, het ontbreken van veranderingsmanagement, niet methodisch werken of doelen stellen en niet in staat zijn om een en ander te beheersen en samen te vatten in een waterdicht contract.
Het postioneren van it-partners, consultantorganisaties met beperkte kennis van de processen is onjuist en stemmingmakerij.
Wat zegt nu een overschrijding van tijd, geld en haar consequenties? Misschien is er adequaat wijzigingsbeheer gevoerd die alle posten onvoorzien netjes hebben gecalculeerd en voorzien van extra tijd en budget? Misschien waren die overschrijdingen wel gecontroleerde overschrijdingen?
Anderzijds kan in een klant/leverancier relatie niet éénzijdig een controle of regiehouder zijn. Er altijd een onbalans tussen opdrachtgever en leverancier. Beide partijen hebben elkaar nodig. Opdrachtgevers hebben voor de ‘constante veranderingen’ leveranciers nodig. Leveranciers hebben op hun beurt opdrachten nodig. Het gevaar is dat beide partijen elkaar geen tegenwicht kunnen bieden. De opdrachtgever is geen volwaardige gesprekspartner, omdat specialistische kennis van de producten en juridische kennis ontbreekt. Andersom is voor de opdrachtgever het doen van projecten een unieke en eenmalige exercitie die niet valt onder de reguliere bedrijfscompetenties. Het niet hebben van kennis en eigen vrije interpretatie kan al leiden tot een ongewenste start van het project met alle negatieve gevolgen van dien. De verwachtingen en de realisatie kunnen hierdoor niet op elkaar aansluiten. Zolang we dit niet begrijpen zullen we nog decennia dit soort retoriek houden.
Groet,
John Roos