Det korte svaret er: Ja, det bør du! En god arbeidsbeskrivelse kan spare deg for mye stress, tid og kostnader. Høres ut som noe som er verdt å prøve, ikke sant? I dette blogginnlegget går vi gjennom det grunnleggende om hvordan du skriver en effektiv arbeidsbeskrivelse. Vi går også gjennom de viktigste fordelene med dette dokumentet. Men først skal vi forklare hva en SOW er og hvilken plass den har i prosjektledelsesprosessen.
Hva er en arbeidsbeskrivelse i prosjektledelse?
A Guide to the Project Management Body of Knowledge definerer prosjektets arbeidsbeskrivelse som en narrativ beskrivelse av produkter, tjenester eller resultater som skal leveres av et prosjekt (kilde: PMBOK® Guide - femte utgave).
I bunn og grunn er det et dokument som beskriver ulike aspekter ved prosjektetinkludert:
- mål,
- arbeidsomfang,
- tidsplan og forfallsdatoer,
- standarder og definisjon av suksess,
- betalingsdetaljer.
Arbeidsbeskrivelsen må signeres av alle prosjektets interessenter og er ofte en del av en prosjektkontrakt.
Du lurer kanskje på hva som er forskjellen mellom en arbeidsbeskrivelse og et arbeidsomfang. Det første er navnet på dokumentet som vanligvis inneholder prosjektets omfang. Når vi sier "arbeidsomfang", refererer vi vanligvis til det arbeidet som må gjøres for å levere et prosjekt. Å dokumentere omfanget er et viktig element i en effektiv styring av prosjektets omfang. Det kan du gjøre ved å lage en såkalt work breakdown structure (WBS) som lar deg visualisere omfanget. Det kan også være en god idé å legge til WBS i arbeidsbeskrivelsen.
De viktigste fordelene med å lage en prosjektledelsesoppgave
Øverst i dette blogginnlegget nevnte vi at en god arbeidsbeskrivelse kan spare deg for mange nerver og mye penger. Det gjelder spesielt når du jobber med eksterne interessenter, og prosjektet ditt er ganske komplekst. Det kan være livsviktig å ha én eneste kilde til sannheten om hva du skal og ikke skal gjøre. Takket være en Statement of Work kan du gjøre det:
- Styr forventningene - SOW-en bør gi en tydelig oversikt over hva som ligger innenfor og utenfor prosjektets omfang. Det er nyttig for prosjektteamet, men gjør det også mulig for deg å styre kundens forventninger. Når det er prosjektgjennomsiktighetAlle parter vet hva de kan forvente og når.
- Beslutte planleggingskonflikter og andre konflikter - selv om du klart definerer arbeidet teamet ditt skal utføre, kan det av og til oppstå tvister eller misforståelser. Arbeidsbeskrivelsen er her for å hjelpe deg med å løse dem: Når du er i tvil, kan du henvise til arbeidsbeskrivelsen! Det betyr naturligvis at arbeidsbeskrivelsen bør være nøyaktig og detaljert nok til å være til hjelp når du og kunden har behov for å avklare visse ting.
- Unngå at omfanget sklir ut omfangsglidningNår arbeidet er dårlig definert, er det mer sannsynlig at prosjektets omfang vokser ukontrollert. Med en arbeidsbeskrivelse vet alle involverte ikke bare hva som skal gjøres, men også når det skal leveres og hva som er "sluttproduktet". Selvsagt bør det også finnes prosesser for endringskontroll, slik at man kan gjøre justeringer i prosjektet når det er behov for det.
[/vc_column_text]
Hva bør du inkludere i en arbeidsbeskrivelse i prosjektledelse?
Det er viktig å merke seg at prosjekter kan være svært forskjellige, så avhengig av hva slags prosjekter de leverer, kan ulike selskaper bruke svært forskjellige arbeidsbeskrivelser. Det er imidlertid noen elementer som vanligvis vil inngå i en SOW. La oss gå gjennom dem én etter én:
Sammendrag av prosjektet
I innledningen til arbeidsbeskrivelsen kan du oppsummere prosjektet og skissere alle de involverte partene. I sammendraget av prosjektet forklarer du vanligvis formålet og visjonen med prosjektet. Hva handler dette prosjektet om? Hva er det forretningsmessige målet med å gjennomføre det? Hvilket problem skal sluttproduktet løse?
Ved å forklare disse elementene øverst i SOW-en setter du tonen for hele dokumentet og gir en begrunnelse for å inkludere eller ikke inkludere bestemte leveranser i omfanget.
Prosjektets omfang
I denne delen av arbeidsbeskrivelsen prøver du å svare på to spørsmål:
- Hva vil bli levert?
- Hva vil ikke bli levert?
Denne delen kan naturligvis ikke være for vag, da det kan føre til misforståelser. På den annen side er det ikke sikkert at du har mulighet til å skissere alle oppgavene på dette punktet. Hvis det er tilfellet, er det helt i orden. Det avgjørende er at du gjenspeiler det omfanget du og de andre interessentene har blitt enige om.
Du kan gå fra en mer generell oversikt over omfanget til å liste opp spesifikke trinn og oppgaver som prosjektteamet må utføre. Ikke glem leveransene, og vær spesifikk når det gjelder dem. Det er viktig å unngå tvetydige formuleringer som at dere skal levere det ene eller det andre. Hvis du ønsker at arbeidsbeskrivelsen skal være til hjelp i eventuelle fremtidige forhandlinger med kunden, bør den være så tydelig som mulig.
Det kan også være en god idé å inkludere et negativt omfang i SOW-en. Vi snakker her om elementer i prosjektet som ble diskutert med kunden eller som finnes i konkurrentenes produkter, men som dere til slutt ble enige om å ikke inkludere i omfanget.
Tidsplan og milepæler
Når du beskriver de ulike trinnene i prosjektet, kan det være lurt å inkludere milepæler i prosjektet og forfallsdatoer også. Noen prosjekter har faste tidsfrister, mens andre ikke har det, så du vil ikke alltid kunne spesifisere den nøyaktige utførelsesperioden. Det er likevel nyttig å i det minste kommunisere de ulike fasene i prosjektet i SOW-en og angi omtrentlig hvor lang tid de bør ta.
Akseptkriterier, definisjoner av suksess
Vi har allerede understreket at du må bruke et presist språk i arbeidsbeskrivelsen og presentere prosjektet på en nøyaktig måte. Det samme gjelder for standarder og akseptkriterier som også bør inkluderes i arbeidsbeskrivelsen.
Tenk deg at teamet ditt jobber med en mobilapplikasjon for kunden. Det er ikke nok å bare beskrive appens funksjoner i SOW-en. Hva om appen fungerer som spesifisert på de fleste mobile enheter, men ikke på alle? Hvis du og kunden ikke blir enige om en liste over plattformene appen skal fungere på, blir det vanskelig å argumentere for at jobben er fullført. Derfor er det så viktig å inkludere noen bransjespesifikke standarder. For programvareutviklingsprosjekter kan det dreie seg om detaljer om
- testing (Hvordan skal produktet testes?),
- enheter, nettlesere og operativsystemer.
- nedetid og vedlikehold av produktet,
- sikkerhetsstandarder osv.
Du kan også nevne kundens ansvar i SOW-dokumentet - må de for eksempel levere noen eiendeler?
Til slutt bør du registrere prosjektets definisjon av suksess: Hvordan forventer kunden at et vellykket prosjekt skal være? Hvem skal ha ansvaret for å avgjøre om prosjektet er vellykket?
Pris og betalingsbetingelser
Informasjon om budsjettet er en integrert del av SOW-en. Hvis du kan presentere kostnadene for prosjektet, bør du skrive dem ned. Hvis du jobber etter medgått tid og materialer, eller hvis det finnes en annen avtale, må du forklare vilkårene tydelig. Ikke glem ekstra prosjektkostnader: lisensavgifter, utstyr, reiser osv.
Betalingsplanen bør også spesifiseres i SOW. Når kan du forvente betaling? Er det noen avdrag? Som ansvarlig for prosjektet er det i din egen interesse å ikke la det være rom for tvil i noen deler av SOW, og denne delen er naturlig nok ikke noe unntak.
Har du samlet alle opplysningene som trengs i arbeidsbeskrivelsen? Sørg for at alle involverte parter er kjent med dokumentet, og få det signert.
Spar bedriften din for mye penger og bryderi med en god SOW i prosjektledelsen
Nå forstår du nok verdien av en velskrevet arbeidsbeskrivelse. Enten du driver et boutique-byrå eller jobber for en større organisasjon, er det et nyttig element i teamets prosjektstyringsprosess. Del guiden vår med prosjektlederne i bedriften din, og oppfordre dem til å lage arbeidsbeskrivelser for de ulike prosjektene de driver.
Her på Teamdeck-bloggen deler vi ofte veiledninger om prosjektledelse. Her er noen av dem du og dine teamkolleger kan ha nytte av:
- En guide til sporing av prosjektkostnader
- Alt du trenger å vite om statusrapporter for prosjektet
- Tips for effektiv møteledelse
- og mange flere!
