Vi är alla omgivna av krav och förväntningar. Både på oss själva och på andra. I min roll som chef och ansvarig för IT-området ställer jag en hel del krav på såväl leverantörer och medarbetare som på projektleveranser och IT-beställare.  
Fokus för det här inlägget är förväntningar och krav inom IT-området. I bästa fall är kraven klara, tydliga och rätt prioriterade. I värsta fall blir kravhanteringen till en enda viskningslek eller som en vandringssägen.

Här kommer tre IT-relaterade vandringssägner från nutid. Är de sanna eller falska? Svaret finner du längst ned i detta inlägg:
1. Ipod fungerar som åskledare. Läkare i The New England Journal of Medicine har studerat skadorna hos två män som blivit träffade av blixten samtidigt som de lyssnat på sina Ipods. Skadorna bestod av skadade trumhinnor, förlorad hörsel och brännskador

2. Microsofts trådlösa och portabla toalett. Microsofts håller på och utvecklar den nya portabla toalett iLoo med trådlöst tangentbord, plasmaskärm och extern Hotmail-station för de som står i kö utanför toaletten.

3. Saddam Hussein köper 4000 Playstation 2 för att utveckla massförstörelsevapen. Den 19 december 2000 pumpade nyhetssajten Worldnetdaily.com upp nyheten. Anonyma millitära källor uppgav att datakraften i PS2:an skulle kunna användas till att bygga en enorm superdator. Bara genom att koppla ihop några få PS2:or skulle Irak enligt experterna kunna bygga system för en obemannad raket eller liknande.

Finns det nöjda IT-användare och beställare?
När är en beställare eller användare nöjd med en IT-leverans? Är det när kraven verkligen är uppfyllda eller när användaren upplever att kraven är uppfyllda? Eller är det när den som skriker högst får igenom sina krav? Att ha en väl fungerande kravprocess är lika med att involvera de olika kompetenserna (kravställare) som ska delta i processen för en effektiv kravhantering.  Kravprocessen ska, som jag ser det, omfatta aktiviteter och de kompetenser som vet vad som förväntas och som kan prioritera mellan vad som är måsten och vad som är trevligt att ha. Till sin hjälp ska det finnas beskrivningar (gärna i form av GUI-bilder), mallar, checklistor m.m. Och, ja, det finns nöjda beställare och användare. I de lyckade exempel jag tänker på handlar det om utveckling av funktionalitet som varit ganska liten men som gett stor effekt för användaren och som dessutom levererats förhållandevis snabbt. Förväntningar stiger ofta i samband med att det blir längre leveranstider.

Varför är det så viktigt med en bra kravhantering?
Framförallt för att det kostar så oändligt mycket tid och kraft med missnöjda användare och kunder och det kostar tid, kraft och pengar att rätta fel i efterhand i ställe för att göra rätt från början. Felaktiga krav är enligt flera undersökningar en av de stora felkällorna vid systemutvecklingsprojekt. Anledningarna är många, t.ex. utveckling av funktioner som inte används (felaktig ambitionsnivå) och för stort fokus på omfattande kravdokument som tas fram för tidigt. Detta är ett mycket kostsamt arbete och när lösningen senare levereras så motsvarar den ofta inte förväntningarna.
Utan bra krav blir det inget bra IT-stöd. Vad som är bra krav kan diskuteras. Som jag ser det gäller det att formulera kraven rätt, och det gäller att formulera rätt krav. För att undvika viskingsleken och att det blir en vandringssägen av kravarbetet ska det finnas en transparens genom hela arbetet. Från analysfas till leverans och från kravanalytiker till styrgrupp.

Några kritiska framgångsfaktorer som jag skulle vilja lyfta fram för att lyckas med kravarbetet är följande.
Verksamhetsanalys – Det är viktigt att formulera kraven rätt men det är ännu viktigare är att formulera rätt krav. För att veta att det är just ”rätt krav” krävs en bra problembeskrivning eller målbild för utveckling, där behovet och sammanhanget framgår.

Prioritera – Kraven är ofta många och omfattande. Utöver att formulera rätt krav är det också viktigt att välja de krav som ger mest nytta. Vad ska kraven uppnå för funktioner? Olika studier visar att 80 % av värdet i de flesta system levereras av 20 % av funktionerna. Och, upp till 2/3 av funktionerna används sällan eller aldrig. Och vem är med och prioriterar kraven? Är det den som hörs mest eller den som vet mest om hur systemet ska användas i praktiken?  

Kravens utformning – Placera inte kravet i ett specifikt system för tidigt och arbeta iterativt. Detaljera tillräckligt det vill säga varken mer eller mindre än nödvändigt och använd gärna grafiska bilder för att exemplifiera kraven. Att krav förändras efter vägen i ett projekt är en naturlig del av utvecklingen och det är därför viktigt att inblandade kravställare är involverade hela tiden och tar ansvar för de krav som slutgiltigt ska gälla. Ingen blir nöjd av att hålla fast vid en kravbild som efter hand visar sig vara felaktig.  
Eller enkelt beskrivet, det handlar om hantering av förväntningar.

Och svaren på de tre IT-relaterade vandringssägnerna, hur var det med dem? Sanna eller falska? Här är svaren:

1. I juli förra året berättade en rad nyhetssajter att Ipods lockade till sig blixtar vid åskväder Rubrikerna var falska och syftade på upptäckter i The New England Journal of Medicine där läkare studerat skadorna hos två män som blivit träffade av blixten samtidigt som de lyssnat på sina Ipods. Skadorna – skadade trumhinnor, förlorad hörsel och brännskador – uppstod visserligen på grund av Ipoden.
2. I maj 2003 exploderade nyheten om att Microsofts nya portabla toalett iLoo var under utveckling. Självklart handlade det om ett skämt, men både AP och Wall Street Journal körde nyheten. PR-tricket var signerat Microsofts brittiska kontor.
3. Så här i efterhand kan vi ju konstatera att Irak inte hade några massförstörelsevapen – kanske använde de sina PS2:or till att spela spel?

Nästa gång blir det fokus på test och testområdet. Hur mycket ska man testa ett IT-system egentligen, varför minskar alltid tiden till test. Och hur skulle världen se ut om alla små barn slutade testa sig fram.