Prosjektbeskrivelse: Hva det er og hvordan du skriver en
En prosjektbeskrivelse er et kort, grunnleggende dokument som samler teamet rundt hva et prosjekt er, hvorfor det finnes, og hvordan dere skal levere det før dere begynner arbeidet. Etter min erfaring er det å hoppe over dette en av de raskeste måtene et prosjekt kan mislykkes på: Omfanget øker gradvis, interessenter trekker i ulike retninger, og ingen blir enige om hvordan «ferdig» ser ut.
Denne veiledningen dekker alt fra hva som bør inkluderes og hvem som skriver den, til vanlige feil og når den bør oppdateres. Jeg skal også komme inn på hvordan prosjektstyringsprogramvare kan gjøre det mye enklere for distribuerte team å opprette og dele prosjektbeskrivelser.
Hva er en prosjektbeskrivelse?
En prosjektbeskrivelse er et kort dokument som definerer hva et prosjekt er, hvorfor det gjennomføres, og hvordan dere planlegger å levere det. Den samler det viktigste: mål, omfang, tidsplan, interessenter og budsjett, på ett sted før arbeidet starter.
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
Det er den eneste sannhetskilden teamet bruker når de trenger en påminnelse om hva prosjektet faktisk skal oppnå.
Hvorfor er en prosjektbeskrivelse viktig?
Her er hva en god prosjektbeskrivelse gjør for teamet ditt:
- Samler interessentene tidlig: Alle blir enige om hvordan suksess ser ut før arbeidet starter, ikke etterpå.
- Holder omfanget under kontroll: Et skriftlig og godkjent omfang gir deg noe konkret å vise til når forespørslene begynner å utvide seg.
- Gjør opplæringen raskere: Nye teammedlemmer får raskt kontekst uten en 30-minutters samtale.
- Reduserer beslutningstretthet: Når det oppstår avveininger underveis i prosjektet, gir prosjektbeskrivelsen teamene et rammeverk for å ta beslutninger.
- Skaper ansvarlighet: Navngitte ansvarlige og definerte resultater gir mindre rom for uklarhet om hvem som har ansvar for hva.
En prosjektbeskrivelse forebygger de to vanligste årsakene til at prosjekter kommer på avveie: feiljusterte forventninger og et stadig økende omfang. PMIs forskning viste at 52 % av prosjekter opplever omfangsutvidelse eller ukontrollerte endringer. Etter min erfaring er det mest sannsynlig at prosjekter som hoppet over en prosjektbeskrivelse, ender opp i denne statistikken.
Mal for prosjektbeskrivelse
Last ned malen for prosjektbeskrivelse og et eksempel på en prosjektbeskrivelse her. Du kan tilpasse den til dine egne prosjektbeskrivelser (og legge til organisasjonens logo og profil), og eksempelet viser deg nøyaktig hva som bør stå i hver del.
Eksempel på prosjektbeskrivelse
Slik kan prosjektbeskrivelsen din se ut når den er ferdig utfylt:
| Jobbdetaljer | |||
|---|---|---|---|
| Kunde og merkevare | Aston Baby / Rebecca Miller | AM | Hannah McNamee |
| Jobbnavn og nummer | Oppdatering av nettsted / AB5099 | PM | Ben Aston |
| Budsjett | $250,000 inkludert reserve | Frister | Lansering – 1. oktober |
| Hvorfor? – Kundens forretningsutfordring |
|---|
| ABs salg har falt betydelig de siste 6 månedene; dette prosjektet er først og fremst salgsdrevet Trafikken på nettstedet har gått ned, antallet e-postpåmeldinger har sunket, produktvisningene har gått ned, og frafallet i handlekurven har økt. Hovedmålet er å øke salget ved å: øke antall visninger/besøk til 4 sider per besøk (fra dagens 2), redusere frafallet i handlekurven (fra 60 % til 30 %) og øke antallet e-postpåmeldinger til 20 per dag (fra dagens 5) |
| Hva? – Tingene vi skal gjøre/opprette for å møte denne utfordringen |
|---|
| Oppdatere hjemmesiden for å fremheve produkter bedre + inkludere mer livsstilsbilder Oppdatere produktsiden for å fremheve andre produkter, for kryssalg og mersalg Forenkle kategorisidene og betalingsflyten Øke synligheten til skjemaet for e-postpåmelding |
| Når? – Prosjektets tidslinje |
|---|
| Oppstartsmøte med kunden 20. september Lansering – 1. november (fristen styres av den forhåndsbestilte betalte mediekampanjen for høytiden.) |
| Hvordan? – Prosessen vi må følge |
|---|
| AB foretrekker å starte med en kartleggingsfase og opprette en prioritert liste over forbedringer Prosjektet vil deretter gjennomføres i iterative UX-/design- og utviklingssprinter Prioriteten er å håndtere raske gevinster for konvertering nederst i salgstrakten så snart som mulig, og deretter ta tak i de større utfordringene på nettstedet etter hvert som budsjett og tidslinje tillater det. |
| Hvem? – Personene som er involvert |
|---|
| Kunde: Rebecca Miller (hovedinteressent) DPM-prosjektteamet: Simon (CD), Suze (tekst), Dave (strategi) Warren (UX), Rory (teknologi), Ben (AM) |
| Noe annet? |
|---|
| Kunden ønsker å beholde nettstedet på Woocommerce og WordPress Tidligere strategiarbeid med vekst for astonbaby.com bør gjennomgås og refereres til gjennom hele prosjektet |
Prosjektbeskrivelse sammenlignet med andre prosjektdokumenter
En prosjektbeskrivelse forveksles ofte med dokumenter som har andre formål. Bruk denne tabellen for å forstå hvor en prosjektbeskrivelse passer inn sammenlignet med andre vanlige prosjektdokumenter:
| Dokument | Formål | Typisk lengde | Når det opprettes |
|---|---|---|---|
| Prosjektbeskrivelse | Samordne teamet om mål, omfang og fremgangsmåte | 1–2 sider | Ved prosjektoppstart |
| Prosjektmandat | Formelt godkjenne prosjektet og definere sponsorens myndighet | 2–5 sider | Før oppstart eller ved oppstart |
| Prosjektplan | Detaljert oppdeling av oppgaver, tidsplan og ressursplan | 5–20+ sider | I planleggingsfasen |
| Kreativ brief | Veilede kreativt arbeid (design, tekst, kampanjer) | 1 side | Før det kreative arbeidet begynner |
| Prosjektforslag | Argumentere for finansiering eller godkjenning | Varierer | Før prosjektet godkjennes |
| Sammendrag for ledelsen | Oppsummere resultater for ledelsen | 1 side | Ved prosjektslutt eller rapportering |
Beskrivelsen er mer detaljert enn et prosjektmandat, men langt mindre detaljert enn en fullstendig prosjektplan. Hvis noen i teamet ditt gir deg et dokument på 15 sider og kaller det en beskrivelse, er det en plan.
Hvem skriver en prosjektbeskrivelse, og når?
Prosjektlederen har vanligvis ansvaret for prosjektbeskrivelsen, men å skrive den er en samarbeidsprosess. Du innhenter innspill fra interessenter, fageksperter og den som sponser prosjektet. Beskrivelsen gjenspeiler innspillene deres, selv om det er du som utarbeider den.
Skriv beskrivelsen under oppstartsfasen, før planlegging eller ressursallokering finner sted. Hvis du ferdigstiller tidsplaner eller fordeler oppgaver før beskrivelsen er godkjent, arbeider du i feil rekkefølge.
Her er hvem som vanligvis bidrar til hver del:
- Prosjektleder: Utarbeider dokumentet, legger til rette for godkjenning og vedlikeholder det gjennom hele prosjektet.
- Prosjektsponsor: Bekrefter forretningsbegrunnelsen og godkjenner omfang og budsjett.
- Viktige interessenter: Validerer mål, avdekker begrensninger og bekrefter rollene sine.
- Fageksperter: Bidrar med informasjon om teknisk omfang, gjennomførbarhet og ressursbehov.
Jeg vil foreslå å holde en kort oppstartssamling med bidragsyterne før utkastet utarbeides. Det tar mindre tid enn å korrigere en prosjektbeskrivelse som ikke gjenspeiler prosjektmålene.
Viktige elementer i en prosjektbeskrivelse
Alle prosjektbeskrivelser ser litt forskjellige ut avhengig av prosjektet, men disse elementene er vanligvis alltid med.
Bakgrunn og kontekst
Forklar hvorfor dette prosjektet finnes. Hva er forretningsproblemet, muligheten eller utløsende årsak? Denne delen gir nye deltakere og interessenter som kommer til senere, et bilde av situasjonen «før». Begrens deg til to eller tre setninger.
Mål og suksessmålinger
Beskriv hva du prøver å oppnå, og hvordan du vil vite at du har oppnådd det. Skriv målene ved hjelp av SMART-rammeverket (spesifikke, målbare, oppnåelige, relevante og tidsavgrensede). Vage mål som «forbedre brukeropplevelsen» trenger et målbart resultat, for eksempel «redusere frafallsraten i introduksjonsprosessen med 20 % innen Q2».
Omfang
Definer hva som er inkludert, og hva som ikke er det. Elementer innenfor omfanget er leveranser og arbeid teamet har ansvar for. Elementer utenfor omfanget er uttrykkelige unntak som ellers kunne blitt tatt for gitt. Det å være spesifikk hindrer interessenter i å legge til «bare én ting til» seks uker inn i prosjektet.
Tidslinje og milepæler
List opp de viktigste datoene: prosjektstart, sentrale milepæler og måldatoen for ferdigstillelse. Du trenger ikke et fullstendig Gantt-diagram, men en håndfull forankringsdatoer gir alle en felles oppfatning av tempo og hvor mye det haster.
Målgruppe
Beskriv hvem prosjektets resultat er beregnet på. For en produktfunksjon er det sluttbrukeren. For et internt initiativ kan det være en bestemt avdeling. Dette sørger for at beslutningene tar utgangspunkt i hvem som faktisk drar nytte av arbeidet.
Interessenter og roller
Navngi de involverte og tydeliggjør hva hver person har ansvar for. Bruk en RACI-matrise eller en enkel liste for mindre prosjekter hvis en fullstendig matrise føles unødvendig omfattende. Det viktige er at ingen trenger å lure på om det er deres ansvar å ta en beslutning.
Budsjett og ressurser
Oppgi det godkjente budsjettet og eventuelle større ressursforpliktelser (f.eks. bemanning, verktøy, leverandører og infrastruktur). Du trenger ikke en detaljert kostnadsoversikt i prosjektbeskrivelsen. En øvre grense og viktige ressursbegrensninger er tilstrekkelig på dette stadiet.
Kommunikasjonsplan
Beskriv hvordan teamet skal holde seg samkjørt. Ta med møtefrekvens, format for statusrapportering og hvem som får hvilke oppdateringer. Dette trenger ikke være omfattende. Selv én setning som «ukentlig statuse-post til sponsorer hver fredag» er mer nyttig enn ingenting.
Slik skriver du en prosjektbeskrivelse: trinn for trinn
Følg disse trinnene for å lage en prosjektbeskrivelse som er nyttig fra første dag:
- Samle inn kontekst før du skriver: Snakk med prosjektsponsoren og de viktigste interessentene. Forstå den forretningsmessige drivkraften, kjente begrensninger og hvordan et vellykket resultat ser ut for personene som betyr mest.
- Utarbeid bakgrunn og mål først: Begynn med «hvorfor» før «hva». Når formålet er tydelig, blir resten av prosjektbeskrivelsen enklere å skrive på en konsekvent måte.
- Definer omfanget tydelig: List opp hva som er inkludert, og hva som ikke er det. Involver interessentene i dette trinnet. Uenigheter om omfang er mye enklere å løse i et utkast enn midt under leveransen.
- Legg til forankringspunkter i tidslinjen og navn på ansvarlige: Selv omtrentlige milepælsdatoer og navngitte roller er bedre enn plassholdere. Konkretisering skaper ansvarlighet.
- Fyll inn budsjett og ressurser: Få et bekreftet budsjettintervall fra sponsoren før du ferdigstiller dokumentet. Estimater uten godkjenning skaper problemer senere.
- Skriv kommunikasjonsplanen: Avtal hyppighet og format for oppdateringer med sponsoren. Denne delen tar fem minutter, men sparer timevis med ad hoc-meldinger.
- Send ut til gjennomgang og få godkjenning: Send utkastet til alle viktige interessenter. Ta inn tilbakemeldingene, og innhent deretter skriftlig godkjenning.
- Del det med hele teamet: Legg det ut et sted der alle kan finne det, for eksempel i prosjektstyringsverktøyet, på en delt disk eller på teamets dokumentasjonsplattform.
Vanlige feil i prosjektbeskrivelser du bør unngå
De fleste problemer med prosjektbeskrivelser handler ikke om hva dokumentet inneholder, men om hvordan det ble utarbeidet eller brukt. Vær oppmerksom på følgende:
- Å skrive den uten innspill: En prosjektbeskrivelse som er utarbeidet uten innspill fra interessentene, må revideres, ofte mer enn én gang. Involver de rette personene tidlig.
- Å være vag om omfanget: «Forbedre dashbordet» er ikke en omfangsbeskrivelse. Tvetydighet inviterer til antakelser, og antakelser fører til at omfanget vokser.
- Å hoppe over listen over det som er utenfor omfanget: Hvis du bare definerer hva som er inkludert, vil interessentene selv fylle ut tomrommene (vanligvis til sin egen fordel).
- Å sette mål uten måleparametere: Mål uten målbare resultater kan ikke evalueres. Hvis du ikke kan måle det, kan du ikke bekrefte at det er ferdig.
- Å arkivere den etter oppstartsmøtet: Prosjektbeskrivelsen bør være en levende referanse, ikke et engangsprodukt. Hvis den ikke er enkel å finne, vil den ikke bli brukt.
Verktøy for å effektivisere prosjektbeskrivelsen
Her er noen verktøy som gjør prosessen raskere og resultatet mer nyttig:
Clicks on the links below may earn a commission, which supports our independent testing and review of software and services. Learn more about how we stay transparent.
Når du bør oppdatere eller revidere prosjektbeskrivelsen
En prosjektbeskrivelse bør være oppdatert så lenge prosjektet varer, og det betyr at du må gå gjennom den på nytt når ting endrer seg.
Oppdater prosjektbeskrivelsen når noe av følgende skjer:
- Endringer i omfanget: Alle formelt godkjente tillegg eller fjerninger av leveranser bør gjenspeiles i prosjektbeskrivelsen.
- Endringer i tidsplanen: Hvis viktige milepæler flyttes, må du oppdatere prosjektbeskrivelsen slik at den ikke motsier den gjeldende planen.
- Endringer blant interessenter eller i eierskap: Nye beslutningstakere må navngis, og personer som har sluttet, må erstattes.
- Budsjettendringer: Godkjente budsjettendringer bør dokumenteres i prosjektbeskrivelsen, ikke bare i et regneark.
- Målene utvikler seg: Hvis forretningsmålet endres underveis i prosjektet, bør prosjektbeskrivelsen gjenspeile det nye målet.
Når du oppdaterer prosjektbeskrivelsen, bør du notere versjonen og hva som er endret. Dette gjør endringshistorikken synlig og gir interessentene en tydelig oversikt over hvorfor prosjektet utviklet seg. Jeg behandler versjonsnotater som en enkel endringslogg. Det tar to minutter og sparer mye tid på samtaler av typen «Vent, jeg trodde vi ble enige om at …».
Start ditt neste prosjekt på riktig måte
En solid prosjektbeskrivelse er en av de tydeligste måtene å fremstå som en forberedt og samkjørt prosjektleder på. Hvis du vil ha flere verktøy som dette for å videreutvikle arbeidet ditt med prosjektleveranser, kan du melde deg på vårt gratis nyhetsbrev og medlemskap for å få tilgang til maler, arbeidsoppskrifter og innsikt fra andre prosjektledere, utviklet for prosjektledere som arbeider i kunstig intelligens-æraen.
