Agenda voor een projectkickoff-vergadering voor engineeringteams

De vraag die kickoff-vergaderingen overslaan

Een projectkickoff die goed verloopt, laat het team afgestemd achter op wat er gebouwd moet worden, wie wat doet, en wanneer dingen af moeten zijn. Die afstemming houdt meestal zo’n drie weken stand. Dan sluipt de scope uit, verandert een stakeholder van mening over een kernaanname, verschuift een afhankelijkheid, en ontdekt het team dat het nooit heeft afgesproken wie de knoop doorhakt wanneer twee redelijke mensen het oneens zijn.

De vraag die de meeste kickoff-agenda’s overslaan, is: hoe neemt dit team beslissingen wanneer er iets misgaat? Niet het projectplan — het besluitvormingskader. Wie is verantwoordelijk voor de scope wanneer een feature geschrapt moet worden? Wat doet het team wanneer een technische beperking een producteis onderuithaalt? Welke stakeholder heeft het laatste woord wanneer twee afdelingen verschillende dingen willen?

Deze vragen zijn makkelijk te beantwoorden bij de kickoff, omdat er nog niets op het spel staat. Ze zijn veel moeilijker te beantwoorden halverwege het project, wanneer iedereen een standpunt heeft. Het onderstaande sjabloon reserveert er tijd voor voordat het moeilijke deel begint.

De agenda (kopieer en plak dit)

Duur: 60–90 minuten afhankelijk van de complexiteit van het project
Vorm: begeleid; alle belangrijke stakeholders en bijdragers aanwezig of asynchroon beoordeeld voordat er wordt gestart

Onderdeel 1 — Projectdoel en scope (20 min)

Verwoord het doel in één zin: hoe ziet succes eruit, meetbaar indien mogelijk
In scope: wat het project zal opleveren, specifiek benoemd
Buiten scope: wat dit project expliciet niet zal doen — noem minstens drie dingen
Succescriteria: hoe weet het team dat het project af is?
De EM of PM is verantwoordelijk voor dit onderdeel; engineers spreken tegen als de geformuleerde scope niet strookt met de haalbaarheid

Onderdeel 2 — Rollen en verantwoordelijkheid (15 min)

Noem voor elke werkstroom één verantwoordelijke — geen team, een persoon
Wie hakt de knoop door over: productscope, technische architectuur, externe communicatie?
Wie wordt geïnformeerd vs. geraadpleegd vs. is de beslisser bij elk belangrijk type beslissing?
Noem de projectleider die aanspreekbaar is als niets anders duidelijk is

Onderdeel 3 — Beperkingen en risico’s (15 min)

Harde beperkingen: deadline, budget, compliance, afhankelijkheden van andere teams
Bekende risico’s: wat zijn de drie belangrijkste dingen die dit project kunnen ontsporen?
Voor elk risico: waarschijnlijkheid, impact, en verantwoordelijke voor de mitigatie
Wat zou ertoe leiden dat het project wordt geannuleerd of aanzienlijk wordt afgeschaald? Benoem het nu

Onderdeel 4 — Communicatieplan (10 min)

Hoe vaak stemt het team af? In welke vorm?
Wie krijgt een statusupdate, en hoe? Ga er niet van uit dat stakeholders hetzelfde kanaal willen
Waar leeft de projectdocumentatie?
Wat is de escalatieroute als iets het project blokkeert?

Onderdeel 5 — Open vragen (15 min)

Noem elke vraag die het team vandaag niet kan beantwoorden
Voor elke: wijs een verantwoordelijke aan en een datum waarop het antwoord nodig is
Vragen zonder datum en verantwoordelijke staan halverwege het project nog steeds open

Onderdeel 6 — Volgende stappen (10 min)

De drie dingen die de komende vijf werkdagen moeten gebeuren om met het echte werk te beginnen
Elke volgende stap heeft één verantwoordelijke
Bevestig hoe de kickoff-samenvatting wordt verspreid en aan wie

Wat populaire kickoff-sjablonen missen

De meeste kickoff-sjablonen zijn grondig over het projectplan en dun over wat er gebeurt wanneer het plan niet standhoudt. Ze leveren een net scopedocument en een RACI-matrix op, wat nuttig is. Ze leveren geen gedeeld antwoord op "wat doen we als de databaseleverancier zijn prijzen halverwege het project verdrievoudigt?" of "wat sneuvelt er als we de harde deadline halen bij 80% van de features af?".

De afwezigheid van scope-out is de andere consistente leemte. Verwoorden wat er in scope zit, is rechttoe rechtaan. Verwoorden wat er expliciet buiten valt — drie of vier specifieke dingen opsommen die het project niet zal doen — dwingt hetzelfde gesprek over verwachtingen van stakeholders af, maar dan vanuit de andere richting. Stakeholders die ervan uit zouden gaan dat de mobiele client was inbegrepen, komen daar bij de kickoff achter in plaats van in week zes.

De derde leemte is het onderdeel open vragen. Teams willen bij de kickoff niet naar boven brengen wat ze niet weten, omdat het voelt als toegeven dat ze niet klaar zijn. Maar onbekende antwoorden worden blokkades halverwege het project, en blokkades halverwege het project zijn duur. Hoe eerder je weet dat de vraag bestaat, hoe eerder iemand het antwoord kan toe-eigenen.

Voor hoe deze leemtes uitgroeien tot overhead over een project van meerdere maanden: De vergadertaks.

Waarom kickoff-notities de moeite waard zijn om goed te doen

Het kickoffdocument is het meest geraadpleegde artefact in elk project. Het is wat mensen nagaan wanneer de scope wordt betwist, wanneer een nieuw teamlid aansluit, wanneer een stakeholder vraagt "hebben we X niet bij de kickoff besloten?". Een kickoff die goed is gedocumenteerd, is een project dat makkelijker te managen is.

Pavleur legt de volledige kickoff automatisch vast: de scope zoals verwoord, de rollen zoals toegewezen, de risico’s zoals genoemd, de open vragen met verantwoordelijken, de volgende stappen met verantwoordelijken en datums. Als iemand de projectbriefing, een diagram of een requirements-document via het scherm deelde, wordt de visual in het rapport opgenomen naast de discussie. Tools met alleen audio geven je wie wat zei; ze leggen niet het architectuurdiagram op het scherm vast toen de tech lead de afhankelijkheid beschreef. Het resulterende rapport dient vanaf dag één als het bronbestand van waarheid voor het project. Voor hoe dit zich verhoudt tot traditionele vergadervastleggingstools: Pavleur vs. alternatieven.

Een opmerking over aanwezigheid

Iedereen van wie wordt verwacht dat ze een beslissing over dit project nemen, zou de kickoff moeten bijwonen, of vóór de start van het werk een volledige opname en geschreven samenvatting moeten beoordelen. Een stakeholder die de kickoff mist en twee weken later informeel over de scope hoort, is een scope-conflict halverwege het project dat staat te gebeuren. De taak van de kickoff is om gedeelde context op te bouwen, en gedeelde context bestaat alleen als de relevante mensen in de ruimte zijn.