Agenda för projektuppstartsmöte för utvecklingsteam

Frågan som uppstartsmöten hoppar över

En projektuppstart som går bra lämnar teamet med samsyn om vad som ska byggas, vem som gör vad och när saker ska vara klara. Den samsynen håller vanligtvis i sig i ungefär tre veckor. Sedan smyger omfattningen iväg, en intressent ändrar sig om ett kärnantagande, ett beroende halkar, och teamet upptäcker att de aldrig kom överens om vem som fattar beslutet när två rimliga personer är oense.

Frågan de flesta uppstartsagendor hoppar över är: hur ska teamet fatta beslut när något går fel? Inte projektplanen — beslutsramverket. Vem äger omfattningen när en funktion behöver skäras bort? Vad gör teamet när en teknisk begränsning ogiltigförklarar ett produktkrav? Vilken intressent har sista ordet när två avdelningar vill ha olika saker?

Dessa frågor är lätta att besvara vid uppstarten eftersom inget står på spel ännu. De är mycket svårare att besvara mitt i projektet när alla har en ståndpunkt. Mallen nedan reserverar tid för dem innan den svåra delen börjar.

Agendan (kopiera och klistra in denna)

Längd: 60–90 minuter beroende på projektets komplexitet
Format: Faciliterad; alla nyckelintressenter och bidragsgivare närvarande eller asynkront granskade innan start

Sektion 1 — Projektmål och omfattning (20 min)

Ange målet i en mening: hur ser framgång ut som resultat, mätbart om möjligt
Innanför omfattningen: vad projektet ska leverera, specifikt namngivet
Utanför omfattningen: vad projektet uttryckligen inte ska göra — lista minst tre saker
Framgångskriterier: hur ska teamet veta att projektet är klart?
Utvecklingschefen eller produktchefen äger denna sektion; ingenjörerna trycker tillbaka om den angivna omfattningen inte matchar genomförbarheten

Sektion 2 — Roller och ägarskap (15 min)

För varje arbetsström, namnge en ansvarig — inte ett team, en person
Vem fattar det slutliga beslutet om: produktomfattning, teknisk arkitektur, extern kommunikation?
Vem är informerad kontra rådfrågad kontra beslutsfattare för varje större beslutstyp?
Namnge projektledaren som är ansvarig om inget annat är tydligt

Sektion 3 — Begränsningar och risker (15 min)

Hårda begränsningar: deadline, budget, efterlevnad, beroenden av andra team
Kända risker: vilka är de tre största sakerna som skulle kunna spåra ur detta projekt?
För varje risk: sannolikhet, konsekvens och ansvarig för åtgärd
Vad skulle få projektet att ställas in eller kraftigt bantas i omfattning? Namnge det nu

Sektion 4 — Kommunikationsplan (10 min)

Hur ofta ska teamet stämma av? Vilket format?
Vem får en statusuppdatering, och hur? Anta inte att intressenterna vill ha samma kanal
Var lever projektdokumentationen?
Vad är eskaleringsvägen om något blockerar projektet?

Sektion 5 — Öppna frågor (15 min)

Lista varje fråga teamet inte kan besvara idag
För varje: tilldela en ansvarig och ett datum då svaret behövs
Frågor utan datum och ansvarig kommer fortfarande vara öppna vid halvvägspunkten

Sektion 6 — Nästa steg (10 min)

De tre saker som måste hända inom de kommande fem arbetsdagarna för att verkligt arbete ska kunna börja
Varje nästa steg har en enda ansvarig
Bekräfta hur uppstartssammanfattningen ska distribueras och till vem

Vad populära uppstartsmallar gör fel

De flesta uppstartsmallar är grundliga kring projektplanen och tunna kring vad som händer när planen inte håller. De producerar ett rent omfattningsdokument och en RACI-matris, vilket är användbart. De producerar inte ett gemensamt svar på ”vad gör vi när databasleverantören tredubblar sina priser mitt i projektet?” eller ”vad skärs bort om vi når den hårda deadlinen med funktionerna 80 % klara?”

Frånvaron av vad som är utanför omfattningen är den andra genomgående luckan. Att ange vad som är innanför omfattningen är enkelt. Att ange vad som uttryckligen är utanför — att lista tre eller fyra specifika saker projektet inte ska göra — framtvingar samma samtal om intressenternas förväntningar men från andra hållet. Intressenter som skulle ha antagit att mobilklienten ingick får reda på det vid uppstarten snarare än i vecka sex.

Den tredje luckan är sektionen med öppna frågor. Team vill inte lyfta fram vad de inte vet vid uppstarten eftersom det känns som att erkänna att man inte är redo. Men okända svar blir blockerare mitt i projektet, och blockerare mitt i projektet är dyra. Ju tidigare du vet att frågan finns, desto tidigare kan någon ta ansvar för svaret.

För hur dessa luckor ackumuleras till överhead under ett flermånadersprojekt: Mötesskatten.

Varför uppstartsanteckningar är värda att få rätt

Uppstartsdokumentet är den artefakt som refereras oftast i vilket projekt som helst. Det är vad folk kollar när omfattningen ifrågasätts, när en ny teammedlem ansluter, när en intressent frågar ”kom vi inte överens om X vid uppstarten?” En uppstart som är väldokumenterad är ett projekt som är lättare att styra.

Pavleur fångar hela uppstarten automatiskt: omfattning så som den angavs, roller så som de tilldelades, risker så som de namngavs, öppna frågor med ansvariga, nästa steg med ansvariga och datum. Om någon skärmdelade projektbeskrivningen, ett diagram eller ett kravdokument mitt i mötet, inkluderas bilden i rapporten tillsammans med diskussionen. Enbart ljudbaserade verktyg ger dig vem som sa vad; de fångar inte arkitekturdiagrammet på skärmen när den tekniska ledaren beskrev beroendet. Den resulterande rapporten fungerar som projektets sanningskälla från dag ett. För hur detta står sig mot traditionella verktyg för mötesfångst: Pavleur jämfört med alternativen.

En anmärkning om närvaro

Alla som förväntas fatta ett beslut i detta projekt bör närvara vid uppstarten, eller granska en fullständig inspelning och skriftlig sammanfattning innan arbetet börjar. En intressent som missar uppstarten och får veta omfattningen informellt två veckor senare är en omfattningstvist mitt i projektet som väntar på att hända. Uppstartens uppgift är att bygga gemensamt sammanhang, och gemensamt sammanhang existerar bara om de relevanta personerna är i rummet.