Op deze pagina
- Waarom de meeste projecten al mislukken voordat ze beginnen
- Wat een compleet projectplan daadwerkelijk bevat
- Scope vóór planning: de meest genegeerde regel in projectmanagement
- RACI: de tool die de verspreiding van verantwoordelijkheid voorkomt
- Risicoregister opgesteld voordat de risico's zich voordoen
- Voor projecten die al in de problemen zitten
- Een projectplanningssessie met Paul starten
Waarom de meeste projecten al mislukken voordat ze beginnen
Projectfalen is achteraf zelden een verrassing. De onderliggende oorzaken zijn bijna altijd zichtbaar in het oorspronkelijke plan - of in het ontbreken daarvan. Een takenlijst met datums en zonder scopeverklaring. Een tijdlijn die is opgesteld voordat de afhankelijkheden waren begrepen. Eigenaarschap dat over een team is verdeeld zonder een RACI om het expliciet te maken. Risico's die één keer tijdens een kick-offbijeenkomst zijn besproken en nooit zijn vastgelegd. Dit zijn geen uitvoeringsfouten. Het zijn planningsfouten die de uitvoering vervolgens moet opvangen.
Onderzoek naar projectfalen wijst consequent dezelfde oorzaken aan: een onduidelijke scope waardoor vereisten onbeperkt kunnen uitbreiden, onrealistische tijdlijnen die zijn opgesteld zonder inzicht in al het werk, onduidelijk eigenaarschap waardoor hiaten en doublures ontstaan, en risico's die voorzienbaar waren maar niet zijn beperkt. Elk hiervan is een planningsprobleem, geen uitvoeringsprobleem - en elk is te voorkomen door het juiste raamwerk aan het begin toe te passen.
Paul - de projectmanagementagent van KissMySkills - past dat raamwerk toe in één intakegesprek. De output is een compleet projectplan, opgesteld volgens de methodologie die ervaren projectmanagers toepassen: een scopeverklaring met expliciete uitsluitingen, work breakdown structure, mijlpaaltijdlijn op het kritieke pad, RACI-matrix, risicoregister met mitigerende acties en een communicatieplan voor stakeholders. Opgesteld aan het begin, voordat er ook maar één taak begint.
Paul stelt de scopeverklaring, work breakdown structure, RACI-matrix, tijdlijn op het kritieke pad en het risicoregister op - een compleet projectplan in één sessie.
Paul bekijken →Wat een compleet projectplan daadwerkelijk bevat
De meeste documenten die "projectplannen" worden genoemd, zijn takenlijsten met datums en bovenaan een naam. Een compleet projectplan bestaat uit zes onderdelen die de aanpak met alleen een takenlijst weglaat - elk gericht op een andere faalwijze.
Een scopeverklaring die vastlegt wat binnen de scope valt en, minstens zo belangrijk, wat expliciet buiten de scope valt. Zonder expliciete uitsluitingen dijt de scope uit totdat alle beschikbare tijd en het volledige budget zijn opgebruikt, aangejaagd door verzoeken van stakeholders die afzonderlijk redelijk zijn, maar gezamenlijk de planning ruïneren.
Een work breakdown structure die de projectresultaten opsplitst in werkstromen en vervolgens in taken, totdat elk onderdeel van het werk is toegewezen en ingeschat. De WBS is het hulpmiddel dat het werk zichtbaar maakt dat altijd wordt onderschat omdat het tussen de belangrijkste mijlpalen valt - de integratietests, het goedkeuringsproces, de documentatie, de training en de overgangsactiviteiten.
Een mijlpaalplanning die is gebaseerd op het kritieke pad - de reeks taken waarbij elke vertraging de einddatum van het project vertraagt. De meeste projectplanningen worden achterwaarts opgesteld vanaf een gewenste einddatum, zonder vast te stellen welk pad door het werk werkelijk kritiek is. Wanneer een niet-kritieke taak uitloopt, is dat een probleem. Wanneer een taak op het kritieke pad uitloopt, loopt het hele project uit.
Een RACI-matrix die voor elke belangrijke oplevering de rollen Responsible, Accountable, Consulted en Informed toewijst. De tool die eigenaarschap expliciet maakt voordat de uitvoering begint, in plaats van in week vier te ontdekken dat twee mensen dachten dat de ander verantwoordelijk was voor een oplevering die door niemand werd voltooid.
Een risicoregister waarin geïdentificeerde risico's worden vastgelegd, de waarschijnlijkheid en impact ervan worden beoordeeld, risicobeperkende acties worden toegewezen en een eigenaar wordt aangewezen voor het monitoren van elk risico gedurende het project.
Een communicatieplan voor stakeholders waarin staat wie welke update met welke frequentie ontvangt - zodat stakeholders nooit worden verrast door de projectstatus en de projectmanager nooit zonder een voorbereide update voor een belangrijke vergadering komt te zitten.
Scope vóór planning: de meest genegeerde regel in projectmanagement
Planningen die zonder duidelijke scope zijn opgesteld, zijn geen planningen - het zijn schattingen met een schijnprecisie. De meest voorkomende reden dat projecten deadlines niet halen, is niet een slechte uitvoering door het team. Het is dat de planning werd opgesteld voordat de volledige scope duidelijk was, of voordat alle afhankelijkheden waren geïdentificeerd, of voordat iemand de vragen had gesteld die het werk aan het licht brengen dat niet in de oorspronkelijke requirements voorkomt.
Paul vraagt naar opleveringen, afhankelijkheden, beperkingen en expliciete uitsluitingen voordat hij een planning opstelt. De scopebeschrijving is de eerste output - bevestigd en overeengekomen voordat er ook maar één mijlpaaldatum wordt vastgesteld. Scope creep is aanzienlijk gemakkelijker te voorkomen dan te beheersen nadat het is begonnen, en de expliciete uitsluitingen in de scopebeschrijving geven de projectmanager de bevoegdheid om "dat valt buiten de scope" te zeggen wanneer er nieuwe verzoeken binnenkomen. Zonder gedocumenteerde uitsluitingen wordt elk gesprek van het type "dat klinkt eenvoudig, kunnen we het toevoegen?" een onderhandeling.
RACI: de tool die de verspreiding van verantwoordelijkheid voorkomt
De verspreiding van verantwoordelijkheid is het equivalent in projectmanagement van het omstandereffect: wanneer meerdere mensen betrokken zijn bij een oplevering zonder duidelijk eigenaarschap, gaat iedereen ervan uit dat iemand anders ermee bezig is. Het resultaat is een oplevering die niemands probleem is totdat het ieders probleem wordt - laat ontdekt, gehaast uitgevoerd en bij het team neergelegd.
Een RACI-matrix voorkomt dit door het eigenaarschap ondubbelzinnig vast te leggen voordat de uitvoering begint. Responsible is de persoon die het werk uitvoert. Accountable is de enige aangewezen persoon die verantwoording aflegt voor het resultaat - er kan er maar één zijn. Consulted zijn de mensen van wie input vereist is. Informed zijn de mensen die op de hoogte moeten blijven van de status. Paul maakt voor elk belangrijk op te leveren resultaat in elke werkstroom van het project een RACI, waarbij elke stakeholder met een rol wordt opgenomen.
De RACI is bedoeld om tijdens de projectkick-offvergadering te worden doorgenomen - niet om als document te worden verstuurd voor een asynchrone beoordeling, maar om als team te bespreken zodat iedereen zijn rol bevestigt, zijn verantwoordelijkheid begrijpt en de kans krijgt om zorgen te uiten voordat het project begint. Conflicten in de RACI die bij de kick-off worden ontdekt, zijn in vijf minuten opgelost. Conflicten die halverwege het project worden ontdekt, kosten weken.
Risicoregister opgesteld voordat de risico's zich voordoen
Het beste moment om een risicoregister op te stellen is bij de start van het project, wanneer de aandacht van het team op de toekomst is gericht en er nog opties openstaan. Risico's die aan het begin worden geïdentificeerd, kunnen worden beperkt. Risico's die pas worden geïdentificeerd wanneer ze zich daadwerkelijk voordoen, kunnen alleen worden beheerd - de opties zijn beperkter, de kosten hoger en de impact op de planning groter.
Paul maakt een risicoregister met geïdentificeerde risico's, beoordelingen van waarschijnlijkheid en impact (hoog/middel/laag), specifieke mitigerende maatregelen voor elk risico en een aangewezen eigenaar die elk risico gedurende de hele projectlevenscyclus bewaakt. De geïdentificeerde risico's omvatten zowel de voor de hand liggende risico's - beschikbaarheid van belangrijke resources en vertragingen bij afhankelijkheden van derden - als de categoriespecifieke risico's die volgens de ervaring het vaakst voorkomen bij dit type project.
Voor projecten die al in de problemen zitten
Paul stelt ook vast waarom projecten in moeilijkheden raken en helpt ze herstellen - hij plant dus niet alleen nieuwe projecten. Bij een project dat achterloopt op schema, het budget overschrijdt of lijdt onder ongecontroleerde scope-uitbreiding, brengen de intakevragen de hoofdoorzaak aan het licht: een onduidelijke oorspronkelijke scope, een onrealistische tijdlijn, onduidelijk eigenaarschap of risico's die zich hebben gemanifesteerd zonder dat er mitigatieplannen klaarlagen. Het herstelplan pakt de werkelijke oorzaak aan in plaats van alleen de resterende planning te comprimeren - want het comprimeren van een planning voor een fundamenteel gebrekkig plan levert een andere versie van dezelfde mislukking op.
Een projectplanningssessie met Paul starten
Laad het Paul-vaardigheidsbestand in Claude Projects. Plak de activatieprompt. Paul stelt intakevragen over het project: het doel, de op te leveren resultaten, de deadline, de teamsamenstelling, bekende afhankelijkheden en beperkingen. Geef specifieke antwoorden - hoe meer details over het daadwerkelijke project, hoe nauwkeuriger het plan. De volledige sessie levert in 30 minuten een compleet projectplan op. Paul werkt met Claude, ChatGPT of elke AI-chat die systeemprompts accepteert.