6 veelvoorkomende redenen waarom projecten mislukken: voorbeelden en geleerde lessen

Wanneer worden projecten als mislukkingen beschouwd?

Projecten worden als mislukkingen beschouwd wanneer ze budgetoverschrijdingen hebben, te laat worden opgeleverd of niet volgens de geplande scope worden opgeleverd. Er is echter vaak enige speelruimte. Projecten lopen vaak vertraging op door redenen waar de projectmanager geen invloed op heeft (bijvoorbeeld omdat de klant de inhoud voor zijn website niet op tijd heeft aangeleverd).

De scope kan in de loop van een project ook vaak veranderen door wijzigingen in de behoeften van de klant of stakeholder. Hoewel scope-uitbreiding een oorzaak van projectmislukking kan zijn, hoeft dit niet te leiden tot een mislukt project als het goed wordt aangepakt (met wijzigingsverzoeken en goedkeuring van belangrijke stakeholders).

6 veelvoorkomende redenen waarom projecten mislukken & voorbeelden

Dus waarom mislukken projecten? Hier zijn vijf van mijn grootste mislukkingen op het gebied van projectmanagement, die veelvoorkomende oorzaken van projectmislukking illustreren, evenals de belangrijke lessen die ik heb geleerd om het succes van toekomstige projecten te verbeteren.

1. Niet communiceren wanneer het moeilijk wordt

Het is een basaal menselijk instinct om niet de aandacht op jezelf te willen vestigen wanneer er iets is misgegaan en niemand dat heeft gemerkt. Het druist in tegen de aard van projectmanagement, maar slechte communicatie is zo vaak de reden waarom projecten mislukken.

Ik geef toe dat de combinatie van een zeer moeilijke klant en een budget of planning die dreigde te worden overschreden, ervoor heeft gezorgd dat ik net iets te lang aarzelde om een klant op de hoogte te brengen van de status van diens project.

Dit geldt vooral wanneer het de afgelopen dagen of weken stil en probleemloos is geweest binnen een project. Dat is ook de kwetsbaarste periode in de looptijd van je project—het is zo belangrijk om het vertrouwen dat een klant in zijn projectmanager heeft te behouden en te versterken.

Geleerde les:

Elke keer dat ik op het punt sta te wachten voordat ik een klant slecht nieuws breng, denk ik bij mezelf: is het beter om hun verwachtingen nu bij te stellen, of wil ik dit pas aanpakken als het te laat is? Het antwoord is: doe het ALTIJD nu en wees proactief.

Je legt daarmee ook de basis voor het beheren van toekomstige onrealistische verwachtingen tijdens het werken met een bepaalde klant.

2. Je niet houden aan de afgesproken scope

Tijdens een bijzonder gedetailleerd project stelde een teamlid dat nauw met mij samenwerkte voor om een nieuwe schuifregelaarplug-in uit te proberen voor een portfoliosectie waaraan we werkten voor de website van een klant.

Deze maakte gebruik van een framework waarmee we doorgaans niet werkten, maar de schuifregelaar zag er eleganter uit en werkte beter dan degene die we normaal gebruikten. In eerste instantie aarzelde ik vanwege de krappe planning en de bijzonder gedetailleerde ontwerprichtlijnen van het project, maar ik liet me overtuigen door de belofte van betere functionaliteit voor de klant EN ons ontwikkelteam.

Het was niet iets waarvan we eerder hadden besproken om het aan onze gebruikelijke gereedschapsset toe te voegen, maar het moment leek juist en het was een goede gelegenheid om de nieuwe plug-in in actie te zien.

Uiteindelijk bleek dit een van de duurste beslissingen van het project te zijn, zowel in manuren als in budget. De schuifregelaar ondersteunde uiteindelijk geen belangrijke functie en bood geen eenvoudige ondersteuning voor responsieve afmetingen of bepaalde browsers.

Dit was niet als geplande update door het gebruikelijke beoordelings- en besluitvormingsproces met technische leads en andere ontwikkelaars gegaan. Het was een ongelooflijk eenvoudige fout die ons beiden veel stress, schaamte en verspilde middelen kostte.

Het onnodig ‘opleuken’ van de scope door nieuwe projectopleveringen toe te voegen of projecttaken onnodig ingewikkeld te maken, is een andere typische reden waarom projecten mislukken.

Geleerde les:

Houd je aan je processen en pas dingen niet zomaar aan. Als je teamleden echt behoefte hebben aan of baat hebben bij een wijziging in processen of hulpmiddelen (waaronder projectmanagementsoftware of andere projectmanagementtools en technologie) halverwege een project, doorloop dan alle stappen om deze zorgvuldig te beoordelen.

3. Te amicaal worden met je team en klanten

Er is een duidelijk onderscheid tussen professionele relaties en informele vriendschappen, en ik heb geleerd die twee door zorgvuldig te oefenen gescheiden te houden.

Dat wil niet zeggen dat je geen vrienden kunt zijn met je teamgenoten of klanten—let er gewoon op wanneer je de professionaliteit in je interacties aan- of uitzet.

Jaren geleden werkte ik bij een bedrijf dat vol zat met mensen die net waren afgestudeerd, allemaal vergelijkbare interesses hadden en dicht bij elkaar in onze stad woonden. Natuurlijk trokken we na het werk en in het weekend samen op, waardoor er hechte vriendschappen ontstonden.

Op een dag moest ik vragen om een snelle oplevering van een project dat eigenlijk niemand leuk vond—het was niet mooi, niet leuk en iets wat door de meeste mensen niet werd gezien of gewaardeerd.

De ontwerper van het project overschreed de deadline ruimschoots en werkte in plaats daarvan aan een groter, moderner websiteontwerp dat pas weken later af hoefde te zijn. Ik sprak hem erop aan en hij vroeg me waarom ik zo streng voor hem was terwijl we vrienden waren.

Het vervagen van de grenzen tussen het persoonlijke en het professionele is soms de reden waarom projecten mislukken, omdat het de aanspreekbaarheid kan beïnvloeden.

Wat ik heb geleerd:

Wees vriendelijk, maar blijf professioneel om mensen verantwoordelijk te kunnen blijven houden voor hun acties binnen een project. Bij vrienden hebben we veel sneller het gevoel dat we ergens mee wegkomen, en dat kan een gevaarlijke (en ongemakkelijke) situatie worden wanneer dit wordt vermengd met professionele verplichtingen.

4. In paniek raken voordat je de kans hebt gehad om na te denken

Misschien ligt het aan mij, maar ik merk dat ik gemakkelijk reageer op bepaalde alarmsignalen of trefwoorden binnen projecten.

Denk aan e-mails in hoofdletters, de woorden “nieuwe deadline” of “site offline”, of meer onschuldige waarschuwingssignalen zoals gebrekkige communicatie op een cruciaal moment van een project, een nieuwe belanghebbende die vlak voor de lancering bij een project wordt betrokken, of vreemde storingen op een site vlak voor demonstraties aan klanten.

Niets maakt me meer van mijn stuk dan me onmiddellijk tot een manager, ontwikkelaar of klant wenden om opheldering te vragen over iets wat duidelijk (of door mijzelf uitvoerbaar) zou zijn geweest als ik even de tijd had genomen om adem te halen, na te denken en mijn volgende stap te overwegen.

Er zijn zo veel situaties geweest waarin ik dacht dat er een grote bug op een site zat (terwijl het gewoon een probleem met mijn eigen cache of die van de klant was), een verzoek om een functie verkeerd interpreteerde omdat die veel groter leek dan werkelijk nodig was, of een klant dacht dat zijn site/server offline was terwijl hij in werkelijkheid geen verbinding met internet had (ja, dat gebeurt vaak).

Hoewel dit punt op zichzelf geen grote mislukking van een project is, draagt het bij aan slechte communicatie en kan het paniek veroorzaken wanneer paniek niet nodig is.

Wat ik heb geleerd:

Wees nooit bang om je af te wenden van een reactieve e-mail of bericht, even te pauzeren en een moment de tijd te nemen om iets te onderzoeken voordat je om meer hulp vraagt.

5. Processen niet volgen

Ach ja: de denkfout dat “dit onderdeel ons gebruikelijke ontwikkel-, ontwerp-, beoordelings- en QA-proces kan overslaan omdat het maar een kleine wijziging is”. Dit is zo vaak de reden waarom projecten mislukken.

Ik heb dit zo vaak zien gebeuren bij projecten. Ik heb deze fout gemaakt met ogenschijnlijk “eenvoudige” onderhoudsupdates, kleine functieverzoeken binnen grotere projecten en wijzigingen in de projectomvang in het algemeen.

Iets als het bijwerken van een optie in een formulierveld lijkt aan de oppervlakte misschien eenvoudig, maar kan uitmonden in spaghetti-code en een update van het volledige systeem zodra een ontwikkelaar erin duikt.

Op dezelfde manier kan een klant die om een kleine visuele wijziging in een project vraagt het ontwerpproces overhoophalen en je ertoe dwingen een deel van de volledige gebruikersstroom van de site opnieuw te overwegen.

Wat ik heb geleerd:

Vertrouw altijd op het proces en doorloop de processen voor verkenning, schatting en QA op de juiste manier: ik heb geleerd dat er nooit een wijziging klein genoeg is om NIET iets anders onderweg te verstoren.

Bescherm je proces en zet je in voor de juiste aanpak—evenals dat slechts iets meer inspanning betekent. Dit betekent ook dat je de juiste projectmanagementmethode of workflow kiest, of dat nu agile, waterval, Kanban of een hybride aanpak is.

6. Geen duidelijke doelen stellen

Vanaf het begin moeten projecten duidelijke, meetbare projectdoelen hebben (ook wel SMART-doelen genoemd). Hoe kunnen we weten of we aan een succesvol project werken als we niets hebben om de voortgang van het project aan te toetsen?

Als onderdeel van het planningsproces bepaal je projectmijlpalen, doelstellingen en succesindicatoren. Denk na over je projectschema, projectvereisten en projectbudget. Kies de KPI's die het meest logisch zijn voor je project of initiatief.

Dit is een van de meest voorkomende oorzaken van mislukking. Zonder dit weten projectteamleden (en jij!) niet of je op schema ligt wat betreft planning, scope en budget. Je krijgt te maken met gemiste deadlines en budgetoverschrijdingen voordat je zelfs maar merkt dat er iets mis is.

Les:

Stel altijd KPI's en meetwaarden vast voor je projecten, zelfs voor kleinere projecten waarbij dit misschien onnodig voelt of als een extra stap om iets vast te stellen wat je al weet. Je ontdekt misschien een discrepantie tussen je projectdoelstellingen en KPI's, waardoor je jezelf later een hoop kopzorgen bespaart.

3 stappen om projectmislukking te voorkomen

Een manier om projectmislukking te voorkomen is om gedurende het project op verschillende momenten projectevaluaties uit te voeren. Hier zijn drie stappen om in gedachten te houden:

1. Identificeer risico's: Normaal gesproken doe je dit als onderdeel van het proces voor het opstellen van het projectplan. Leg risico's vast in een risicoregister of RAID-logboek.
2. Beoordeel risico's: Beoordeel de waarschijnlijkheid en impact van elk risico. Risico's die zeer waarschijnlijk optreden en de meest negatieve impact zouden hebben, moeten de meeste aandacht krijgen.
3. Maak risicobeheerplannen en noodplannen: Wat doe je als een bepaald risico werkelijkheid wordt? Hoe kun je de kans verkleinen dat dit risico zich voordoet?

Lees hier meer over hoe je projectmislukking kunt voorkomen.

Wat vind je ervan?

Dit zijn enkele van de meest voorkomende redenen voor projectmislukking, maar het zijn niet de enige. Je kunt ook te maken krijgen met een gebrek aan middelen, een gebrek aan teamwork en allerlei andere problemen. Het belangrijkste is om waakzaam te blijven, je communicatiekanalen open te houden en ervoor te zorgen dat je risico's hebt afgedekt die je project kunnen bedreigen.

Til je vaardigheden op het gebied van projectmanagement naar een hoger niveau met een van deze uitgebreide cursussen risicobeheer.