Agenda for prosjektoppstartsmøte for utviklingsteam

Spørsmålet oppstartsmøter hopper over

Et prosjektoppstartsmøte som går bra, etterlater teamet samkjørt om hva som skal bygges, hvem som gjør hva, og når ting skal leveres. Den samkjøringen holder vanligvis i omtrent tre uker. Så øker omfanget, en interessent ombestemmer seg om en kjerneantakelse, en avhengighet glipper, og teamet oppdager at de aldri ble enige om hvem som tar avgjørelsen når to fornuftige personer er uenige.

Spørsmålet de fleste oppstartsagendaer hopper over, er: hvordan skal dette teamet ta beslutninger når noe går galt? Ikke prosjektplanen — beslutningsrammeverket. Hvem eier omfanget når en funksjon må kuttes? Hva gjør teamet når en teknisk begrensning ugyldiggjør et produktkrav? Hvilken interessent har siste ord når to avdelinger vil ha forskjellige ting?

Disse spørsmålene er lette å besvare ved oppstart fordi ingenting står på spill ennå. De er mye vanskeligere å besvare midtveis i prosjektet når alle har en posisjon. Malen under setter av tid til dem før den vanskelige delen starter.

Agendaen (til å kopiere)

Varighet: 60–90 minutter avhengig av prosjektkompleksitet
Format: Fasilitert; alle nøkkelinteressenter og bidragsytere til stede eller asynkront gjennomgått før start

Seksjon 1 — Prosjektmål og omfang (20 min)

Formuler målet i én setning: hvordan ser suksess ut som resultat, målbart hvis mulig
Innenfor omfang: hva prosjektet skal levere, konkret navngitt
Utenfor omfang: hva dette prosjektet eksplisitt ikke skal gjøre — list opp minst tre ting
Suksesskriterier: hvordan vet teamet at prosjektet er ferdig?
Teamlederen eller produktsjefen eier denne seksjonen; ingeniørene protesterer hvis det oppgitte omfanget ikke stemmer med gjennomførbarheten

Seksjon 2 — Roller og eierskap (15 min)

For hver arbeidsstrøm, navngi én ansvarlig — ikke et team, en person
Hvem tar den endelige avgjørelsen om: produktomfang, teknisk arkitektur, ekstern kommunikasjon?
Hvem blir informert vs. konsultert vs. beslutningstaker for hver større beslutningstype?
Navngi prosjektlederen som er ansvarlig hvis ikke noe annet er klart

Seksjon 3 — Rammer og risikoer (15 min)

Harde rammer: frist, budsjett, samsvarskrav, avhengigheter til andre team
Kjente risikoer: hva er de tre viktigste tingene som kan spore prosjektet av?
For hver risiko: sannsynlighet, konsekvens og ansvarlig for tiltak
Hva ville fått prosjektet til å bli avlyst eller vesentlig redusert i omfang? Navngi det nå

Seksjon 4 — Kommunikasjonsplan (10 min)

Hvor ofte skal teamet synke? I hvilket format?
Hvem får en statusoppdatering, og hvordan? Ikke anta at interessentene ønsker samme kanal
Hvor bor prosjektdokumentasjonen?
Hva er eskaleringsveien hvis noe blokkerer prosjektet?

Seksjon 5 — Åpne spørsmål (15 min)

List opp hvert spørsmål teamet ikke kan besvare i dag
For hvert: tildel en ansvarlig og en dato svaret trengs innen
Spørsmål uten dato og ansvarlig vil fortsatt være åpne halvveis i prosjektet

Seksjon 6 — Neste steg (10 min)

De tre tingene som må skje i løpet av de neste fem virkedagene for å starte reelt arbeid
Hvert neste steg har én enkelt ansvarlig
Bekreft hvordan oppstartsoppsummeringen skal distribueres og til hvem

Hva populære oppstartsmaler gjør feil

De fleste oppstartsmaler er grundige om prosjektplanen og tynne på hva som skjer når planen ikke holder. De produserer et rent omfangsdokument og en RACI-matrise, som er nyttig. De produserer ikke et felles svar på «hva gjør vi når databaseleverandøren tredobler prisen midt i prosjektet?» eller «hva blir kuttet hvis vi treffer den harde fristen med 80 % av funksjonaliteten ferdig?»

Fraværet av omfang-ut er det andre gjennomgående hullet. Å oppgi hva som er innenfor omfang er greit. Å oppgi hva som eksplisitt er utenfor — å liste opp tre eller fire konkrete ting prosjektet ikke skal gjøre — tvinger fram den samme samtalen om interessentenes forventninger, men fra den andre siden. Interessenter som skulle til å anta at mobilklienten var inkludert, får vite det ved oppstart heller enn i uke seks.

Det tredje hullet er seksjonen for åpne spørsmål. Team vil ikke synliggjøre det de ikke vet ved oppstart fordi det føles som å innrømme at de ikke er klare. Men ukjente svar blir til blokkeringer midtveis, og blokkeringer midtveis er dyre. Jo tidligere du vet at spørsmålet finnes, desto tidligere kan noen ta eierskap til svaret.

For hvordan disse hullene hoper seg opp til overhead over et flermånedersprosjekt: Møteskatten.

Hvorfor oppstartsnotater er verdt å gjøre riktig

Oppstartsdokumentet er den mest refererte gjenstanden i ethvert prosjekt. Det er det folk sjekker når omfanget bestrides, når et nytt teammedlem kommer til, når en interessent spør «bestemte vi ikke X ved oppstart?» Et godt dokumentert oppstartsmøte er et prosjekt som er lettere å styre.

Pavleur fanger opp hele oppstarten automatisk: omfang slik det ble uttrykt, roller slik de ble tildelt, risikoer slik de ble navngitt, åpne spørsmål med ansvarlige, neste steg med ansvarlige og datoer. Hvis noen delte skjerm med prosjektbriefen, et diagram eller et kravdokument midt i møtet, er det visuelle inkludert i rapporten ved siden av diskusjonen. Lyd-baserte verktøy gir deg hvem som sa hva; de fanger ikke opp arkitekturdiagrammet på skjermen da den tekniske lederen beskrev avhengigheten. Den resulterende rapporten fungerer som prosjektets fasitdokument fra dag én. For hvordan dette sammenlignes med tradisjonelle møtefangstverktøy: Pavleur vs. alternativene.

En merknad om oppmøte

Alle som forventes å ta en beslutning i dette prosjektet, bør delta på oppstarten, eller gjennomgå et fullstendig opptak og en skriftlig oppsummering før arbeidet starter. En interessent som går glipp av oppstarten og lærer omfanget uformelt to uker senere, er en omfangstvist midtveis i prosjektet som venter på å skje. Oppstartens jobb er å bygge felles kontekst, og felles kontekst finnes bare hvis de relevante personene er i rommet.