Hur man skriver en arbetsbeskrivning

Arbetsbeskrivning. Hur enkelt det än låter är det ingen lätt uppgift att göra rätt. Men ingenting är mer grundläggande för att ett projekt ska lyckas. Om arbetsbeskrivningen är för vag, för bred eller för allmän kan den ge utrymme för olika tolkningar, vilket kan leda till problem längre fram. Det gäller för ett internt projekt, och det gäller dubbelt så mycket när det finns leverantörer inblandade.

”Att en arbetsbeskrivning inte genomförs på rätt sätt är ofta orsaken till att parterna hamnar i en tvist”, säger David M. Greenberg, advokat i gruppen för teknik, media och telekommunikation vid Greenberg Traurig LLP:s New York-kontor.

För att få ditt projekt rätt från början bör du följa dessa riktlinjer för att skriva en effektiv arbetsbeskrivning, eller SOW, som det kallas.

Förstå vad en SOW är.

En SOW definierar omfattningen av det arbete som krävs och den tid inom vilken det ska utföras. Det är ”hörnstenen i ett avtal”, säger Nick Scafidi, IT-upphandlingsansvarig på energileverantören National Grid USA i Westboro, Massachusetts. ”Det fastställer förväntningar, leveranser, vad som är acceptabelt, priset och prislistan. Utan det är det som att säga till en entreprenör: ’Bygg ett hus åt mig’ och tala om för honom när, vilken typ eller hur stort hus han ska bygga.”

Vissa vad som ska ingå.

Bruce Russell, som skrev under många SOW:s när han var operativ chef på ett programvaruutvecklingsföretag, säger att en bra SOW innehåller följande saker:

  • De viktigaste leveranserna och när de förväntas.
  • De uppgifter som stöder leveranserna samt vilken sida – det inhyrande företaget eller tjänsteleverantören – som kommer att utföra dessa uppgifter.
  • Projektets styrningsprocess samt hur ofta styrande kommittéer kommer att träffas.
  • Vilka resurser som krävs för projektet, vilka anläggningar som kommer att användas och vems utrustning som kommer att behövas, samt testningskrav.
  • Vem som kommer att betala vilka kostnader och när.

”Arbetsbeskrivningen samlar alla delar i början”, säger Russell, som nu är professor i företagsledning vid Northeastern University’s College of Business i Boston. ”Ju mer exakt du kan göra det, ju mer kvantitativt, desto bättre.”

Definiera framgång.

En arbetsbeskrivning bör klargöra för alla parter vad som utgör framgång eller misslyckande, säger Melise R. Blakeslee, advokat i gruppen för immateriella rättigheter, media och tekniska transaktioner vid McDermott Will & Emery LLP i Washington.

”Du måste beskriva arbetet på ett adekvat sätt och kriterierna för hur ni båda kan komma överens om att något är framgångsrikt genomfört”, säger Ruth Anne Guerrero, standardiseringsansvarig vid Project Management Institute Inc. i Newtown Square, Pennsylvania, och tidigare IT-projektledare.

Om du till exempel förväntar dig att din leverantör ska ta fram användarkrav bör det i ditt uppdragsavtal anges att leverantören måste intervjua specifika användargrupper och få dem att godkänna kraven innan arbetet anses vara slutfört. Detta definierar framgång bättre än att bara säga: ”Leverantören ska ta fram användarkrav”.

Definitionen av framgång beror på projektet, säger Guerrero. IT-projektledare måste specificera om ett framgångsrikt genomförande definieras av snabbhet, svarstid, användarvänlighet eller alla tre och sedan kvantifiera dem i kravspecifikationen.

Genomför inte en tidtabell.

Ett framgångsrikt genomförande kan dock inte definieras enbart av systemets snabbhet eller reaktionsförmåga. Vad är det för nytta med en fantastisk tillämpning om det tar ett decennium att bygga den? Det är därför som en SOW måste innehålla tidsaspekter. Guerrero rekommenderar att man använder ett språk som tillåter viss flexibilitet snarare än ett fast datum i kalendern. I en uppdragsbeskrivning bör det till exempel anges att slutanvändarkraven ska vara klara två månader efter det att kontraktet har undertecknats – en formulering som fortfarande får projektet att gå framåt samtidigt som den tar hänsyn till eventuella problem, till exempel en försening i undertecknandet av kontraktet.

En SOW bör också ange specifika tider för formella granskningar, så att alla inblandade kan bekräfta att de är på rätt spår, säger Matt Liberatore, professor vid avdelningen för besluts- och informationsteknik och John F. Connelly Chair in management vid College of Commerce and Finance vid Villanova University i Villanova, Pa.

Binda betalningen till milstolpar.

En annan viktig komponent för att hålla arbetet på rätt spår är att fastställa specifika milstolpar i kontraktet och knyta betalningen till ett framgångsrikt slutförande, säger Blakeslee.

När Scafidi skriver en SOW specificerar han att betalningar till leverantörer görs efter godkännande av viktiga leveranser. Han noterar också att han kommer att behålla en del av betalningen tills leverantören bevisar att alla leveranser fungerar tillsammans.

Använd ett språk som alla kan förstå.

Det är inte bara IT-avdelningen och dess leverantörer som använder SOW:n, säger Blakeslee. Skriv det därför inte som om det bara är IT-personal som kommer att se det. ”Den ska vara begriplig för slutanvändare, tjänsteleverantörer, ledningen och en domare”, säger hon.

Var specifik.

Och även om många parter måste förstå arbetsbeskrivningen bör du vara exakt när du beskriver projektets omfattning och krav, säger Blakeslee. Hon har sett dokument som fastställer vaga mål, till exempel ”kommer att arbeta efter bästa förmåga”. Hon jämför det med en husägare som anlitar en målare med instruktioner om att ”göra sitt bästa”.

”Om målaren gör det men målar ditt hus lila i stället för vitt, kan du inte göra anspråk på honom”, säger hon.

Scafidi har tagit sådana råd till sitt hjärta. I stället för att säga att en uppgift kommer att ta ”en rimlig tid” skriver Scafidi: ”Den angivna uppgiften kommer inte att ta mer än fyra timmar”.

”Advokater mår bra när vi har en klar, otvetydig definition på sådana saker”, säger han.

Håll dig till efterbehandlingsbehoven.

Guerrero rekommenderar att efterproduktionskraven inkluderas i SOW. Ange vilka tester och vilket stöd du behöver från leverantören, säger hon. Och om du planerar att låta intern personal stödja systemet efter installationen bör kontraktet ta upp om leverantören kommer att utbilda din personal. Ett sådant språk garanterar att leverantören inte bara levererar systemet och går därifrån.

Pratt är en av Computerworlds skribenter i Waltham, Mass. Kontakta henne på [email protected].

Lämna ett svar

Din e-postadress kommer inte publiceras.