Konsten att prioritera bland 100 IT-projekt

När jag kom till Tretti fanns det en kort lista på några stora projekt som bara måste genomföras. Till detta fanns det en mängd små projekt, buggar och feature requests. Det fanns ingen CTO eller produktägare på Tretti så mycket av ansvaret för att prioritera mellan dessa hamnade på utvecklarna i synnerhet vår lead.

Kvalitén på projekt och ärenden var väldigt blandade. En kort mening om en ny knapp, en utförlig beskrivning om en ny funktion, ett argt mail om en funktion som är trasig m.m. För att få koll på vad som låg började vi med scrum som metodik och vi fick upp ärenden tydligare på en digital plattform. Det fanns ingen idé att riva upp det som utvecklarna redan jobbade med men nu visualiserade vi vad som kom in och ut från vårt team.

Nästa steg för mig var att skapa en heltäckande backlog för allt som är efterfrågat och prioritera detta. Lättare sagt än gjort, men det gick att få ihop allt som var liggande. Som en första sortering utgick jag ifrån en ganska grov modell impact matrix som skulle fokusera på maximal värde för affären.

För system som påverkar slutkunden mappade jag in projekt efter hur många kunder ändringen påverkade och hur ofta. För interna system såg det ungefär likadant ut men där antal kunder var utbytta mot en skala av medarbetare. Det finns fler parametrar att ta ställning till när man prioriterar, men detta gav en grov bild som funkade.

impact matrix på externa projekt

Jag har testat lite olika metoder för att göra detta. Det som fungerat bäst är att visa alla avdelningschefer vilka projekt som deras team efterfrågar och låta dem sätta prioritet som grupp — att skapa en kultur av produktägarskap. Jag har både testat att låta dem prioritera all ärenden på listan i ordning eller helt enkelt välja ut två-tre ärenden som brinner nu. Det senare fungerar bäst enligt min mening. Jag har också smugit in lite frågeställningar som hjälper dem att välja utifrån impact.

Det vi jobbar på nu är att se över hur ärenden kommer in och hur vi kan automatiskt kan få den som rapporterar ärenden att värdera dem utan att sätta en prioritet. Det tar helt enkelt för lång tid att ta in allt och processa det genom en egen impact matrix.

Inom agile finns det en del som hävdar att s.k. impact mapping (inte samma som min lösning ovan) är det bästa sättet att värdera projekt på. Istället för att sätta roadmaps och deadlines så jobbar man alltid på det projekt som ger mest värde. Det är en intressant tanke och jag tror att nyckeln är att man får med hela organisationen på tåget om det ska funka. Tack till Marcus Hamrin (Agile project manager på Ooyala) för bra intro till detta.

###

Denna post är nummer 57 i en serie av 100 poster i utmaningen #blogg100 där jag fokuserar på hur vi skapar Trettis nya sajt. Alla åsikter är mina egna.

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *