Anders Myrén

Kravhantering är ett samspel mellan behov och lösning

2018-02-15 Artikelbanken Kravhantering Läst 806 gånger

Finns det paralleller mellan IT-utveckling och våra erfarenheter av badrumsrenovering? Jag har ofta använt mig av analogier med husbyggnation för att beskriva behovet av krav och nu fortsätter jag med mina personliga erfarenheter av en badrumsrenovering.

I denna artikel beskriver jag mina erfarenheter av vilka krav som diskuteras i projektet (och hemma vid köksbordet), vilka krav som inte diskuteras och de krav som i slutändan blir implementerade. Jag har inte svar på alla frågor eftersom svaren ofta ”beror på”.

Renoveringen av badrummet är ett exempel som kommer att följa genom texten som till sist avslutas med en summering:

  1. Att beskriva behov och krav är en ledningsfråga

Att lägga tid och pengar på behov och kravarbete är en förutsättning för att verksamheten skall kunna beskriva sina behov och krav för att slutligen få den lösning organisationen och användarna efterfrågar. En kravstrategi är ett bra första steg. Du som läsare kanske tycker att det är självklart men det är det tyvärr inte alltid i alla organisationer.

Vi föräldrar gjorde en enkel skiss (utan tonåringarna) som vi diskuterade med arbetsledaren på byggföretaget. Det visade sig att vår kunskap om moderna badrum var bristfällig och det blev en del överraskningar.

  1. Politik och motstridiga mål eller KPI:er (Key Performance Indicator) inom organisationen

Det finns andra behov som är lite svårare att definiera och förhålla sig till för en Business Analyst (och andra). Relationen mellan koncern eller centrala staber och dotterbolag, divisioner eller avdelningar kan vara känslig men det är kanske inte projektets uppgift att överbrygga skillnader och rena motsättningar mellan avdelningar. Hur tacklar man politik och revir i ett kravinsamlingsarbete? Listan med exempel på motstridiga behov, krav och mål kan göras lång och det är i slutändan en ledningsfråga att lösa dessa problem.

Tonåringarna hemma var högljudda intressenter men vi som föräldrar fick hålla i budgeten… 

  1. Vad är egentligen de grundläggande behoven?

När ett projekt startas eller är i sin linda kan det vara bra att tidigt ställa några frågor om vilka behov och krav som är med i kravfasen eller inte och varför de är med (eller inte med). Är även de icke-funktionella kraven med? Till exempel legala krav, möjlighet att underhålla lösningen och användbarhet?

Är alla berörda intressenter med och ställer krav? Kundtjänst, Usability och IT-Drift kan ibland involveras väldigt sent. Någon kan till och med hamna utanför, med katastrofala konsekvenser. Skall hela familjen diskutera badrumsrenoveringen och vem anser att det exempelvis behövs toalettrullehållare och tvättkorg i badrummet? Det är egentligen en Stakeholder analysis-aktivitet att leta reda på intressenterna för att förstå vilka behov och krav som diskuteras och varför de är med i projektbakgrunden, projektscopet, projektdirektivet etc. Detta ämne berör jag dock inte vidare här.

I grund och botten handlar det om att förstå varför projektet skall starta. Det kan vara rationella behov och krav till mer lösa idéer, eller vaga och/eller illa underbyggda idéer som bygger på antaganden. I vårt fall var det ett akut renoveringsbehov på grund av anmärkningar i besiktningsprotokollet som var anledningen till att starta projektet.

Projektdirektivet ger förhoppningsvis läsaren (Business Analyst, Arkitekt, Projektledare etc) en bild av vilka grundläggande behov som skall lösas. Samtidigt kan man ställa sig frågan vilka behov som inte är med men som kanske borde finnas med. Vad behöver familjen för funktioner i badrummet? Har tonåringarna något behov av plats för tvättkorg och förstår de behovet av den? Är det kanske viktigare för dem med eluttag till musik, speglar eller 10 stycken USB-uttag i badrummet?

Genom att tidigt fråga beställaren kanske man får väl underbyggda orsaker till varför projektets omfattning ser ofullständig ut. Beställarens position och inflytande i företaget (eller organisationen) samt medlemmarna i styrgruppen kan också ge indikationer till varför vissa behov är med, prioriteras och beskrivs, och varför vissa inte är det.

De användare som skall nyttja resultatet av projektet, bör vara representerade och vara djupt involverade i behovs- och kravfasen. Hur vill familjen, det vill säga både föräldrarna och tonåringarna att badrummet skall se ut, inklusive behovet av tvättkorg?

  1. Varför, varför och slutligen varför?

Samtidigt får inte behoven beskrivas i termer av hur det existerande systemet eller lösningen fungerar eller framförallt inte fungerar. Den aktuella processen (och förändringarna av den) måste styra behoven av systemstöd och behoven bör beskrivas utan systemreferenser. Är det beskrivna behovet en work-around för att det nuvarande systemet inte fungerar och stödjer processen? Ibland kan den nuvarande lösningen vara en organisatorisk work-around för att samarbetet mellan avdelningar inte fungerar. Då är det bättre att lösa den organisatoriska frågan istället för att fortsätta med en permanent work-around i framtiden, även i den nya lösningen.

Så här i efterhand kan vi konstatera att vi inte frågade oss själva och beskrev de grundläggande behoven, utan tog med oss lösningar från det ursprungliga badrummet som visade sig inte vara så bra i det nya badrummet.

  1. Förankra behov och krav i organisationens mål och strategier

En bra indikator på om behovet är relevant och förankrat, är om det går att spåra det till ett eller flera affärsmål. Systembolagets något motstridiga verksamhetsidé, att informera om alkoholens risker och samtidigt sälja alkohol, kan bli en utmaning för exempelvis utveckling av e-handel.

Förändrade KPI:er och andra nyckeltal, bör definieras i behovsanalysen för att projektleveransen skall kunna följas upp. Varför behöver badrummet renoveras, varför skall toaletthållaren bytas ut och var skall den placeras? Kanske relevant på familjerådet men… Spårbarhet till affärsidé och mål kan i och för sig vara ett kapitel för sig men behovet bör kunna spåras till något mål för att visa att behovet verkligen bidrar till projektmålen.

Vad finns det för dokumentationsbehov? Finns det en domänägare eller systemägare? Har han eller hon gett sina synpunkter? Reglerna för fuktspärrar i badrummet kräver dokumentation, vilket vi inte visste.

En IT-strategi bör åtminstone synas indirekt i projektdirektiv och behov. Att rensa upp i systemdjungeln för att minska kostnader, kan vara ett behov. Teknologier, metoder, produktlivscykler, leverantörsrelationer etc utvecklas och behovet kan vara en mer leverantörs- eller teknologioberoende lösning. Ta dessa diskussioner tidigt. De kommer i alla fall att dyka upp, förr eller senare.

Strävar företaget eller organisationen efter att dela på IT-resurser mellan olika funktioner, processer och regioner eller länder? Då skall projektet ta hänsyn till de kraven. Annars kan det bli en sen och tråkig överraskning att man inte är överens när projektet skall leverera.

Behovet av att samla in data till organisationens Data Warehouse, kan ställa krav på ett nytt affärssystem. Frågor om insamling av data kan ge nya behov som kanske inte fanns med från början i projektet.

  1. Spårbarhet

Finns det behov som beskriver affärsutvecklingens önskemål? Nya marknader, affärsmodeller, paketering av produkter och tjänster, språk, valutor, prismodeller, tidzoner, måttenheter, graden av självbetjäning, produkter och tjänster etc. Det är viktigt att kunna spåra behoven till ursprunglig kravställare, för att kunna få mer information i ett senare skede.

Är familjen överens om hur badrummet skall inredas? Nu skall jag inte överdriva tonåringarnas intresse för badrummet men behovet behöver förankras och spåras. Det kanske räcker med ett handfat? 

  1. Icke-funktionella krav

Myndigheter, betalningsinfrastruktur, branschorganisationer, integrationspartners etc kan ställa krav på företaget och organisationen i ett projekt. Bokföringslagen kräver exempelvis att transaktioner skall kunna spåras och sparas. Skatteverket, Finansinspektionen, BankGirot etc har alla krav på underlag och speciella filformat, frekvens etc.

Den nya General Data Protection Regulation (GDPR) och tidigare Personuppgiftslagen (PUL) ställer krav på användandet, lagring och överföring av personuppgifter. Det är viktigt att identifiera någon intern eller extern resurs som har kunskap om detta område. Har behoven säkerställts?

Arkitekter på olika nivåer kan behöva bidra med krav som är viktiga för lösningens utformning. User Experience och Usability-experter kan också behöva beskriva behov och krav. Behoven av användbarhet kan ibland beskrivas alldeles för sent vilket kan medföra att lösningen knappt går att använda.

Här kom byggledaren med värdefulla kommentarer om våtrumsstandarder, fuktspärrar, försäkringsbolagets krav etc som vi inte hade någon aning om.

  1. ROI (Return On Investment)

Behov och krav kan dokumenteras detaljerat men falla pladask vid leverans på grund av dåligt underbyggda ekonomiska kalkyler. Ökade intäkter eller effektivitetsvinster överskattas (en grov generalisering) och kostnader underskattas för att ROI-beräkningen skall kunna bekräfta behovets existens. Projektet bör göra om ROI-beräkningen efter ett tag. Kan behov då upp- respektive nedprioriteras tack vare mer information?

Badrummet blev dyrare än beräknat. Vi hade en grov budget som var baserad på en del gissningar. 

  1. Prioritera, prioritera och prioritera

Många delar av verksamheten har behov för att uppfylla verksamhetsmålen och de behöver då beskrivas. Alla behov kan inte tillgodoses men i alla fall beskrivas kortfattat och prioriteras på ett strukturerat sätt för att sedan kunna detaljeras och utvecklas när det börjar bli dags att utveckla.

Omprioritering behöver göras allt eftersom under projektet och här har Produktägaren en nyckelroll för att rätt funktioner och lösningar skall se dagens ljus.

  1. Tillfälliga manuella lösningar och prototyper

Vid oklara behov och krav, kan en manuell lösning illustrera processen och ge användarna och organisationen idéer till behov och krav. ”Seeing is believing” är ett uttryck som jag gillar. Vid flera tillfällen har abstrakt och svårläst kravdokumentation blivit mycket intressant och engagerande när den blivit konkret i form av manuella lösningar, rollspel och/eller prototyper.

I vårt badrum blev det trångt på grund av en ogenomtänkt placering av handfat och toalettstol. Vi hade kanske upptäck det problemet med hjälp av en skiss. Så här i efterhand var dörrar i glas till duschen ingen bra idé. De blir snabbt smutsiga av kalk och tvålrester. Underhållbarheten hade vi med andra ord inte med i kravbeskrivningen. 

  1. Proof of Concept (POC)

Vid inköp av lösningar kan en POC ge insikter kring behov och krav som kanske inte fanns med på agendan i inledningsskedet. Processer kanske kan implementeras på ett annat sätt eller kanske till och med ändras lite för att fungera bättre i ett nytt system. Inte minst för att minska behovet av anpassningar av standardlösningar. Branschspecifika standardlösningar och de principer som finns där, kan ge input till den egna processen.

Allt eftersom lösningen levereras, tänk till och fundera. I vårt fall fick byggarna förstärka väggarna vilket gjorde att avståndet mellan handfat och toalettstol minskade. Det i sin tur borde vi ha upptäckt och köpt ett mindre handfat.

Paralleller mellan IT-projekt och badrumsrenovering?

Styrgruppen (i mitt exempel föräldrarna och beställarna) och mottagande organisation (tonåringarna) har olika drivkrafter… De har kanske helt olika behov?

Lösningarna på detta återkommande problem är enkla men kan samtidigt tyvärr vara svår. Här kommer en summering av punkterna ovan: 

  1. Engagera de som skall påverka (ledningen) och de som blir påverkade (användarna, kunder, mottagare av systemet och tonåringarna). Glöm inte integrationspartnerna.
  2. Red ut politik och motstridiga interna behov, innan kravanalysen inleds.
  3. Beskriv först behoven förutsättningslöst och utan lösningsperspektiv.
  4. Ställ den obekväma frågan ”Varför” (flera gånger). Beskrivningen kanske döljer ett annat mer grundläggande behov? Gamla sanningar kanske inte håller längre.
  5. Förankra behoven i organisationens mål och strategier.
  6. Notera spårbarhet till ursprungligt behov och kravställare.
  7. Ta in lösningsarkitekt tidigt för att identifiera områden som måste utredas mer.
  8. Gör tidiga ROI-beräkningar (så långt det nu går) för att rensa ut de mest galna idéerna.
  9. Prioritera. Prioritera.
  10. Tillfälliga manuella lösningar och prototyper kan ge insikter om alternativa krav som inte var möjliga att förutse i den tidiga kravdiskussionen.
  11. Gör en Proof of Concept på de viktigaste behoven för att verkligen förstå och utveckla behoven och hur de kan realiseras.
Dela artikeln