Tips från projektcoachen – Kravhantering

Två grossistföretag gick samman. Deras produkter kompletterade varandra och man förväntade sig därför en stor försäljningsökning. Ett annat mål var att sänka kostnaderna med effektivare organisation, bättre processer och modernare IT-stöd. Ökad användning av webben var en nyckelfaktor. I den första etappen – delprojekt 1 – skulle en ny ordermottagningsprocess skapas, där kunden skulle kunna registrera sin order direkt via webben eller knapptelefon eller ringa till en ordermottagare. Det var bråttom.

Ett välrenommerat konsultföretag kontrakterades för systemutvecklingen. Man anordnade workshops där konsulten tillsammans med användarna specificerade hur systemet skulle se ut. Databaser byggdes upp, program skrevs, tester genomfördes, personalen utbildades, systemet startade. Allt flöt på till belåtenhet och systemet kunde startas två veckor före planerad tid. Projektplanen höll med råge! Men redan under den första veckan framkom missnöje med systemet. Det gällde ”krångliga” och onödigt många bilder och de passade inte riktigt ihop med vissa blanketter och koder. I vissa arbetsmoment måste man titta i fyra olika bilder. I vecka tre dök det upp tekniska problem i form av konstigt långa svarstider ibland. Kunder klagade på att systemet inte fungerade under vissa versioner av Netscape. Vid första månadsskiftet visade det sig att kopplingen till ekonomisystemet inte fungerade. VD och styrelse fick panik, verksamheten var i gungning.

En totalt oplanerad brandkårsutryckning krävdes och en stark oro uppkom för de efterföljande etapperna som redan var planerade.

Du kallas in som projektcoach med uppdraget att reda ut situationen. Vad gör du?

Jag kontrakterades som coach för att reda ut situationen och ta reda på varför det gått snett och att stödja projektledaren i de kommande projektetapperna. Jag satte mig in i vad som hänt på en vecka och kunde konstatera att konsultföretaget byggt systemet så som sagts i specifikationerna, men att det var i själva specifikationerna det brast eftersom man inte tacklat kraven på ett professionellt sätt.

Prototyper som kunde provköras saknades, ekonomipersonal var inte med i projektet, ny oprövad teknik användes, verksamhetsprocesserna dokumenterades inte så att alla förstod. En annan svaghet var att systemet var byggt i för stora komponenter, vilket minskade flexibiliteten inför framtida vidareutvecklig. Dessutom ifrågasatte jag om man inte kunnat köpa vissa komponenter. Några ”smarta” delar i systemet ifrågasatte jag också, eftersom de avvek från vedertagen standard och skapade ett stort leverantörsberoende. Till företagsledningens bestörtning kom jag med det drastiska förslaget att göra om etapp 1 och införa en professionell kravhanteringsprocess (mycket av det som gjorts var fortfarande användbart).

Styrelsen accepterade rådet eftersom mycket fanns att vinna i de följande tre etapperna. Konsultföretaget, som fortfarande bedömdes som kompetenta, behölls. Projektledaren, som kom från användarsidan behölls också, men fick nu till sin hjälp en specialist på systemutveckling och framför allt kravhantering.

Många studier visar att brister i kravhantering är den främsta orsaken till att man misslyckas i systemutvecklingsprojekt. Det gäller att:

• ha en bra kravhanteringsprocess så att man på ett systematiskt sätt och med bra tekniker, hjälpmedel och vedertagna standards tar sig från behov i verksamheten till specifikationer på system
• få med alla intressenter i systemet så att alla önskemål och krav kommer med
• dokumentera kraven så att alla förstår. Körbara prototyper är ett bra komplement till skrivna specifikationer
• strukturera kraven med hjälp av användningsfall
• gör riskanalyser, förhandla och prioritera kraven
• validera kraven, d.v.s. förvissa dig om att systemet verkligen löser verksamhetens problem
• skapa testfall, baserade på användningsfallen, inför kommande acceptanstester
• använda datorstöd för kravhantering om projektet är stort. Där kan man registrera, relatera och bryta ner olika typer av krav. Man kan också relatera krav till realiserade systemdelar och därigenom säkerställa att inget glöms bort

Tänk även på att beakta andra krav än de funktionella kraven som t ex hur orderregistrering skall gå till, det finns även andra typer av krav, s.k. icke-funktionella, som är minst lika viktiga. Exempel på sådana är användbarhet, tillgänglighet, prestanda, förändringsbarhet, designbegränsningar, standards (interna och externa), säkerhet och legala krav.