Arbejdsbeskrivelse. Selv om det lyder ligetil, er det ikke nogen let opgave at få en korrekt. Men intet er mere grundlæggende for et projekts succes. Hvis arbejdsbeskrivelsen er for vag, for bred eller for generisk, kan den give plads til forskellige fortolkninger, hvilket kan føre til problemer senere hen. Det gælder for et internt projekt, og det gælder dobbelt så meget, når der er leverandører involveret.
“Manglende korrekt udførelse af en arbejdsbeskrivelse er ofte årsagen til, at parterne ender i en tvist,” siger David M. Greenberg, advokat i praksisgruppen for teknologi, medier og telekommunikation på Greenberg Traurig LLP’s New York-kontor.
For at få dit projekt rigtigt første gang skal du følge disse retningslinjer for at skrive en effektiv arbejdsbeskrivelse, eller SOW, som det kærligt kaldes.
Forstå, hvad en SOW er.
En SOW definerer omfanget af det krævede arbejde og det tidsrum, inden for hvilket det skal udføres. Det er “hjørnestenen i en aftale”, siger Nick Scafidi, it-indkøbschef hos energileverandøren National Grid USA i Westboro, Mass. “Den fastlægger forventninger, leverancer, hvad der er acceptabelt, prisen og tidsplanen for prisfastsættelsen. Uden det er det som at sige til en entreprenør: ‘Byg mig et hus’ og fortælle ham hvornår, hvilken slags eller hvor stort det skal være.”
Ved, hvad der skal medtages.
Bruce Russell, der har underskrevet adskillige SOW’er, da han var driftschef i et softwareudviklingsfirma, siger, at en god SOW indeholder følgende ting:
- De vigtigste leverancer og hvornår de forventes.
- De opgaver, der understøtter leverancerne, samt hvilken side – den ansættende virksomhed eller tjenesteudbyderen – der skal udføre disse opgaver.
- Projektets styringsproces, samt hvor ofte de styrende udvalg skal mødes.
- Hvilke ressourcer der kræves til projektet, hvilke faciliteter der skal bruges, og hvis udstyr der skal bruges, samt testkrav.
- Hvem skal betale hvilke omkostninger og hvornår.
“Arbejdsbeskrivelsen samler alle elementer i begyndelsen”, siger Russell, der nu er professor i ledelse ved Northeastern University’s College of Business i Boston. “Og jo mere præcis du kan gøre det, jo mere kvantitativt, jo bedre.”
Definér succes.
En arbejdsbeskrivelse bør for alle parter tydeliggøre, hvad der udgør succes eller fiasko, siger Melise R. Blakeslee, advokat i gruppen for intellektuel ejendomsret, medier og teknologitransaktioner hos McDermott Will & Emery LLP i Washington.
“Man er nødt til at beskrive, hvad arbejdet er, og kriterierne for, hvordan I begge er enige om”, at noget er afsluttet med succes, siger Ruth Anne Guerrero, standardansvarlig hos Project Management Institute Inc. i Newtown Square i Newtown Square, Pennsylvania, og tidligere it-projektleder.
For eksempel, siger hun, hvis du forventer, at din leverandør skal udvikle brugerkrav, bør din SOW angive, at leverandøren skal interviewe specifikke brugergrupper og få dem til at godkende kravene, før arbejdet anses for at være udført. Det definerer succes bedre end blot at sige: “Leverandøren skal udarbejde brugerkrav”.
Definitionen af succes afhænger af projektet, siger Guerrero. IT-projektledere skal specificere, om en vellykket implementering er defineret ved hastighed, svartid, brugervenlighed eller alle tre og derefter kvantificere dem i SOW’en.
Glem ikke en tidsplan.
Succesfulde implementeringer kan dog ikke defineres alene ud fra systemets hastighed eller responsivitet. Hvad nytter det trods alt at have en fantastisk applikation, hvis det tager et årti at bygge den? Det er derfor, at en SOW skal indeholde tidselementer. Guerrero anbefaler, at man bruger et sprog, der giver mulighed for en vis fleksibilitet i stedet for en fast dato i kalenderen. En SOW bør f.eks. specificere, at slutbrugerkravene skal foreligge to måneder efter, at kontrakten er underskrevet – en formulering, der stadig får projektet til at skride fremad, samtidig med at der tages højde for potentielle problemer som f.eks. en forsinkelse i forbindelse med underskrivelsen af kontrakten.
En SOW bør også udpege specifikke tidspunkter for formelle gennemgange, så alle involverede parter kan bekræfte, at de er på rette spor, siger Matt Liberatore, professor i afdelingen for beslutnings- og informationsteknologi og John F. Connelly Chair in management ved College of Commerce and Finance ved Villanova University i Villanova, Pennsylvania.
Binde betaling til milepæle.
En anden vigtig komponent for at holde arbejdet på sporet er at fastsætte specifikke milepæle i SOW’en og binde betalingen til en vellykket gennemførelse, siger Blakeslee.
Når Scafidi skriver en SOW, specificerer han, at betalinger til leverandører sker efter accept af vigtige leverancer. Han bemærker også, at han vil tilbageholde en del af betalingen, indtil leverandøren beviser, at alle leverancerne fungerer sammen.
Brug et sprog, som alle kan forstå.
Den it-afdeling og dens leverandører er ikke de eneste, der bruger SOW’en, siger Blakeslee. Så du skal ikke skrive det, som om det kun er it-folk, der skal se det. “Den skal være forståelig for slutbrugere, tjenesteudbydere, ledelsen og en dommer”, siger hun.
Vær specifik.
Og selv om mange parter skal forstå arbejdsbeskrivelsen, skal du være præcis i beskrivelsen af projektets omfang og krav, siger Blakeslee. Hun har set dokumenter, der opstiller vage mål som f.eks. “vil arbejde efter bedste evne”. Hun sammenligner det med en husejer, der hyrer en maler med instruktioner om at “gøre sit bedste”.
“Hvis maleren gør det, men maler dit hus lilla i stedet for hvidt, så har du ikke noget krav mod ham”, siger hun.
Scafidi har taget sådanne råd til sig. I stedet for at sige, at en opgave vil tage “et rimeligt tidsrum”, skriver Scafidi: “Den angivne opgave vil ikke tage mere end fire timer”.
“Advokaterne har det godt, når vi har en klar og utvetydig definition på den slags ting”, siger han.
HUSK postproduktionens behov.
Guerrero anbefaler at medtage postproduktionsbehov i SOW’en. Skriv ud, hvilke test og hvilken support du har brug for fra leverandøren, siger hun. Og hvis du planlægger at have interne folk til at supportere systemet efter installationen, bør SOW’en indeholde oplysninger om, hvorvidt leverandøren vil uddanne dit personale. Et sådant sprog, siger hun, garanterer, at leverandøren ikke “bare leverer systemet og går sin vej”.
Pratt er medvirkende forfatter hos Computerworld i Waltham, Mass. Kontakt hende på [email protected].