Påslagna men bortkopplade: Projektledningsfunktionerna som team slutar använda
Tidrapportering: Många team överger tidrapporteringsfunktioner eftersom de inte är tillräckligt anpassade till de verkliga behoven av att följa projektens framsteg.
Anpassade kolumner: För många anpassade kolumner kan komplicera arbetsflöden och minska teamets övergripande effektivitet och tydlighet.
Aktivitetsberoenden: Aktivitetsberoenden misslyckas ofta i praktiken på grund av underhållsproblem och störningar i verkligheten.
Överautomatisering: Komplex automatisering kan förvirra team, vilket leder till misstro och att man avviker från de avsedda arbetsflödena.
Enkelhet vinner: Att återgå till enkla och effektiva metoder leder ofta till bättre projektledningsresultat än komplexa funktioner.
Projektledningsverktyg är fullpackade med funktioner som är utformade för att skapa ordning i komplext arbete. Men fler funktioner leder inte alltid till bättre resultat. I team av alla storlekar upprepas samma mönster: en lovande funktion aktiveras, används i några veckor och dör sedan stilla ut. Kvar blir ett system som är svårare att använda än tidigare och ett team som har hittat egna lösningar.
Vi frågade flera yrkesverksamma vilka funktioner de hade stött på i praktiken som verkade användbara vid konfigurationen men misslyckades i verkligheten. Här är det goda, det dåliga och det fula.
Löftet med tidsregistrering (och varför det gick om intet)
Inbyggd tidsregistrering är en av de funktioner som oftast aktiveras – och överges – i verktyg som Jira. Aaron Whittaker, VP för efterfrågegenerering på Thrive Agency, aktiverade Jiras inbyggda arbetslogg av exakt samma skäl som de flesta team gör. "Vi aktiverade den eftersom den verkade vara ett praktiskt sätt att förstå hur arbetsinsatsen fördelades mellan betalda medier, SEO och innehållsarbete", säger han. "Målet var tydligare rapportering och bättre planering av kampanjernas tidslinjer."
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
Den fick aldrig fäste. Whittaker pekar på en grundläggande skillnad mellan vad funktionen mäter och vad team faktiskt behöver veta. "Funktionen registrerar timmar, inte framsteg", förklarar han. "Att logga fem eller sex timmar på annonsoptimering eller uppdateringar av landningssidor säger inte om resultatet förbättrades eller om arbetet närmar sig slutförande."
Kravet på manuell inmatning gjorde saken värre. Efter att ha kört funktionen i ungefär en månad för mer än 170 arbetsuppgifter hade bara omkring 55 användbara registreringar – och de saknade konsekvens. "Att registrera tid innebar att hoppa mellan flera uppgifter under dagen, vilket hela tiden bröt koncentrationen", säger Whittaker. "Efter ett tag kändes det bara som något man var tvungen att göra, inte som något som faktiskt hjälpte."
Att registrera tid innebar att hoppa mellan flera uppgifter under dagen, vilket hela tiden bröt koncentrationen. Efter ett tag kändes det bara som något man var tvungen att göra, inte som något som faktiskt hjälpte.
Hans team övergav funktionen och återgick till ett enkelt tavellbaserat arbetsflöde. "Tidsregistrering verkade användbar vid konfigurationen, men i verkliga arbetsflöden duplicerade den den överblick vi redan hade och skapade friktion utan att förbättra leveransen."
Anpassade arbetsflödeskolumner: när flexibilitet blir en belastning
Anpassade kolumner känns som en naturlig förlängning av ett bra processtänkande. Scott Davis, grundare och vd för Outreach.io, lärde sig den hårda vägen att funktionen snabbt kan spåra ur. "Vi aktiverade 'lägg till anpassade kolumner' i Jiras scrumtavlor för några år sedan för att skapa transparens i vårt arbetsflöde", säger han. "Vi aktiverade funktionen på mindre än en minut. Vi ägnade veckor åt att göra den till en dold kostnad."
Vi aktiverade funktionen på mindre än en minut. Vi ägnade veckor åt att göra den till en dold kostnad
Det som började som en enda kolumn med namnet "Att verifiera" mellan Pågående och Klart mångdubblades snabbt. "Innan vi visste ordet av fanns det en granskningskolumn för varje team", säger Davis. Produktteamet lade till en kolumn för intressentgodkännande och QA lade till ytterligare en för extra kontroller. "Varje scrumtavla såg annorlunda ut och var inte lätt att navigera i. Man måste kontrollera tavlans konfigurationer bara för att veta hur ärendet ska flyttas."
Kostnaden syntes i datan. "Vårt teams cykeltid under våra sprintar med hög arbetsvolym sprintar fortsatte att öka från 8 dagar till i genomsnitt 10.75 dagar, och det berodde främst på att det var oklart vad varje extra anpassat statusfält betydde", förklarar Davis. "Vår återkopplingsstatistik från retrospektiven var full av 'bortkastad tid på att diskutera statusnamn'."
Hans råd till alla team som överväger att anpassa kolumnerna: "Betrakta varje tillagd kolumn som teknisk skuld. Utan god rollstyrning och ett bra skäl att avvika från standardinställningarna blir det svårare att skala arbetet än att ändra standardarbetsflödet. De flesta team kommer tyst att överge de extra kolumnerna efter några sprintar."
Uppgiftsberoenden: rena i teorin, trasiga i praktiken
Uppgiftsberoenden är en av de mest tilltalande funktionerna i alla projekthanteringsverktyg. Logiken är sund: länka samman uppgifter så att förseningar automatiskt synliggörs och utlöser rätt åtgärder. I praktiken tenderar funktionen att falla samman under tyngden av verklighetens variationer.
Dmitrii Malashkin, grundare & vd på Born to Move, implementerade beroenden och avancerade automatiseringar för slutförande av uppgifter i Asana — och senare i monday.com — för att hålla projektens tidslinjer uppdaterade och under kontroll. "Verkligheten var dock att våra teammedlemmar aldrig riktigt använde dem efter den första veckan efter implementeringen", säger han. Anledningen var enkel: "Att underhålla dina beroenden och automatiseringar är ett helt eget arbete som ingen förväntas eller faktiskt vill utföra, särskilt när det inte är obligatoriskt."
Att underhålla dina beroenden och automatiseringar är ett helt eget arbete som ingen förväntas eller faktiskt vill utföra, särskilt när det inte är obligatoriskt.
När störningar i verkligheten inträffade — ett saknat tillstånd, en schemaändring i sista minuten eller en konflikt med kundens tillgänglighet — bröts kedjan. "Det gör att en enda felpunkt bryter hela beroendekedjan", förklarar Malashkin. "Arbetsflödet börjar skicka en mängd generiska förfrågningar om statusuppdateringar, vilket sedan leder till att alla tystar dem." Resultatet blev en utbredd notifieringströtthet.
Hans team övergav till slut funktionen helt. "Våra projektledare och arbetsledare återgick till platta, icke-hierarkiska uppgiftslistor samt gruppchattar som sitt huvudsakliga arbetssätt för att samordna insatser och få mer arbete gjort."
Eric Turney, vd på The Monterey Company, såg samma mönster. "Funktionen som jag har sett dö vid kontakt med verkliga arbetsflöden är uppgiftsberoenden i ett projekthanteringsverktyg", säger han. "Den fungerade aldrig eftersom prioriteringarna ändrades för ofta, underhållet var irriterande och systemet blev inaktuellt snabbare än någon ville underhålla det." Hans team föll tillbaka på enklare ansvarsfördelning, tydliga förfallodatum och direkt kommunikation. "Funktionen såg smart ut i konfigurationsfasen, men i verkligheten skapade den administration utan att ge oss tillräckligt mycket kontroll tillbaka för att motivera den."
Uppgiftsberoenden fungerade aldrig eftersom prioriteringarna ändrades för ofta, underhållet var irriterande och systemet blev inaktuellt snabbare än någon ville underhålla det.
Överautomatisering: när systemet motarbetar teamet
Automatisering är ett av de största försäljningsargumenten för moderna projekthanteringsplattformar — och en av de enklaste sakerna att överdriva. Tom Jauncey, verkställande direktör på Global Sound Group, beskriver en välbekant fälla: "En sak som ser bra ut på papperet men som inte fungerar särskilt bra i praktiken är när vi gör saker alltför automatiska i verktyg som monday.com. Det kan bli för komplicerat för teamet att följa."
En sak som ser bra ut på papperet men som inte fungerar särskilt bra i praktiken är när vi gör saker alltför automatiska i verktyg som monday.com. Det kan bli för komplicerat för teamet att följa.
När automatiseringen blir för skiktad slutar teamen att lita på den. "Det som händer är att människor börjar ignorera systemet eller göra saker på sitt eget sätt eftersom det verkar för svårt att förstå eller känns som att det håller dem tillbaka", säger Jauncey. Det planerade arbetsflödet och det faktiska arbetsflödet skiljer sig åt. "Sättet vi planerar arbetet på ser bra ut när vi planerar det. Det stämmer inte riktigt överens med hur teamet arbetar från dag till dag."
Lärdomen som hans team kom fram till var enkel: "Det bästa sättet att göra saker på är det sätt som människor faktiskt använder, inte det sätt som har flest funktioner."
Fält för procentuell färdigställandegrad och illusionen av framsteg
Vissa funktioner misslyckas inte för att de är för komplexa — de misslyckas för att de är för förenklade. Nikita Patil Brennan, Senior Project Manager, lyfter fram fält för procentuell färdigställandegrad som ett tydligt exempel. "En funktion för projektledning som finns i MS Project/Asana är procentuell färdigställandegrad för uppgifter", säger hon. "Den berättar inte hela historien — 71 % kan innebära att uppgifterna till största delen är slutförda, att uppgifter är i riskzonen, att uppgifter är blockerade och så vidare." Ett enda tal plattar till den kontext som team behöver för att kunna agera. Framsteg är inte samma sak som hälsa, och ett mått som inte kan skilja mellan de två ger ingen användbar information.
Den [% färdigställandegrad för uppgifter] berättar inte hela historien — 71 % kan innebära att uppgifterna till största delen är slutförda, att uppgifter är i riskzonen, att uppgifter är blockerade och så vidare.
AI-funktioner som lovade för mycket men levererade för lite
När AI-funktioner har lanserats på projektledningsplattformar har skillnaden mellan demonstrationsprestanda och praktisk användbarhet återkommande varit en källa till frustration. Megan Cotterman, fristående projektledare och verksamhetskonsult, fick uppleva detta på nära håll. "Jag hade den upplevelsen när Asana först lanserade sin AI-funktion", säger hon. "Jag ställde frågor om vissa projekt i vissa sammanhang och hade väldigt svårt att hitta det jag frågade efter."
Jag ställde frågor [till Asana AI] om vissa projekt i vissa sammanhang och hade väldigt svårt att hitta det jag frågade efter.
Problemet är inte unikt för Asana — det speglar en bredare utmaning med AI-funktioner som är byggda för allmänna användningsområden men ännu inte har tränats på den specificitet och nyansrikedom som kännetecknar hur verkliga projektdata struktureras och söks.
Tillbaka till grunderna — argumenten för enkelhet
Inom varje funktionskategori lyckades de team som återfick fotfästet genom att förenkla. James Dyble fångar den känsla som många yrkesverksamma till slut kommer fram till. "Jag brukade svära på digitala uppgiftshanterare och var övertygad om att allt skulle finnas i en app", säger han. "Sedan kom jag på mig själv med att gång på gång sträcka mig efter penna och papper."
Jag brukade svära på digitala uppgiftshanterare och var övertygad om att allt skulle finnas i en app. Sedan kom jag på mig själv med att gång på gång sträcka mig efter penna och papper.
Hans lösning var inte att helt överge digitala verktyg, utan att vara mer medveten om vad de används till. "Nu har jag landat i ett hybridupplägg: Jag har mina större projekt och listor i ett digitalt verktyg, men hanterar mina dagliga prioriteringar på en enkel post-it-lapp. Det är något tillfredsställande med den fysiska handlingen att bocka av saker allt eftersom."
Det mest effektiva projektledningssystemet är inte det där flest funktioner är aktiverade. Det är det som teamet faktiskt kommer att använda.
Vill du ha fler insikter som dessa? Skapa ett kostnadsfritt DPM-konto för att höra från fler experter som dessa.
