Naar de inhoud
Prompt bibliotheek

Projectmanagement prompts

Kadering, verslagen, planningen en risicobeheer voor projecten die binnen de deadline blijven. Vervang de variabelen tussen haakjes door je eigen context. Kopieer de prompt of open deze direct in de chat.

  • 50 Projectmanagement prompts
  • Kopiëren of openen in chat

Een projectplan (PID) opstellen

Het document dat iedereen op één lijn brengt voor de start: scope, out-of-scope, risico's en mijlpalen.

Schrijf het projectplan voor het project [naam project] voor [bedrijf]. Doel van het project: [doel]. Opdrachtgever: [opdrachtgever]. Team: [samenstelling]. Budget: [budget]. Beoogde deadline: [deadline]. Aanleiding van het project: [context].

Structuur: context en het op te lossen probleem (3 regels), SMART-geformuleerde doelstelling, inbegrepen scope, expliciet UITGESLOTEN scope (even gedetailleerd als de inbegrepen scope om 'scope creep' te voorkomen), deliverables met acceptatiecriteria, gedateerde mijlpalen, rollen en verantwoordelijkheden (wie beslist, wie voert uit, wie wordt geraadpleegd, wie wordt geïnformeerd), geïdentificeerde risico's met beheersmaatregelen ([reeds bekende risico's]), aannames en afhankelijkheden.

Formuleer elke sectie zo dat eventuele meningsverschillen NU naar boven komen bij het nalezen, in plaats van halverwege het project. Eindig met de 3 belangrijkste vragen die de stuurgroep moet beslissen voor de lancering.

Vergaderingen omzetten in een actielijst

Een kort verslag met besluiten en toegewezen acties op basis van ruwe aantekeningen.

Zet mijn ruwe vergaderaantekeningen om in een gestructureerd verslag. Vergadering: [onderwerp] op [datum], deelnemers: [deelnemers]. Hier zijn mijn aantekeningen: [ruwe aantekeningen].

Output-formaat: genomen besluiten (ondubbelzinnig geformuleerd, inclusief wie het besluit heeft genomen), acties (tabel: actie, verantwoordelijke, deadline; als een van de drie ontbreekt, markeer dit als 'NOG TE BEPALEN' in plaats van iets te verzinnen), besproken punten zonder besluit (max. 2 regels per punt), uitgestelde punten met de datum voor de volgende bespreking.

Richtlijnen: maximaal één pagina, geen herformuleringen die de betekenis veranderen, vermijd vage termen als 'er is afgesproken om stappen te zetten'. Eindig met de lijst 'NOG TE BEPALEN' punten die naar de deelnemers moet voor validatie.

Project opdelen in werkpakketten en planning

De stap van doelstelling naar planning: pakketten, taken, afhankelijkheden en het kritieke pad.

Verdeel het volgende project in werkpakketten en stel de planning op. Project: [beschrijving project en eindresultaat]. Deadline: [datum]. Beschikbaar team: [personen en beschikbaarheid, bijv. 2 personen parttime]. Bekende beperkingen: [beperkingen: klantvalidatie, afhankelijkheid leverancier, vakantieperiode].

Werk als volgt: verdeel het in werkpakketten die elk een controleerbaar resultaat opleveren (geen pakket 'coördinatie'), splits elk pakket op in taken van 0,5 tot 3 dagen, identificeer afhankelijkheden en het kritieke pad, bouw expliciete marges in bij onzekere taken in plaats van verborgen marges overal.

Lever op: de gestructureerde lijst werkpakketten -> taken met schattingen, de weekplanning met validatiemijlpalen, het kritieke pad gemarkeerd, en de 3 taken die direct moeten starten omdat ze de rest beïnvloeden. Meld het als de deadline [datum] onhaalbaar is met het beschreven team, onderbouwd met cijfers.

Wekelijkse voortgangsrapportage opstellen

De statusupdate van één pagina die besluitvormers echt lezen: status, feiten en benodigde besluiten.

Schrijf de wekelijkse voortgangsrapportage voor project [naam project] voor [ontvangers, bijv. stuurgroep]. Gegevens van deze week: voortgang [gedaan vs gepland], knelpunten [tegengekomen problemen], veranderende risico's [risico's], verbruikt budget [verbruikt vs gepland], verwachte besluiten [blokkerende besluiten en sinds wanneer].

Strikt formaat van één pagina: projectstatus (groen/oranje/rood) met ÉÉN zin die de kleur rechtvaardigt, 3 belangrijkste feiten van de week, voortgang vs plan (één regel per actief werkpakket), risico's en knelpunten (alleen wat veranderd is sinds vorige week), benodigde besluiten met naam van de beslisser en impact van vertraging, prioriteiten voor volgende week.

Richtlijnen: een project gaat nooit terug naar groen zonder uitleg over de oplossing; een oranje status die twee weken aanhoudt wordt rood; bij openstaande besluiten staat de datum van de oorspronkelijke aanvraag.

Een projectevaluatie (post-mortem) leiden

Volledige voorbereiding van een nuttige retro: verloop, vragen en actiegerichte leerpunten.

Bereid de facilitatie voor van een retrospectief voor project [naam project], dat net is afgerond [resultaat: op tijd, X vertraging, gestaakt]. Deelnemers: [deelnemers en rollen]. Duur: [duur, bijv. 1,5 uur]. Hoogtepunten: [wat ging goed/fout, eventuele spanningen].

Lever op: de getimede agenda (opening met de regel 'we zoeken oorzaken, geen schuldigen', individuele input voor de groepsdiscussie om groepsdenken te voorkomen, bespreking hoofdpunten, besluiten), de exacte vragen om vaagheden te vermijden ('op welk moment wisten we dat de deadline zou verschuiven? wat hield ons tegen dit te zeggen?'), en de techniek om [gevoelig onderwerp] te bespreken zonder dat het een tribunaal wordt.

Output-formaat leerpunten: elk leerpunt wordt een actiegerichte regel voor het volgende project ('vanaf nu doen we...'), met een verantwoordelijke. Maximaal 5 regels: meer wordt niet toegepast.

Business case opstellen voor go/no-go

Een gestructureerd go/no-go dossier: belangen, opties, kosten, risico's en besliskriteria.

Je bent een ervaren projectdirecteur. Help me bij het bouwen van de business case voor project [naam project] binnen [bedrijf]. Probleem of kans aan de basis: [context]. Verwachte voordelen: [gehoopte baten]. Maximaal budget: [bedrag]. Bekende alternatieven: [alternatieven, inclusief niets doen].

Structureer het dossier in 6 delen: op te lossen probleem en kosten van niets doen, mogelijke opties (inclusief status quo) met voor- en nadelen, ruwe schatting van kosten en doorlooptijd per optie in bandbreedtes, verwachte voordelen gekoppeld aan meetbare KPI's, belangrijkste risico's per optie, beargumenteerd advies.

Beperkingen: elk voordeel moet gekoppeld zijn aan een controleerbare indicator, anders classificeren als 'niet-meetbare gok'. Formuleer 5 go/no-go besliskriteria die de commissie kan afvinken. Eindig met een lijst ontbrekende informatie die de studie verzwakt en wie deze moet leveren.

Project charter opstellen voor kleine projecten

Een charter van één pagina om een klein project te kaderen zonder de zwaarte van een volledig PID.

Schrijf een project charter van één pagina voor een klein project. Project: [beschrijving in 2 zinnen]. Aanvrager: [aanvrager]. Betrokkenen: [personen en beschikbare tijd]. Gewenste deadline: [datum]. Eventueel budget: [bedrag of geen].

Verplicht formaat, maximaal één pagina: doel in één meetbare zin, eindresultaat en hoe we herkennen dat het klaar is, wat buiten de scope valt (minimaal 3 regels), wie beslist bij knopen doorhakken, mijlpalen (maximaal 3), het belangrijkste risico en de beheersing daarvan.

Richtlijnen: geen projectmanagement-jargon, zinnen die een leek direct begrijpt. Als informatie ontbreekt, schrijf dan 'TE VERHELDEREN met [persoon]' in plaats van te verzinnen. Eindig met de 2 belangrijkste vragen voor de aanvrager voor de start.

Requirements-interviews voorbereiden

Interviewgidsen per profiel om de werkelijke behoeften te achterhalen voordat de scope vaststaat.

Ik start het project [naam project] voor [bedrijf] en moet de behoeften ophalen. Te interviewen personen: [lijst profielen, bijv. directie, eindgebruikers, IT]. Wat het project moet opleveren: [beoogd resultaat]. Beschikbare tijd per interview: [duur].

Bereid per profiel een interviewgids voor: 8 tot 10 open vragen van breed naar specifiek. Maak onderscheid tussen vragen over de huidige werkwijze (irritaties, workarounds, volumes) en vragen over de toekomstige behoefte. Voeg per profiel 2 'strikvragen' toe die onuitgesproken behoeften naar boven halen, zoals 'wat doe je als de huidige tool niet volstaat?'.

Richtlijnen: vermijd sturende vragen en ja/nee-vragen. Lever ook een synthese-sjabloon om interviews te consolideren: expliciete behoeften, afgeleide behoeften, tegenstrijdigheden tussen profielen en opvallende quotes.

User stories met acceptatiecriteria schrijven

Ruwe behoeften omzetten in testbare user stories met controleerbare criteria.

Zet deze ruwe behoeften om in user stories voor het realisatieteam. Project: [naam en korte beschrijving]. Betrokken gebruikers: [gebruikersprofielen]. Geuite behoeften: [lijst behoeften].

Produceer voor elke behoefte: de user story in het formaat 'Als [profiel], wil ik [actie] zodat [voordeel]', 3 tot 5 acceptatiecriteria geformuleerd als binaire checks (ja/nee, geen vage termen als 'snel' of 'gebruiksvriendelijk' zonder drempelwaarde), en vragen voor de aanvrager als de behoefte te vaag is.

Richtlijnen: een story moet in enkele dagen uitvoerbaar zijn, stel anders een splitsing voor. Signaleer oplossingen die vermomd zijn als behoeften en herformuleer ze. Presenteer in een tabel: story, acceptatiecriteria, geschatte omvang (S/M/L), open vragen. Eindig met de afhankelijkheden tussen stories.

Een overvolle backlog prioriteren

De backlog rangschikken op waarde en inspanning, zodat keuzes verdedigbaar worden.

Help me de backlog van project [naam project] te prioriteren. Openstaande items: [lijst verzoeken met korte beschrijving]. Teamcapaciteit: [capaciteit, bijv. 15 mandagen per maand]. Prioritair doel voor dit kwartaal: [doel]. Belanghebbenden met de meeste druk: [politieke context].

Beoordeel elk item op twee assen: waarde (bijdrage aan kwartaaldoel, aantal gebruikers, kosten van niet oplossen) en geschatte inspanning (relatieve omvang). Deel in 4 categorieën in: nu doen (hoge waarde, lage inspanning), plannen (hoge waarde, hoge inspanning), opvulling (lage waarde, lage inspanning), expliciet weigeren of uitstellen (lage waarde, hoge inspanning).

Richtlijnen: druk van een aanvrager is geen criterium voor waarde, maar lijst weigeringen apart op voor een toelichting. Lever de rangschikking in een tabel met rechtvaardiging, en schrijf de 3 lastigste weigeringsberichten: kort en feitelijk.

Een kwartaalroadmap opstellen

Resultaatgerichte roadmap per kwartaal, inclusief de onderbouwing van keuzes.

Stel de roadmap op voor de komende 2 kwartalen voor [product of project] van [bedrijf]. Jaardoelen: [doelen]. Kandidaat-projecten: [lijst met ideeën]. Teamcapaciteit: [omvang en beschikbaarheid]. Reeds gedane toezeggingen: [niet-onderhandelbare afspraken].

Organiseer de roadmap per kwartaal door elke regel te formuleren als een verwacht resultaat, niet als een feature ('verwerkingstijd aanvragen verkorten' in plaats van 'module X ontwikkelen'). Per kwartaal: max 2 of 3 grote blokken, het beoogde resultaat, de KPI voor succes, en afhankelijkheden.

Richtlijnen: houd 20% van de capaciteit vrij voor onvoorziene zaken en vermeld dit expliciet. Lijst op wat bewust niet wordt gedaan en waarom. Lever twee versies: een gedetailleerde voor het team en een versie van 5 regels voor de directie. Signaleer items waarvan de waarde te vaag is.

Projecturen realistisch inschatten

Schattingen in bandbreedtes met expliciete aannames en correctie voor optimisme-bias.

Help me de uren voor project [naam project] in te schatten. Inhoud: [lijst werkpakketten of taken]. Team: [profielen en ervaring]. Beschikbare historie: [vergelijkbare projecten en hun werkelijke duur, indien bekend].

Per pakket: een schatting in bandbreedtes (optimistisch, waarschijnlijk, pessimistisch) in plaats van één getal, de aannames onder de schatting (wat moet waar zijn?), en de factor die het scenario pessimistisch zou maken.

Richtlijnen: als er historie is, vergelijk de schatting met de werkelijke duur van toen en verklaar het verschil. Voeg systematisch 'vergeten' uren toe: bugfixing na oplevering, coördinatie, inwerken, geplande afwezigheid. Presenteer het totaal in 3 scenario's. Als het verschil tussen optimistisch en pessimistisch meer dan 100% is, geef dan aan welke info nodig is om onzekerheid te verkleinen.

Projectbudget en maandelijkse monitoring

Volledig projectbudget per post, inclusief monitoringsysteem en waarschuwingen.

Bouw het volledige budget voor project [naam project] van [bedrijf]. Geplande interne uren: [mandagen per profiel en uurtarief]. Externe inkoop: [lijst]. Duur: [duur]. Goedgekeurd budget: [bedrag].

Produceer eerst het budget per post: gewaardeerde interne uren, externe diensten, licenties, bijkomende kosten, en een post onvoorzien (onderbouw het percentage op basis van onzekerheid). Signaleer overschrijdingen direct bij de opbouw.

Stel daarna het maandelijkse monitoringsysteem op: tabel verbruikt vs budget, herberekende 'estimate to complete' (niet alleen wat er nog over is), prognose bij afronding, en 2 drempelwaarden voor waarschuwingen aan de sponsor. Eindig met de 3 meest voorkomende budgetoverschrijdingen bij dit type project en hoe ze vroegtijdig te herkennen.

Risicoregister voor een project opstellen

Een geprioriteerd risicoregister met impact, kans en beheersmaatregelen per groot risico.

Stel het risicoregister op voor project [naam project]. Context: [beschrijving project, deadline, belangen]. Reeds bekende risico's: [geïdentificeerde risico's]. Externe afhankelijkheden: [leveranciers, andere teams, validaties].

Vul mijn lijst aan met typische risico's voor dit soort projecten in 4 categorieën: menselijk (vertrek, overbelasting, gebrek aan kennis), technisch, organisatorisch (trage besluitvorming, uitdijende scope), extern. Per risico: concrete beschrijving, waarschijnlijkheid (laag/midden/hoog), impact (laag/midden/hoog), resulterende score, vroegtijdig signaal, preventieve maatregel, terugvalplan, eigenaar.

Richtlijnen: formuleer elk risico als een gebeurtenis ('leverancier levert maand te laat'), nooit als vaag thema ('planning'). Beperk tot de 10 belangrijkste risico's. Beschrijf het review-ritueel: frequentie en te stellen vragen.

Stakeholdermap van een project maken

Een invloed/houding-matrix van betrokkenen, met een passend engagementplan per persoon.

Breng de stakeholders in kaart voor project [naam project] bij [bedrijf]. Geïdentificeerde actoren: [lijst personen/entiteiten met rol]. Wat het project voor hen verandert: [verwachte impact]. Reeds waargenomen steun of weerstand: [context].

Positioneer elke actor op twee assen: invloed op het project (kan het blokkeren of versnellen) en huidige houding (voorstander, neutraal, sceptisch). Per invloedrijke actor: wat heeft die te winnen of te verliezen, waarschijnlijke tegenwerping in eigen woorden, en passende actie (betrekken bij besluiten, regelmatige info, 1-op-1 gesprek voor aankondigingen).

Richtlijnen: verwar het organogram niet met werkelijke invloed, noem ook informele leiders. Lever het plan in een tabel: actor, huidige positie, benodigde positie voor succes, acties, eigenaar, deadline. Eindig met de 2 prioritaire actoren voor deze week.

Communicatieplan voor een project opstellen

Wie, wat, hoe vaak en via welk kanaal informeren, zonder mensen te overladen.

Stel het communicatieplan op voor project [naam project]. Doelgroepen: [doelgroepen, bijv. sponsor, team, eindgebruikers, andere afdelingen]. Projectduur: [duur]. Bekende momenten: [mijlpalen, livegang, aankondigingen]. Beschikbare kanalen: [e-mail, intranet, overleg, narrowcasting].

Definieer per doelgroep: wat moeten ze weten (en alleen dat), de frequentie, het kanaal, het formaat (2 regels, één A4, meeting), en wie de boodschap maakt. Maak onderscheid tussen structurele communicatie (voortgang) en incidentele communicatie (kick-off, livegang, incident, afronding).

Richtlijnen: elke communicatie moet de vraag 'wat betekent dit voor mij?' beantwoorden, anders schrappen. Schrijf de concepttekst voor de kick-off en de livegang-aankondiging. Presenteer in een tabel en noem de 3 grootste communicatiefouten bij dit type project.

RACI-matrix voor een project opstellen

Ondubbelzinnige verdeling van verantwoordelijkheden en detectie van rolconflicten.

Bouw de RACI-matrix voor project [naam project]. Hoofdactiviteiten: [lijst activiteiten of deliverables]. Actoren: [personen of functies]. Reeds geconstateerde onduidelijkheid: [context, bijv. twee mensen denken dat ze over hetzelfde beslissen].

Ken per activiteit rollen toe: R (Responsible - voert uit), A (Accountable - eindverantwoordelijk, slechts één per regel), C (Consulted - vooraf raadplegen), I (Informed - achteraf informeren). Licht niet-voor-de-hand-liggende keuzes toe.

Kwaliteitscheck: nooit twee A's op één regel, geen regel zonder R, signaleer actoren die overal 'C' zijn (bottleneck) of actoren zonder rol. Presenteer in een tabel, noem de 3 meest conflictgevoelige regels met advies, en geef de vragen mee voor het teamoverleg voor definitieve vaststelling.

Project kick-off voorbereiden

Het volledige verloop van een kick-off die het team op één lijn brengt en motiveert.

Bereid de kick-off voor van project [naam project]. Deelnemers: [deelnemers en rollen]. Duur: [duur, bijv. 1 uur]. Status kadering: [PID goedgekeurd of in concept]. Gevoelige punten: [scepticisme, historie van mislukte projecten op dit vlak].

Lever op: de getimede agenda (waarom dit project en waarom nu, concreet eindresultaat, out-of-scope, wie doet wat, mijlpalen, werkafspraken, vragen), de 3 kernboodschappen voor de deelnemers, en hoe om te gaan met [gevoelig punt] zonder dat het de sfeer verpest of wordt ontweken.

Richtlijnen: een kick-off is geen eenrichtingsverkeer. Plan 2 interactieve momenten (bijv. risico-inventarisatie, inventarisatie persoonlijke beperkingen). Schrijf de uitnodiging met agenda en voorbereiding, en lijst op wat VOOR de kick-off besloten moet zijn om vaagheid te voorkomen.

Agenda en facilitatie van een stuurgroep

Een stuurgroepoverleg gericht op besluitvorming, niet op het voorlezen van de status.

Bereid de volgende stuurgroep voor van project [naam project]. Deelnemers: [stuurgroepleden]. Duur: [duur]. Projectstatus: [voortgang, knelpunten, budget]. Benodigde besluiten: [verwachte besluiten met opties]. Onderwerpen die de discussie kunnen kapen: [gevoelige zaken].

Stel de agenda op rondom de te nemen besluiten: elk besluit krijgt een tijdslot, voorbereide opties (2 of 3, met voor/nadelen en advies), en de consequentie als het besluit wordt uitgesteld. De voortgang wordt in max. 10 minuten behandeld op basis van een vooraf gestuurd document.

Lever: de getimede agenda, de exacte formulering van elk besluitverzoek, de techniek om zijpaden over [gevoelig onderwerp] beleefd af te kappen, en een sjabloon voor de besluitenlijst (binnen 24u te versturen). Eindig met wat 48u vooraf naar de deelnemers moet.

Presentatie voor de stuurgroep structureren

De opzet per slide voor een stuurgroeppresentatie van maximaal 10 slides.

Structureer de presentatie voor de stuurgroep van project [naam project]. Gegevens van de maand: voortgang [gepland vs werkelijk], budget [verbruikt vs totaal], risico's [status], benodigde besluiten [lijst], highlights [gebeurtenissen].

Maak een opzet per slide, max. 10 slides: samenvatting (status, kernboodschap, besluiten), voortgang per werkpakket met afwijkingen, budgetverloop, risico's met gewijzigde status, zoom op het knelpunt van de maand met opties/advies, gevraagde besluiten (één slide per besluit), volgende stappen.

Per slide: titel als boodschap ('Pakket 2 loopt in op schema', niet 'Voortgang pakket 2'), inhoud in max. 5 bullets, en wat je mondeling toelicht (niet op slide). Richtlijnen: geen herhaling van context die ze al kennen, cijfers afgerond en vergeleken. Eindig met de check: als ze alleen slide 1 lezen, weten ze dan genoeg?

Wijzigingsbeheer (Change Request) inrichten

Een simpel proces om wijzigingen in scope te beoordelen zonder het project te laten ontsporen.

Richt het proces voor wijzigingsverzoeken in voor project [naam project]. Context: [bron van verzoeken, bijv. klant voegt wensen toe, directie verandert van koers]. Bestaande overleggen: [meetings/commissies]. Beschikbare marge: [resterende tijd/budget].

Definieer: het minimale aanvraagformulier (omschrijving, aanvrager, onderbouwing, urgentie), de 4 vaste beoordelingsvragen (impact tijd, impact budget, impact op andere pakketten, wat als we het niet doen?), wie beslist op basis van impact (stel drempelwaarden voor), en hoe besluiten worden vastgelegd in een 'change log'.

Schrijf ook 3 standaardreacties: verzoek geaccepteerd met impact, verzoek uitgesteld naar volgende fase, verzoek geweigerd met onderbouwing. Richtlijnen: het proces moet op een half A4 passen, anders wordt het niet gebruikt. Geen mondelinge toezeggingen buiten de log om. Eindig met hoe dit proces aan een veeleisende aanvrager te presenteren.

Onderhandelen over een onhaalbare deadline

Onderbouwde argumentatie en opties voor wanneer de gevraagde datum niet haalbaar is.

Help me bij het voorbereiden van de heronderhandeling van een onhaalbare deadline. Project: [naam project]. Gevraagde deadline: [datum]. Mijn overtuiging: er is [realistische duur] nodig omdat [redenen: urenschatting, afhankelijkheden, team]. Belang van de datum: [waarom deze datum, indien bekend]. Sponsor: [profiel sponsor].

Stel op: de feitelijke onderbouwing van het gat (uren vs capaciteit in simpele cijfers), plus 3 eerlijke opties: deadline halen door scope te verkleinen (benoem wat eruit gaat), volledige scope behouden door deadline te verschuiven, extra middelen inzetten met kosten en beperkingen (nieuwe mensen zijn niet direct productief).

Richtlijnen: zeg nooit 'onmogelijk' zonder alternatief. Accepteer geen compromis dat niet doorgerekend is. Bereid antwoorden voor op 3 bezwaren: 'zoek het maar uit' en 'we zien wel'. Formaat: één pagina argumentatie plus tabel met 3 opties en consequenties.

Herstelplan voor een vertraagd project

Diagnose van de vertraging en een realistisch herstelplan, zonder magische tijdsbesparing.

Stel een herstelplan op voor project [naam project], dat [duur vertraging] achterloopt op de deadline van [datum]. Geïdentificeerde oorzaken: [oorzaken]. Resterend werk: [resterende taken met schattingen]. Team: [samenstelling]. Speelruimte: [extra budget, onderhandelbare scope].

Start met de diagnose: komt het door te lage schattingen, scope creep, weggetrokken resources of externe blokkades? Dit bepaalt het plan. Bouw het herstel op basis van reële knoppen: scope verkleinen, taken parallelliseren, overbodige taken schrappen, extra inzet alleen op het kritieke pad.

Richtlijnen: verboden om schattingen 'in te dikken' zonder onderbouwing, verboden om testtijd te schrappen. Lever op: de nieuwe betrouwbare planning, wat er is opgeofferd, de 2 voorwaarden voor succes, en de boodschap aan de sponsor waarin de vertraging wordt erkend zonder excuses.

Een blokkade escaleren zonder relaties te schaden

Een feitelijk escalatiebericht met opties en de kosten van niets doen, klaar voor verzending.

Bereid de escalatie voor van een blokkade in project [naam project]. Blokkade: [beschrijving, bijv. uitblijven besluit, resource niet vrijgegeven]. Sinds: [datum]. Reeds ondernomen stappen: [pogingen tot oplossing]. Ontvanger escalatie: [persoon en niveau]. Betrokkenen bij de blokkade: [actoren en gevoeligheden].

Schrijf het escalatiebericht: herhaling van de blokkade in 3 feitelijke regels met data, concrete gevolgen van niets doen (verloren dagen, kosten, bedreigde mijlpalen), 2 of 3 opties voor deblokkering met mijn advies, en het gevraagde besluit met deadline.

Richtlijnen: geen persoonlijke verwijten, laat feiten en data spreken. De ontvanger moet kunnen beslissen op basis van dit bericht alleen. Bereid ook de mondelinge 'elevator pitch' van 60 seconden voor, en een bericht aan de betrokkenen zodat ze de escalatie niet via via horen.

Actiebewaking tussen vergaderingen

Een systeem voor opvolging en herinneringen dat acties vooruit helpt zonder te micromanagen.

Organiseer de opvolging van acties voor project [naam project] tussen de vergaderingen door. Huidige situatie: [probleem, bijv. acties worden half gedaan, herinneringen voelen als politieagent spelen]. Vergaderfrequentie: [frequentie]. Beschikbare tools: [spreadsheet, ticketsysteem, chat].

Stel een systeem voor: formaat van de actielijst (actie met werkwoord en resultaat, één eigenaar, deadline, status), het update-ritueel (wie, wanneer, hoe lang), en de escalatie-ladder: automatische reminder op D-2, individueel feitelijk bericht op de deadline, bespreking in overleg pas bij tweede overschrijding.

Schrijf sjablonen voor reminders op de 3 niveaus: kort en zonder verwijt. Richtlijnen: een actie zonder deadline of eigenaar wordt niet geaccepteerd. De lijst mag niet groter zijn dan wat het team aankan. Eindig met hoe dit aan het team te presenteren als ondersteuning in plaats van controle.

Projectdashboard ontwerpen

KPI's die de werkelijke koers van het project tonen, in plaats van schijncontrole.

Ontwerp het dashboard voor project [naam project]. Type project: [aard en resultaat]. Duur: [duur]. Aandachtspunten: [bijv. strakke deadline, krap budget, kritieke kwaliteit]. Beschikbare data: [uren, budget, tickets].

Selecteer max. 6 tot 8 KPI's in 3 blokken: voortgang (gerealiseerd vs gepland in afgeronde deliverables, niet in percentages van lopende taken), gezondheid (acties te laat, openstaande besluiten en ouderdom, stijgende risico's), middelen (verbruikt vs budget, teambelasting).

Per KPI: definitie, bron, frequentie, onderbouwde drempelwaarde. Richtlijnen: ban niet-controleerbare statusupdates ('80% klaar') ten gunste van binair klaar/niet-klaar. Elke KPI moet leiden tot een mogelijke actie bij rood. Beschrijf de wekelijkse review van 15 minuten: volgorde, vragen en wanneer te escaleren.

Maandrapportage voor de directie

Een maandelijkse samenvatting op één pagina met koers, keuzes en waarschuwingen.

Schrijf de maandrapportage van project [naam project] voor [ontvangers, bijv. directie/MT]. Gegevens van de maand: resultaten [geleverd], afwijkingen [vertraging/overschrijding], budget [verbruikt vs gepland], risico's [status], genomen besluiten, waarschuwingen.

Formaat van één pagina: algemene koers in 2 zinnen (landt het project op tijd/binnen budget, ja/nee, en wat is er veranderd?), resultaten van de maand in 3 bullets gekoppeld aan mijlpalen, afwijkingen met oorzaak en aanpak (geen afwijking zonder plan), budget met prognose, escalaties naar directie met expliciet verzoek.

Richtlijnen: de directie leest veel van dit soort rapporten, vermijd zelfpromotie en vulling. Elke waarschuwing moet een specifiek verzoek bevatten (besluit, middelen). Afwijkingen en slecht nieuws bovenaan, niet onderaan verstoppen.

Resources verdelen over meerdere projecten

Een methode voor prioritering tussen projecten waarbij de gevolgen van keuzes zichtbaar worden.

Help me bij het verdelen van resources over concurrerende projecten. Lopende projecten: [lijst projecten met deadline, belang en status]. Gedeelde resources: [personen en huidige verdeling]. Huidig conflict: [beschrijving resourceconflict]. Wie beslist uiteindelijk: [persoon/orgaan].

Maak eerst een eerlijke foto: wie werkt aan wat in werkelijke percentages (niet theoretisch), en wie zit boven de 100%. Stel daarna een wegingskader op: belang voor het bedrijf, kosten van vertraging per project, onomkeerbaarheid (deadline die verloopt), externe verplichtingen.

Pas dit kader toe op het conflict en maak 2 scenario's: wat wint en verliest elk project per scenario, en de resulterende einddatum. Richtlijnen: los het conflict niet op door mensen te overbelasten of door parttime inzet op 3 projecten te beloven. De onderbouwing moet verdedigbaar zijn naar de 'verliezende' projectleiders.

Sprintplanning voorbereiden

Een sprintplanning met een helder doel, realistische capaciteit en een haalbaar commitment.

Bereid de planning voor van de volgende sprint voor team [team] op project [naam project]. Sprintduur: [duur]. Capaciteit: [aanwezigen, verlof, tijd buiten sprint: support, meetings]. Geprioriteerde backlog: [items met schatting]. Restpunten vorige sprint: [niet afgeronde items].

Structureer de sessie: berekening reële capaciteit (beschikbare tijd minus overhead en buffer), formulering van het sprintdoel in één zin (resultaat, geen lijst tickets), selectie van items binnen capaciteit (start met restpunten), gezamenlijke check of elk item begrepen en 'Ready' is.

Richtlijnen: weiger items zonder acceptatiecriteria. Als de druk hoger is dan de capaciteit, is het antwoord een keuze tussen items, nooit stilzwijgend meer accepteren. Lever de getimede agenda, het sprintdoel en 3 signalen tijdens de sprint dat het commitment niet gehaald gaat worden.

Sprint retrospective met concrete acties

Een kort en terugkerend retro-format, met variatie om sleur te voorkomen.

Bereid de facilitatie voor van de sprint retrospective voor team [team]. Duur: [duur, bijv. 45 min]. Huidige sfeer: [context, bijv. sleur, recente spanning, nieuw team]. Actuele onderwerpen: [gebeurtenissen afgelopen sprint]. Acties uit vorige retro's: [status].

Lever op: de getimede agenda startend met de check op vorige acties (een retro zonder opvolging sterft uit), een werkvorm passend bij de sfeer met instructies, verdiepingsvragen als het oppervlakkig blijft, en de selectiemethode: max. 2 verbeteracties, gekozen door het team, elk met eigenaar en deadline in de volgende sprint.

Richtlijnen: geen vage acties als 'beter communiceren', elke actie beschrijft een waarneembare verandering. Zaken buiten de invloedssfeer van het team worden apart genoteerd voor escalatie. Stel ook 2 alternatieve werkvormen voor voor de volgende keer.

Een nuttige Daily Standup inrichten

Regels voor een kort dagelijks overleg dat blokkades opspoort in plaats van agenda's voorleest.

Kader de Daily Standup voor team [team] op project [naam project]. Huidige situatie: [probleem, bijv. duurt 30 min, voelt als verantwoording aan de baas, mensen haken af]. Teamgrootte: [aantal]. Werkwijze: [kantoor, remote, hybride].

Stel het doelformaat voor: maximale duur, vaste tijd, inhoud gericht op coördinatie (wat is klaar sinds gisteren, wat blokkeert of gaat blokkeren, wat heb ik van anderen nodig?). Zaken die geen coördinatie zijn (technische discussies, probleemoplossing) worden genoteerd en direct daarna besproken met alleen de betrokkenen.

Geef: de spelregels (team praat met elkaar, wisselende facilitator), de zin om zijpaden af te kappen zonder te kwetsen, aanpassingen voor [werkwijze], en 3 signalen dat een Daily niet meer werkt met de oplossing. Eindig met het bericht aan het team over het nieuwe formaat.

Definition of Done en kwaliteitscriteria bepalen

Een gedeeld begrip van 'klaar' om deliverables die voor 90% af zijn te voorkomen.

Help team [team] bij het definiëren van de Definition of Done (DoD) voor project [naam project]. Type deliverables: [aard, bijv. software, training, rapporten]. Geconstateerde problemen: [symptomen, bijv. items worden heropend, wisselende kwaliteit, gaten bij acceptatie].

Bouw de DoD op 3 niveaus: wat maakt een item 'klaar' (controleerbare criteria: peer-reviewed, getest, gedocumenteerd, gevalideerd door wie), wat is expliciet uitgesloten om realistisch te blijven, en toegestane uitzonderingen met de regel hoe deze vast te leggen.

Richtlijnen: max. 8 criteria, allemaal ja/nee-checks, geen criteria die het team nu niet kan waarmaken (anders wordt de DoD genegeerd bij haast). Lever ook: de methode om dit in een workshop te laten adopteren, de regel voor lopend werk, en het ritueel om de DoD na een paar weken te evalueren.

Gebruikersacceptatietest (GAT) en PV organiseren

Een testplan met geprioriteerde testcases, regels voor bevindingen en een besluitvormingsdocument.

Organiseer de gebruikersacceptatietest (GAT) voor project [naam project]. Te testen deliverable: [beschrijving]. Beschikbare testers: [profielen]. Geplande duur: [duur]. Bestaande acceptatiecriteria: [criteria, of geen].

Stel op: het testplan met testcases georganiseerd per gebruikersproces (niet per scherm), elke case beschreven in input, actie, verwacht resultaat; prioritering (blokkerend voor livegang, belangrijk, wenselijk); regels voor classificatie van bevindingen (bugs) met voorbeelden; het proces voor herstel en hertesten.

Lever ook het sjabloon voor het Proces-Verbaal (PV) van acceptatie: wat is getest, bevindingen per niveau, besluit (acceptatie, acceptatie onder voorbehoud met data, afkeur) en ondertekenaars. Richtlijnen: een test zonder realistische data bewijst niets. Voorbehouden moeten een eigenaar en deadline hebben.

Livegang-plan en checklist voor de overgang

Het draaiboek van uur tot uur voor een livegang, inclusief go/no-go criteria en rollback-plan.

Bereid het draaiboek voor de livegang voor van [resultaat/systeem] voor project [naam project]. Streefdatum: [datum]. Impact op gebruikers: [wie en hoeveel]. Tijdvenster: [bijv. weekend, nacht]. Betrokkenen: [personen en rollen]. Rollback mogelijk: [ja/nee/deels, en hoe].

Stel op: de checklist vooraf (technische vereisten, goedkeuringen, communicatie, back-ups, beschikbaarheid sleutelfiguren), het draaiboek van uur tot uur met verantwoordelijke en succes-criterium per stap, go/no-go beslismomenten met wie beslist, het rollback-plan (wanneer activeren en hoe uitvoeren), en nazorg in de eerste uren/dagen.

Richtlijnen: elke stap heeft een controleerbaar succes-criterium, geen 'het zou goed moeten zijn'. Het rollback-plan moet even gedetailleerd zijn als de livegang zelf. Eindig met het bericht aan gebruikers voor en na de overgang.

Continuïteit waarborgen tijdens migratie

Organisatie van de overgangsperiode waarin het oude en nieuwe systeem naast elkaar bestaan.

Organiseer de bedrijfscontinuïteit tijdens de migratie van [oud systeem/proces] naar [nieuw systeem/proces] bij [bedrijf]. Geplande overgangsduur: [duur]. Kritieke activiteiten: [activiteiten]. Betrokken teams: [teams]. Risicoperiode: [bijv. jaarafsluiting, seizoenspiek].

Behandel de valkuilen: welk systeem is leidend voor welk type data tijdens de co-existentie (duidelijke regels per case), hoe dubbele invoer te voorkomen of strak te organiseren, wie handelt lopende zaken af die in het oude zijn gestart en in het nieuwe eindigen, en hoe bevriezen of synchroniseren we data bij de definitieve overstap.

Lever op: tabel met kritieke activiteiten en hun werkwijze tijdens de overgang, de 'bron van waarheid' regels, het versterkte supportplan voor de eerste weken, en de 3 meest waarschijnlijke incidentscenario's met bijbehorende acties.

Project netjes afsluiten en borgen

Checklist voor administratieve, contractuele en documentaire afsluiting van een project.

Bereid de afsluiting voor van project [naam project], waarvan het resultaat is geaccepteerd op [datum]. Projectonderdelen: [leveranciers, budget, documentatie, team]. Openstaande punten: [eventuele restpunten uit acceptatie].

Stel de volledige afsluitchecklist op: contractueel (afrekening leveranciers, afhandeling voorbehouden, intrekken toegangen externen), financieel (stopzetten urenschrijven, balans werkelijk vs budget met uitleg, sluiten budgetregels), documentatie (archivering, wat moet over 2 jaar vindbaar zijn en voor wie), menselijk (herplaatsing team, persoonlijke bedankjes), overdracht (wie wordt verantwoordelijk voor beheer/exploitatie, inclusief supportafspraken).

Richtlijnen: maak onderscheid tussen wat de afsluiting blokkeert en wat later kan. Een project dat voor '98% klaar' is en 6 maanden doorsleept is duur; stel een harde einddatum vast. Lever ook het sjabloon voor de projectevaluatie op één pagina.

Projectoverdracht tussen projectleiders

Overdrachtsdossier en inwerkplan om van piloot te wisselen zonder de draad kwijt te raken.

Organiseer de overdracht van project [naam project] tussen [vertrekkende projectleider] en [nieuwe projectleider]. Reden vertrek: [reden en opzegtermijn]. Status: [voortgang, hete hangijzers, komende mijlpalen]. Beschikbare overdrachttijd: [duur overlap].

Stel het overdrachtsdossier op met focus op wat NIET in documenten staat: historie van besluiten en hun achtergrond, mondelinge toezeggingen aan sponsor/klant, gevoelige onderwerpen en onderlinge verhoudingen, risico's die informeel bewaakt worden, de werkelijke status van werkpakketten buiten de officiële rapportage.

Organiseer de overlap: meetings waar de vertrekker de nieuwe persoon introduceert (sponsor, team), volgorde van onderwerpen op urgentie, en het bericht over de wisseling dat vertrouwen wekt. Richtlijnen: overdracht moet controleerbaar zijn; maak een lijst vragen die de nieuwe persoon aan het eind zelfstandig moet kunnen beantwoorden.

Nieuw teamlid onboarden in een project

Een inwerktraject dat een nieuwkomer snel productief maakt zonder het hele team te belasten.

Bereid de onboarding voor van [nieuwkomer, profiel] voor team [naam project] op [datum]. Status project: [voortgang en context]. Verwachte rol: [taken]. Beschikbare tijd team voor begeleiding: [beperking].

Stel het traject voor de eerste 2 weken op: het leespakket voor dag 1 beperkt tot de essentie (PID, laatste voortgangsrapport, risicoregister, begrippenlijst), 4 kennismakingsgesprekken met de juiste personen en hun doel, een eerste nuttige bijdrage in week 1 (kies wat passend is bij [rol]), en een buddy met een dagelijkse check-in van 10 minuten.

Richtlijnen: voorkom 15 passieve meetings; de nieuwkomer leert door te doen. Benoem expliciet wat niemand vertelt: gevoeligheden, 'no-go' onderwerpen, werkelijke besluitvorming. Lever de planning, de leeslijst en de vragen die de nieuwkomer na 15 dagen moet kunnen beantwoorden.

Conflict tussen teamleden oplossen

Een stappenplan voor bemiddeling bij een conflict dat de projectvoortgang belemmert.

Help me een conflict in mijn projectteam op te lossen. Context: [feitelijke beschrijving conflict tussen twee personen, zonder oordeel], op project [naam project]. Waargenomen impact: [effecten: informatie achterhouden, gespannen sfeer, vertraging]. Mijn rol: [projectleider, met/zonder hiërarchische lijn]. Historie: [duur conflict, eerdere pogingen].

Stel een aanpak in 3 fasen voor: eerst individuele gesprekken (vragen om beide versies te begrijpen zonder partij te kiezen, valkuilen zoals scheidsrechter spelen), daarna een gezamenlijk gesprek (kader scheppen, terug naar feiten als het persoonlijk wordt, afspraken maken over 2 of 3 werkafspraken), en tenslotte opvolging (hoe controleren of afspraken nagekomen worden zonder te spioneren).

Richtlijnen: blijf in de rol van projectleider; zaken voor HR of lijnmanagement worden doorgezet. Niemand mag als 'schuldige' uit het traject komen. Geef aan welke signalen directe escalatie vereisen.

Een falende externe leverancier aanspreken

Een escalatieladder, van feitelijke waarschuwing tot voorbereiding op beëindiging.

Help me een leverancier aan te spreken die ondermaats presteert op project [naam project]. Leverancier: [bedrijf en dienst]. Geconstateerde tekortkomingen: [gedateerde feiten: vertraging, slechte kwaliteit, wisseling contactpersoon, loze beloften]. Contractueel kader: [wat zegt het contract: deliverables, deadlines, boetes]. Afhankelijkheid: [hoe vervangbaar is deze partij?].

Bouw de stappen op: eerst het gesprek (feitelijk dossier van afwijkingen tussen afspraak en werkelijkheid; agenda van de meeting waarin een gedateerd herstelplan wordt geëist in plaats van excuses), daarna strakke monitoring (korte mijlpalen, verslag na elk contact), en tenslotte voorbereiding op een alternatief (discreet starten als de afhankelijkheid groot is).

Richtlijnen: leg alles schriftelijk vast na mondeling overleg voor dossieropbouw. Blijf feitelijk en zakelijk; geen dreigementen die niet uitgevoerd kunnen worden. Lever: het dossieroverzicht, de uitnodigingsmail, de agenda en de objectieve criteria voor beëindiging.

Programma van Eisen (PvE) voor aanbesteding

Een document dat de behoefte en kaders beschrijft zonder de oplossing voor te schrijven.

Schrijf het Programma van Eisen (PvE) voor een uitvraag naar leveranciers voor [onderwerp, bijv. nieuwe website, tool, dienstverlening] voor [bedrijf]. Behoefte: [beschrijving probleem en doel]. Technische en organisatorische context: [huidige situatie, beperkingen]. Indicatief budget: [bandbreedte, of bewust niet genoemd]. Planning: [deadlines].

Structuur: introductie bedrijf en context (half A4), het op te lossen probleem en doelen geformuleerd als resultaten (beschrijf de behoefte, niet de oplossing, tenzij noodzakelijk), scope en uitsluitingen, niet-onderhandelbare eisen (technisch, juridisch, AVG/GDPR), gewenste deliverables, selectiecriteria met weging, verloop van de procedure (vragen, inleverdatum, presentaties), en verplicht format voor de offerte om vergelijking mogelijk te maken.

Richtlijnen: elke eis moet testbaar zijn bij oplevering. Maak onderscheid tussen 'knock-out' criteria en wensen. Eindig met 5 vragen voor de presentatieronde die laten zien of de leverancier de behoefte echt begrijpt.

Offertes vergelijken met een objectieve matrix

Een gewogen analysematrix om offertes te vergelijken zonder verblind te worden door de vorm.

Bouw de vergelijkingsmatrix voor de ontvangen offertes voor [onderwerp]. Offertes: [aantal en korte samenvatting: prijs, levertijd, aanpak]. Belangrijkste criteria: [prioriteiten, bijv. deadline, support, Total Cost of Ownership, continuïteit]. Waargenomen signalen: [bijv. extreem lage prijs, generiek antwoord].

Bouw de matrix: criteria gegroepeerd (begrip van de vraag, voorgestelde aanpak, kwaliteit team, volledige prijs inclusief verborgen kosten, vergelijkbare referenties, contractvoorwaarden), weging op basis van mijn prioriteiten, scoreschaal met beschrijving per niveau om subjectiviteit te beperken.

Pas de matrix toe en signaleer: onverklaarbare prijsverschillen (een lage prijs verbergt vaak een beperkte scope), beloofde experts die niet op het project komen, terugkerende verborgen kosten. Lever de ingevulde tabel, verhelderingsvragen per offerte, en een beargumenteerd advies in 5 regels.

Verandermanagementplan opstellen

Een plan voor gebruikersbegeleiding per doelgroep, van interne ambassadeurs tot nazorg.

Stel het verandermanagementplan op voor [project, bijv. nieuwe tool, proceswijziging] bij [bedrijf]. Betrokken doelgroepen: [groepen, aantal en wat er verandert]. Geuite of verwachte zorgen: [weerstand]. Planning: [belangrijke data]. Beschikbare middelen: [tijd, budget, ambassadeurs].

Per doelgroep: wat verandert er concreet in hun dagelijks werk (winst EN verlies, verzwegen verlies wreekt zich later), benodigd niveau van begeleiding (info, training, intensieve support), en de kernboodschap vanuit hun perspectief.

Structureer in de tijd: vooraf (aankondiging, netwerk van ambassadeurs gekozen op geloofwaardigheid, training), tijdens (extra support, verzamelen irritaties, zichtbaar oplossen van gemelde problemen), achteraf (meten van werkelijk gebruik in plaats van trainingsdeelname, aanpakken resterende weerstand).

Richtlijnen: geen plan gebaseerd op 'meer communiceren' zonder inhoud. Elke actie heeft een eigenaar en datum. Lever het plan in een tabel per doelgroep en een geconsolideerde tijdlijn.

Trainingsplan voor eindgebruikers ontwerpen

Een trainingsaanpak per profiel, gebaseerd op praktijkcasussen en gemeten op gebruik.

Ontwerp het trainingsplan voor eindgebruikers voor de uitrol van [tool/proces] bij [bedrijf]. Gebruikers: [profielen, aantallen, IT-vaardigheid, locatie]. Wat moet elk profiel kunnen: [taken]. Beperkingen: [beschikbaarheid, budget, deadline].

Bouw een aanpak per profiel in plaats van één algemene training: voor elk de 5 tot 10 belangrijkste handelingen uit hun praktijk (geen volledige knoppencursus), passend formaat (korte groepssessie, tutorial, werkplekbegeleiding), duur, en naslagwerk (bijv. 'one-pagers' per taak).

Plan sessies zo dicht mogelijk op de livegang: een training 6 weken voor gebruik wordt vergeten. Regel een vangnet voor afwezigen en lokale aanspreekpunten per team.

Richtlijnen: meet succes op werkelijk gebruik na livegang (kunnen ze de kerntaken uitvoeren, volume supportvragen) en niet op aanwezigheid. Lever het plan in een tabel per profiel en een geprioriteerde lijst met te maken materiaal.

Communiceren tijdens een projectcrisis

Crisisberichten voor elke doelgroep, van de eerste melding tot de oplossing.

Een groot incident treft project [naam project]: [aard van het incident, bijv. mislukte livegang, dataverlies, uitval kritieke dienst]. Geconstateerde impact: [wie is getroffen en hoe]. Status van de oplossing: [wat weten we, wat nog niet]. Te informeren doelgroepen: [directie, interne teams, klanten, partners].

Schrijf de communicatievolgorde: het eerste snelle bericht (wat weten we, wat niet, wat doen we en wanneer volgt de volgende update - beloof een tijdstip voor de update, geen tijdstip voor de oplossing), tussentijdse updates volgens afspraak (ook als er geen nieuws is), en het oplossingsbericht met maatregelen ter voorkoming.

Pas elk bericht aan per doelgroep: de directie wil impact en besluiten, gebruikers willen weten hoe ze nu kunnen werken, klanten willen weten of ze veilig zijn. Richtlijnen: geen speculatie over de oorzaak, geen schuldigen aanwijzen, geen loze beloften over hersteltijd. Lever de berichten en de regels over wie met wie spreekt.

Team-OKR's opstellen

Kwartaaldoelen en meetbare resultaten, afgestemd op de prioriteiten van de organisatie.

Help team [team] van [bedrijf] bij het opstellen van de OKR's voor kwartaal [kwartaal]. Bedrijfsprioriteiten: [prioriteiten]. Terugkerende taken: [vaste activiteiten]. Geplande projecten: [ideeën]. Teamomvang: [aantal].

Produceer max. 2 of 3 Objectives: elk geformuleerd als een inspirerende maar concrete verandering (geen takenlijst), expliciet gekoppeld aan een bedrijfsprioriteit. Per Objective 2 tot 4 Key Results: meetbaar met start- en streefwaarde, gericht op resultaat en niet op activiteit ('verwerkingstijd verlagen van X naar Y' en niet 'tool Z uitrollen').

Richtlijnen: dagelijkse 'business as usual' wordt geen OKR; een Key Result waarvan we niet weten hoe we het meten wordt herformuleerd of geschrapt. Signaleer doelen waar het team te weinig invloed op heeft. Lever de voorgestelde OKR's, de vragen voor de teamworkshop en het monitoringsritueel (frequentie, 15 min format, wat te doen bij afwijking).

Kwartaalevaluatie van OKR's leiden

De balans opmaken aan het eind van het kwartaal: eerlijk scoren, lessen trekken en vooruitkijken.

Bereid de kwartaalevaluatie voor van de OKR's van team [team]. OKR's afgelopen kwartaal: [doelen en resultaten met score]. Belangrijke gebeurtenissen: [context: onvoorzien, wijziging prioriteit, vertrek]. Deelnemers: [deelnemers]. Duur: [duur].

Structureer de evaluatie in 3 delen: eerlijke score per Key Result op basis van harde cijfers (niet gemeten is niet gehaald), analyse van afwijkingen (onderscheid tussen uitvoering, te hoge ambitie of externe factoren), besluiten voor het volgende kwartaal (wat verlengen we, wat stoppen we, wat passen we aan).

Richtlijnen: de evaluatie is geen verantwoordingsoefening; ban context-slides en ga direct naar de cijfers. Een doel dat direct 100% gehaald is, zegt iets over de ambitie; een doel op 20% over de uitvoering. Lever: de getimede agenda, de scorematrix, analysevragen per KR, en het sjabloon voor het samenvattende bericht na afloop.

Incident post-mortem zonder schuldvraag

Analyse van een incident gericht op systeemoorzaken en preventieve maatregelen.

Bereid de post-mortem voor van incident [beschrijving] op [datum] binnen project [naam project]. Bekende tijdlijn: [verloop met tijden]. Betrokkenen: [actoren]. Sfeer: [context, bijv. iemand voelt zich aangevallen, directie zoekt zondebok].

Structureer het document en de meeting: feitelijke tijdlijn gezamenlijk reconstrueren (uur tot uur, zonder interpretatie), oorzakenanalyse die verder gaat dan de individuele fout (een menselijke fout is een symptoom: wat maakte de fout mogelijk, wat had het moeten opvangen?), wat ging goed in detectie en reactie, en preventieve acties.

Spelregels voor de opening: we zoeken hoe het systeem het incident toeliet, niet wie de fout maakte. Wie zegt 'ik maakte een fout' helpt het team en mag daar nooit spijt van krijgen. Richtlijnen: max. 5 acties, elk met eigenaar en deadline, met focus op het onmogelijk maken van de fout boven 'beter opletten'. Lever het sjabloon en de agenda.

Lessen omzetten in teamstandaarden

Van verzamelde leerpunten naar werkafspraken die ook echt worden nageleefd.

Help me de 'lessons learned' van [team/bedrijf] om te zetten in standaarden. Beschikbaar materiaal: [bronnen: retro-verslagen, projectevaluaties, post-mortems, klachten]. Huidig probleem: [symptoom, bijv. dezelfde fouten herhalen zich, evaluaties worden nooit meer gelezen].

Werk als volgt: groepeer lessen per thema en zoek naar patronen (herhaling bepaalt de prioriteit), zet elke les om in een actiegerichte regel met een trigger ('bij elke projectstart doen we X'), en bepaal waar deze regels landen zodat ze op het juiste moment gezien worden: in document-templates en checklists in plaats van in een los handboek.

Richtlijnen: max. 10 regels in totaal, elke regel heeft een eigenaar. Plan een halfjaarlijkse review om overbodige regels te schrappen. Lever: de voorgestelde regels gerangschikt op gebruiksmoment, de plek van integratie, en het bericht aan het team.

Projectaudit of kwaliteitsreview voorbereiden

Voorbereiding op een projectaudit: dossier, zwakke punten erkennen en gespreksvoering.

Bereid project [naam project] voor op een audit of kwaliteitsreview door [auditor: interne audit, klant, certificerende instantie] op [datum]. Scope van de review: [wat wordt onderzocht]. Werkelijke status: [bekende sterktes/zwaktes, documentatie status]. Belang: [financiering, klantvertrouwen, certificering].

Organiseer de voorbereiding: het referentiedossier (PID, besluiten, risicolog, verslagen, budget) met focus op wat waarschijnlijk ontbreekt of verouderd is, de vragen die de auditor waarschijnlijk stelt, en voor elk zwak punt de eerlijke houding: erkennen, laten zien dat het onder controle is, en het gedateerde actieplan presenteren.

Richtlijnen: ga nooit documenten vervalsen of antedateren; een erkend zwak punt met een geloofwaardig plan werkt beter dan een façade die instort tijdens een interview. Brief de betrokkenen op feiten, niet op 'mooie praatjes'. Lever: de dossier-checklist, waarschijnlijke vragen met antwoorden, en de planning voor de voorbereiding.

Test deze Projectmanagement prompts op je eigen data

Kopieer een prompt naar GPTPro en vergelijk direct de resultaten van Claude, GPT, Gemini en Mistral voor jouw specifieke case.