Det øjeblik, jeg vidste, det var tid til at skifte værktøjer
Friktion ved værktøjet: Når et værktøj til projektstyring skaber mere arbejde, end det sparer, er det tid til at genoverveje det.
Problemer med anvendelsen: Lav opbakning fra teamet og dårlig introduktion kan være tegn på, at der er behov for at skifte værktøj for at opnå bedre funktionalitet.
Kompleksitet i virksomhedsplatforme: Ufleksible arbejdsgange i værktøjer til store virksomheder kan hæmme produktiviteten og få en til at skifte til enklere muligheder.
Tidspunkt for forandring: Vurder værktøjer i tre til seks måneder; vedvarende problemer kan gøre et skift nødvendigt.
At blive, hvor man er: Mindre utilfredshed retfærdiggør ikke et skift; vurder, om fordelene opvejer forstyrrelserne ved overgangen.
At skifte projektstyringsværktøj er aldrig en beslutning, man træffer let. Omkostningerne ved migreringen, indlæringskurverne, teamets modstand — intet af det er trivielt. Men der kommer et tidspunkt, hvor friktionen ved at blive opvejer friktionen ved at skifte.
De ledere inden for projektstyring og drift, som har været igennem det, siger, at tegnene som regel er tydelige set i bakspejlet. Den sværere del er at genkende dem i realtid og gøre noget ved det.
Når værktøjet skaber mere arbejde, end det sparer
Den mest grundlæggende test af ethvert projektstyringsværktøj er enkel: Gør det arbejdet lettere eller sværere? Matthew Fox, senior projektleder og driftsspecialist hos Fox Consulting, siger det ligeud. "Hvis du oplever, at dit interne personale bruger mere tid på at arbejde med værktøjet end i værktøjet, er det et advarselstegn," siger 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 tilføjer, at når et værktøj "skaber en masse friktion", fører til nødløsninger og optager en betydelig del af teamets arbejdsuge, er noget gået galt. "Et værktøj skal understøtte det igangværende arbejde, ikke skabe friktion, når vi forsøger at få arbejdet gjort."
Et værktøj skal understøtte det igangværende arbejde, ikke skabe friktion, når vi forsøger at få arbejdet gjort.
Når værktøjet teknisk set fungerer, men knap nok
Nogle gange er problemet ikke, at et værktøj helt mangler funktioner til projektstyring, men at det føles som en kamp at bruge funktionerne. Julia Rajic, driftschef hos Point Blank, oplevede dette på egen hånd med Resource Guru. "I teorien kunne det gøre alle de ting, vi havde brug for," siger hun, "men faktisk at få det til at gøre de ting føltes som at trække tænder ud."
Platformen manglede den daglige fleksibilitet, hendes team havde brug for — ting som nem håndtering af midlertidigt personale samt at kunne trække og slippe for at justere tidsplaner. Administrationen af det, forklarer hun, "var meget sværere, end den behøvede at være." Når et værktøj kræver så stor en indsats bare for at fungere, er det holdt op med at være en løsning.
Når manglende funktionalitet møder mislykket implementering
Skift af værktøj sker sjældent af én enkelt grund. Rajic beskriver en anden overgang, som hendes team gennemgik — fra monday.com til Asana — hvor beslutningen skyldtes en kombination af manglende funktioner og et sammenbrud i teamets opbakning. "En stor del af diskussionen om, hvorfor vi skulle væk fra monday, handlede om ressourcestyring," forklarer hun. "Det var ikke rigtig godt til ressourcestyring."
Men funktionalitet var ikke hele historien. Bureauet var aldrig blevet ordentligt introduceret til monday.com til at begynde med, hvilket betød, at implementeringen aldrig nåede det nødvendige niveau. "Der var meget af den slags: ‘Jeg kan ikke lide det her, det er nyt, jeg nægter at bruge det,’" siger Rajic. "Så implementeringen var ikke på det niveau, vi havde brug for, for at det kunne blive en succes." Når et værktøj svigter på begge fronter samtidig, bliver argumentet for at skifte svært at modsige. Men det giver også en vigtig læring: Hvis dit team ikke er villigt til at blive introduceret til et nyt værktøj, eller hvis din organisation ikke har ressourcerne til at bruge tid på introduktionen, kan det være bedre at holde fast i den nuværende løsning.
Implementeringen [af monday.com] var ikke på det niveau, vi havde brug for, for at det kunne blive en succes.
Når virksomhedsværktøjer bliver bureaukrati
Virksomhedsplatforme som Jira er bygget til kompleksitet — men kompleksiteten kan blive selve problemet. Ryan Gilbreath, teknisk projektleder hos RTS Labs, har set det ske. Om hvad der afgør, om et teams Jira-oplevelse bliver god eller dårlig, siger han: "Jeg føler virkelig, at det handler om, hvordan JIRA-administratoren konfigurerer det, og hvilke arbejdsgange de har på plads.” Når disse arbejdsgange er rigide, og adgang til dokumenter eller samarbejde med andre teams kræver, at man skal igennem den ene forhindring efter den anden, holder værktøjet op med at accelerere arbejdet og begynder i stedet at hæmme det.
"Hvis det er [Jiras opsætning], der sænker fremdriften," siger Gilbreath, "går jeg nok uden om Jira og bruger noget andet, sandsynligvis et regneark, hvis det er det hele." At en erfaren teknisk projektleder frivilligt ville gå tilbage til et regneark, siger meget om, hvor dårligt et overkonfigureret virksomhedsværktøj kan ramme ved siden af.
Hvis det er [Jiras opsætning], der sænker fremdriften, går jeg nok uden om Jira og bruger noget andet.
Hvor længe skal man vente, før man tager springet
Ikke alle problemer med et værktøj berettiger til et øjeblikkeligt skifte. Melody MacKeand, grundlægger af Melody MacKeand Consulting, anbefaler at give interne procesforbedringer en reel chance, før man konkluderer, at det er selve værktøjet, der er problemet. "Jeg forsøger at give det tre til seks måneder til at styre skibet i en anden retning," siger hun.
Hvis de samme problemer fortsætter efter denne periode, kan det være tid til at handle — men MacKeand anerkender også en mindre målbar grund til at foretage en ændring. "Hvis et team har brugt en platform i lang tid, for eksempel 10+ år, har de nogle gange bare brug for at skifte værktøjet for at føle, at der bliver lyttet til dem, eller at noget rent faktisk er anderledes. Og i det tilfælde er jeg helt åben over for at skifte værktøj." Nogle gange handler værdien ved at skifte ikke kun om driften — det er også et signal til teamet om, at ledelsen lytter.
Hvis et team har brugt en platform i lang tid, for eksempel 10+ år, har de nogle gange bare brug for at skifte værktøjet for at føle, at der bliver lyttet til dem.
Argumentet for at blive
Selvfølgelig er utilfredshed med et værktøj ikke altid en grund til at forlade det. Marissa Taffer, grundlægger og direktør for M. Taffer Consulting, kommer med et vigtigt modargument. "Jeg ønsker ikke at få nogen til at lære et nyt værktøj bare for forandringens skyld," siger hun. "Hvis der er en overbevisende grund til at skifte, er det fint. Men jeg vil ikke gennemføre ændringen, bare fordi jeg tror, at vi kunne organisere et projekt bedre i et andet system." Forstyrrelsen ved en værktøjsmigrering — tiden, oplæringen, modstanden — skal afvejes mod en konkret fordel. Marginale forbedringer er ikke nok.
Hvis der er en overbevisende grund til at skifte [værktøjer], er det fint. Men jeg vil ikke gennemføre ændringen, bare fordi jeg tror, at vi kunne organisere et projekt bedre i et andet system.
Temaet på tværs af alle disse perspektiver er det samme: Værktøjet findes for at tjene teamet, ikke omvendt. Når det forhold vender — når platformen begynder at opsluge energi, blokere for fremskridt eller udhule tilliden — er det på tide at handle. De projektledere, der navigerer godt i disse beslutninger, er ikke dem med de mest prangende teknologistakke. Det er dem, der ved, hvornår de skal blive, og hvornår de skal skifte.
Vil du have flere indsigter som disse? Opret en gratis DPM-konto for at høre fra flere eksperter som disse.
