Projectfalen voorkomen in 3 stappen + 4 casestudy’s
Er zijn veel redenen waarom projecten mislukken, maar ze komen vrijwel allemaal neer op een van twee dingen (soms op beide):
- Er was een risico dat niemand herkende, en/of
- We reageerden niet goed toen er een probleem ontstond
In dit artikel wil ik me richten op het grotere geheel om de belangrijkste oorzaak van het mislukken van projecten—en vaak ook van projectmanagement—aan te pakken.
Zo voorkom je dat een project mislukt en dit kun je doen als dat catastrofale probleem dat je niet had voorzien zich toch voordoet (je kunt het nog steeds voor elkaar krijgen als je snel en doordacht handelt!).
Create a Free Account to Read More
Unlock this piece and join a community of forward-thinking leaders discovering tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Wat is projectfalen?
Precies wat het klinkt—wanneer een project de projectdoelstellingen die het team aan het begin heeft vastgesteld niet oplevert, niet voldoet aan de verwachtingen van de klant of belangrijke belanghebbenden, of niet binnen de planning, het budget of de scope blijft.
Waarom mislukken projecten?
Zoals ik in de inleiding al aangaf, zijn er verschillende veelvoorkomende redenen waarom projecten kunnen mislukken. Meestal komt dit doordat een risico niet goed is beoordeeld en/of het team (inclusief de projectmanager) niet goed op het risico heeft gereageerd.
Andere veelvoorkomende oorzaken van projectfalen zijn onder meer slechte communicatie over de status, problemen of risico's; teamleden die zich niet houden aan de projectscope, de projectresultaten (d.w.z. scope-uitbreiding) of het tijdsbestek, of deze niet goed begrijpen; een gebrek aan middelen; of het niet volgen van aangewezen processen of methodologieën.
Hoe voorkom je projectfalen: 3 stappen
Risicomanagement is een belangrijke projectmanagementactiviteit. Het is zo belangrijk dat het niet beheersen van risico's vaak neerkomt op falend projectmanagement. Risicomanagement bestaat uit drie belangrijke onderdelen:
- Identificeer risico's.
- Beoordeel wat je hebt geïdentificeerd: Hoe waarschijnlijk is het dat het gebeurt en hoe ernstig worden de gevolgen als dat gebeurt? Wat zijn de waarschijnlijkheid en de impact?
- Bereid beperkende maatregelen en noodplannen voor voor de risico's die je voor het overige succesvolle project kunnen torpederen. Risicoregisters zijn handig om bij te houden wat je hebt gedaan.
1. Identificeer risico's
Identificeer eerst de risico's. Als je dit goed doet, vergroot je je kansen op projectsucces aanzienlijk. Hoewel het moeilijk is om ze allemaal te ontdekken, kun je de grootste risico's meestal achterhalen als je systematisch naar het project kijkt. Dit maakt doorgaans deel uit van het opstellen van een projectplan.
Mijn achtergrond ligt in softwareontwikkeling, zowel voor producten als voor IT, en in de bijbehorende processen. Softwareprojecten zijn complex en kwetsbaar en bevatten, op enkele zeldzame uitzonderingen na, niet de ingebouwde foutbeveiliging en inspecties die bijvoorbeeld de bouw of de productie van medische hulpmiddelen wel kent.
Je moet projectdoelen hebben voor elk van de vier knoppen:
- Planning
- Inhoud
- Kosten
- Kwaliteit
Als je niet weet wat die zijn, is dat je startpunt. Ik merk doorgaans dat twee van de vier enigszins zullen verschuiven, maar hoe beter je begrijpt waar je naartoe gaat, hoe gemakkelijker het wordt om obstakels te identificeren.
Als je begrijpt welke van de vier knoppen de hoogste prioriteit heeft, kun je risico's beperken door op kleine schaal passende compromissen te sluiten.
Het is gemakkelijk om volledig op te gaan in de planningsknop van het project en risico's te missen die invloed kunnen hebben op de andere knoppen, maar ze hangen allemaal samen en zijn allemaal belangrijk om te identificeren.
Je planningsdoelen halen met een product dat vol fouten zit, is meestal geen goede optie—evenals je het uitbrengt, zul je uiteindelijk herstelreleases moeten uitvoeren die de planning voor een toereikend product verder vertragen dan het aanpakken van het probleem in eerste instantie zou hebben gedaan.
Naast de 4 knoppen
Naast de vier knoppen moet je drie aspecten van je project in balans houden:
- Product, dat doorgaans door de knoppen wordt gedekt
- Proces
- Mensen
Procesrisico's komen in twee vormen voor: een bestaande ontoereikendheid van het proces, waardoor niet aan de behoeften van je project wordt voldaan, en het ontbreken van een proces voor iets dat cruciaal is voor wat je team doet. Procesrisico's zijn vrij eenvoudig te beperken door het proces op te stellen of te verbeteren.
Het menselijke aspect wordt vaak genegeerd, maar je team en de teams waarmee het samenwerkt, zullen je project maken of breken. Moeilijke of ongeïnteresseerde belanghebbenden bij het project maken het lastig om te krijgen wat je nodig hebt om vooruitgang te boeken.
Overwerkte, gestreste of ongelukkige teamleden zullen de klus niet klaren. Sommige mogelijke personeelsproblemen kunt u openbaar identificeren, andere wilt u misschien privé bespreken, maar maak niet de fout ze te negeren.
2. Beoordeel de risico's die u hebt geïdentificeerd
Bepaal na het identificeren van de risico's hoe waarschijnlijk het is dat het risico zich voordoet. Ik gebruik meestal een percentage: 100% betekent dat ik ervan overtuigd ben dat het zal gebeuren. Het is ook belangrijk om te bepalen hoe ernstig het zal zijn als het risico zich daadwerkelijk voordoet. De eenvoudigste manier om dit te doen is risico's in te delen als hoog, gemiddeld of laag.
Nadat u deze analyse hebt uitgevoerd, is het tijd om uw team erbij te betrekken. Vraag elk projectteamlid of elke bijdrager waarover diegene zich zorgen maakt, voeg die punten toe aan de lijst met risico's en leg ze ter beoordeling voor:
- Kan het team andere risico's bedenken die u nog niet hebt behandeld?
- Wat vinden zij van de analyse van waarschijnlijkheid en impact?
Op basis van deze bijeenkomst kunt u uw risicoplan aanpassen. Deel één en twee zijn voorlopig afgerond. U moet de risico's minstens wekelijks opnieuw beoordelen om te zien of er nieuwe risico's zijn, of sommige risico's niet langer van toepassing zijn en of de waarschijnlijkheid of impact is veranderd.
3. Stel mitigatie- en continuïteitsplannen op
Als ten slotte de combinatie van waarschijnlijkheid en impact van bepaalde risico's uw project mogelijk kan ontsporen, stelt u samen met uw team gedocumenteerde mitigatie- en continuïteitsplannen op.
Mitigatie houdt in dat u ervoor zorgt dat het risico zich minder waarschijnlijk voordoet of minder impact heeft als het zich toch voordoet. Een continuïteitsplan richt zich op de stappen die u neemt als het risico onvermijdelijk is en zich voordoet.
Zorg ervoor dat de plannen worden gedocumenteerd en dat iedereen ervan op de hoogte is. Het is ook een goed idee om naast de 4 knoppen en het proces rekening te houden met mogelijke personeelsproblemen, maar waarschijnlijk wilt u deze analyse zelf uitvoeren en vertrouwelijk houden.
Hoe u een mislukking van een project overleeft
De tweede reden voor mislukkingen in projectmanagement is een slechte reactie op een projectrisico dat zich voordoet, voorzien of niet. Dit ligt echt volledig in uw handen als projectmanager. Begin voordat u een van de onderstaande stappen uitvoert met deze 2 tips:
- Raak niet in paniek. Vergeet niet te ademen.
- Wijs geen schuldigen aan en laat niemand anders beginnen met anderen de schuld te geven.
1. Raadpleeg uw continuïteitsplan
Als u een continuïteitsplan hebt, beleg dan onmiddellijk een bijeenkomst of stuur op zijn minst een e-mail om het continuïteitsplan in werking te stellen. Herinner mensen eraan wat het plan inhoudt en vertel iedereen wanneer en hoe de voortgang moet worden gerapporteerd.
Als u dit overslaat of uitstelt, zult u merken dat mensen die graag willen helpen in paniek zijn ingesprongen. Wanneer dit gebeurt, raakt u het overzicht kwijt over wat er is gedaan en wordt het probleem vaak erger.
Als u geen continuïteitsplan hebt, mobiliseer dan onmiddellijk iedereen met een uitnodiging voor een bijeenkomst en strikte instructies om tot na de bijeenkomst NIETS ANDERS TE DOEN.
Anders zal iedereen proberen te helpen en hebt u geen idee wat er is gedaan. Benoem het probleem tijdens de bijeenkomst duidelijk: het is altijd verbazingwekkend hoeveel verschillende ideeën mensen hebben over wat het probleem is.
Voer gezamenlijk een analyse van de grondoorzaak uit om de kern van het probleem te achterhalen en stel een plan op om te herstellen: wie doet wat en hoe. Bij het uitvoeren van een analyse van de grondoorzaak moet u begrijpen wie wat heeft gedaan in de aanloop naar het probleem, maar houd de discussie op dat niveau.
Met andere woorden: alleen de feiten. Wijs niemand de schuld toe, want met de vinger wijzen leidt af. Als uw team niet in staat is de oplossing te bedenken, hebt u enkele opties.
De eerste is iemand erbij halen die verstand heeft van het algemene onderwerp, maar niet aan dit specifieke project werkt. Als het probleem bijvoorbeeld bij de database lijkt te liggen, kunt u een databasebeheerder die momenteel niet aan het project werkt erbij halen voor een ander perspectief.
Een andere techniek is iemand erbij halen die helemaal geen praktische kennis van het project heeft. Soms komen door elke stap expliciet te moeten uitleggen gebrekkige aannames of zaken aan het licht die mensen over het hoofd zagen.
2. Los het probleem op
Zorg ervoor dat iedereen achter uw aanpak staat en wijs taken toe. Laat mensen aan u rapporteren over de voortgang en vertel hun hoe vaak ze voortgangsrapportages moeten sturen: elk uur, wanneer ze een taak hebben afgerond, aan het einde van de dag of op een ander moment dat gezien de situatie logisch is.
De rapportage lijkt voor u misschien vanzelfsprekend, maar dat zal niet voor iedereen zo zijn. Regelmatige updates helpen het team gefocust te blijven. Rapporteer regelmatig de geconsolideerde voortgang aan het hele team.
Teamleden die geen onmiddellijke taken hebben, zullen onrustig worden en uiteindelijk proberen in te springen en te helpen, tenzij u hun voortgangsupdates en andere informatie geeft.
Het is ook erg belangrijk om het management op de hoogte te houden. Gebruik uw beoordelingsvermogen om te bepalen wie op welk moment updates nodig heeft, maar rapporteer regelmatig de geconsolideerde voortgang aan het hele team.
3. Rond het af
Tenminste, wanneer het echt klaar is. Stel een eindrapport op en ga verder met de volgende stap. Geef het team wat tijd om bij te komen.
4. Houd een evaluatie achteraf of retrospectief
Het is belangrijk om een projectevaluatie uit te voeren om geleerde lessen te verzamelen. Zo structureer je dit:
- Beschrijf het probleem, zodat iedereen dezelfde uitgangspunten heeft
- Begin met wat goed ging. Zelfs in de meest benarde situatie ging er nog iets goed. Hierdoor begint de bijeenkomst meteen met een heel andere toon.
- Bespreek wat beter moet. Als er tijd is, brainstorm dan over manieren om de verbeteringen door te voeren; wijs anders taken en deadlines toe en kom op die data terug.
Als het daadwerkelijk iemands schuld was, bespreek dit dan met die persoon—privé. Als je dit openbaar doet, zal je hele team zich afvragen wie er de volgende keer publiekelijk voor schut wordt gezet.
Als je deze stap helemaal overslaat, zal je team het gevoel krijgen dat iemand ermee weggekomen is en dat het probleem niet is opgelost. Wees feitelijk en volg eventuele persoonlijke proceswijzigingen op die iemand moet doorvoeren. Het draait allemaal om verantwoordelijkheid en verbetering, niet om iemand de schuld te geven.
3 voorbeelden van mislukte projecten uit de praktijk
Ik heb mijn deel van de mislukte IT-projecten meegemaakt, hoewel ze gelukkig—maar met pijn en moeite—zijn hersteld.
Hier zijn een paar van mijn eigen mislukte IT-projecten en ontwikkelingsprojecten, evenals een voorbeeld van een beroemd mislukt project.
Deze voorbeelden van mislukte projecten en casestudy's van mislukte projecten zouden je ook een concreet idee moeten geven van de manieren waarop projecten kunnen mislukken en hoe hiermee kan worden omgegaan.
1. Het boekhoudsysteem
In het begin van mijn carrière werkte ik bij IBM. Mijn eerste echte baan bestond uit het overnemen van een vrij klein systeem dat gegevens aanleverde aan de bedrijfsboekhoudsystemen. Iemand binnen IBM had het op een klein systeem geschreven in een obscure programmeertaal met de naam RPG.
Ik beheerde niet alleen het project—ik beheerde het hele systeem (hoewel er een beheerder was), waaronder het verzamelen van projectvereisten, het oplossen van problemen en het programmeren.
Op een mooie dag plaatste ik een nieuw programma, voerde het uit en ontdekte ik een fout. Ik corrigeerde de fout en voerde het programma opnieuw uit. De volgende ochtend werd ik gebeld door de mensen van de boekhouding: er waren dubbele boekingen (en dat is heel slecht nieuws in de wereld van de boekhouding).
Ten eerste had niemand mijn werk gecontroleerd. Ten tweede had ik geen mensen van de achterliggende systemen ingeschakeld om de boekingen te controleren voordat ze werden doorgegeven. En ten derde had ik niet de tijd genomen om enkele oude programma's te analyseren die nog steeds draaiden en dubbele boekingen veroorzaakten. Er was ook geen proces, behalve wat ik ter plekke zelf bedacht.
En toen kwam mijn reactie—paniek. Mijn hemel, net van de universiteit en ik breng het boekhoudsysteem van IBM in de problemen. Ik had niet de juiste mensen ingeschakeld—de beheerder wist niet wat er aan de hand was—en hij genereerde zonder het te weten nog een reeks boekingen. Uiteindelijk werkte ik 48 uur achter elkaar om de hoofdoorzaak te achterhalen, het probleem op te lossen en programma's te schrijven en uit te voeren om de boekhoudkundige fouten te herstellen.
En ik heb mijn les geleerd—kijk zorgvuldig, laat werk controleren, denk na over wat er mis kan gaan en stop en denk na voordat je erin duikt om dingen te proberen op te lossen (allemaal zaken waarbij boekhoudkundige projectmanagementsoftware kan helpen). Stel je nu voor dat ik een team van 10 mensen aanstuurde en iedereen hetzelfde deed in een poging het probleem op te lossen. Het zou echt niet meer te herstellen zijn geweest zonder de boekhoudsystemen van IBM uit te schakelen om het probleem op te lossen.
2. Het nieuwe interne product
Als consultant leidde ik een nieuw, groot project waarbij veel mensen invloed hadden op de vereisten, wat leidde tot eindeloze verschuivingen in de functionele prioriteiten. We gebruikten een agile projectmanagementproces, dat dit bedrijf nog niet eerder had gebruikt. QA was zeer goed in testen, maar begreep het perspectief en de workflow van de eindgebruiker nog niet.
Ik wist dit allemaal en bracht het van tijd tot tijd ook onder woorden, maar ik had geen risicoregister, geen beoordeling van impact en waarschijnlijkheid, geen noodplan en geen risicobeperkende plannen. Ik was ook niet het primaire informatiekanaal naar de projectsponsor, hoewel ik af en toe met haar overlegde.
We voegden een sprint toe. Daarna nog een. Vervolgens voegden we, toen duidelijk werd dat we nog niet helemaal op het punt waren waarop we een bètatest konden uitvoeren, een derde sprint toe.
Omdat ik niet degene was die informatie aan de projectsponsor verstrekte, had ik geen idee dat zij dit allemaal niet wist. De verantwoordelijke persoon maakte de kritieke fout de sponsor niet in te lichten, in de hoop dat we het toch voor elkaar zouden krijgen.
En eerlijk gezegd: hoewel ik het over risico's had gehad, had ik hem geen concrete reeks risico's gegeven om te presenteren, zodat de sponsor voorbereid was op de mogelijkheid dat de planning zou uitlopen.
Midden in dit alles had ik een vergadering met de sponsor en verwees ik terloops naar die laatste sprint die we zouden toevoegen. Ze onderbrak me. Ze wist er niets van en was niet blij.
Uiteindelijk was ze meer van streek door de verrassing dan door de vertraging in de planning. Er waren publieke gevolgen en uiteindelijk ging de verantwoordelijke voor het project elders in het bedrijf werken, omdat het vertrouwen weg was.
Opnieuw heb ik belangrijke lessen geleerd van de mislukking. Alleen de risico’s kennen is niet genoeg; je moet ze samenbrengen, beoordelen, er plannen voor risicobeperking en noodplannen voor opstellen en ze openbaar en voortdurend in beeld houden.
Ik ben nooit iemand geweest die risico’s en problemen verbergt, maar het belang van transparantie binnen projecten werd onmiskenbaar duidelijk.
3. Herinner je je OS2 nog?
Nee, niemand. Het is een van de vele mislukte systeemontwikkelingsprojecten. Ik werkte bij IBM toen de oorspronkelijke OS2 uitkwam—een concurrent van Windows. Ik heb die eerste versie niet eens geprobeerd, omdat we bij IBM allemaal wisten dat die veel fouten bevatte. De rest van de wereld ontdekte meteen dat het te veel problemen had om de moeite waard te zijn.
Het bevatte genoeg fouten dat het projectteam onmogelijk kon hebben gedacht dat het volledig klaar was, maar op de een of andere manier maakten ze niet de juiste afweging en stelden ze de release niet uit. Als je geen rekening houdt met de menselijke factor, zullen zowel je team als je klanten een mooi plan snel ruïneren.
In software zijn er allerlei alternatieven voor deze situatie—een beperkte release uitvoeren voor mensen die de fouten willen tolereren om nieuwe, geavanceerde software te kunnen gebruiken, openbaar maken dat je wacht totdat de betrouwbaarheid aan je hoge standaarden voldoet, enzovoort.
Dit was nog vroeg genoeg in mijn loopbaan om waardevolle lessen te kunnen trekken uit het feit dat een product waar ik dol op was al bij de tweede release op een dood spoor zat.
Wees duidelijk over je prioriteiten—er zijn enkele gevallen waarin het belangrijker is om op een bepaalde datum uit te brengen dan om productkwaliteit te bieden, maar dat zijn er niet veel.
Gebruik je 4 knoppen, geef je fouten toe en maak de oplossingen zichtbaar, zodat mensen erop vertrouwen dat je het probleem begrijpt en niet twee keer dezelfde fout zult maken.
Houd rekening met de menselijke factor—die is net zo cruciaal als de technologie. Vanaf dat moment heb ik deze lessen meegenomen naar software- en IT-projecten, en ze zijn van onschatbare waarde geweest.
Kortom
Onthoud over het geheel genomen dat je uiteindelijk weliswaar verantwoordelijk bent, maar niet al het werk hoeft te doen. Je moet het zelfs absoluut niet alleen proberen te doen. Je kunt profiteren van de brede ervaring en kennis van je team. Jij bent de leider, maar je hoeft niet het hele team te zijn.
Projectmanagementsoftware en andere projectmanagementtools kunnen je helpen risico’s, mijlpalen, de toewijzing van middelen en andere kritieke indicatoren bij te houden die aangeven of je op weg bent naar een succesvol project.
