<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=463105&amp;fmt=gif">
2019-01-23 | IT

3 steg till bättre IT-kravställning vid upphandling

Lästid: 10 minuter

Krav är inte bara till för att de som levererar projektet ska veta vad de ska leverera, men de är i lika stor grad till för att du som beställare ska veta vad du vill ha. Om du inte vet vilka krav du ska ställa på projektet, så kan du inte heller veta när du är nöjd. Att ställa krav kan vara svårt och det kan kännas jobbigt att formulera sina behov på ett strukturerat sätt. 

Det finns få saker som är så viktiga som att ställa rätt krav från början. Jag som systemutvecklare befinner mig oftast i situationer där mitt arbete är direkt kopplat till vad en kund vill ha levererat. Mitt jobb går ut på att uppfylla krav, så jag måste kunna lita på att kraven har ett värde, att de är ställda med en tanke bakom. För det jag vill är inte att bara bocka av krav från en lista, jag vill fylla den kundens behov. Men ofta sker den enda kommunikationen med kunden via en kravlista, och jag har många gånger fått ställa frågan ”Men vad vill de ha egentligen, vad är deras behov?”

Och det är inte bara användarna av ett system som ska bli nöjda. Det finns oftast en IT-avdelning som också har rätt att säga sitt och som ofta har tydliga krav och direktiv som man måste förhålla sig till.

Så varför är det så svårt att ställa krav? 

I min mening finns det tre utmaningar med kravställning.

  • Ställ rätt krav
  • Begränsa kraven
  • Ställ säkra krav 

1. Ställ rätt krav

Att ställa rätt krav handlar om flera saker. 

Skall man ställa krav alls?

I en traditionell utvecklingsprocess är kraven det första man tar fram och ett av de viktigaste verktygen man har att jobba med. Men om man jobbar agilt blir kraven mindre betydelsefulla, eftersom man hela tiden utvärderar och itererar fram lösningar. Här måste man bestämma om det alls behöver tas fram krav, eller om det räcker med att identifiera behoven. Det kan tyckas vara liten skillnad på de två, men ett krav är något som skall kunna mätas och bockas av. Ett behov är mer luddigt och svårare att mäta, men är i grunden det som kunden vill ha. Att skriva krav är ett sätt att beskriva ett behov, men det kan lätt uppfattas som ett kontrakt som måste uppfyllas. Det gör det svårt att fokusera på själva behovet utan fokus kommer att ligga på att uppfylla kraven. Om de då inte är formulerade exakt rätt, så är risken stor att man skjuter över målet.

Vem ställer kraven?

Det handlar dels om att täcka slutanvändarnas behov. Är de med och kravställer? Vanligt är att man har med representanter från slutanvändarna i en kravdiskussion, men representerar de hela organisationen? Ibland kan det vara lätt att missa en avdelning som berörs eller en roll som inte är så tydlig. Det är viktigt att alla som ska använda det nya systemet får säga sitt, men det är också viktigt att få med sig andra som kan bli påverkade. Om en avdelning inför ett nytt IT-stöd, kan det få konsekvenser för en annan avdelning? Ofta finns det roller i en avdelning som kan tyckas vara representerade, men skulle de hålla med? Om någon inte får säga sin mening när man ställer kraven, så kommer deras behov med största säkerhet inte uppfyllas eller i alla fall inte på det sättet som de hade föredragit.

På vilken nivå ställs kraven?

Man måste försöka ställa kraven på en rimlig nivå. Om du fokuserar på detaljer så blir det lätt att missa helheten. Skriver du minutiösa krav, så kommer du drunkna i kravlistor och leverantören kommer att behöva fokusera för mycket i detaljerna och får svårt att justera efterhand. Det kommer bli oändliga kravmöten där krav ska gås igenom och granskas, godkännas och revideras. Vill man ändra i kraven (och detta kommer både beställaren och leverantören vilja göra) så blir det mycket administrativt merarbete.
Men om man bara ser övergripande på kraven så kommer de små sakerna att falla mellan stolarna. Beställaren kommer förvänta sig en sak och leverantören kommer att leverera en annan, då de uppfattat behoven annorlunda. Här är det väldigt viktigt att båda parterna har ett tätt samarbete med kontinuerliga avstämningar och rapporteringar. 

Hur utvärderas kraven?

Slutligen handlar rätt krav om att kunna utvärdera resultatet. Kan du utifrån kraven säga att en leverans är lyckad eller inte? Har leverantören fullgjort sitt uppdrag så fort kraven är mötta eller först när beställaren är nöjd? Och hur vet beställaren att den är nöjd?
Det är viktigt att ställa mätbara krav, som man lätt kan testa av, men det handlar ju som sagt om att fylla ett behov. Man kan täcka användarnas behov på många olika sätt och det viktigaste är att de är nöjda, inte att kraven är avbockade i en lista.

 

2. Begränsa kraven

Att begränsa kraven innebär att man sätter upp en lägsta nivå för vad leveransen ska innehålla för att uppfylla användarnas behov.

Det är svårt att veta från början exakt hur man vill att resultatet ska bli, men det är viktigt att veta vad som är kritisk funktionalitet och vad som är "användargodis". Om man skriver en kravlista där man har med alla funktioner man kan komma på, utan att prioritera och dela in i iterationer, så kommer projektet att dra ut på tiden, det kommer kosta mer, och du kommer inte att bli nöjd. Om man istället bestämmer en lägsta nivå för leveransen, som innehåller de mest nödvändiga funktionerna, så kan man utvärdera tidigt och kanske inser du att en hel del funktioner var onödiga.

Särskilt när man ersätter ett system med ett annat så är det väldigt vanligt att man mappar funktionalitet ett till ett och har det som lägsta nivå. Detta är särskilt vanligt när invanda användare är med och skriver kraven. ”System 1 kan minsann göra detta, så det måste gå i det nya”
Men om man börjar smått med de viktigaste bitarna, så kanske det andra visar sig onödigt eftersom det då finns utrymme att bygga systemet annorlunda och bättre.

 

3. Ställ säkra krav

Samtidigt som alla användare och roller ska vara representerade i en kravställning så är det väldigt viktigt att den övriga organisationen är med på banan.

En tidigare kollega skriver om De bästa sätten att bemöta Shadow IT och de faror som uppstår när verksamheten beställer system utan att blanda in IT-avdelningar. Här handlar det inte om att fånga användarkrav, utan att fånga krav som ställs på systemnivå. Hur kan man garantera säkerheten? Hur gör man integrationer till interna eller externa system, hur kommer man åt säkrad data? Ska det nya systemet kopplas ihop och samarbeta med andra system? 

Den här typen av krav är väldigt viktiga att få med från början då de påverkar hela projektets omfattning. Det kostar mycket pengar att komma på sent att det inte alls gick att göra en viss typ av lösning eftersom organisationens IT-säkerhetspolicy ser ut på ett visst sätt. 

Det är viktigt att som IT-chef veta vem som ska vara med och ställa krav på nya projekt. Inte bara för att alla ska få lov att säga sitt, men för att ett projekt inte är lyckat förrän alla användare har ett leende på läpparna och är nöjda med resultatet. Men det är inte bara användarna som ska vara glada. IT-avdelningen ska vara glad, du ska vara glad och leverantören ska vara glad. Resan dit kan vara krokig, men att iterera fram en lösning där man från början är något vag i kraven är ofta bättre än att skriva meterlånga listor med krav och köra på i 180, då är det lätt att köra i diket när vägen svänger. Och glöm inte IT-avdelningen. Den finns till av en anledning och den ställer helt andra krav än användarna.

Som vi märker håller IT-chefens uppdrag på att förändras mer och mer. Bland annat kommer denne i framtiden att ännu tydligare stötta verksamheten när det kommer till affärsutveckling. Men hur hanterar man något sådant, och vad bör man förbereda sig på? Läs mer om det i vår nya guide: IT-chefens nya uppdrag.

Ladda ner IT-chefens nya uppdrag här