Dagsorden til projektopstartsmøde for udviklingsteams

Spørgsmålet, opstartsmøder springer over

En projektopstart, der går godt, efterlader teamet afstemt om, hvad der skal bygges, hvem der gør hvad, og hvornår tingene skal være færdige. Den afstemning holder som regel omkring tre uger. Så skrider scopet, en interessent skifter mening om en central antagelse, en afhængighed glider, og teamet opdager, at de aldrig blev enige om, hvem der træffer afgørelsen, når to fornuftige personer er uenige.

Det spørgsmål, de fleste opstartsdagsordener springer over, er: hvordan vil dette team træffe beslutninger, når noget går galt? Ikke projektplanen — beslutningsrammen. Hvem ejer scopet, når en funktion skal skæres væk? Hvad gør teamet, når en teknisk begrænsning ugyldiggør et produktkrav? Hvilken interessent har det sidste ord, når to afdelinger vil noget forskelligt?

Disse spørgsmål er lette at besvare ved opstarten, fordi der ikke er noget på spil endnu. De er langt sværere at besvare midt i projektet, når alle har taget stilling. Skabelonen nedenfor reserverer tid til dem, før den svære del begynder.

Dagsordenen (klar til copy-paste)

Varighed: 60-90 minutter afhængigt af projektets kompleksitet
Format: Faciliteret; alle nøgleinteressenter og bidragydere til stede eller asynkront gennemgået før start

Sektion 1 — Projektmål og scope (20 min)

Formulér målet i én sætning: hvordan ser succes ud som resultat, målbart hvis muligt
I scope: hvad projektet vil levere, konkret navngivet
Uden for scope: hvad dette projekt eksplicit ikke vil gøre — nævn mindst tre ting
Succeskriterier: hvordan ved teamet, at projektet er færdigt?
EM'en eller PM'en ejer denne sektion; ingeniører gør indsigelse, hvis det anførte scope ikke stemmer overens med gennemførligheden

Sektion 2 — Roller og ejerskab (15 min)

For hvert arbejdsområde: navngiv én ansvarlig — ikke et team, en person
Hvem træffer den endelige afgørelse om: produktscope, teknisk arkitektur, ekstern kommunikation?
Hvem er informeret vs. konsulteret vs. beslutningstager for hver større beslutningstype?
Navngiv projektlederen, der er ansvarlig, hvis intet andet er klart

Sektion 3 — Begrænsninger og risici (15 min)

Hårde begrænsninger: deadline, budget, compliance, afhængigheder af andre teams
Kendte risici: hvad er de tre største ting, der kunne afspore dette projekt?
For hver risiko: sandsynlighed, konsekvens og ansvarlig for afhjælpning
Hvad ville få projektet til at blive aflyst eller væsentligt reduceret i scope? Navngiv det nu

Sektion 4 — Kommunikationsplan (10 min)

Hvor ofte synkroniserer teamet? Hvilket format?
Hvem får en statusopdatering, og hvordan? Antag ikke, at interessenter ønsker samme kanal
Hvor ligger projektdokumentationen?
Hvad er eskaleringsvejen, hvis noget blokerer projektet?

Sektion 5 — Åbne spørgsmål (15 min)

Nævn hvert spørgsmål, teamet ikke kan besvare i dag
For hvert: tildel en ansvarlig og en dato, hvorved svaret er nødvendigt
Spørgsmål uden en dato og en ansvarlig vil stadig være åbne halvvejs igennem

Sektion 6 — Næste skridt (10 min)

De tre ting, der skal ske i de næste fem arbejdsdage for at starte det reelle arbejde
Hvert næste skridt har en enkelt ansvarlig
Bekræft, hvordan opstartsopsummeringen vil blive fordelt, og til hvem

Hvad populære opstartsskabeloner gør forkert

De fleste opstartsskabeloner er grundige omkring projektplanen og tynde omkring, hvad der sker, når planen ikke holder. De producerer et rent scope-dokument og en RACI-matrix, hvilket er nyttigt. De producerer ikke et fælles svar på "hvad gør vi, når databaseleverandøren tredobler deres priser midt i projektet?" eller "hvad bliver skåret, hvis vi rammer den hårde deadline ved 80 % funktionsfærdig?"

Fraværet af scope-out er det andet konsekvente hul. At angive, hvad der er i scope, er ligetil. At angive, hvad der eksplicit er ude — nævne tre eller fire konkrete ting, projektet ikke vil gøre — fremtvinger den samme samtale om interessenters forventninger, men fra den anden retning. Interessenter, der ville have antaget, at mobilklienten var med, finder ud af det ved opstarten frem for i uge seks.

Det tredje hul er sektionen med åbne spørgsmål. Teams vil ikke bringe det frem, de ikke ved, i opstarten, fordi det føles som at indrømme, at man ikke er klar. Men ukendte svar bliver til blokeringer midt i projektet, og blokeringer midt i projektet er dyre. Jo tidligere du ved, at spørgsmålet findes, jo tidligere kan nogen tage ejerskab over svaret.

For hvordan disse huller hober sig op til overhead over et flermåneders projekt: Mødeskatten.

Hvorfor opstartsnoter er værd at få rigtige

Opstartsdokumentet er det hyppigst refererede artefakt i ethvert projekt. Det er det, folk tjekker, når scopet bliver bestridt, når et nyt teammedlem kommer til, når en interessent spørger "besluttede vi ikke X i opstarten?" En opstart, der er veldokumenteret, er et projekt, der er lettere at styre.

Pavleur fanger hele opstarten automatisk: scope som anført, roller som tildelt, risici som navngivet, åbne spørgsmål med ansvarlige, næste skridt med ansvarlige og datoer. Hvis nogen delte skærm med projektbriefet, et diagram eller et kravdokument midt i mødet, er det visuelle med i rapporten sammen med diskussionen. Rene lydværktøjer giver dig, hvem der sagde hvad; de fanger ikke arkitekturdiagrammet på skærmen, da tech lead'en beskrev afhængigheden. Den resulterende rapport fungerer som projektets kilde-til-sandhed-dokument fra dag ét. For hvordan dette sammenlignes med traditionelle værktøjer til mødeindfangning: Pavleur vs. alternativerne.

En note om fremmøde

Alle, der forventes at træffe en beslutning om dette projekt, bør deltage i opstarten eller gennemgå en fuld optagelse og skriftlig opsummering, før arbejdet starter. En interessent, der går glip af opstarten og hører om scopet uformelt to uger senere, er en scope-strid midt i projektet, der venter på at ske. Opstartens opgave er at opbygge fælles kontekst, og fælles kontekst findes kun, hvis de relevante personer er i lokalet.