Øyeblikket jeg visste at det var på tide å bytte verktøy
Friksjon ved bruk av verktøyet: Når et verktøy for prosjektstyring skaper mer arbeid enn det sparer, er det på tide å vurdere alternativene på nytt.
Utfordringer med innføring: Lav oppslutning i teamet og dårlig opplæring kan være tegn på at man bør bytte verktøy for å få bedre funksjonalitet.
Kompleksitet i virksomhetsverktøy: Rigide arbeidsflyter i verktøy for større virksomheter kan hemme produktiviteten og føre til at man bytter til enklere alternativer.
Tidspunkt for endring: Vurder verktøyene i tre til seks måneder. Vedvarende problemer kan gjøre et bytte nødvendig.
Å bli værende: Mindre misnøye er ikke grunn nok til å bytte. Vurder om fordelene oppveier ulempene ved migreringen.
Å bytte prosjektstyringsverktøy er aldri en beslutning man tar lett på. Migreringskostnadene, læringskurvene, motstanden i teamet – ingenting av dette er ubetydelig. Men det kommer et punkt der friksjonen ved å bli værende veier tyngre enn friksjonen ved å forlate verktøyet.
Prosjektstyrings- og driftslederne som har vært gjennom dette, sier at tegnene vanligvis er tydelige i ettertid. Den vanskeligste delen er å gjenkjenne dem mens det skjer, og gjøre noe med det.
Når verktøyet skaper mer arbeid enn det sparer
Den mest grunnleggende testen av ethvert prosjektstyringsverktøy er enkel: Gjør det arbeidet enklere eller vanskeligere? Matthew Fox, senior prosjektleder og driftsspesialist hos Fox Consulting, sier det rett ut. «Hvis du oppdager at de interne medarbeiderne dine bruker mer tid på å jobbe med verktøyet enn i verktøyet, er det et rødt flagg», sier han.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Han legger til at når et verktøy «skaper mye friksjon», fører til omveier og legger beslag på en betydelig del av teamets arbeidsuke, har noe gått galt. «Et verktøy skal støtte arbeidet som pågår, ikke skape friksjon når vi prøver å få jobben gjort.»
Et verktøy skal støtte arbeidet som pågår, ikke skape friksjon når vi prøver å få jobben gjort.
Når verktøyet teknisk sett fungerer, men så vidt
Noen ganger er ikke problemet at et verktøy mangler PM-funksjoner fullstendig, men at det føles som en kamp å bruke disse funksjonene. Julia Rajic, driftsdirektør hos Point Blank, opplevde dette på nært hold med Resource Guru. «I teorien kunne det gjøre alt vi trengte at det skulle gjøre», sier hun, «men å faktisk få det til å gjøre disse tingene føltes som å trekke ut tenner.»
Plattformen manglet den daglige fleksibiliteten teamet hennes trengte – ting som å administrere midlertidig ansatte på en enkel måte og dra og slippe for å justere tidsplaner. Administrasjonen av den, forklarer hun, «var mye vanskeligere enn den trengte å være». Når et verktøy krever så mye innsats bare for å fungere, har det sluttet å være en løsning.
Når funksjonshull møter mislykket innføring
Bytte av verktøy skjer sjelden av én enkelt grunn. Rajic beskriver en annen overgang teamet hennes navigerte – fra monday.com til Asana – der beslutningen kom ned til en kombinasjon av manglende funksjonalitet og manglende oppslutning i teamet. «Mye av diskusjonen om hvorfor vi skulle gå bort fra monday, handlet om ressursstyring», forklarer hun. «Det var egentlig ikke særlig godt på ressursstyring.»
Men funksjonalitet var ikke hele historien. Byrået hadde aldri fått en ordentlig innføring i monday.com til å begynne med, noe som betydde at bruken aldri nådde terskelen den måtte nå. «Det var mye av typen: «Jeg liker ikke dette, det er nytt, jeg kommer til å nekte å bruke det»», sier Rajic. «Så bruken var ikke på det nivået vi trengte for at det skulle bli vellykket.» Når et verktøy svikter på begge områder samtidig, blir det vanskelig å argumentere mot å bytte. Men dette gir en viktig lærdom: Hvis teamet ditt ikke er villig til å få opplæring i et nytt verktøy, eller organisasjonen din ikke har ressurser til å bruke tid på innføringen, kan det være bedre å fortsette som før.
Bruken [av monday.com] var ikke på det nivået vi trengte for at det skulle bli vellykket.
Når virksomhetsverktøy blir byråkrati
Virksomhetsplattformer som Jira er utviklet for kompleksitet – men denne kompleksiteten kan bli selve problemet. Ryan Gilbreath, teknisk prosjektleder hos RTS Labs, har sett dette skje. Når det gjelder hva som avgjør om et team får en god eller dårlig Jira-opplevelse, sier han: «Jeg føler virkelig at det handler om hvordan JIRA-administratoren setter det opp, og arbeidsflytene de har på plass.» Når disse arbeidsflytene er rigide, og det å få tilgang til dokumenter eller samarbeide med andre team krever at man må hoppe gjennom en rekke hindringer, slutter verktøyet å effektivisere arbeidet og begynner i stedet å hindre det.
«Hvis det er [Jiras oppsett] som bremser fremdriften», sier Gilbreath, «kommer jeg sannsynligvis til å gå bort fra Jira og bruke noe annet, sannsynligvis et regneark hvis det er det eneste alternativet.» At en erfaren teknisk prosjektleder er villig til å gå tilbake til et regneark, sier mye om hvor dårlig et overkonfigurert virksomhetsverktøy kan treffe.
Hvis det er [Jiras oppsett] som bremser fremdriften, kommer jeg sannsynligvis til å gå bort fra Jira og bruke noe annet.
More Articles
- Slått på, koblet av: Funksjonene i prosjektstyringen team slutter å bruke
- Prosjektlederens snarvei: Verktøy som faktisk eliminerer tidstyveri
- Å håndtere oppgaver som prosjektleder: 3 viktige strategier 2026
- Nye funn: De nye verktøyene PM-eksperter er begeistret for akkurat nå
- Topp 5 datadrevne trender innen prosjektledelse i 2025
Hvor lenge bør man vente før man tar steget
Ikke alle problemer med et verktøy krever et umiddelbart bytte. Melody MacKeand, grunnlegger av Melody MacKeand Consulting, anbefaler å gi interne prosessforbedringer reelt spillerom før man konkluderer med at det er selve verktøyet som er problemet. «Jeg prøver å gi det tre til seks måneder for å styre skuta rundt», sier hun.
Hvis de samme problemene vedvarer etter denne perioden, kan det være på tide å handle – men MacKeand erkjenner også en mindre målbar grunn til å gjøre en endring. «Hvis et team har brukt en plattform lenge, for eksempel i over 10 år, trenger de noen ganger ganske enkelt at verktøyet endres, slik at de føler at de blir hørt, eller at noe faktisk er annerledes. Og i så fall er jeg virkelig åpen for å bytte verktøy.» Noen ganger handler verdien av å bytte ikke bare om drift – det er også et signal til teamet om at ledelsen lytter.
Hvis et team har brukt en plattform lenge, for eksempel i over 10 år, trenger de noen ganger ganske enkelt at verktøyet endres, slik at de føler at de blir hørt.
Argumentene for å bli værende
Det er selvsagt ikke all misnøye med et verktøy som er en grunn til å forlate det. Marissa Taffer, grunnlegger og president i M. Taffer Consulting, kommer med et nødvendig motargument. «Jeg vil ikke få noen til å lære seg et nytt verktøy bare for å gjøre det», sier hun. «Hvis det finnes en overbevisende grunn til å bytte, er det greit. Men jeg kommer ikke til å gjøre endringen bare fordi jeg tror vi kunne organisert et prosjekt bedre i et annet system.» Forstyrrelsen et verktøybytte medfører – tiden, opplæringen og motstanden – må veies opp mot en konkret fordel. Marginale forbedringer er ikke nok.
Hvis det finnes en overbevisende grunn til å bytte [verktøy], er det greit. Men jeg kommer ikke til å gjøre endringen bare fordi jeg tror vi kunne organisert et prosjekt bedre i et annet system.
Temaet på tvers av alle disse perspektivene er det samme: Verktøyet finnes for å tjene teamet, ikke omvendt. Når dette forholdet snus på hodet – når plattformen begynner å tappe energi, hindre fremdrift eller svekke tilliten – da er tiden inne. Prosjektlederne som håndterer disse beslutningene godt, er ikke de som har de mest prangende teknologistakkene. Det er de som vet når de skal bli værende, og når de skal bytte.
Vil du ha flere innsikter som dette? Opprett en gratis DPM-konto for å høre fra flere eksperter som disse.
