Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Wijkt de ICT-sector af bij 'mislukte projecten'?

Computable Expert

John Roos
Programmamanager Npo Security Iso, GEMEENTE PIJNACKER-NOOTDORP. Expert van Computable voor de topics Management, Digital Transformation en Maatschappij.

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.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Lees een prince2 boekje, kijk wat rond in enkele bedrijven en je komt tot dezelfde conclusie.

John,
Interessante beschouwing en heel herkenbaar. Als je dezelfde beschouwing nu eens doet vanuit een project sturing perspectief. Kom je dan tot dezelfde conclusie?

Praktijk in de ICT laat her en der toch wel progressie zien in methodisch werken in de uitvoering. Echter in de sturing van projecten is zelfs Pino vaak nog een brug te ver. Herken je dat?

Het is herkenbaar omdat het een open deur is :-)

Prince2 toetst na elke fase de resultaten aan de Business Case EN laat geeft de vrijheid om zelf de fases in te delen. Risico is dus tot minimum beperkt. In het ergste geval staakt men het project (precies op tijd).

Prince2 projecten falen dus omdat de Business Case niet goed is opgesteld en/of men de methode niet goed volgt en uitvoert.

Interessant artikel en inderdaad herkenbaar. Heb wel vaker gezien dat Pino gehanteerd wordt, dan weet de projectleider nog net een PID te maken i.p.v. een PVA, maar wat een Project Board is, dat weten ze soms niet eens. Dat is toch wel vreemd, ik heb ook ooit eens 'de kleine Prince 2' gelezen, en ik als techneut weet het wel.

Misschien dat naast een Prince 2 certificaat een IPMA-C of B toch wel handig is. Heb ook samengewerkt met projectleiders die IPMA gecertificeerd waren of hier mee bezig waren, en over deze PL's was ik tevreden. Het kan natuurlijk toeval zijn, met mijn beperkte waarnemingen. Misschien hebben anderen hier nog interessants over op te merken?

Beste Opendeur (leuke naam) en Harry,

Natuurlijk is het een open deur en conclusie. Het gaat erom wat je bewust ermee doet en onderdeel maakt bij de vraagstelling moeten we dit project nu wel doen?

Uit eigen (master) onderzoek blijkt dat onder de 200 onderzochte bedrijven dat zij onvolwassen zijn of een beetje gestandaardiseerd. E.e.a wordt nog eens versterkt daar 66% niet methodisch werkt.

Dus praten over PRINCE2 of andere smaken heeft dus geen zin. En ja we weten het. We lezen het. Maar we leren er niet van. De projecten zijn gewoonweg niet te rechtvaardigen. Het is niet realistisch. We laten het maakbaar maken.

Je kan bovenstaande beschouwen als onderdeel of afweging of het project te besturen of te beheersen is. Met dergelijke uitkomsten denk ik van niet. Projecten zullen dan ontaarden in brandhaarden waar de PM als een brandweerman probeert te redden wat er te redden valt. Het resultaat zal er wel komen maar de nevenschade op tijd, budget of kwaliteit zullen groot zijn.

Dergelijke projecten vallen dan in de categorie 'mislukt'. Een vakman zou dan in de embryonale fase van een dergelijk project 'nee' moeten zeggen op basis van argumenten.

Tegen onze kinderen zeggen we ook nee als ze nog niet volwassen zijn om alleen over de wereld te zeilen of naar Salou te gaan. Al die kinderen hebben een mooie en maakbaar gemaakte business case. Maar als ouder en deskundige maken we een keus op basis van realiteit, vermogen en volwassenheid. En als ze mogen dan zijn er maatregelen getroffen om het realistisch te maken.

Pas dergelijke aanpak ook eens toe bij bedrijven en haar projecten. Ik zie procesmatige beoordeling tussen thuis en werk geen verschil.

John Roos







John,

Dan kom je precies waar het pijn punt zit; er wordt geen NEE verkocht/geaccepteerd door de business. Mogelijk kunnen wij (als ict-ers) het niet goed onderbouwen en wordt de business case niet goed opgesteld, maar mijn ervaring is dat als de business erom vraagt, de business het ook krijgt. Projecten worden niet tussentijds (netjes; op basis van het niet meer halen van de business case) gestopt.

Tja, het artikel is idd geen open deur in de zin dat er nog zoveel projecten mislukken. Kennelijk moet het nog een keer uitgespeld.

Maar zoals aftervillage hierboven ook aangeeft, Business geeft gewoon een opdracht en zoekt iemand die altijd JA zegt tegen de Case.
Zelfs je kinderen zullen waarschijnlijk iets proberen in trant van : "van mamma mag het wel"..

Open deur,

Als we geen 'nee' meer durven te zeggen dan houdt het op. Dan hoeven projectmanagers niet meer op cursus. We hoeven alleen maar op 'ja' knikkers te selecteren of iedereen een vrijbrief geven. Leve de lol!

Maar in onze organisatie hebben we gelukkig nog de taken, verantwoordelijkheden, bevoegdheden en autoriteit goed belegd. Als het niet realistisch is en onvolwassen dan stemmen we niet toe.

Business case is prima benadering, maar wanneer is de rationale/rekensom zuiver en volledig? Hoe stel je objectief (moeilijk genoeg), vast of de benefit & kosten wel realistisch is geraamd qua hoogte en duur? Veel benefit componenten zijn ook erg lastig te kwantificeren. Ook de financiële interpretatie is belangrijk (netto contante waarde). Hoe stel je vervolgens vast per jaar wat de daadwerkelijke hoogte van de benefit is per jaar (benefit tracking) -dat toe te rekenen is aan het slagen van het project? Pas na verstrijken van de terugverdien tijd "weet je zeker" of project geslaagd is -of niet...

@Appelman

Wat jij noemt zijn gewoon projectrisico's. "Gewoon" wat betreft dat het in Prince2 uitvoerig beschreven wordt, niet gewoon in de zin dat het eenvoudig is. Wat jij noemt is wellicht een van de lastigste aspecten binnen een Project.

Projectrisico's behoren teruggekoppeld, door de Project Manager aan het Project Board. Die krijgt dan een reeel beeld van de kans van slagen van het project.

Er is vaak een druk op Project Managers om de risico's te onderschatten of zelfs bewust te rooskleurig voor te stellen. Wordt het mandaat door het Board gegeven dan kan er geld verdiend worden en zoals aftervillage hierboven al aangaf, een project wordt zelden na evaluatie van een fase gestopt.

???
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

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2010-09-21T15:51:00.000Z John Roos
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.