Ögonblicket då jag visste att det var dags att byta verktyg
Friktion i verktyget: När ett verktyg för projektledning skapar mer arbete än det sparar är det dags att tänka om.
Problem med användningen: Lågt stöd från teamet och bristfällig introduktion kan signalera att det behövs ett byte till verktyg med bättre funktionalitet.
Komplexitet på företagsnivå: Stela arbetsflöden i verktyg för stora företag kan hindra produktiviteten och leda till ett byte till enklare alternativ.
Rätt tid för förändring: Utvärdera verktyg i tre till sex månader. Kvarstående problem kan göra ett byte nödvändigt.
Att stanna kvar: Mindre missnöje motiverar inte ett byte. Bedöm om fördelarna väger upp störningarna vid en migrering.
Att byta projektledningsverktyg är aldrig ett beslut man fattar lättvindigt. Kostnaderna för migreringen, inlärningskurvorna, teamets motstånd – inget av det är trivialt. Men det kommer en punkt när friktionen i att stanna kvar överväger friktionen i att lämna.
De ledare inom projektledning och verksamhetsdrift som har gått igenom det säger att tecknen vanligtvis är tydliga i efterhand. Det svårare är att känna igen dem i realtid och göra något åt saken.
När verktyget skapar mer arbete än det sparar
Det mest grundläggande testet av alla projektledningsverktyg är enkelt: gör det arbetet enklare eller svårare? Matthew Fox, senior projektledare och specialist på verksamhetsdrift på Fox Consulting, uttrycker det tydligt. "Om du upptäcker att din interna personal lägger mer tid på att arbeta med verktyget än i verktyget, är det en varningssignal", säger 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 tillägger att när ett verktyg "skapar mycket friktion", leder till kringlösningar och tar upp en betydande del av teamets vecka, har något gått fel. "Ett verktyg ska stödja det pågående arbetet, inte skapa friktion när vi försöker få arbetet gjort."
Ett verktyg ska stödja det pågående arbetet, inte skapa friktion när vi försöker få arbetet gjort.
När verktyget tekniskt sett fungerar, men knappt
Ibland är problemet inte att ett verktyg helt saknar PM-funktioner, utan att det känns som en kamp att använda funktionerna. Julia Rajic, operativ chef på Point Blank, upplevde detta på nära håll med Resource Guru. "I teorin kunde det göra allt vi behövde att det skulle göra", säger hon, "men att faktiskt få det att göra de sakerna kändes som att dra ut tänder."
Plattformen saknade den flexibilitet i det dagliga arbetet som hennes team behövde – till exempel att enkelt hantera tillfällig personal och justera scheman genom att dra och släppa. Administrationen av den, förklarar hon, "var mycket svårare än den behövde vara". När ett verktyg kräver så mycket ansträngning bara för att fungera har det slutat vara en lösning.
När funktionsluckor kombineras med misslyckad implementering
Byten av verktyg sker sällan av en enda anledning. Rajic beskriver en annan övergång som hennes team genomförde – från monday.com till Asana – där beslutet berodde på en kombination av saknade funktioner och ett minskat stöd från teamet. "En stor del av diskussionen kring varför vi skulle lämna monday handlade om resurshantering", förklarar hon. "Det var inte särskilt bra på resurshantering."
Men funktionaliteten var inte hela historien. Byrån hade aldrig fått en ordentlig introduktion till monday.com från början, vilket innebar att användningen aldrig nådde den nivå som krävdes. "Det var mycket av typen: ‘Jag gillar inte det här, det är nytt, jag tänker vägra använda det’", säger Rajic. "Så användningen var inte på den nivå vi behövde för att det skulle bli framgångsrikt." När ett verktyg misslyckas på båda dessa fronter samtidigt blir argumenten för att byta svåra att säga emot. Men det finns en viktig lärdom här: om ditt team inte vill introduceras till ett nytt verktyg, eller om din organisation inte har resurser att lägga tid på introduktionen, kan det vara bättre att behålla nuläget.
Användningen [av monday.com] var inte på den nivå vi behövde för att det skulle bli framgångsrikt.
När företagsverktyg blir byråkrati
Företagsplattformar som Jira är byggda för komplexitet – men komplexiteten kan bli själva problemet. Ryan Gilbreath, teknisk projektledare på RTS Labs, har sett det hända. När det gäller vad som avgör om ett teams Jira-upplevelse blir bra eller dålig säger han: "Jag känner verkligen att det handlar om hur JIRA-administratören konfigurerar det och vilka arbetsflöden de har på plats.” När dessa arbetsflöden är rigida och det krävs omständliga kringvägar för att komma åt dokument eller samarbeta med andra team slutar verktyget att påskynda arbetet och börjar i stället hindra det.
"Om det är [Jiras konfiguration] som bromsar framdriften", säger Gilbreath, "kommer jag förmodligen att gå utanför Jira och använda något annat, troligen ett kalkylblad om det behövs." Att en erfaren teknisk projektledare frivilligt skulle återgå till ett kalkylblad säger mycket om hur illa ett överkonfigurerat företagsverktyg kan missa målet.
Om det är [Jiras konfiguration] som bromsar framdriften kommer jag förmodligen att gå utanför Jira och använda något annat.
Hur länge ska man vänta innan man agerar?
Alla problem med verktyg motiverar inte ett omedelbart byte. Melody MacKeand, grundare av Melody MacKeand Consulting, rekommenderar att man ger interna processförbättringar en ordentlig chans innan man drar slutsatsen att det är själva verktyget som är problemet. "Jag försöker ge det en tidsram på tre till sex månader för att styra om skutan", säger hon.
Om samma problem kvarstår efter den perioden kan det vara dags att agera — men MacKeand medger också att det finns ett mindre mätbart skäl att göra en förändring. "Om ett team har arbetat med en plattform under lång tid, säg 10+ år, behöver de ibland helt enkelt byta verktyg för att känna att de blir hörda eller att något faktiskt är annorlunda. Och i så fall är jag verkligen öppen för ett verktygsbyte." Ibland handlar värdet av att byta inte bara om verksamheten — det är en signal till teamet om att ledningen lyssnar.
Om ett team har arbetat med en plattform under lång tid, säg 10+ år, behöver de ibland helt enkelt byta verktyg för att känna att de blir hörda.
Argumenten för att stanna kvar
Självklart är inte all frustration över ett verktyg ett skäl att lämna det. Marissa Taffer, grundare och ordförande för M. Taffer Consulting, erbjuder ett viktigt motargument. "Jag vill inte tvinga någon att lära sig ett nytt verktyg bara för sakens skull", säger hon. "Om det finns ett övertygande skäl att byta, visst. Men jag tänker inte genomföra förändringen bara för att jag tror att vi skulle kunna organisera ett projekt bättre i ett annat system." Störningarna vid en verktygsmigrering — tiden, utbildningen och motståndet — måste vägas mot en konkret fördel. Marginella förbättringar når inte upp till den nivån.
Om det finns ett övertygande skäl att byta [verktyg], visst. Men jag tänker inte genomföra förändringen bara för att jag tror att vi skulle kunna organisera ett projekt bättre i ett annat system.
Den gemensamma nämnaren i alla dessa perspektiv är densamma: verktyget finns till för att hjälpa teamet, inte tvärtom. När den relationen vänds upp och ner — när plattformen börjar ta energi, hindra framsteg eller urholka förtroendet — då är det dags. De projektledare som hanterar dessa beslut väl är inte de som har de mest imponerande teknikstackarna. Det är de som vet när de ska avvakta och när de ska byta.
Vill du ha fler insikter som dessa? Skapa ett kostnadsfritt DPM-konto för att höra från fler experter som dessa.
