För en person innebär det fem sidor och en renare layout. För en annan innebär det en bloggmigrering, nya landningssidor, uppdaterade texter och en logotyp som de har velat göra om i flera månader.
En arbetsbeskrivning löser det. Den definierar vad projektet ska leverera, hur arbetet ska utföras, när varje del ska vara klar, vad som räknas som godkänt och vad som faller utanför avtalet.
Tydlighet är viktigare än man kan tro. Standish Groups CHAOS-rapport visar att endast cirka 31 % av projekten slutförs i tid och inom ramen för projektbeskrivningen.
Här kommer den obekväma delen: de flesta av dessa missar är inte ett disciplinproblem. De är ett arkiveringsproblem. Arbetsbeskrivningen undertecknas, skickas via e-post och arkiveras, och från det ögonblicket börjar den glida ifrån det faktiska arbetet. Vid vecka tre står det fem sidor i dokumentet och femton i projektet, och ingen kan peka ut var skillnaden uppstod. Lösningen är inte en längre arbetsbeskrivning. Det är en arbetsbeskrivning som förblir kopplad till det arbete den beskriver.
Denna guide visar hur du skriver en arbetsbeskrivning som är tillräckligt tydlig för att du ska kunna fastställa pris, planera, fördela uppgifter, godkänna och hantera projektet efter uppstarten.
TL;DR
En bra arbetsbeskrivning besvarar fyra frågor: vad du ska leverera, hur, när och vad som räknas som färdigt. Den bästa arbetsbeskrivningen är inte den mest detaljerade, utan den som fortfarande är sanningsenlig och transparent efter 30 dagar.
Detaljerna kan glömmas bort när arbetet väl har kommit igång, så det är viktigt att ha ett uppdaterat dokument under hela projektet. Detta säkerställer att vad som ligger ”utanför uppdraget” är tydligt definierat och kan hänvisas till.
Täck in alla sju komponenterna, och istället för vaga verb som ”hantera” ska du ange siffror, till exempel ”4 inlägg/månad”. Ange tydligt vad du inte gör, namnge de beroenden på kundsidan som orsakar flest förseningar, och se alltid till att få skriftligt godkännande för varje ändringsbegäran innan du påbörjar arbetet. Koppla sedan det undertecknade dokumentet till de pågående uppgifterna, så att när arbetsomfånget utvidgas blir ändringen synlig och prissättbar istället för att ske i smyg och utan kostnad.
Vad är en arbetsbeskrivning?
Ett arbetsbeskrivningsdokument (SOW) är ett dokument som exakt definierar vad ett projekt ska leverera, hur, när och vad som utgör ett färdigt arbete. Det definierar tydligt arbetsomfånget så att alla parter – kunder, leverantörer och interna team – är överens om vad som ska levereras innan arbetet påbörjas.
Dess uppgift är att skapa samstämmighet. Arbetsbeskrivningen anger målen, listar leveranserna, delar upp dem i uppgifter, kopplar dem till en tidsplan och anger hur varje leverans ska bedömas som färdigställd. Den blir den referens som alla hänvisar till när en fråga eller en ändring dyker upp. Det är också därför den fungerar som ryggraden i hanteringen av projektets omfattning.
Vad är skillnaden mellan arbetsbeskrivning och arbetsuppgiftsbeskrivning?
En arbetsbeskrivning beskriver vad som ska göras; en arbetsplan beskriver hur de båda parterna ska samarbeta för att utföra arbetet. De två begreppen har samma förkortning, SOW, och används ofta omväxlande, men de fungerar på olika nivåer.
Ett tredje liknande begrepp är projektomfattning. Detta definierar gränserna för själva projektet – vad som ingår och vad som inte ingår – snarare än arbetet eller arbetsrelationen.
| Dokument | Vad den besvarar | Innehåller vanligtvis | När du använder den |
|---|---|---|---|
| Arbetsbeskrivning | Vilka arbetsuppgifter ska utföras | Mål, leverabler, uppgifter, tidsplan, godkännandekriterier, undantag | Att definiera ett specifikt uppdrag eller en specifik projektfas |
| Arbetsbeskrivning | Hur parterna ska samarbeta | Arbetsbeskrivningen samt juridiska villkor, betalningsplan, garantier och styrning | Det fullständiga avtalet, ofta med arbetsbeskrivningen (SOW) infogad i det |
| Projektets omfattning | Projektets fullständiga avgränsning | Alla leverabler och det arbete som krävs för att ta fram dem, samt vad som inte ingår | Intern planering och hantering av arbetsomfånget under hela projektet |
I praktiken är uppdragsbeskrivningen det övergripande avtalet, och arbetsbeskrivningen är det avsnitt i avtalet som specificerar vad som ska levereras. Projektets omfattning är det planeringsbegrepp som båda dokumenten beskriver. Om en intressent frågar efter ”SOW” är det värt att ta tio sekunder för att kontrollera vilket av dokumenten som avses, eftersom de juridiska villkoren och betalningsvillkoren finns i uppdragsbeskrivningen, inte i arbetsbeskrivningen.
Vad ska ingå i en arbetsbeskrivning? De viktigaste komponenterna
Ett komplett arbetsbeskrivningsdokument ska göra det enkelt att förstå, prissätta, planera och godkänna arbetet. Om en viktig del saknas kan det leda till förvirring senare.
Här är vad du bör inkludera:
- Mål och syfte: Denna del förklarar varför arbetet utförs och vilket resultat det ska leda till. Begränsa detta till en eller två meningar, skrivna på kundens språk. Till exempel är ”Förbättra den organiska leadgenereringen från företagets blogg” tydligare än ”genomföra en innehållsstrategi”.
- Leverabler: Det här är de specifika resultat som du ska leverera. Namnge och specificera dem i siffror där det är möjligt. Skriv ”12 inlägg per månad på LinkedIn och Instagram”, inte ”hantering av sociala medier”.
- Uppgifter och aktiviteter: I detta avsnitt specificeras det arbete som krävs för att ta fram varje leverans. Det behöver inte inkludera varje liten åtgärd, men det bör vara tillräckligt detaljerat för att man ska kunna förstå vilket arbete som ingår. För en omdesign av en webbplats kan det till exempel handla om wireframing, textförfattande, utveckling, kvalitetssäkring och lanseringsstöd.
- Tidsplan och milstolpar: Använd detta avsnitt för att visa hur projektet kommer att fortskrida från uppstart till slutförande. Ange startdatum, slutdatum, huvudfaser, granskningspunkter och beroenden. En tydlig tidsplan hjälper alla att se vad som måste hända innan nästa fas kan inledas
- Godkännandekriterier: Här definieras hur varje leverans ska granskas, godkännas och anses vara färdig. Kunden vet vilken kvalitetsstandard som förväntas, och du vet när arbetet kan avslutas istället för att revideras i all oändlighet
- Undantag och antaganden: Här anger du tydligt vad som inte ingår och vilka förutsättningar projektet bygger på. Du kan till exempel utesluta hantering av betalda annonser från ett arbetsbeskrivningsdokument för innehåll eller utgå från att kunden tillhandahåller varumärkesriktlinjer innan arbetet påbörjas. Detta avsnitt förhindrar att arbetsomfånget utvidgas innan projektet startar
- Kostnad och betalningsvillkor: Detta avsnitt behandlar den totala kostnaden, faktureringsstrukturen, betalningsplanen och betalningsutlösande händelser. Många SOW:er kopplar betalningarna till milstolpar, såsom kontraktsundertecknande, leverans av första utkastet, slutgiltigt godkännande eller projektets slutförande
- Roller och ansvarsområden: Ange vem som ansvarar för varje leverans, vem som godkänner den och vem som är kundens enda kontaktperson
Vilka typer av arbetsbeskrivningar finns det?
Arbetsbeskrivningar kan vanligtvis delas in i fyra olika strukturer. Vilken som är rätt beror på hur förutsägbart projektet är, hur tydligt du kan definiera leveranserna och vilken typ av risk varje part är villig att ta.
- Leveransbaserat (design/bygg): Denna typ kopplar betalning och godkännande till specifika leveranser. Den fungerar bäst när leveranserna redan är tydligt definierade, till exempel en webbplats med ett fast antal sidor, ett bestämt antal designelement eller en definierad uppsättning blogginlägg.
- Tid och material: Denna struktur innebär att man fakturerar för de timmar, verktyg och kostnader som används under arbetets gång. Den passar projekt där omfattningen fortfarande är osäker, där det krävs mycket utredningsarbete eller där det är troligt att omfattningen kommer att ändras. Använd den när en fast lista över leverabler skulle vara mer av en gissning än en plan.
- Insatsnivå: Denna typ innebär att man avsätter en fastställd mängd tid, support eller kapacitet under en definierad period. Det är vanligt vid ramavtal, löpande konsulttjänster, underhåll och supportarbete där de exakta uppgifterna kan variera från vecka till vecka, men servicenivån förblir konsekvent.
- Prestationsbaserad: Denna struktur kopplar betalningen till utfall eller mätbara resultat snarare än till nedlagda timmar eller levererade tillgångar. Den fungerar endast när båda parter är överens om tydliga mätvärden, utgångsläget är klart och leverantören har tillräcklig kontroll över resultatet.
Snabbtips:
- Fasta, väl definierade leverabler → leveransbaserad
- Osäker eller utredningskrävande arbetsbeskrivning → tid och material
- Löpande support eller fast avtal → arbetsinsats
- Betalning kopplad till ett tydligt, mätbart resultat → prestationsbaserad
De flesta tvister om arbetsomfånget uppstår när strukturen inte stämmer överens med arbetet. Ett leveransbaserat arbetsbeskrivningsdokument kan fungera bra för en fast webbplatsutveckling, men det kan bli riskabelt för ett projekt som fortfarande kräver forskning, strategi eller samordning med intressenterna. Om du ännu inte kan ange vilka leveranser som ska göras, låtsas inte att du kan det i arbetsbeskrivningsdokumentet. Använd en struktur som återspeglar osäkerheten.
Hur man skriver en arbetsbeskrivning (steg-för-steg-guide)
För att skriva en SOW ska du definiera målet, lista vad som ingår och vad som inte ingår, dela upp dem i uppgifter, fastställa en tidsplan med beroenden, skriva acceptanskriterier, ange antaganden och en process för ändringshantering, och sedan lägga till kostnader och godkänna dokumentet. Dessa sju steg tar ett projekt från start till avslut. I praktiken:
Steg 1: Definiera målen och framgångskriterierna
Börja med att definiera varför arbetet utförs och hur ett bra resultat ska se ut. Detta utgör grunden för hela arbetsbeskrivningen. Om målet är vagt kommer även leveranserna, tidsplanen och godkännandeprocessen att bli vaga.
Formulera målet i en eller två meningar som kunden kan känna igen sig i. Undvik intern jargong och vaga formuleringar som ”förbättra varumärkets närvaro” eller ”stödja marknadsföringsinsatserna”. Koppla istället arbetet till ett tydligt affärsresultat.
Till exempel:
- Svagt mål: ”Skapa en bättre webbplats.”
- Tydligare mål: ”Omforma webbplatsen så att B2B-köpare snabbare förstår produkten och skickar in förfrågningar om demonstrationer med färre avhopp.”
Lägg sedan till framgångskriterier. Dessa behöver inte alltid vara hårda KPI:er, särskilt om projektet är kreativt eller inriktat på utforskning. Men de bör förklara hur båda parter ska kunna avgöra om arbetet har uppnått sitt syfte.
Steg 2: Lista vad som ingår och vad som inte ingår i leveransen
Ange sedan varje leverans som kunden kommer att få. Var specifik, konkret och tydlig.
Undvik allmänna verb som ”hantera”, ”stödja”, ”ta hand om” eller ”optimera” om du inte definierar vad de innebär. Dessa ord låter användbara i ett anbud, men de skapar utrymme för omfattningsglidning i ett SOW.
Till exempel:
- Svagt leveransmål: ”Sköta företagets blogg.”
- Tydligare leveranskrav: ”Publicera fyra SEO-blogginlägg per månad, vart och ett på mellan 1 500 och 2 000 ord, med en revisionsomgång per inlägg.”
Den mer omfattande versionen förklarar för kunden vad de får, hur mycket de får och var gränserna går. Ange sedan vad som inte ingår i leveransen i samma avsnitt. Här specificerar du vad som inte ingår i arbetet, även om det känns självklart för dig.
För ett bloggprojekt kan följande exempel på icke-levererbara delar ingå:
- Sökordsanalys utöver den godkända innehållsplanen
- Ladda upp inlägg till CMS:et
- Anpassade bilder eller illustrationer
- Intervjuer med sakkunniga
- Mer än en revisionsomgång per artikel
- Marknadsföring i sociala medier efter publicering
Exempel från verkligheten: Bagagesystemet på Denver International Airport
Det automatiserade bagagesystemet på Denver International Airport är en nyttig varning för alla arbetsbeskrivningar.
Det övergripande uppdraget lät enkelt: bygga ett automatiserat bagagesystem för den nya flygplatsen. Men det faktiska arbetet omfattade flera terminaler, flygbolag, bagagetyper, routningsregler och operativa undantag.
Enligt en granskning av projektet utförd av GAO tilldelade Denver BAE Automated Systems ett kontrakt värt cirka 195,6 miljoner dollar 1992. År 1995 hade kostnaden stigit till över 290 miljoner dollar. Flygplatsens invigning försenades också från oktober 1993 till februari 1995 på grund av systemproblem och omfattande ändringar.
Arbetsomfattningen förändrades ständigt på grund av tillkommande transportband, hantering av bagage i udda storlekar, underhållsutrustning, uppdateringar av rutter och ändringar som flygbolagen begärde. En senare överenskommelse minskade bagagehanteringskapaciteten från 65 väskor per minut per linje till 30. Denver var också tvunget att bygga ett konventionellt reservsystem för bagagehantering, vilket GAO uppskattade till 63 miljoner dollar.
Lärdom: Definiera inte bara det övergripande resultatet, utan även gränserna kring det. I beskrivningen av ett ”automatiserat bagagesystem” borde det ha angetts vilka flygbolag, bagagetyper, undantag, reservprocesser och teststandarder som ingick eller inte ingick.
Men gränserna på papperet var inte hela lösningen. Denver hade en arbetsbeskrivning. Vad man saknade var en arbetsbeskrivning kopplad till det praktiska genomförandet, så varje transportband, ändring av rutten och begäran från flygbolaget blev ett sidavtal som aldrig införlivades i det ursprungliga dokumentet. Dokumentet och byggprojektet blev två skilda projekt.
Steg 3: Dela upp leveranserna i uppgifter
När du har listat varje leverans, gör ett enkelt test: skulle någon kunna börja arbeta utifrån den här raden redan imorgon?
Om svaret är nej är beskrivningen fortfarande för allmän.
Ta ett leveransmål i taget och dela upp det i åtgärder på uppgiftsnivå med hjälp av formatet verb + objekt. Till exempel: ”skapa wireframe för hemsidan”, ”granska juridisk text”, ”godkänna slutlig design” eller ”ladda upp blogginlägg till CMS”. Undvik vaga uppgiftsnamn som ”webbplatsarbete”, ”innehållssupport” eller ”designuppdateringar”. De visar inte vem som gör vad.
För ett bloggprojekt (4 SEO-blogginlägg per månad) kan uppgiftsfördelningen se ut så här:
| Uppgift | Ägare | Beroende |
|---|---|---|
| Bekräfta ämnen och nyckelord | Innehållsstrateg/SEO-strateg | Kunden godkänner innehållsplanen |
| Skapa uppdragsbeskrivningar | Innehållsstrateg | Nyckelord bekräftade |
| Skriv första utkast | Författare | Godkända uppdragsbeskrivningar |
| Granskning av produktens korrekthet | Kund SME | Inlämnade utkast |
| Redigera för att förbättra strukturen och tydligheten | Redaktör | Kommentarer från SME har lagts till |
| Lägg till interna länkar och metadata | SEO-specialist | Slutredigeringen är klar |
| Ladda upp till CMS | Innehållsansvarig | Kunden godkänner det slutgiltiga utkastet |
Denna uppgiftsnivå synliggör den faktiska arbetsbelastningen bakom leveransen. Den visar också var förseningar kan uppstå. Om kundens ämnesexpert inte granskar utkastet i tid, drabbas redaktören, SEO-specialisten och innehållsansvarig av förseningar. Denna beroendestruktur bör vara tydlig redan innan projektet startar.
För större projekt bör du använda en arbetsfördelningsstruktur. Det innebär att du grupperar arbetet efter faser och sedan delar upp varje fas i specifika uppgifter. En omdesign av en webbplats kan till exempel omfatta behovsanalys, webbplatskarta, wireframes, text, design, utveckling, kvalitetssäkring, inställning av analysverktyg och lansering. Varje fas ska sedan brytas ned till enskilda uppgifter med en ansvarig person, ett slutdatum och en godkännandepunkt.
Du kan skapa denna uppgiftskarta i:
- ClickUp, Asana eller monday.com för ägare, deadlines, beroenden och statusuppföljning
- Jira för arbetsbeskrivningar inom mjukvara, produktutveckling och teknik
- Trello för enklare leverans i Kanban-stil
- Använd Miro eller FigJam för att visuellt kartlägga arbetsflödet innan du omvandlar det till uppgifter
- Google Sheets eller Excel om kunden vill ha en enkel uppgiftstabell bifogad till arbetsbeskrivningen
Steg 4: Fastställ tidsplan, milstolpar och beroenden
Omvandla nu uppgiftslistan till en tidsplan. Lägg till startdatum, slutdatum, viktiga milstolpar och eventuella beroenden som kan påverka leveransen.
Skriv inte bara ”Projektet ska vara klart om sex veckor”. Dela upp tidsplanen i faser, till exempel kartläggning, första utkast, granskning, revideringar, slutgiltigt godkännande och lansering. Markera sedan vilka milstolpar som utlöser betalning, godkännande eller nästa arbetsfas.
Till exempel:
- Uppstartssamtal genomfört senast den 3 maj
- Kunden tillhandahåller varumärkesmaterial senast den 6 maj
- Första utkastet ska vara klart senast den 15 maj
- Feedback från kunden ska lämnas in inom tre arbetsdagar
- Slutliga revideringar levereras senast den 24 maj
- Slutgiltigt godkännande senast den 28 maj
Det viktigaste är att identifiera beroenden, särskilt de på kundsidan. Många projektförseningar beror inte på själva arbetet. De beror på försenad feedback, saknade inloggningsuppgifter, försenade juridiska granskningar, intressenter som inte är tillgängliga eller material som anländer efter att teamet redan har påbörjat arbetet.
Se till att dessa är tydligt angivna innan arbetet påbörjas.
Till exempel: ”Projektets tidsplan är beroende av att kunden lämnar feedback i tid, att nödvändiga verktyg finns tillgängliga och att godkända varumärkesmaterial levereras. Förseningar i feedback, godkännanden, åtkomst eller material kan förskjuta projektets tidsplan med motsvarande antal arbetsdagar.”
Steg 5: Skriv acceptanskriterier för varje leverans
Definiera för varje leverans vad som räknas som godkänt. Det är denna klausul som förhindrar att ett projekt hamnar i en ändlös spiral av ”nästan klara”-revideringar.
Se till att kriterierna är kopplade till observerbara kontroller. Vid en webbplatsmigrering kan ”klar för lansering” innebära att omdirigeringar har testats, att analysverktygen fungerar, att kontaktformulären fungerar och att de godkända sidorna laddas korrekt på både datorer och mobiler. För en säljpresentation kan det innebära något helt annat.
Undvik formuleringar som enbart bygger på subjektiva bedömningar, såsom ”kunden är nöjd med arbetet”. En bättre formulering skulle vara:
”Leveransen anses godkänd när den uppfyller de överenskomna kriterierna, inkluderar den godkända revisionsomgången och har fått skriftligt godkännande från kunden.”
Detta ger båda parter en tydlig avgränsning. Nya önskemål kan fortfarande komma in efter det, men de hanteras som ändringsförslag snarare än som en utvidgning av den ursprungliga arbetsbeskrivningen.
Steg 6: Ange antaganden, undantag och en process för ändringshantering
Det är här du skyddar projektet mot smygande utvidgning.
Antaganden
- Feedback från kunden kommer inom tre arbetsdagar
- Alla nödvändiga källfiler kommer att finnas tillgängliga innan projektet startar
- Ett enda beslutsfattare kommer att ge det slutgiltiga godkännandet
Undantag
- Logotypdesign
- Löpande underhåll
- Begäran om nya sidor som går utöver den överenskomna omfattningen
- SEO-stöd efter lansering
Process för ändringshantering
- Allt arbete som ligger utanför detta arbetsomfång måste begäras skriftligen
- Förfrågan kommer att granskas med avseende på kostnads- och tidsmässiga konsekvenser
- Båda parter måste godkänna ändringen innan arbetet påbörjas.
Den sista delen är viktigast. Om leverantören utför extra arbete först och diskuterar betalningen senare blir det mycket svårare att genomdriva ändringsbegäran.
Exempel från verkligheten: FBI:s projekt ”Virtual Case File”
FBI:s projekt ”Virtual Case File” är ett tydligt exempel på varför förändringshantering och milstolpar måste fastställas i arbetsbeskrivningen redan i ett tidigt skede.
Projektet syftade till att modernisera FBI:s ärendehanteringssystem. Men enligt en granskning utförd av justitiedepartementets generalinspektör saknade FBI och dess underleverantörer en klar förståelse för designkraven allteftersom arbetet fortskred. En projektledare vid FBI uppgav att omfattningen av Trilogy-programmet ökade med cirka 80 % efter att projektet hade inletts.
Kontraktsstrukturen gjorde också problemet svårare att hantera. Granskningen visade att arbetsbeskrivningarna inte innehöll specifika milstolpar för färdigställande och kritiska beslutspunkter, och att det inte fastställdes några påföljder om milstolparna inte uppnåddes.
Projektet lades slutligen ner efter att cirka 170 miljoner dollar hade spenderats.
Lärdomen: Skriv fast förändringsprocessen innan arbetet påbörjas. Arbetsbeskrivningen bör specificera hur ändringar begärs, prissätts, godkänns och integreras i tidsplanen, med konkreta milstolpar och granskningspunkter inbyggda. Annars blir ändringar av arbetsomfånget informella beslut, och informella beslut blir kostsamma.
Det är samma misstag som med en arkiverad PDF-fil, fast i en skala på 170 miljoner dollar: arbetsbeskrivningarna var statiska medan kraven förändrades. Eftersom inget kopplade samman arbetsbeskrivningen med det pågående arbetet fanns det inget som kunde fånga upp den 80-procentiga tillväxten när den inträffade.
Steg 7: Ange kostnad, betalningsvillkor och godkännande
Avsluta arbetsbeskrivningen med de kommersiella villkoren: totalpris, faktureringsstruktur, betalningsplan, förfallodatum, villkor vid försenad betalning samt den person som är behörig att godkänna arbetet.
Koppla betalningarna till tydliga delmål där det är möjligt. Till exempel:
- 40 % betalas vid kontraktsskrivningen
- 30 % ska betalas efter den första större leveransen eller inlämningen av utkastet
- 30 % betalas efter slutleverans eller godkännande
För löpande uppdrag ska du ange det månatliga arvode, faktureringsdatum, vad som ingår i uppdraget samt vad som gäller om kunden överskrider de överenskomna timmarna eller leveranserna.
Se sedan till att få ett skriftligt godkännande. En SOW utan godkännande är bara ett arbetsutkast. Underskrifter bekräftar att båda parter är överens om leveranser, tidsplan, undantag, betalningsvillkor och ändringsprocess innan arbetet påbörjas.
Skapa en arbetsbeskrivning på några minuter med denna färdiga mall
Mallen för arbetsbeskrivning från ClickUp ger dig ett färdigt dokument där du kan samla projektdetaljer, leverabler, ansvarsområden, tidsplaner, förändringshantering, budget och godkännanden på ett och samma ställe. Den är användbar när du vill att arbetsbeskrivningen ska bli en del av projektets arbetsflöde.
Varför använda den här mallen:
- Planera de centrala avsnitten i arbetsbeskrivningen redan från början, inklusive bakgrund och mål, leverabler, leverantörens ansvar, kundens ansvar, tidsplan, kommunikationsplan, förändringshantering, budget och godkännanden
- Länka arbetsbeskrivningen till rätt plats i ClickUp, så att dokumentet kopplas tillbaka till det faktiska projektet
- Använd över 15 anpassade vyer, såsom Lista, Gantt, Arbetsbelastning och Kalender, för att omvandla den skriftliga arbetsbeskrivningen till spårbart arbete med ansvariga, datum och beroenden
- Lägg till anpassade fält och statusar för att följa godkännandeprocessen, ändringar i arbetsbeskrivningen, budgetdetaljer och intressenternas ansvarsområden under projektets gång
Exempel på arbetsbeskrivningar per bransch
En SOW innehåller samma huvudavsnitt oavsett bransch: mål, leverabler, tidsplan, antaganden, undantag, godkännandekriterier, betalningsvillkor och godkännande.
Det som förändras är risken.
Ett webbplatsprojekt misslyckas oftast på grund av antalet sidor, revideringar, äganderätten till CMS-systemet och support efter lanseringen. Ett byggprojekt misslyckas däremot ofta på grund av bygglov, förhållanden på byggplatsen, besiktningar och materialändringar.
Använd exemplen nedan som vägledning för att utforma din egen arbetsbeskrivning, inte som avtal som ska kopieras ord för ord.
Här är ett exempel på en arbetsbeskrivning för omdesign av en webbplats i miniatyr, där alla centrala avsnitt är ifyllda:
Mål: Ersätta marknadsföringssajten för att hjälpa B2B-köpare att snabbare förstå produkten och öka antalet anmälningar till demonstrationer.
Leverans: 8 utformade och utvecklade sidor baserade på den godkända webbplatskartan, 2 revisionsomgångar per sida, överlämning av CMS och en 1-timmars utbildning.
Tidsplan: 6 veckor fördelat på 3 milstolpar: godkännande av design (vecka 2), färdigställande av utveckling (vecka 4), lansering (vecka 6).
Godkännandekriterier: Varje sida godkänns mot den undertecknade designskissen, laddas korrekt på både dator och mobil och godkänns skriftligen av kunden.
Undantag: Textförfattande, licensiering av stockfoton, nya sidor utöver webbplatskartan, SEO-migrering, underhåll efter lansering.
Betalning: 40 % vid avtalsskrivning, 30 % när bygget är klart, 30 % vid lansering.
Ändringshantering: Alla förfrågningar som ligger utanför detta arbetsomfång registreras, prissätts med hänsyn till kostnads- och tidsmässig påverkan och godkänns skriftligen innan arbetet påbörjas.
Mål: Ersätta marknadsföringssajten för att hjälpa B2B-köpare att snabbare förstå produkten och öka antalet anmälningar till demonstrationer.
Leverans: 8 utformade och utvecklade sidor baserade på den godkända webbplatskartan, 2 revisionsomgångar per sida, överlämning av CMS och en 1-timmars utbildning.
Tidsplan: 6 veckor fördelat på 3 milstolpar: godkännande av design (vecka 2), färdigställande av utveckling (vecka 4), lansering (vecka 6).
Godkännandekriterier: Varje sida godkänns mot den undertecknade designskissen, laddas korrekt på både dator och mobil och godkänns skriftligen av kunden.
Undantag: Textförfattande, licensiering av stockfoton, nya sidor utöver webbplatskartan, SEO-migrering, underhåll efter lansering.
Betalning: 40 % vid avtalsskrivning, 30 % när bygget är klart, 30 % vid lansering.
Ändringshantering: Alla förfrågningar som ligger utanför detta arbetsomfång registreras, prissätts med hänsyn till kostnads- och tidsmässig påverkan och godkänns skriftligen innan arbetet påbörjas.
Arbetsbeskrivning för kreativ byrå eller omdesign av webbplats
Risken vid webbuppdrag är dolda arbetsinsatser. En kund kan utgå från att textinnehåll, SEO-migrering, nya sidor, stockfoton, anpassad grafik, CMS-uppladdning och support efter lansering ingår, såvida inte arbetsbeskrivningen anger något annat.
Innehåller:
- Antal sidor eller mallar
- Ansvar för design och utveckling
- Antal revideringsomgångar per sida
- Överlämning av CMS eller utbildning
- Testning av webbläsare och enheter
- Öppna supportfönstret
Uteslut:
- Textförfattande om inte annat anges
- Stockfotografier eller licensavgifter
- Nya sidor utöver den godkända webbplatskartan
- SEO-migrering om inte annat anges
- Löpande underhåll efter lansering
Exempel på formuleringar i arbetsbeskrivningar:
”Leverantören ska utforma och utveckla åtta webbsidor utifrån den godkända webbplatskartan, med upp till två revisionsomgångar per sida. Textförfattande, licensiering av stockbilder, begäran om ytterligare sidor, SEO-migrering och underhåll efter lansering ingår inte, såvida inte detta godkänts genom en skriftlig ändringsbegäran.”
Arbetsbeskrivning för byggprojekt
Risken inom byggbranschen är att man antar att ”byggandet” omfattar allt som har med byggandet att göra. Bygglov, besiktningar, tillträde till byggplatsen, väderrelaterade förseningar, ökade materialkostnader och ägarstyrda designändringar måste behandlas uttryckligen.
Innehåller:
- Arbeta i olika faser, till exempel rivning, förberedelse av byggplatsen, stomarbete, elinstallation, VVS-arbete, slutbehandling eller städning
- Material och specifikationer
- Kontrollpunkter
- Milstolpar för utbetalning
- Regler för tillträde till arbetsplatsen
Uteslut:
- Tillståndsavgifter, om dessa inte ingår
- Oförutsedda förhållanden på byggarbetsplatsen
- Designändringar på begäran av beställaren
- Materialuppgraderingar efter godkännande
- Arbete utanför de godkända ritningarna
Exempel på formuleringar i arbetsbeskrivningar:
”Entreprenören ska utföra förberedelser på byggplatsen, stomarbete, grovinstallation av el samt slutbearbetning i enlighet med de godkända ritningarna och specifikationerna. Avgifter för bygglov, ändringar som beställaren begär, oförutsedda förhållanden på byggplatsen samt materialuppgraderingar ingår inte och kommer att hanteras genom en ändringsorder.”
Arbetsbeskrivning för mjukvaru- eller produktutveckling
Risken inom mjukvaruutveckling är vagt formulerade funktionsbeskrivningar. ”Bygg en instrumentpanel” kan betyda tio olika saker för tio olika intressenter. Definiera funktionen, testvillkoren, miljön, ansvaret för integrationen och supportperioden efter lanseringen.
Innehåller:
- Användarberättelser eller funktionslista
- Funktionella krav
- Icke-funktionella krav, såsom prestanda, säkerhet och tillgänglighet
- Ansvar för API eller integration
- Omfattning av testning och felkorrigering
- Förberedelse och överlämning till produktion
Uteslut:
- Funktioner som inte ingår i de listade användarberättelserna
- Kostnader för verktyg från tredje part
- Datarensning eller migrering, såvida inte detta ingår i uppdraget
- Stora UX-omgestaltningar
- Support efter garantiperioden
Exempel på formuleringar i arbetsbeskrivningar:
”Leverantören ska utveckla de användarberättelser som anges i bilaga A och driftsätta dem i testmiljön för granskning av kunden. Funktioner som inte ingår i bilaga A, abonnemangsavgifter för tredjepartstjänster, rensning av historiska data samt support efter garantitidens utgång ingår inte, såvida inte detta godkänns genom en ändringsbegäran.”
Arbetsbeskrivning för marknadsföringskampanj
Risken inom marknadsföring ligger i att blanda ihop leverabler med resultat. Du kan fastställa omfattningen för kampanjstrategi, marknadsföringsmaterial, rapportering och lanseringsstöd. Du bör vara försiktig med att lova antal leads, intäkter, CAC eller ROAS, såvida inte leverantören har kontroll över mediebudgeten, landningssidan, säljuppföljningen och inställningarna för spårning.
Innehåller:
- Kampanjstrategi
- Målgrupp och budskap
- Antal annonskoncept eller kreativa varianter
- Skriva eller skapa innehåll till en landningssida
- E-posttext
- Rapporteringspanel
- Rapporteringsfrekvens
Uteslut:
- Utgifter för betalda medier
- Konfigurering av annonskonto, om inte annat anges
- Extra kreativa varianter
- Arvoden till influencers eller samarbetspartners
- Uppföljning av försäljningen
- Prestandagarantier utanför överenskomna kontroller
Exempel på formuleringar i arbetsbeskrivningar:
”Leverantören ska tillhandahålla en kampanjstrategi, tre kreativa annonskoncept, text till landningssidan, två marknadsföringsmejl och en resultatrapporteringspanel. Utgifter för betalda medier, arvoden till influencers, ytterligare kreativa varianter och försäljningsuppföljning ingår inte. Resultatmålen är vägledande såvida de inte separat är kopplade till godkänd budget, mätning och kampanjkontroller.”
Arbetsbeskrivning för konsultuppdrag eller fast uppdrag
Risken med fasta avtal är oklar kapacitet. ”Löpande support” kan innebära obegränsat antal samtal, strategi, genomförande, rapportering och ad hoc-förfrågningar, om inte arbetsbeskrivningen definierar timmar, svarstider, mötesfrekvens och regler för förlängning.
Innehåller:
- Antal timmar per månad eller leveransvolym
- Förväntningar på svarstid
- Mötesschema
- Rapporteringsfrekvens
- Huvudsaklig kontaktperson
- Regler för förlängning eller upphörande
Uteslut:
- Arbete utöver månatliga arbetstimmar
- Leverans samma dag om inte annat avtalats
- Nya strategiska projekt
- Ytterligare workshoppar för intressenter
- Utförande av arbete utanför det avtalade tjänsteområdet
Exempel på formuleringar i arbetsbeskrivningar:
”Leverantören ska tillhandahålla upp till 20 timmars konsultstöd per månad, inklusive ett rådgivningssamtal per vecka, asynkron granskning av överenskomna underlag och en månatlig sammanfattning av rekommendationer. Outnyttjade timmar överförs inte till nästa månad. Nya projekt, förfrågningar som ska hanteras samma dag och arbete utöver 20 timmar kräver skriftligt godkännande.”
Det bästa tillvägagångssättet är detsamma i alla branscher: räkna upp leveranserna, ange de vanligaste antagandena och formulera undantag för de önskemål som mottagarna sannolikt kommer att framföra senare.
Omformulering: Betrakta arbetsbeskrivningen som en arbetsgrund, inte som en arkiverad PDF-fil
Vid det här laget är mönstret tydligt: en undertecknad PDF-fil kan inte följa med i ett projekt som utvecklas. Så den egentliga frågan är inte hur man skriver en bättre SOW, utan vad SOW:n blir efter undertecknandet.
Betrakta det som två saker, inte en. Det undertecknade avtalet förblir oförändrat som utgångspunkt – en dokumentation av vad båda parter kom överens om från början. Arbetet kring det förblir dynamiskt: uppgifter, ansvariga, tidsplaner, godkännanden, budgetar, risker och ändringsförslag. När dessa två är kopplade till varandra kan en ny begäran inte i smyg bli gratisarbete; den syns i förhållande till utgångspunkten som en ändring.
Här är skillnaden:
| Statisk arbetsbeskrivning | Arbetsbeskrivningens utgångsläge |
|---|---|
| Finns som PDF eller dokumentbilaga | Kopplat till uppgifter, tidsplaner, godkännanden och budget |
| Öppnas endast när något går fel | Används som referens under leverans- och granskningscykler |
| Ändringar sker via Slack, e-post eller separata samtal | Ändringar registreras, prissätts, godkänns och kopplas till hur de påverkar tidsplanen |
| Uppgiftslistan avviker från det ursprungliga avtalet | Genomförandet kan spåras tillbaka till den godkända arbetsbeskrivningen |
Det undertecknade arbetsbeskrivningsdokumentet bör inte redigeras på ett slarvigt sätt varje gång något ändras. Detta är ett miniatyrproblem av typen ”work-sprawl”, där uppdateringen hamnar i ett direktmeddelande, arbetsbeskrivningen finns i ett separat dokument och uppgiftslistan finns någon annanstans.
Det är här verktyg som ClickUp kommer till nytta. Arbetsbeskrivningen kan finnas samlad tillsammans med uppgifter, kommentarer, godkännanden, deadlines och budget.
Denna korta ClickUp-video visar hur det ser ut och hur teamen får ihop det hela.
Bästa praxis: Se alltid till att originalversionen förblir oförändrad och hantera ändringar genom en tydlig ändringslogg eller godkänd ändringsbegäran. Om en kund till exempel ber om två extra landningssidor under en kampanj ska begäran inte bara dyka upp på projekttavlan. Den ska registreras som en ändring av arbetsomfattningen, granskas med avseende på påverkan på kostnad och tidsplan, godkännas skriftligen och sedan läggas till i arbetsplanen.
Så här hanterar du ett arbetsomfång i ClickUp
Det är enklare att hantera en arbetsbeskrivning när dokumentet, uppgifterna, godkännandena och tidsplanen hänger ihop:
Använd ClickUp Docs för att skriva arbetsbeskrivningen där arbetet utförs
Börja med arbetsbeskrivningen i ClickUp Docs. Du kan använda dokumentet för att fastställa mål, leverabler, undantag, tidsplan, godkännandekriterier och betalningsvillkor. Allteftersom projektet fortskrider kan dokumentet sedan förbli kopplat till de uppgifter och milstolpar som det reglerar.
I avsnittet ”Leverabler” i ett arbetsbeskrivningsdokument för en webbplats kan man till exempel länka till uppgifter som rör text till startsidan, wireframes, designgranskning, utveckling, kvalitetssäkring och slutgiltigt godkännande. Det gör det enklare att hänvisa till arbetsbeskrivningen under leveransen.
Omvandla leverabler till ClickUp-uppgifter och deluppgifter
När arbetsbeskrivningen är klar kan du omvandla varje leverans till en uppgift eller en grupp av deluppgifter med ClickUp Tasks.
Till exempel kan ”tre landningssidor” delas upp i separata uppgifter för varje sida. Varje sida kan sedan ha deluppgifter för text, design, utveckling, granskning, kvalitetssäkring och godkännande.
Detta hjälper teamet att se det faktiska arbetet bakom varje leverans. Det minskar också risken för en smygande utvidgning av arbetsomfånget. Om en fjärde landningssida dyker upp på uppgiftslistan är den lättare att upptäcka eftersom den inte stämmer överens med den ursprungliga arbetsbeskrivningen.
Övervaka aktiva arbetsbeskrivningar med realtidsdashboards
ClickUp-dashboards är till hjälp när du hanterar flera SOW:er samtidigt.
En byrå, en entreprenör eller ett driftsteam kan använda översiktspaneler för att följa upp försenade godkännanden, arbete per kund, kommande milstolpar, öppna ändringsförfrågningar, arbetsbelastning och budgetsignaler. Detta gör det enklare att upptäcka risker i arbetsomfattningen innan de blir ett marginalproblem.
Om till exempel tre kundprojekt väntar på återkoppling kan en översiktssida visa förseningen för alla konton istället för att gömma den i separata uppgiftslistor.
ClickUps instrumentpaneler har förändrat hur vi sköter den dagliga driften på byrån. Vi övervakar kapaciteten hos tre utvecklingsteam och upptäcker hinder innan de leder till förseningar, vilket gör att vi lägger mindre tid på att följa upp status i Slack-trådar och mer tid på att faktiskt driva kunduppdragen framåt.
ClickUps instrumentpaneler har förändrat hur vi sköter den dagliga driften på byrån. Vi övervakar kapaciteten i tre utvecklingsteam och upptäcker hinder innan de leder till förseningar, så att vi lägger mindre tid på att jaga statusuppdateringar i Slack-trådar och mer tid på att faktiskt driva kunduppdragen framåt.
Skapa utkast, sammanfatta och kontrollera sammanhanget med ClickUp Brain
ClickUp Brain kan utarbeta ett SOW utifrån en projektbeskrivning, sammanfatta långa kundsamtal, omvandla anteckningar till presentationer eller besvara frågor med hjälp av teamdata från uppgifter, dokument, chatt och anslutna arbetsytor.
När det gäller SOW innebär det att du kan ställa frågor som:
- ”Vilka leveranser väntar fortfarande på kundens godkännande?”
- ”Vilka uppgifter lades till efter det ursprungliga arbetsbeskrivningsdokumentet?”
- ”Sammanfatta de öppna ändringsförfrågningarna för denna kund.”
- ”Utarbeta acceptanskriterier utifrån dessa leverabler.”
Brain utvidgar dessutom denna kontextbaserade inriktning ytterligare med AI som bygger på företagets projekt, dokument, medarbetare, konversationer och kunskap.
Låt Super Agents sköta återkommande kontroller av arbetsomfånget
Superagenter är mest användbara när processen redan är definierad.
Ett team kan till exempel utse en ansvarig person som ska förbereda en veckovis genomgång av arbetsomfånget, sammanfatta försenade godkännanden, markera uppgifter som saknar status i arbetsomfånget eller utarbeta en uppdatering till kunden inför ett milstolpsmöte.
Ett bra användningsexempel skulle kunna vara:
”Varje fredag ska du sammanfatta alla öppna ändringsförfrågningar, uppgifter som lagts till under veckan, försenade godkännanden och milstolpar som är i riskzonen för detta kundprojekt.” Det ger projektledaren en snabbare granskningscykel. Det bör dock inte ersätta det formella godkännandet. Allt extraarbete måste fortfarande godkännas skriftligen innan det blir en del av arbetsbeskrivningen.
Ärlig begränsning
ClickUp är användbart när avvikelser från arbetsbeskrivningen medför reella kostnader: byråer, serviceteam, entreprenörer, konsulter, driftsteam och interna team som hanterar flera projekt samtidigt.
För en frilansare som arbetar ensam och skriver ett arbetsbeskrivningsdokument på en sida för ett enkelt projekt kan detta vara mer struktur än vad som behövs. Ett överskådligt dokument, en delad uppgiftslista och ett undertecknat godkännande kan räcka.
Fördelen blir tydlig när arbetsbeskrivningen inte längre bara är ett dokument. Den blir istället den utgångspunkt som ditt team kan koppla till uppgifter, tidsplaner, godkännanden, ändringsförfrågningar och kommunikation med kunden.
Vanliga misstag i arbetsbeskrivningar som bör undvikas
| Fel | Varför det orsakar problem | Fix |
|---|---|---|
| Vaga leveransmål | Ord som ”hantera”, ”stödja” eller ”optimera” kan tolkas på flera sätt när inga kvantiteter eller avgränsningar anges. | Namnge resultatet, lägg till ett nummer och definiera överlämningen |
| Ingen lista över undantag | Allt som inte uttryckligen nämns kan antas ingå, särskilt när det gäller uppdrag för kunder. | Lägg till ett avsnitt om ”arbete utanför uppdraget” för relaterade uppgifter som kunden rimligen kan förvänta sig |
| Räkna revisioner utan att definiera en revision | ”Två omgångar” kan fortfarande bli rörigt om en omgång innehåller tio ändringar som inte har något med varandra att göra från fem intressenter | Definiera vad en revisionsomgång innefattar, vem som kan begära den och när den avslutas |
| Ingen process för ändringshantering | Varje ny förfrågan blir en informell förhandling när arbetet redan har påbörjats | Kräv skriftligt godkännande för alla ändringar av arbetsbeskrivningen, inklusive konsekvenser för kostnad och tidsplan |
| Att bortse från beroenden på kundsidan | Försenad återkoppling, saknade filer eller försenade godkännanden kan förskjuta tidsplanen, samtidigt som leverantören får ta på sig skulden | Ange vad kunden måste tillhandahålla, senast när, och hur förseningar påverkar leveransdatum |
Gör ditt arbetsbeskrivningsdokument till ett levande system
En bra arbetsbeskrivning lönar sig tre gånger om. Att skriva den tvingar dig att konkretisera de otydliga delarna. Under projektets gång löser den tvister innan de eskalerar. Och när arbetsomfånget kryper utöver det avtalade gör den förändringen synlig istället för att låta den glida igenom obemärkt.
Men allt detta är beroende av en enda förutsättning: dokumentet får inte hamna i glömska i en inkorg.
De team som får ut mest av detta betraktar arbetsbeskrivningen som ett levande system: tydligt definierad från början, kopplad till de faktiska uppgifterna och reviderad i takt med att arbetet utvecklas. Täck in de sju komponenterna, kvantifiera varje leverans, specificera undantagen och se till att dokumentet förblir kopplat till det arbete det beskriver.
Det snabbaste sättet att omsätta detta i praktiken är att utgå från en mall och koppla den till ditt projekt. Kom igång med ClickUp gratis, anpassa SOW-mallen i Docs och länka sedan varje leverans till de uppgifter som ska åstadkomma den.
Vanliga frågor om arbetsbeskrivningar
Vad är skillnaden mellan en arbetsbeskrivning och ett projektomfång?
En arbetsbeskrivning är ett dokument som specificerar leveranser och uppgifter för ett specifikt uppdrag eller en specifik fas. Projektomfattningen är det bredare planeringsbegreppet som definierar projektets fullständiga avgränsning: allt som ingår och allt som inte ingår. Kort sagt beskriver arbetsbeskrivningen en del av arbetet, medan projektomfattningen beskriver hela den ram som arbetet ingår i.
Vad är skillnaden mellan en arbetsbeskrivning och ett ramavtal (MSA)?
Ett ramavtal (MSA) fastställer de övergripande juridiska och kommersiella villkoren som reglerar en pågående relation mellan kund och leverantör; en arbetsbeskrivning definierar vad som ska levereras för ett specifikt projekt inom ramen för detta. Den typiska hierarkin är att ramavtalet (MSA) ligger högst upp, enskilda arbetsbeskrivningar under det och arbetsbeskrivningen inbäddad i varje enskild arbetsbeskrivning. Ramavtalet (MSA) undertecknas en gång; en ny arbetsbeskrivning utfärdas för varje uppdrag.
Vilka är de fyra typerna av arbetsbeskrivningar?
De fyra vanligaste strukturerna är leveransbaserad (betalning kopplad till specifika resultat), tid-och-material (fakturering av timmar och kostnader allteftersom arbetet utförs), arbetsinsatsbaserad (en fastställd kapacitet under en viss period, vanligt vid fasta arvoden) och prestationsbaserad (betalning kopplad till mätbara resultat). Välj den struktur som bäst stämmer överens med hur förutsägbara leveranserna är. De flesta tvister om arbetsomfånget uppstår när strukturen inte passar arbetet.
Vem skriver arbetsbeskrivningen?
Det är vanligtvis den som utför arbetet som utarbetar arbetsbeskrivningen: byrån, leverantören eller den interna projektledaren. Båda parter granskar och godkänner sedan dokumentet innan arbetet påbörjas. Att utarbeta den själv är en fördel eftersom det ger dig möjlighet att fastställa leveranser, gränser och undantag på dina villkor.
Är en arbetsbeskrivning juridiskt bindande?
En arbetsbeskrivning blir juridiskt bindande så snart den undertecknas som en del av ett avtal eller en arbetsbeskrivning. I sig själv definierar den främst arbetet, men inom ramen för ett undertecknat avtal blir den en referens för vad som har utlovats. För allt som rör avtal bör du låta en kvalificerad expert granska de bindande villkoren.
Kan en arbetsbeskrivning användas för interna projekt?
Ja. Ett arbetsomfång fungerar mellan interna team – till exempel när marknadsavdelningen beställer en datadashboard eller driftsavdelningen begär ett internt verktyg – på exakt samma sätt som mellan en kund och en leverantör. Komponenterna är identiska: mål, leverabler, tidsplan, godkännandekriterier och undantag. Den enda skillnaden är att godkännandet kommer från en intern intressent istället för en extern kund, och att betalningsvillkoren kan ersättas av budget- eller resursallokering.
Vad är ett annat ord för arbetsbeskrivning?
Ett arbetsomfång kallas ibland för arbetsbeskrivning, projektbeskrivning eller helt enkelt ”omfånget”, även om dessa termer inte är perfekta synonymer. En arbetsbeskrivning är det övergripande avtalet, medan en projektbeskrivning är den interna planeringsversionen. Om någon använder termerna vagt, bekräfta då om de avser leveranserna (arbetsomfånget) eller det fullständiga avtalet (arbetsbeskrivningen) innan du agerar utifrån det.
Vad är skillnaden mellan en arbetsbeskrivning och en arbetsfördelningsstruktur (WBS)?
Ett arbetsomfång anger vad som ska levereras och villkoren kring detta; en arbetsfördelningsstruktur (WBS) delar upp dessa leverabler i en hierarki av delleverabler och uppgifter. Arbetsomfånget är avtalet; WBS är den underliggande genomförandekartan. Du bygger upp WBS utifrån leverablerna i arbetsomfånget, vilket gör att dokumentet förblir kopplat till de faktiska uppgifterna istället för att glida iväg.