Löpande konsultuppdrag eller kostnad för framtagning av kravspecifikation?


En fråga som ibland kommer upp kring olika typer av konsultuppdrag, särskilt i den inledningsfas i projektet när man inte har en klar bild över exakt vad projektet ska omfatta i första etappen, i andra etappen och i framtiden, är:

Ska uppdraget utföras löpande och påbörjas direkt eller ska projektet istället inledas med en förstudie där man istället för att omedelbart börja med själva "jobbet" lägger tid och pengar på att skapa en kravdokumentation för projektet som därefter styr och begränsar arbetet i projektet.

 

Svaret är såklart att det är upp till beställaren att avgöra men vår professionella erfarenhet med många år och otaliga olika typer av IT-projekt, små som stora, är att det i regel aldrig är kostnadseffektivt att utföra mindre konsultuppdrag mot en kravspecifikation!

Även om det kan kännas "tryggt" att ha en prelliminär uppskattning om ungefärlig tidsåtgång för vissa delmoment i uppdraget och även om det såklart är nyttigt att gå igenom projektets delmoment i detalj både mentalt och att få ned det i ett dokument så är detta en form av falsk trygghet, det (att upprätta en kravdokumentation) kommer så gott som uteslutande att innebära:

  • en högre kostnad
  • längre utvecklingstid
  • minskad flexibilitet

 

Dessutom tar det såklart tid i ert it-projekt om arbetet inleds med att skapa en kravspecifikation.

 

Visste du att över 95% av alla mindre IT-projekt utförs löpande
och att även de riktigt stora organisationerna mer och mer
styrt om till att arbeta med små, avgränsade
"releaser" de senaste åren?

 

 

 - Kravspec? kanske någon på ert företag säger, det är ju ingen matcha att slänga ihop en sådan i en texteditor på några minuter!

Nja, riktigt så enkelt är det inte.

Först och främst: ett dokument som tar några minuter att slänga ihop i en texteditor är inte en kravspec, inte ens en önskelista utan lite anteckningar som visserligen säkerligen är en bra gund att arbeta vidare utifrån men det är omöjligt att använda ett sådant dokument som en kravspec - den innehåller inte ens allt som en kravspecifikation ska omfatta till att börja med!

 

Vad är en kravspecifikation?

 

Om en kravspecifikation, eller den samlade kravdokumentationen som det ofta benämns i IT-projekt, ska vara giltig och kunna tillföra någonting så är det inte alls en enkel match att "slänga ihop det".

Det är inte ett dokument utan en samling av flera olika dokument.

Det är inte någonting som beställaren själv kan ta fram utan någonting som i huvudsak leverantören tar fram åt och tillsammans med beställaren. Detta arbete tar naturligtvis lite tid och kostar pengar.

Eftersom arbetet med att upprätta en godkänd kravspecifikation måste utföras i början av projektet så innebär det att själva "utvecklingsarbetet" inte kan påbörjas direkt.

Av denna anledning är det en mycket dålig arbetsmodell i projekt där en "release" måste göras snabbt, tex en första version av en produkt eller en websida måste levereras till användare direkt.

Slutligen måste alla parter vara överens om kravspecifikationen, först när beställaren och leverantören godkänt kravspecifikationen kan den läggas till den övriga dokumentationen i projektet och påverka styrningen i projektet. Nu läggs hela kravdokumentationen upp på utvecklingsservern och nu kan arbetet med att tidsuppskatta de olika delmomenten påbörjas. Vissa delmoment kanske inte kan tiduppskattas och viss tiduppskattning kan komma att behöva revideras men i regel ska stora delar av projektets delmoment kunna tidsuppskattas med en felmarginal om ca 10%. I annat fall är troligtvis inte arbetet med att upprätta kravdokumentationen korrekt utfört och man kanske behöver bolla tillbaks projektet till detta steg igen innan tidsuppskattningen kan slutföras.

Återigen, är detta ett lite mindre IT-projekt så förstår nog de flesta att redan i detta stadie i projektet, när beställaren betalat för att ta fram en kravspecifikation, vilket är bra och behövdes så att man vet "vad" man ska göra, och när beställaren dessutom betalat för att leverantören ska tidsuppskatta dokumentationen och tänka igenom själva "hur" arbetet kan utföras och i viss mån även "när" delmoment kan utföras osv så har prislappen redan blivit ganska hög.

 

"Pratar vi tex om ett vanligt webutvecklingsprojekt för att tex ta

fram en ny webplats så skulle kostnaderna redan säkerligen

ha överstigit totalkostnaden för att slutföra arbetet mot

löpande räkning redan innan arbetet med att ta fram

webplatsen ens har påbörjats i projektet

med en kravspecifikation."

 

Varför tar det så lång tid att upprätta en kravspecifikation?

Inte ens för en relativt liten webplats är det enkelt att snabbt skapa en kravspec som fungerar och går att arbeta utifrån. Varför? Jo, för att kravmaterialet ska kunna användas så måste det omfatta ett flertal olika arbetsmoment för att ta fram olika typer av dokument som alla är viktiga och belyser olika aspekter av arbetsmoment.

Utan dessa dokument och framför allt utan alllt det "tänkande" och diskuterande som leder fram till den slutliga versionen av dessa dokument så är det omöjligt att kunna i detalj specificera vad som ska utföras, hur det ska utföras och uppskatta hur lång tid det kan tänkas ta.

Just det sistnämnda var väl hela poängen med att ta fram en kravspecifikation i första ledet?

Egentligen borde fokus ligga på "vad" och "hur", det är i regel detta som påverkar kostnader.

 

Inte ens med alla de praktiska verktyg som vi och andra experter inom webutveckling använder så går det att kraftigt reducera tiden det tar att upprätta kravmaterialet. Det måste gås igenom tillsammans med beställaren och helst om möjligt involvera personal från beställaren. Det är inte ovanligt att man har en eller flera personer som arbetar enbart med att hantera dokumentationen i projekt som styrs från kravspecikation. Särskilt en bit in i projektet är det viktigt, när olika versioner och revideringar av tex "användningsfallen" (en delmängd av dokumentationen som ingår i kravmaterialet) behöver göras!

 

 

I kravdokumentationen måste åtminstone dessa dokument upprättas:

 - Övergripande punktlista som beskriver funktioner och refererar till detaljerade beskrivningar i de övriga dokumenten. Detta brukar ofta lite slarvigt benämnas kravspec. Kravspecen är dock egentligen hela kravdokumentationen och ingen del av dokumentationen klarar sig för sig själv utan allt hänger ihop med varandra.

I regel måste man först utföra en förstudie där bla behovsanalys utförs för att därefter kunna påbörja arbetet med att upprätta själva kravdokumentationen.

 

 - Användningsfall. Ett stort antal detaljerade specifikationer kring handhavande, dessa kan heta lite olika saker och fungera på lite olika sätt i olika typer av projekt men grundprincipen är att allt som exempelvis alla användare, administratörer, opriviligerade användare osv kan göra i systemet, allt som kan gå rätt, allt som kan gå fel ska hanteras och beskrivas. Det kan vara allt från felmeddelanden och hantering av fel i en inloggningssida till vilken färg en särkild knapp ska ha i ett gränsnitt, om knappen ska vara synlig i olika situation osv.

Denna del av kravdokumentationen blir i regel oerhört omfattande eftersom den måste beskriva i detalj exakt vad som ska utföras.

 

Utöver dessa dokument finns även annan dokumentation, både "levande" och mer "statisk" exempelvis: som styrdokument, så kallade "actionlistor" (dvs att-göra-lister med tidsallokering, resursallokering, beskrivning av delmoment och inte minst prioriteringar för alla de olika "små-punkter" som behöver göras.

Hade man valt att istället arbeta mot löpande räkning skulle det egentligen kanske räckt gott och väl med en actionlista, som revideras och byggs på efter hand, tex i form av protokoll vid telefonmöten där tilläggsbeställningar görs osv. En betydligt mer överskådlig arbetsmodell, en betydligt mer effektiv arbetsmetod särskilt vid mindre och medelstora projekt.

 

 

Grundproblemen med ett konsultuppdrag som ska utföras mot en kravdokumentation är således att

  • eftersom kravdokumentationen ska kunna fungera som ett styrdokument för hur hela projektet ska utföras så kommer den antingen att vara "fryst", det normala vilket i sig innebär att man innan arbetet påbörjas bestämmer exakt vad som ska utföras och sedan ej reviderar detta förrän arbetet är utfört. Därefter analyserar man situationen och lägger till tilläggsbeställningar. Och det kommer att bli mycket tillägg - det är detta som är den allra största fördelen med att jobba mot löpande räkning i små men även medelstora projekt - det är helt enkelt så mycket som kommer att förändras under resans gång så att det är omöjligt för, den kanske dessutom oerfarna, beställaren att i förväg avgränsa på rätt sätt.
  • Saker och ting kommer att förändras och man måste kunna arbeta på ett flexibelt sätt. Inte bara sparar man pengar på att inte behöva utföra det omfattande arbetet med upprätta kravdokumentationen (som kommer vara inaktuell redan efter ett par veckor in i projektet) utan dessutom kan man direkt styra om pågående arbete och spara såväl tid som pengar. Behov av nya funktioner under arbetets gång läggs till direkt och utvecklingstid sparas.

Vår rekommendation är att tänka till både en och två gånger innan man drar igång ett stort konsultuppdrag med kravspecifikation och att man noga överväger om extrakostnaderna som det ofelbart kommer att innebära verkligen är motiverbara. I annat fall bör uppdraget utföras löpande.

 

Varför blir kostnaden lägre om man arbetar löpande?

De största anledningarna att kostnaderna blir oerhört mycket lägre vid löpande arbete är att man dels inte behöver arbeta lika mycket med dokumentation i projektet men också att man snabbare kan byta inriktning i vissa delmoment.

Framför allt blir tidsvinsterna dock att man blir så mycket snabbare på att "svänga om" i projektet, när tillägg av nya funktioner tillkommer i projektet så kan dessa i regel utföras direkt, kanske till och med samma dag! Kostnader sparas då eftersom man inte behöver fortsätta på det "gamla" spåret i ett löpande projekt. I ett projekt med kravspecifikation kanske tvärt om allt först måste slutföras innan man kan gå tillbaks och upptäcka att 90% av allt arbete i en fas av projektet egentligen var helt i onödan eftersom omvärlden förändrats under arbetets gång.

En uppenbar besparing är såklart också att man slipper upprätta en kravspecifikation. Bara detta kan lätt ta lika många timmar som att slutföra hela projektet mot löpande räkning!

 

Varför är det bra med täta testperioder?

I regel brukar man redan vid enklare tester upptäcka tankefel i den urprungliga modellen och yttre omständigheter påverkar hur arbetet måste utföras.

Detta händer i alla projekt, även de som vid första anblick framstår mycket avgränsade och enkla.

Särskilt om du inte är erfaren beställare av IT-projekt så bör du beakta denna risk, du kan helt enkelt inte bedömma alla omständigheter, ta god höjd såväl i tidplanering som budget för alla eventuella ändringar ni vill göra under resans gång.

 

MVP FTW

Det är viktigt att arbeta med täta, små "mini releaser", helst MVP:er (mer om detta nedan).

Vi avgränsar i regel detta med "testperioder". Under en testperiod är arbetet tillfälligt "fryst" och allt som är gjort i det delmomentet eller fasen av projektet testas. Här uppkommer såväl tillägg av ny funktionalitet som tidigare ej var känd (något som helt hade missats vid arbete mot kravspec!) och här kan eventuella fel rättas till. Testningen delas in i TR och CR, detta beskrivs i regel i er offert eller av er kontaktperson hos oss på compartment inledningsvis i projektet och inför varje testperiod.

Att vara "dumsnål" är i regel det värsta man kan göra här, utnyttja testperioderna - att "spara" pengar genom att skjuta på testningen är mycket olyckligt, återigen, det är såklart ni som beställare som ska avgöra vad som är viktigt att lägga pengar på i ert IT-projekt men utan ordentlig "avtestning" kan ni inte veta att arbetet i en fas är ordentligt utfört och ni missar ett viktigt tillfälle att lägga till ny funktionalitet som på ett smidigt sätt kan läggas in i projektet som en ny fas.

Att tro att det är enklare att jobba med få olika faser är fel, det är faktiskt betydligt enklare att jobba med många olika, små och tydligt avgränsade etapper. Den mänskliga hjärnan föredrar i regel att hantera olika grupper av information som inte flyter samman. Utnyttja detta till fullo med olika faser, kalla det fas 1.1, 1.2, 1.3 osv om ni tycker det är mindre förändringar men dra fördel av tydliga avgränsningar här.

 

MVP, som även nämndes ovan, och som vi i regel alltid försöker styra arbetet mot inledningsvis när det handlar om webutveckling som webdesignuppdrag är ett oerhört smart verktyg.

En MVP eller Minimum Viable Product är en strategi eller arbetsmodell som visat sig framgångsrik i många olika sammanhang och som i kort innebär att man delar in arbetet i faser och låter alla dessa faser ha några olika egenskaper. När varje MVP är klar ska en testrelease för den fasen utföras och om så önskas så gör man en release av den fasen/MVP:n.

 

Detta innebär i regel att man tex släpper in slutanvändare i ett system som inte är färdigt utan under utveckling. Man släpper täta releaer och uppdateringar för användarna regelbundet, tar in synpunkter och önskemål från användarna och i det stora hela blir produkten bättre, kunderna och användarna mer nöjda, kostnaderna för utveckling blir lägre och utvecklingstiden kortare. Man slipper framför allt sitta fast med en "plastisk" produkt som är trög att vidareutveckla och man har såväl tekniska som administrativa verktyg och rutiner för att snabbt kunna "svänga om" - något som är oerhört viktigt på webben inte minst. Ofta sker förändringar snabbt och de som "hänger med i svängarna" överlever. Se tex introduktionen av smartphones som ett exempel på förändringar som kan ske över en natt.

 

Bra exempel på hur MVP:er kan delas in är:

- Produkt (delmoment / fas) ska innehålla såväl basfunktioner som ofta är förväntade av användaren, viktiga funktioner för vidareutveckling som kan innehålla fragment som ska byggas på i ett senare skede (exempelvis kanske det finns en kundvagn i webshoppen men i en första version kan man ej betala med kreditkort utan denna funktion läggs till i ett senare skede).

 - Några extra funktioner som är "balla" och får användarna att höja på ögonbrynen lite extra.

 

Grundtanken som ska genomsyra arbetet med MVP:er är: "Release early, release often" (RERO).

Självfallet kan det innebära att man, om man inte är noggrann med testperioderna, riskerar att släppa ut buggar i slutprodukten, något som man antingen väljer att rätta till i efterhand (Microsoft är ett typexempel på detta, se tex hur Windows släpps och uppdateras ständigt) tex i samband med att man introducerar ny funktionalitet eller så gör man mer omfattande tester. Exakt den balans som passar bäst i ett projekt kan variera under olika faser i projektet. Inledningsvis kan det vara en god idé att fokusera på att snabbt få ut "någonting" och långsamt övergå till en mer försiktig arbetsmetod senare i projektet.

 

Tanken med tex en webplats är ju att den aldrig är "färdig" (vad innebär det?) utan ert IT-projekt kommer troligen löpa på under lång tid, i vissa fall som med webplatser så löper det på under hela företagets livstid, därför är det viktigt att kunna styra om inriktningen på arbetet när det mer och mer går in i en förvaltningsfas under en period. Det är dock viktigt att inte fastna där utan att hela tiden vara redo att "blåsa liv" i projektet som nästan gått på sparlåga ett par månader och påbörja vidareutveckling med full kraft. Hela tiden ska ni ifrågasätta varför projektet inte är mer aktivt. Ska en mobilapp läggas till, ska den responsiva front-end-designen uppgraderas osv osv. Nya funktioner ska ständigt läggas till, ni ska förekomma era användares önskningar, ni ska ta in deras önskemål - här gäller det att klara av att förvalta IT-projektet, något som i regel skiljer sig markant från att vara en god beställare eller IT-inköpare. Ta hjälp och anlita experter med spetskompetens som vi på compartment som kan komma med förslag och vara ert bollplank. Saknar er personal den tekniska kompetensen? Ingen fara, det viktiga är att veta vad man vill göra, själva "hur":et löser vi åt er och allt går att göra rent tekniskt egentligen. Konsten ligger i att göra det på det vis som passar ert projekt bäst.

 

Relaterad läsning:

 Konsulttjänster

 Webdesign

 

Taggar: design, konsult, projekt, web, webb, webbdesign, webdesign
Senast uppdaterad:
2013-10-24 12:01
Av: :
compartment AB
Ny version:
1.0
Resultat av röstning:0 (0 röster)

Du kan inte kommentera den här frågan

Chuck Norris has counted to infinity. Twice.

bannerbyte.eu