Hva er et prosjektinitieringsdokument & mal for å lage et
Et prosjektinitieringsdokument (PID) hindrer prosjekter i å løpe løpsk når omfanget endres, interessenter er uenige eller team mister oversikten over prioriteringene. Jeg har sett selv godt planlagte prosjekter rakne uten tydelig dokumentasjon og riktig prosjektstyringsprogramvare for å følge beslutninger, ansvar og leveranser.
I denne veiledningen lærer du hvordan du oppretter et PID som samkjører team tidlig, reduserer forvirring og gir deg et pålitelig rammeverk for håndtering av omfang, kommunikasjon, risikoer og godkjenninger fra oppstart til levering.
Hva er et prosjektinitieringsdokument?
Et prosjektinitieringsdokument er et viktig prosjektdokument som definerer prosjektomfang, milepæler og kriterier for prosjektsuksess. Det setter også prosjektet i kontekst og fungerer som et grunnleggende prosjektdokument som er like viktig både som en intern veiledning og for eksterne interessenter.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
En prosjektleder oppretter vanligvis et PID under prosjektets initieringsfase i prosjektets livssyklus for å etablere tonen, konteksten, forventningene og begrensningene for arbeidet.
Hvorfor er et prosjektinitieringsdokument viktig?
Et prosjektinitieringsdokument er viktig fordi det hjelper teamet med å få en vellykket prosjektstart uten å skape for mye ekstraarbeid i begynnelsen.
I tillegg til å få ting i gang i begynnelsen av prosjektet forblir PID-et et levende dokument som teamet kan bruke som referanse gjennom hele prosjektets livssyklus. Det fungerer som en sikkerhetsmekanisme dersom det skjer endringer i bemanningen eller nye teammedlemmer kommer til, slik at de raskt kan komme inn i arbeidet.
Hva bør et prosjektinitieringsdokument inneholde?
Et prosjektinitieringsdokument bør inneholde følgende:
- Grunnleggende informasjon om prosjektet (f.eks. kunde, prosjektnavn)
- Prosjektdefinisjon
- Prosjektbakgrunn
- Suksesskriterier
- Prosjektbudsjett
- Prosjektplan
- Omfang, inkludert hva som er innenfor og utenfor omfanget
- Prosjektkrav
- Leveranser
- Prosjektstyring
- Forutsetninger og begrensninger
- Prosjektfaser på overordnet nivå
- Interessentenes roller og ansvarsområder
- Risikoer, forutsetninger og avhengigheter
PID-et ditt er ofte et beste estimat basert på arbeidsbeskrivelsen eller beregningen som teamet har utarbeidet. Det er så mange ting som fortsatt er uavklart. Planen du setter sammen, vil kanskje ikke bli gjennomført slik den er tenkt.
Mal for prosjektinitieringsdokument
Her er en enkel mal for prosjektinitiering som du kan laste ned og tilpasse til prosjektene eller initiativene dine. Den inneholder alle delene som er nevnt ovenfor. Vi har også inkludert et utfylt eksempel (mer om det nedenfor), slik at du kan se nøyaktig hva som skal inkluderes i hver del.
Eksempel og prøve på prosjektinitieringsdokument
Her er et eksempel på hvordan et ferdig utfylt prosjektinitieringsdokument kan se ut. Dette utfylte eksempelet er tilgjengelig sammen med malen som er nevnt ovenfor, for å gjøre det enklere for deg å bruke dette formatet i dine egne prosjekter.
Slik oppretter du et prosjektinitieringsdokument: 7 trinn
Slik oppretter du et prosjektinitieringsdokument som inneholder den viktigste prosjektinformasjonen for teamet og interessentene dine.
1. Fastsett konteksten
Begynn med å gi bakgrunnsinformasjon om noen av prosjektets forretningsdrivere (hvis ikke, kan du spørre kundeansvarlig).
- Hvorfor gjennomfører kunden dette prosjektet?
- Hvilket problem skal løses?
- Hva handler prosjektet om?
- Finnes det utelukkende tekniske drivere, eller er prosjektets formål forankret i organisasjonens strategi?
- Hva er forretningsmålene?
- Hvordan definerer og måler kunden suksess? Hvilke måltall bruker de?
Beskriv den strategiske visjonen, målene, prosjektmålene og, ideelt sett, en overordnet målsetning. Dette samordner teamet rundt prosjektets tilnærming, slik at de kan ha disse målene i tankene gjennom hele gjennomføringen.
Det å ha denne konteksten hjelper også teamet når de skal definere ytterligere arbeid og mulige prosjektforbedringer (for eksempel: ville det ikke vært flott om vi kunne …?)
2. Definer prosjektets rammebetingelser
I prosjektinitieringsdokumentet må du være åpen om prosjektbegrensningene, inkludert informasjon som:
- Hva er budsjettet for dette prosjektet?
- Hvordan er budsjettet fordelt på prosjektfase eller leveranse?
- Hvordan ser tidsplanen ut?
- Hvordan ser du for deg samarbeidet med kunden?
- Hva er det første målet teamet skal arbeide mot?
Til syvende og sist vinner og taper teamet sammen. Det er svært lite sannsynlig at man kan levere et vellykket prosjekt hvis hvert enkelt teammedlem gjør ting på sin egen måte. Det å etablere et team av eksperter, i stedet for en samling enkeltpersoner, bidrar langt på vei til å skape samhold og oppmuntre til samarbeid på et tidlig stadium.
3. Definer detaljene
Deretter definerer du prosjektets detaljer i en prosjektomfangsbeskrivelse, slik at teamet får en forståelse av hva de må levere for at prosjektet skal bli vellykket.
For eksempel:
- Hva er omfattet, og hva er ikke omfattet?
- Finnes det noen innledende prosjektkrav som allerede er definert?
En avgjørende del av denne delen er de påkrevde leveransene. Siden disse vanligvis defineres tidlig i kontrakten, må teamet forstå hva som forventes av disse leveransene. Dette omfatter potensielle antakelser og begrensninger, som for eksempel hvor mange revisjoner som skal tas i betraktning.
4. Definer prosjektinndelingsstrukturen og bemanningsplanen
Det er viktig at teamet har en klar forståelse av hvordan prosjektleveransene skal gjennomføres. Dette innebærer å dele arbeidet opp i mindre deler og identifisere hvem som gjør hva.
Her er et eksempel på en overordnet prosjektinndeling:
Gå gjennom den overordnede planen og arbeidsnedbrytningsstrukturen med teamet, slik at de kan komme med innspill. Dette bidrar til å synliggjøre avhengigheter og involvere teamet i utviklingen av prosjektplanen, slik at de får en forståelse av prosjektkonteksten og sitt ansvar for prosjektresultatene.
Prosjektinndelinger kan variere med hensyn til detaljnivået som brukes til å kartlegge de ulike aktivitetene i hver fase. De kan også knyttes til bestemte datoer og samordnes med ressursplanleggingen.
5. Definer hvem som er hvem
Et viktig aspekt ved prosjektinitieringsdokumentet er prosjektteamets struktur (både intern og ekstern.)
- Hvem arbeider i teamet?
- Hvem kan godkjenne ting før de sendes til en kunde?
- Hvem hos kunden må konsulteres før endelig godkjenning?
Ved å etablere disse kommunikasjonskanalene kan man unngå misforståelser senere. Et RACI-diagram er et godt verktøy for å dokumentere dette. Det viser hvem som er/trenger å være:
- Ansvarlig: Hvem utfører arbeidet?
- Beslutningsansvarlig: Hvem tar beslutningene?
- Konsultert: Hvem må spørres før man går videre?
- Informert: Hvem må holdes orientert?
Den beste måten å utvikle et RACI-diagram på er å liste opp prosjektleveransene eller aktivitetene og knytte dem til prosjektroller for både interne og eksterne teammedlemmer. Tildel deretter RACI-statusen. Sørg for at bare én person er beslutningsansvarlig for en prosjektleveranse.
Å definere teamroller og ansvarsområder er en god måte å avklare forventningene til prosjektkommunikasjon og prosjektstyring på. Det reduserer risikoen for at du får høre: «Jeg trodde det var ditt ansvar» eller «Jeg burde ha gjennomgått det før det ble sendt til kunden.»
Internt team
Det interne teamet kan omfatte prosjektlederen, kundeansvarlig, andre teammedlemmer og den øverste ledelsen, i tilfelle de må godkjenne leveransene.
Eksternt team
De viktigste spørsmålene vi må stille kunden, er:
- Hvem vet hva vi skal gjøre, og hvorfor?
- Hvem er ansvarlig for å godkjenne oppdragsbeskrivelsen?
- Hvem er beslutningsansvarlig eller ansvarlig for å godkjenne prosjektleveransene?
- Finnes det en styringsgruppe som vi må konsultere?
- Hvem kommer til å bli irritert hvis vi ikke holder dem orientert?
RACI-diagrammet er en flott måte å få oversikt over hvordan ting fungerer i et byrå, og å komme à jour med interne arbeidsflyter. Suppler RACI-diagrammet med en kommunikasjonsplan som beskriver hvordan dere skal samarbeide på tvers av ulike teamroller.
6. Identifiser risikoer, antakelser, problemer og avhengigheter
Inkluder en oversikt over kjente risikoer og begrensninger som en del av PID-en. Prosjekter kan være komplekse av ulike grunner, og det er nyttig å tenke grundig gjennom dette, forutse prosjektrisikoer og problemer og utvikle strategier for risikoreduksjon.
Noen eksempler er:
- Tidsplaner som er for korte eller for lange
- Budsjettbegrensninger
- Tekniske ukjente faktorer
- Komplekst interessentlandskap
- Enkeltpunkter for svikt
7. Del prosjektinitieringsdokumentet
Sørg for å dele prosjektinitieringsdokumentet med hele teamet. Be kunden godkjenne det for å formalisere antakelser samt roller og ansvarsområder.
Det er også nyttig å bruke det som referanse gjennom hele prosjektets livssyklus, slik at teamet ikke mister oversikten. Dette dokumentet er nyttig når nye prosjektinteressenter blir involvert, eller når leveransen eller arbeidsflyten for dokumentgodkjenning viser seg å være mer komplisert enn forventet.
Hvis du vil vite mer, kan du se vår «mesterklasse» 😉:
Prosjektinitieringsdokument sammenlignet med prosjektplan
Prosjektinitieringsdokumentet dekker «hva» og «hvorfor» bak et prosjekt (det vil si prosjektmålene og forretningsgrunnlaget), mens prosjektplanen bygger videre på prosjektmandatet for å definere hvordan du skal lede prosjektet, inkludert risikostyring, prosjektplanen, kommunikasjon osv.
Du utarbeider prosjektstyringsplanen etter at du allerede har fått støtte fra prosjekteieren til å gjennomføre prosjektet (et trinn som finner sted under prosjektinitieringsfasen).
PID-er sammenlignet med andre typer prosjektinitieringsdokumentasjon
Et forretningsgrunnlag inneholder en fullstendig økonomisk vurdering av prosjektet, inkludert en kostnads- og nytteanalyse, markedsvurdering og konkurranseanalyse.
Selv om du vanligvis vil inkludere en forretningsmessig begrunnelse for prosjektet som en del av prosjektinitieringsdokumentet, kan du også utarbeide et frittstående forretningsgrunnlag for prosjekter som er spesielt komplekse.
Et prosjektinitieringsdokument skiller seg også fra agendaen for prosjektoppstartsmøtet, som er langt mer taktisk. I tillegg til å oppsummere viktige punkter fra PID-en om prosjektomfang og forretningsmål, fremhever den også diskusjonspunktene du ønsker å gjennomgå med interessentene under prosjektplanleggingsfasen.
Hva nå?
Vil du komme i kontakt med andre digitale prosjektledere for å dele ressurser og beste praksis? Bli med i medlemsfellesskapet vårt og få tilgang til over 100 maler, eksempler og demonstrasjoner, og kom i kontakt med hundrevis av andre digitale prosjektledere på Slack.
