Dere byttet verktøy i fjor. Innføringen gikk greit, alle fikk opplæring, og lisensene er betalt. Likevel er statusmøtene like uklare som før, og ingen vet helt hvem som eier hvilken oppgave.
Det er ikke et verktøyproblem. Men det oppdages nesten alltid som ett.
Vi har ledet IT-prosjekter i norske virksomheter i snart 30 år, i bank, offentlig forvaltning og telekom. Aspiria jobber i kundenes egne verktøy, ikke i våre egne, og det gir et bredt sammenligningsgrunnlag. Erfaringen er entydig: verktøyet gjør god styring synlig, og dårlig styring effektiv.
Vi går gjennom de fire kategoriene av verktøy for prosjektledelse i IT og hva hver av dem løser. Så tar vi valget de fleste norske virksomheter står i. Til slutt fem kriterier som betyr noe når du velger, og ett poeng du bør ta med inn i beslutningen.
Hva slags verktøy finnes, og hva løser de?
Markedet ser uoversiktlig ut, men verktøyene faller i fire kategorier. De fleste virksomheter trenger noe fra hver.
Oppgave- og sprintstyring
Dette er verktøyene folk mener når de sier «prosjektverktøy». De holder styr på oppgaver, hvem som gjør hva, og hva som er ferdig. Jira, Azure DevOps, Asana og Trello hører hjemme her.
Kjernefunksjonaliteten er nokså lik på tvers. Forskjellene ligger i hvor mye struktur verktøyet påtvinger deg, og hvor godt det henger sammen med resten av plattformen deres.
Porteføljestyring og ressursoversikt
Når du kjører flere prosjekter samtidig, trenger du å se på tvers. Hvem er allokert hvor, hvilke prosjekter konkurrerer om de samme folkene, og hva skjer med leveranseplanen hvis ett av dem sklir?
Dette er en annen type verktøy enn oppgavestyring, og en av de vanligste feilene er å tro at oppgaveverktøyet dekker begge behov. Det gjør det sjelden godt.
Test- og kvalitetsverktøy
Testledelse har egne verktøy for testcaser, testkjøringer, avviksoppfølging og sporbarhet mot krav. I mange prosjekter lever disse adskilt fra prosjektverktøyet, og det er der sporbarheten ryker.
Kravet om å kunne vise hva som er testet, mot hvilket krav, og med hvilket resultat, hører hjemme i teststrategien lenge før du velger verktøy.
Samhandling og dokumentasjon
Confluence, SharePoint, Notion og lignende. Her bor beslutningsunderlag, referater og planer.
Regelen er enkel: dokumentasjonen skal ligge i virksomhetens systemer, ikke hos leverandøren eller i konsulentens egne maler. Ellers forsvinner prosjekthistorikken den dagen oppdraget avsluttes.
Jira eller Azure DevOps?
For de fleste norske virksomheter med IT-utvikling står valget mellom disse to. Aspiria leder prosjekter i begge, og forskjellen handler mindre om funksjoner enn om hvilken plattform dere allerede lever på.
Kort oppsummert: Jira gir mer frihet, Azure DevOps gir mer styring.
Når Jira passer best
Jira har et stort økosystem av tillegg og lar seg tilpasse nesten hvordan som helst. Det passer godt når flere fagområder skal følge samme arbeid, og når produkt, forretning og utvikling må se det samme brettet.
Frihet har en pris. Uten noen som eier oppsettet, vokser Jira til et virvar av prosjekter, felter og arbeidsflyter som ingen forstår etter to år. Sett av eierskap til konfigurasjonen fra starten.
Vi har overtatt prosjekter der ingen kunne forklare hvorfor en oppgave måtte gjennom sju statuser. Svaret var alltid det samme: noen satte det opp en gang, og de sluttet.
Når Azure DevOps passer best
Azure DevOps er sterkest når utvikling og drift allerede er forankret i Microsofts plattform. Identitetsstyring henger sammen med resten av virksomheten, og sammenhengen mellom kode, bygg, testing og release ligger i samme verktøy.
For offentlig sektor er det et poeng til: Azure DevOps finnes i en variant som kan driftes lokalt. Der kravene sier at data ikke kan ligge hos en ekstern skyleverandør, snevrer valget seg raskt inn, og det skjer oftere enn de fleste tror når anskaffelsen først er i gang.
Hva bør du se etter når du velger?
Fem kriterier som betyr noe i praksis
Hvem eier oppsettet? Et verktøy uten en navngitt eier forfaller. Dette er viktigere enn nesten alle funksjonskrav. I praksis er det ofte IT-prosjektlederen som ender med ansvaret, og da bør det være avklart og ikke antatt.
Passer det arbeidsformen dere faktisk har? Ikke den dere skulle ønske dere hadde. Et verktøy bygget for smidige team fungerer dårlig hvis prosjektene styres etter faseplan.
Kommer dere ut igjen? Sjekk eksportmuligheter før dere låser flere års prosjekthistorikk inne i et format dere ikke kontrollerer.
Hva krever det av opplæring? Verktøy som krever mye opplæring blir brukt av dem som fikk opplæring, og omgått av resten.
Hva sier sikkerhets- og personvernkravene? Avklar dette først, ikke sist. Det eliminerer ofte flere alternativer enn funksjonskravene gjør.
Integrasjonene er der prisen skjuler seg
Lisenskostnaden er sjelden problemet. Kostnaden ligger i å få verktøyet til å snakke med det dere allerede har.
Skal testverktøyet henge sammen med oppgavestyringen? Skal timeføringen inn i økonomisystemet? Skal porteføljeoversikten hente data automatisk, eller skal noen klippe og lime hver måned?
Be leverandøren vise integrasjonene i drift, ikke i en funksjonsliste. Det er her de fleste innføringsprosjekter sprekker på tid.
Et konkret grep: velg ut to arbeidsflyter dere gjør hver uke, og be om å få se dem demonstrert fra ende til ende i deres eget oppsett. Ikke i leverandørens demomiljø, der alt alltid virker.
Verktøy løser ikke ledelse
Dette er poenget som er verdt mer enn resten av artikkelen.
Prosjekter feiler sjelden fordi verktøyet var feil. De feiler fordi målene var uklare, rollene var utydelige, eller fordi ingen turte å si fra at planen ikke holdt. Vi ser det samme mønsteret igjen og igjen, og årsakene til at IT-prosjekter feiler handler nesten alltid om mennesker og styring, ikke om teknologi.
Et godt verktøy gjør god styring synlig for alle. Det gjør også dårlig styring mer effektiv, fordi uklarheten spres raskere og til flere.
Derfor starter vi alltid et hakk før verktøyet. Hva skal prosjektet oppnå? Hvem bestemmer hva? Hvordan vet vi at vi er på etterskudd, og hvem sier fra? Når de spørsmålene har svar, blir verktøyvalget enklere, og som regel mindre viktig enn det virket. Det samme gjelder når dere skal lede digitale prosjekter på tvers av flere leverandører.
Ofte stilte spørsmål om prosjektverktøy
Hvilket verktøy er best for IT-prosjektledelse?
Det finnes ikke ett riktig svar. For virksomheter som allerede bruker Microsofts plattform, er Azure DevOps som regel enklest. For virksomheter der flere fagområder skal følge samme arbeid, er Jira mer fleksibelt. Viktigere enn valget er at noen eier oppsettet og at det passer måten dere jobber på i dag.
Trenger vi et eget verktøy for testledelse?
Hvis prosjektet har krav til sporbarhet mellom krav, testcaser og resultat, ja. Både Jira og Azure DevOps har testmoduler eller tillegg som dekker dette. Poenget er at testdataene ikke skal leve i et regneark på siden av prosjektet.
Hvor mye koster det å innføre et nytt prosjektverktøy?
Lisensene er sjelden hovedkostnaden. Regn med at oppsett, integrasjoner, opplæring og migrering av eksisterende data koster mer enn lisensene det første året.
Bør vi bytte verktøy midt i et prosjekt?
Som hovedregel nei. Et verktøybytte koster fremdrift akkurat når prosjektet trenger den mest, og historikken blir splittet i to systemer. Er dagens verktøy virkelig et hinder, gjør byttet mellom to leveranser, ikke midt i et testløp.
Velg verktøy sist, ikke først
Verktøyene faller i fire kategorier, og de fleste virksomheter trenger noe fra hver. Valget mellom Jira og Azure DevOps avgjøres oftest av hvilken plattform dere allerede lever på, ikke av funksjonslistene.
Men det viktigste er dette: avklar mål, roller og rapportering før dere velger verktøy. Et verktøy kan vise deg at prosjektet er på etterskudd. Det kan ikke fortelle deg hvorfor, og det kan ikke ta beslutningen om hva dere gjør med det.
Vil dere ha hjelp til å få styringen på plass før eller etter et verktøybytte? Les mer om hvordan vi jobber med IT-prosjektledelse, eller ta kontakt for en uforpliktende prat om hva prosjektet deres faktisk trenger.