Scope är ett engelskt ord som används rätt flitigt inom projektledning. Projektets scope är spelrummet för allt arbete som utförs i ett projekt. Projektledare däremot använder ordet mest när de diskuterar vilket arbete som inte ska utföras i projektet. Det mest närbesläktade begreppet på svenska torde vara omfattning (och dess avgränsningar).
GRUNDBESKRIVNING
Ett uppenbart grundexempel på scopingbehov som uppkommer under projektets gång är när ett krav på projektet visar sig vara svårt att genomföra – kanske har man i sin specifikation beskrivit vad som ska göras, men det som utretts och skrivits ned visar sig ändå vara ogenomförbart när man penetrerat problemet djupare.
Alltså kommer frågan upp om hur kravet ska tolkas och genast är önskelistan öppen för tillägg. Det här är ingen svårtolkad situation – det är ganska uppenbart för alla inblandade att man då påverkar projektets scope.
Inom all projektledning är det naturligtvis ett problem om man börjar utföra saker som egentligen inte hör till projektet. Inom IT-projekt, där arbetet ofta har ett stort inslag av nya arbetsuppgifter som aldrig lösts tidigare, så stöter man på avgränsningsproblematiken i flera former. Det kan till och med vara svårt att känna igen det här fenomenet eftersom det kommer insmygande från så många håll. Jag tänkte ta upp några exempel här som jag själv stött på och se hur de kan eller bör hanteras.
EXEMPLET UPPDRAGSGIVAREN
Som exempel på scopeförändringar som kommer uppifrån vill jag nämna när uppdragsgivaren för projektet kommer med tillägg på ett svårgenomskådat sätt. Om ni tänker er in i situationen att projektledaren engagerades tidigt i projektet, redan under kravsammanställningsfasen, så kan ni kanske förstå att uppdragsgivaren hävdar att ”felaktigheter i kraven” borde vara kända av projektledaren sedan länge.
Slutsatsen enligt uppdragsgivaren är att man därför måste välja en stor och dyr lösning. Projektledaren hålls som gisslan och ska svara för kraven.
Frågar ni mig så är inte det här rätt och det måste man vara tydlig med. Projektledaren kan aldrig ha full kontroll på vad alla projektmedlemmar gjort under projektets gång även om man personligen naturligtvis känner att det skulle varit bra om man i detalj förstått hur alla formuleringar i slutänden kan tolkas. Om uppdragsgivaren accepterat en viss kravbeskrivning så kan han/hon inte komma långt senare och kräva att ett svårtolkat krav ska tolkas på ett enda specifikt sätt – inte utan att ta konsekvenserna i form av förlängt och fördyrat projekt.
Slutsatsen blir att omtolkning av ett krav kan göras, men att omtolka det till en mycket större lösning än vad som ursprungligen planerades betyder att projektets scope utökas (vilket förstås också kan göras om medel finns). Man är inte en dålig projektledare för att en scope-diskussion kom upp även om vissa hävdar det i den beskrivna situationen.
EXEMPLET ANVÄNDARE
Framtida användare av ett system kan komma med tillägg på precis hur oväntade sätt som helst. Det vanligaste som jag stött på är att de vill lösa hela sin arbetssituation och därför för in nya önskemål till projektet som efter viss utredning visar sig ligga utanför projektets ramar. Ofta vet de att de försökt få in något som inte hör hemma i projektet.
De svåraste exemplen är när användaren är helt övertygad om att funktionen måste lösas av projektet och när de dessutom har lyckats övertyga projektmedlemmar att funktionen måste inkluderas.
Här har man som projektledare alltid möjligheten att välja sina strider, tycker jag. Om användaren är central och hennes/hans medverkan behövs för att systemet ska få en stor acceptans så kan man välja att inkludera en mindre funktion som strängt taget inte hör hemma i projektet.
Det är lustigt med IT-projekt, men när man som projektledare säger att man inte tycker funktionen egentligen borde vara med, men att man ändå godkänner den eftersom den är ett mindre tillägg, så händer en av två saker: antingen skapas funktionen märkligt snabbt och hela projektet tjänar på det i form av good will från användarna eller också har man öppnat dammluckan för fler krav och i slutänden missnöjda användare i alla fall.
Här är det ren fingertoppskänsla som gäller från projektledaren, tror jag, den oerfarne projektledaren kan förstås säga nej direkt och få missnöjda användare (men håller åtminstone sin budget) den lite mer våghalsige (jag kallar det hellre erfaren) känner när läget är rätt att samla pluspoäng och uppnå en teamkänsla i projektet.
EXEMPLET TEKNIKEN
Det sista exemplet jag tänkte ta upp är när tekniken driver på en scope-förändring. Det här är ett exempel från mitt innevarande projekt. Alla typer av tekniska förbättringar i form av nysläppta tillägg, nya versioner, mm, kan ge upphov till en diskussion om att vi inte tagit tillräcklig hänsyn till de tekniska möjligheterna som nu infunnit sig. Ibland är det här helt nödvändigt för vissa mjukvaruförändringar ger återverkningar som måste hanteras. Det kan vara svårt att se att det faktiskt handlar om scope.
I mitt nuvarande projekt så diskuterade vi möjligheterna med den nya versionen och de möjligheter till framtida förbättrad systemarkitektur som den kan ge upphov till. Inte förrän vi stött och blött frågan i några dagar så insåg jag att vi höll på med en arbetsuppgift som låg bortanför vårt eget projekt.
Vårt projekt ska bara leverera det som sagts, att även leverera en ny systemarkitektur ligger långt utanför ramarna för vårt projekt även om det förstås är bra att vi analyserat den senaste tekniken så att inget i vår lösning blir fel vid versionsbytet. Kanske var det projektledaren som önskade sig det optimala systemet den här gången…
Av Raphael Sedin
Raphaels blogg