Käyttöön otetut, käytöstä poistetut: projektinhallintaominaisuudet, joita tiimit lakkaavat käyttämästä
Ajan seuranta: Monet tiimit luopuvat ajanseurantaominaisuuksista, koska ne eivät vastaa hyvin todellisia projektin etenemisen seurantatarpeita.
Mukautetut sarakkeet: Liiallinen määrä mukautettuja sarakkeita voi monimutkaistaa työnkulkuja sekä heikentää tiimin tehokkuutta ja kokonaiskuvaa.
Tehtävien riippuvuudet: Tehtävien riippuvuudet epäonnistuvat usein käytännössä ylläpitohaasteiden ja todellisten häiriötilanteiden vuoksi.
Liiallinen automatisointi: Monimutkainen automatisointi voi hämmentää tiimejä, jolloin ne alkavat epäillä järjestelmää ja poikkeavat suunnitelluista työnkuluista.
Yksinkertaisuus voittaa: Paluu yksinkertaisiin ja tehokkaisiin menetelmiin johtaa usein parempiin projektinhallinnan tuloksiin kuin monimutkaisten ominaisuuksien käyttö.
Projektinhallintatyökalut sisältävät runsaasti ominaisuuksia, joiden tarkoitus on tuoda järjestystä monimutkaiseen työhön. Useammat ominaisuudet eivät kuitenkaan aina tarkoita parempia tuloksia. Kaikenkokoisissa tiimeissä toistuu sama kaava: lupaava ominaisuus otetaan käyttöön, sitä käytetään muutaman viikon ajan ja sitten se unohtuu hiljaisesti. Jäljelle jää järjestelmä, jota on vaikeampi käyttää kuin ennen, sekä tiimi, joka on kehittänyt omat kiertoratkaisunsa.
Kysyimme useilta alan ammattilaisilta, millaisia ominaisuuksia he ovat työssään kohdanneet: asetuksissa hyödyllisiltä vaikuttaneita, mutta käytännössä epäonnistuneita. Tässä ovat hyvät, huonot ja rumat puolet.
Ajankirjauksen lupaus (ja miksi se romahti)
Järjestelmään sisäänrakennettu ajankirjaus on yksi yleisimmin käyttöön otetuista – ja hylätyistä – ominaisuuksista esimerkiksi Jiran kaltaisissa työkaluissa. Thrive Agencyn kysynnänluonnin varapääjohtaja Aaron Whittaker otti Jiran sisäänrakennetun työaikakirjauksen käyttöön täsmälleen samoista syistä kuin useimmat tiimit. ”Otimme sen käyttöön, koska se vaikutti käytännölliseltä tavalta ymmärtää, miten työpanos jakautui maksullisen median, hakukoneoptimoinnin ja sisältötyön välillä”, hän kertoo. ”Tavoitteena oli selkeämpi raportointi ja kampanjoiden aikataulujen parempi suunnittelu.”
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
Se ei koskaan vakiintunut käyttöön. Whittakerin mukaan ongelmana oli perustavanlaatuinen ristiriita sen välillä, mitä ominaisuus mittaa ja mitä tiimien todellisuudessa tarvitsee tietää. ”Ominaisuus seuraa työtunteja, ei edistymistä”, hän selittää. ”Mainosten optimointiin tai laskeutumissivujen päivityksiin käytetyn viiden tai kuuden tunnin kirjaaminen ei kerro, paraniko suorituskyky tai onko työ lähellä valmistumista.”
Manuaalinen syöttövaatimus pahensi tilannetta. Kun ominaisuutta oli käytetty noin kuukauden ajan yli 170 työtehtävässä, vain noin 55:ssä oli käyttökelpoisia merkintöjä – eivätkä nekään olleet yhdenmukaisia. ”Ajan kirjaaminen tarkoitti siirtymistä päivän aikana useisiin tehtäviin, mikä keskeytti keskittymisen jatkuvasti”, Whittaker sanoo. ”Jonkin ajan kuluttua se tuntui vain asialta, joka oli pakko tehdä, ei sellaiselta, josta olisi oikeasti ollut apua.”
Ajan kirjaaminen tarkoitti siirtymistä päivän aikana useisiin tehtäviin, mikä keskeytti keskittymisen jatkuvasti. Jonkin ajan kuluttua se tuntui vain asialta, joka oli pakko tehdä, ei sellaiselta, josta olisi oikeasti ollut apua.
Tiimi luopui siitä ja palasi yksinkertaiseen taulupohjaiseen työnkulkuun. ”Ajankirjaus vaikutti hyödylliseltä käyttöönoton aikana, mutta todellisissa työnkuluissa se toisti näkyvyyden, joka meillä jo oli, ja lisäsi kitkaa parantamatta työn toimittamista.”
Mukautetut työnkulkusarakkeet: kun joustavuudesta tulee rasite
Mukautetut sarakkeet tuntuvat hyvän prosessiajattelun luonnolliselta jatkeelta. Outreach.io:n perustaja ja toimitusjohtaja Scott Davis oppi kantapään kautta, että ominaisuus voi nopeasti riistäytyä hallinnasta. ”Otimme käyttöön Jiran Scrum-taulujen mukautettujen sarakkeiden lisäämisen muutama vuosi sitten työnkulkumme läpinäkyvyyden parantamiseksi”, hän kertoo. ”Ominaisuuden käyttöönotto kesti alle minuutin. Sen muuttaminen piilossa olevaksi yleiskustannukseksi vei viikkoja.”
Ominaisuuden käyttöönotto kesti alle minuutin. Sen muuttaminen piilossa olevaksi yleiskustannukseksi vei viikkoja
Yhtenä ”Tarkistettavaa”-sarakkeena Keskeneräinen- ja Valmis-sarakkeiden välissä alkanut kokeilu moninkertaistui nopeasti. ”Ennen kuin huomasimmekaan, jokaiselle tiimille oli oma tarkistussarakkeensa”, Davis sanoo. Tuotetiimi lisäsi sarakkeen sidosryhmien hyväksyntää varten, ja laadunvarmistustiimi lisäsi vielä yhden ylimääräisiä tarkistuksia varten. ”Jokainen Scrum-taulu näytti erilaiselta, eikä niissä ollut helppo navigoida. Ihmisten täytyi tarkistaa taulujen määritykset vain tietääkseen, miten kyseistä työtehtävää siirretään.”
Kustannukset näkyivät datassa. ”Tiimimme läpimenoaika suuren työmäärän sprinteissä kasvoi jatkuvasti keskimäärin kahdeksasta päivästä 10,75 päivään, mikä johtui pääasiassa siitä, ettei ollut selvää, mitä kukin ylimääräinen mukautettu tilakenttä tarkoitti”, Davis selittää. ”Retrospektiivien palautemittarit olivat täynnä kommentteja ’ajan tuhlaamisesta tilojen nimistä väittelemiseen’.”
Hänen neuvonsa kaikille sarakkeiden mukauttamista harkitseville tiimeille on seuraava: ”Käsittele jokaista lisättyä saraketta teknisenä velkana. Ilman hyvää roolijakoa ja pätevää syytä poiketa oletuksista työn skaalaaminen on vaikeampaa kuin oletustyönkulun muokkaaminen. Useimmat tiimit luopuvat hiljaisesti ylimääräisistä sarakkeista muutaman sprintin jälkeen.”
Tehtävien riippuvuudet: teoriassa selkeitä, käytännössä toimimattomia
Tehtävien riippuvuudet ovat yksi minkä tahansa projektinhallintatyökalun houkuttelevimmista ominaisuuksista. Logiikka on järkevä: tehtävät linkitetään toisiinsa, jotta viivästykset tulevat automaattisesti esiin ja käynnistävät oikeat toimenpiteet. Käytännössä ominaisuus kuitenkin romahtaa tosielämän vaihtelun painon alla.
Dmitrii Malashkin, Born to Moven perustaja ja toimitusjohtaja, otti käyttöön riippuvuudet ja edistyneet tehtävien valmistumisen automaatiot Asanassa — ja myöhemmin monday.comissa — pitääkseen projektien aikataulut ajan tasalla ja hallinnassa. ”Todellisuudessa tiimimme jäsenet eivät kuitenkaan käyttäneet niitä juuri lainkaan käyttöönottoa seuranneen ensimmäisen viikon jälkeen”, hän sanoo. Syy oli suoraviivainen: ”Riippuvuuksien ja automaatioiden ylläpito on kokonainen työ itsessään, eikä kenenkään kuuluisi tai oikeastaan haluaisi tehdä sitä, varsinkaan silloin, kun niiden käyttöä ei valvota.”
Riippuvuuksien ja automaatioiden ylläpito on kokonainen työ itsessään, eikä kenenkään kuuluisi tai oikeastaan haluaisi tehdä sitä, varsinkaan silloin, kun niiden käyttöä ei valvota.
Kun tosielämän häiriöt iskivät — puuttuva lupa, viime hetken aikataulumuutos tai asiakkaan aikataulun yhteensopimattomuus — ketju katkesi. ”Yksi vikaantumispiste aiheuttaa koko riippuvuusketjun rikkoutumisen”, Malashkin selittää. ”Työnkulku päätyy lähettämään ihmisille tulvan yleisiä tilapäivityspyyntöjä, minkä seurauksena kaikki alkavat mykistää ne.” Tuloksena oli kaikkialla ilmenevä ilmoitusväsymys.
Lopulta hänen tiiminsä hylkäsi ominaisuuden kokonaan. ”Projektipäällikkömme ja työryhmien vetäjät palasivat lopulta litteisiin, ei-hierarkkisiin tehtävälistoihin sekä ryhmäkeskusteluihin ensisijaisena tapanaan koordinoida työtä ja saada enemmän aikaan.”
Myös The Monterey Companyn toimitusjohtaja Eric Turney näki saman kaavan. ”Ominaisuus, jonka olen nähnyt kuolevan kosketuksessa todellisten työnkulkujen kanssa, on projektinhallintatyökalun tehtävien riippuvuudet”, hän sanoo. ”Se ei koskaan juurtunut, koska prioriteetit muuttuivat liian usein, ylläpito oli ärsyttävää ja järjestelmä vanheni nopeammin kuin kukaan halusi ylläpitää sitä.” Hänen tiiminsä palasi yksinkertaisempaan vastuunjakoon, selkeisiin määräaikoihin ja suoraan viestintään. ”Ominaisuus vaikutti älykkäältä käyttöönottovaiheessa, mutta tosielämässä se lisäsi hallinnollista työtä antamatta meille riittävästi lisää hallintaa sen oikeuttamiseksi.”
[Tehtävien riippuvuudet] eivät koskaan juurtuneet, koska prioriteetit muuttuivat liian usein, ylläpito oli ärsyttävää ja järjestelmä vanheni nopeammin kuin kukaan halusi ylläpitää sitä.
Liiallinen automaatio: kun järjestelmä toimii tiimiä vastaan
Automaatio on yksi nykyaikaisten projektinhallinta-alustojen suurimmista myyntivalteista — ja yksi helpoimmin liialliseksi menevistä asioista. Global Sound Groupin toimitusjohtaja Tom Jauncey kuvailee tuttua ansaa: ”Yksi asia, joka näyttää paperilla hyvältä mutta ei todellisuudessa toimi, on se, että teemme asioista liian automaattisia monday.comin kaltaisissa työkaluissa. Tiimin voi olla liian monimutkaista seurata sitä.”
Yksi asia, joka näyttää paperilla hyvältä mutta ei todellisuudessa toimi, on se, että teemme asioista liian automaattisia monday.comin kaltaisissa työkaluissa. Tiimin voi olla liian monimutkaista seurata sitä.
Kun automaatio muuttuu liian monikerroksiseksi, tiimit lakkaavat luottamasta siihen. ”Ihmiset alkavat jättää järjestelmän huomiotta tai tehdä asiat omalla tavallaan, koska sitä vaikuttaa liian vaikealta ymmärtää tai heistä tuntuu, että se jarruttaa heitä”, Jauncey sanoo. Suunniteltu työnkulku ja todellinen työnkulku erkanevat toisistaan. ”Tapa, jolla suunnittelemme työn, näyttää hienolta suunnitteluvaiheessa. Se ei kuitenkaan vastaa tiimin päivittäistä työskentelytapaa.”
Oppi, johon hänen tiiminsä päätyi, oli yksinkertainen: "Paras tapa tehdä asioita on se, jota ihmiset todella käyttävät, ei se, jossa on eniten ominaisuuksia."
Prosentuaaliset valmistumisastetiedot ja edistymisen harha
Jotkin ominaisuudet eivät epäonnistu siksi, että ne ovat liian monimutkaisia — ne epäonnistuvat, koska ne pelkistävät liikaa. Nikita Patil Brennan, vanhempi projektipäällikkö, nostaa prosentuaaliset valmistumisastetiedot tästä hyväksi esimerkiksi. "Yksi MS Projectissa/Asanassa näkyvä projektinhallinnan ominaisuus on tehtävien valmistumisprosentti", hän sanoo. "Se ei kerro koko totuutta — 71 % voi tarkoittaa, että tehtävät ovat pääosin valmiita, tehtävät ovat vaarassa, tehtävät ovat estyneitä jne." Yksi luku häivyttää asiayhteyden, jota tiimit tarvitsevat voidakseen toimia. Edistyminen ei ole sama asia kuin projektin tila, eikä mittari, joka ei pysty erottamaan näitä kahta toisistaan, anna kenellekään hyödyllistä tietoa.
Se [tehtävien valmistumisprosentti] ei kerro koko totuutta — 71 % voi tarkoittaa, että tehtävät ovat pääosin valmiita, tehtävät ovat vaarassa, tehtävät ovat estyneitä jne.
Liikaa luvanneet ja liian vähän tuottaneet tekoälyominaisuudet
Kun tekoälyominaisuuksia on otettu käyttöön projektinhallinta-alustoilla, esittelyissä nähtyjen tulosten ja todellisen hyödyn välinen kuilu on aiheuttanut toistuvasti turhautumista. Megan Cotterman, osa-aikainen projektipäällikkö ja operatiivisen toiminnan konsultti, kohtasi tämän itse. "Koin tämän, kun Asana julkaisi tekoälytoimintonsa ensimmäisen kerran", hän sanoo. "Esitin kysymyksiä tietyistä projekteista tietyissä yhteyksissä, ja minun oli todella vaikea löytää etsimääni."
Esitin [Asanan tekoälylle] kysymyksiä tietyistä projekteista tietyissä yhteyksissä, ja minun oli todella vaikea löytää etsimääni.
Ongelma ei koske ainoastaan Asanaa — se kuvastaa laajempaa haastetta tekoälyominaisuuksissa, jotka on rakennettu yleisiä käyttötapauksia varten, mutta joita ei ole vielä koulutettu ymmärtämään todellisen projektidatan rakennetta ja hakutapaa riittävän yksityiskohtaisesti ja vivahteikkaasti.
Paluu perusteisiin — yksinkertaisuuden puolesta
Kaikissa ominaisuusluokissa uudelleen tasapainon löytäneet tiimit tekivät sen yksinkertaistamalla. James Dyble tiivistää ajatuksen, johon monet alan ammattilaiset lopulta päätyvät. "Vannoin ennen digitaalisten tehtävienhallintatyökalujen nimeen ja olin vakuuttunut siitä, että kaiken pitäisi olla sovelluksessa", hän sanoo. "Sitten huomasin tarttuvani yhä uudelleen kynään ja paperiin."
Vannoin ennen digitaalisten tehtävienhallintatyökalujen nimeen ja olin vakuuttunut siitä, että kaiken pitäisi olla sovelluksessa. Sitten huomasin tarttuvani yhä uudelleen kynään ja paperiin.
Hänen ratkaisunsa ei ollut luopua digitaalisista työkaluista kokonaan, vaan käyttää niitä harkitummin. "Nyt olen päätynyt yhdistelmäratkaisuun: pidän tärkeimmät projektini ja luetteloni digitaalisessa työkalussa, mutta hallitsen päivittäisiä prioriteettejani yksinkertaisella muistilapulla. Asioiden merkitsemisessä tehdyiksi yksi kerrallaan on jotain tyydyttävää."
Tehokkain projektinhallintajärjestelmä ei ole se, jossa on eniten ominaisuuksia käytössä. Se on se, jota tiimi todella käyttää.
Haluatko lisää tällaisia näkemyksiä? Luo ilmainen DPM-tili, niin kuulet lisää näiden kaltaisilta asiantuntijoilta.
