Werkomschrijving. Hoe eenvoudig het ook klinkt, het is geen gemakkelijke taak om er een goed te schrijven. Maar niets is fundamenteler voor het succes van een project. Als de werkomschrijving te vaag, te breed of te algemeen is, kan er ruimte ontstaan voor verschillende interpretaties, wat op den duur tot problemen kan leiden. Dat is waar voor een intern project, en het is dubbel waar wanneer er verkopers bij betrokken zijn.
“Het niet goed uitvoeren van een werkomschrijving is vaak de reden dat partijen in een geschil belanden”, zegt David M. Greenberg, een advocaat in de technologie, media en telecommunicatie praktijkgroep bij Greenberg Traurig LLP ’s New York kantoor.
Om uw project de eerste keer goed te krijgen, volg deze richtlijnen voor het schrijven van een effectieve verklaring van werk, of SOW, zoals het liefkozend wordt genoemd.
Begrijp wat een SOW is.
Een SOW definieert de omvang van het vereiste werk en de tijd waarbinnen het moet worden uitgevoerd. Het is “de hoeksteen van een overeenkomst”, zegt Nick Scafidi, IT-inkoopmanager bij energieleverancier National Grid USA in Westboro, Mass. “Het bepaalt de verwachtingen, de te leveren prestaties, wat aanvaardbaar is, de prijs, het prijsschema. Zonder dat is het alsof je tegen een aannemer zegt: ‘Bouw een huis voor me’, en hem vertelt wanneer, wat voor soort of hoe groot.”
Weten wat je moet opnemen.
Bruce Russell, die tal van SOW’s heeft ondertekend toen hij chief operating officer was bij een softwareontwikkelingsbedrijf, zegt dat een goede SOW deze dingen bevat:
- De belangrijkste deliverables en wanneer ze worden verwacht.
- De taken die de deliverables ondersteunen, evenals welke kant – het inhurende bedrijf of de dienstverlener – deze taken zal uitvoeren.
- Het governance-proces van het project, samen met hoe vaak bestuurlijke comités zullen vergaderen.
- Welke middelen zijn nodig voor het project, welke faciliteiten zullen worden gebruikt en wiens apparatuur nodig zal zijn, evenals testvereisten.
- Wie zal welke kosten betalen en wanneer.
“De werkverklaring brengt alle elementen bij elkaar aan het begin,” zegt Russell, nu een executive professor aan Northeastern University’s College of Business in Boston. “En hoe preciezer je het kunt maken, hoe meer kwantitatief, hoe beter.”
Definieer succes.
Een werkverklaring moet voor alle partijen verduidelijken wat succes of mislukking is, zegt Melise R. Blakeslee, een advocaat in de groep transacties op het gebied van intellectueel eigendom, media en technologie bij McDermott Will & Emery LLP in Washington.
“Je moet adequaat beschrijven wat het werk is en de criteria voor hoe je het beiden eens bent” dat iets met succes is voltooid, zegt Ruth Anne Guerrero, normmanager bij Project Management Institute Inc. in Newtown Square, Pa., en een voormalig IT-projectmanager.
Bijvoorbeeld, zegt ze, als u verwacht dat uw leverancier gebruikerseisen ontwikkelt, moet uw SOW vermelden dat de leverancier specifieke gebruikersgroepen moet interviewen en hen de eisen moet laten goedkeuren voordat het werk als voltooid wordt beschouwd. Dat definieert succes beter dan simpelweg zeggen: “Verkoper zal gebruikerseisen produceren.”
De definitie van succes hangt af van het project, zegt Guerrero. IT-projectleiders moeten specificeren of een succesvolle implementatie wordt gedefinieerd door snelheid, responstijd, gebruiksgemak of alle drie en deze vervolgens kwantificeren in de SOW.
Vergeet een tijdschema niet.
Succesvolle implementaties kunnen echter niet worden gedefinieerd door de snelheid of het reactievermogen van het systeem alleen. Immers, wat heb je aan een geweldige applicatie als het tien jaar duurt om die te bouwen? Daarom moet een SOW tijdelementen bevatten. Guerrero raadt aan een taal te gebruiken die enige flexibiliteit toelaat in plaats van een vaste datum op de kalender. Een SOW zou bijvoorbeeld moeten specificeren dat de eindgebruiker-eisen twee maanden na de ondertekening van het contract moeten worden ingediend – een formulering die het project nog steeds vooruithelpt en tegelijkertijd mogelijke problemen zoals een vertraging in de ondertekening van het contract opvangt.
Een SOW moet ook specifieke tijdstippen voor formele beoordelingen aanwijzen, zodat alle betrokkenen kunnen bevestigen dat ze op schema liggen, zegt Matt Liberatore, een professor in de afdeling besluitvormings- en informatietechnologieën en de John F. Connelly-leerstoel in management aan het College of Commerce and Finance van de Villanova University in Villanova, Pa.
Betaling koppelen aan mijlpalen.
Een ander belangrijk onderdeel om het werk op schema te houden is het vaststellen van specifieke mijlpalen in de SOW en het koppelen van betaling aan succesvolle voltooiing, zegt Blakeslee.
Wanneer Scafidi een SOW opstelt, specificeert hij dat betalingen aan verkopers worden gedaan na acceptatie van belangrijke deliverables. Hij merkt ook op dat hij een deel van het loon zal inhouden totdat de verkoper bewijst dat alle deliverables samenwerken.
Gebruik taal die iedereen kan begrijpen.
De IT-afdeling en haar leveranciers zijn niet de enigen die de SOW gebruiken, zegt Blakeslee. Schrijf het dus niet alsof alleen IT’ers het zullen zien. “Het moet begrijpelijk zijn voor eindgebruikers, dienstverleners, management en voor een rechter,” zegt ze.
Ben specifiek.
Hoewel tal van partijen de werkomschrijving moeten begrijpen, moet je nauwkeurig zijn in het beschrijven van de reikwijdte van het project en de vereisten, zegt Blakeslee. Ze heeft documenten gezien die vage doelen stellen, zoals “zal werken naar hun beste vermogen”. Ze vergelijkt dat met een huiseigenaar die een schilder inhuurt met instructies om “de best mogelijke inspanning te gebruiken.”
“Als de schilder dat doet, maar je huis paars schildert in plaats van wit, dan zou je geen claim tegen hem hebben,” zegt ze.
Scafidi heeft dit advies ter harte genomen. In plaats van te zeggen dat een taak “een redelijke hoeveelheid tijd” in beslag zal nemen, schrijft Scafidi: “De gespecificeerde taak zal niet meer dan vier uur in beslag nemen.”
“Advocaten voelen zich goed als we een duidelijke, ondubbelzinnige definitie hebben over dat soort dingen,” zegt hij.
Houd rekening met postproductiebehoeften.
Guerrero raadt aan om postproductie-eisen op te nemen in de SOW. Geef aan welke tests en ondersteuning je van de leverancier nodig hebt, zegt ze. En als u van plan bent interne mensen het systeem te laten ondersteunen na de installatie, moet het SOW aangeven of de leverancier uw personeel zal opleiden. Dergelijke taal, zegt ze, garandeert dat de verkoper niet “gewoon het systeem leveren en weglopen.”
Pratt is schrijfster bij Computerworld in Waltham, Massachusetts. Neem contact met haar op via [email protected].