Työkalut, joita tiimit joutuvat jatkuvasti säätämään liikaa
Joustavuusongelma: Vaikka projektinhallintatyökalujen joustavuus on houkuttelevaa, se voi johtaa liialliseen monimutkaisuuteen ja tehottomuuteen.
Mukauttamisen ansa: Suosiostaan huolimatta Monday.comin ja Notionin kaltaiset työkalut voivat hukuttaa käyttäjät liiallisiin mukautusvaihtoehtoihin.
Raskaan rakentamisen työkalut: Workfrontin ja ClickUpin kaltaiset monimutkaiset alustat vaativat huomattavan ennakkopanostuksen, jotta niitä voidaan käyttää tehokkaasti.
Jäykät työnkulut: Jiran tai Wriken kaltaisten työkalujen liiallinen hallinta voi saada tiimit kiertämään prosesseja, mikä heikentää tuottavuutta.
Inhimillinen toimintamalli: Työkalujen keskeinen ongelma ei ole itse ohjelmisto, vaan tiimien taipumus määrittää ne liian monimutkaisiksi, mikä vaikeuttaa työnkulkuja.
Projektinhallintatyökaluja myydään usein joustavuuden lupauksella – ajatuksella, että alusta, joka on riittävän tehokas käsittelemään mitä tahansa työnkulkua, tekee mistä tahansa tiimistä tehokkaamman. Monien tiimien kohdalla tämä lupaus kuitenkin kääntyy itseään vastaan. Mitä enemmän työkalu pystyy tekemään, sitä houkuttelevampaa on saada se tekemään kaikkea. Ja jossain mukautettavien kenttien, sisäkkäisten alitehtävien ja värikoodattujen koontinäyttöjen keskellä työkalu lakkaa palvelemasta työtä ja alkaa muodostua työksi itsessään.
Ongelma ei ole yksittäisessä alustassa. Kyseessä on eri kategorioissa toistuva ilmiö: liian paljon vapautta saavat tiimit rakentavat järjestelmiä, joita on liian monimutkaista käyttää, kun taas jäykkiin määrityksiin sidotut tiimit keksivät kokonaan tapoja kiertää ne. Eniten kitkaa aiheuttavat työkalut eivät aina ole huonoimpia työkaluja – usein ne ovat tehokkaimpia työkaluja, joita käytetään ilman rajoituksia.
Mukauttamisen ansa
Jotkin markkinoiden suosituimmista projektinhallinta-alustoista ovat myös useimmiten ylisäädettyjä. Monday.com ja Notion ovat kaksi työkalua, jotka alan ammattilaiset nostavat jatkuvasti esiin – eivät siksi, että työkalut olisi suunniteltu huonosti, vaan koska niiden joustavuus houkuttelee liialliseen rakenteluun.
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
M. Taffer Consultingin perustaja ja toimitusjohtaja Marissa Taffer näkee tämän toistuvasti Monday.comin käytössä. Hän huomauttaa, että "Mondayn kaltainen työkalu tai jokin hieman mukautettavampi työkalu on loistava, mutta siitä tulee helposti ylivoimainen, koska sillä voi tehdä niin monia asioita, että ihmisille annetaan liikaa vapautta ja he alkavat rakentaa järjestelmää tarpeettoman monimutkaiseksi." Siksi hän suosii työkaluja, joissa on sisäänrakennettuja rajoitteita: hänen mukaansa Asana "tuntuu sopivan juuri oikeanlaiselta rajoitteelta".
Ihmisille annetaan liikaa vapautta, ja he alkavat rakentaa järjestelmää tarpeettoman monimutkaiseksi.
Notion saa osakseen samanlaista kritiikkiä. Fox Consultingin vanhempi projektipäällikkö ja operatiivinen asiantuntija Matthew Fox kuvailee sitä työkaluksi, joka houkuttelee innokkaita käyttäjiä, jotka sitten eksyvät käyttöönottoprosessiin: "Monet pitävät Notionista, mutta Notion on kuin karkkikauppa, jossa voit tehdä kaikkea haluamaasi, mutta käytät sitten niin paljon aikaa sen määrittämiseen, ettet oikeastaan saa työtä tehtyä." Mukautettavuudesta tulee itse tuote – ja varsinainen projektityö jää taka-alalle.
Raskaan käyttöönoton työkalut
Erillinen työkalukategoria ei ainoastaan houkuttele rakentamaan järjestelmää tarpeettoman monimutkaiseksi – se edellyttää sitä. Workfrontin, ClickUpin ja HubSpotin tukipalveluratkaisun kaltaiset alustat on rakennettu monimutkaisuutta varten, ja organisaatiot, jotka aliarvioivat käyttöönottoon tarvittavan panostuksen, päätyvät usein järjestelmiin, jotka toimivat teknisesti mutta joita on käytännössä mahdotonta käyttää.
Melody MacKeand Consultingin perustaja Melody MacKeand nostaa sekä Workfrontin että ClickUpin esiin työkaluina, jotka vaativat huomattavaa ennakkotyötä. Hänen kokemuksensa mukaan "rakentamisen osalta todella raskaat työkalut, kuten Workfront, edellyttävät erittäin merkittävää perehdytystä ja rakentamista." ClickUp aiheuttaa samanlaisia haasteita – "usein tarvitaan konsultti tekemään rakentaminen", ja "olen nähnyt organisaatioiden menevän ClickUpin kanssa vikaan silloin, kun ne eivät palkanneet ketään auttamaan rakentamisessa ja rakensivat järjestelmän vähemmän ihanteellisella tavalla."
Rakentamisen osalta todella raskaat työkalut, kuten Workfront, edellyttävät erittäin merkittävää perehdytystä ja rakentamista.
Yritystason työkalut voivat viedä ongelman vielä pidemmälle. Palo Alto Networksin vanhempi ohjelmapäällikkö Yonelly Gutierrez kuvailee kokemustaan Planview'sta varoittavana esimerkkinä siitä, mitä tapahtuu, kun työkalun käyttöliittymä kehittyy tiimin käyttökykyä nopeammin: "Se oli kamalaa. En ymmärtänyt, miten työkalua käytetään. Esihenkilömme joutui istumaan koko tiimin kanssa ja näyttämään meille, miten sitä käytetään... Hän teki päivitykset itse aina, kun hänen piti viedä projektia eteenpäin, koska emme osanneet käyttää sitä." Kun työkalu on niin monimutkainen, että esihenkilöt alkavat tehdä manuaalisia kiertoratkaisuja vain pitääkseen projektit liikkeessä, järjestelmä on epäonnistunut perustehtävässään.
Fox on nähnyt vastaavan ristiriidan HubSpotin kanssa toimistoympäristöissä. ”On yksi toimisto, jonka kanssa olen työskennellyt ja jossa HubSpotista pidetään kovasti”, hän kertoo, mutta ”HubSpotilla on tukipalvelutarjonta, joka sopii toimistoille todella huonosti. Se vaatii valtavasti mukauttamista ja valtavasti määrittämistä.” Alustan ydintuotteen arvostus ei automaattisesti ulotu kaikkiin sen tarjoamiin ominaisuuksiin – ja yhteensopimattoman ratkaisun väkisin sovittaminen maksaa usein enemmän kuin siitä on hyötyä.
Kun jäykät työnkulut muodostuvat esteeksi
Liiallinen määrittäminen ei johdu ainoastaan liiallisesta vapaudesta. Se voi johtua myös liiallisesta kontrollista. Kun ylläpitäjät lukitsevat työkalut tiukkojen työnkulkujen ja liiallisten prosessivaatimusten taakse, tiimit eivät muutu tuottavammiksi – ne keksivät tapoja kiertää työkalun kokonaan.
Jira yhdistetään useimmiten tähän ongelmatilanteeseen. RTS Labsin tekninen projektipäällikkö Ryan Gilbreath syyttää suoraan määritysvalintoja: ”Koen todella, että kyse on siitä, miten Jiran ylläpitäjä määrittää sen ja millaiset työnkulut hän ottaa käyttöön. Jos työnkulku on hyvin jäykkä ja minun täytyy tehdä tämä ja tuo päästäkseni käsiksi tiettyihin asiakirjoihin tai tiimeihin, ja se hidastaa etenemistä, menen todennäköisesti Jiran ulkopuolelle.” Ongelma ei ole itse työkalussa – vaan sen sisällä tehdyissä valinnoissa.
Koen todella, että kyse on siitä, miten Jiran ylläpitäjä määrittää sen ja millaiset työnkulut hän ottaa käyttöön.
Wrike edustaa samasta ongelmasta toista versiota, mutta seuraukset ovat erilaiset. Point Blankin operatiivinen johtaja Julia Rajic kuvaa, kuinka Wriken täydellinen integrointi erittäin yksityiskohtaisiin malleihin ja jäykkiin tehtävärakenteisiin heikensi vähitellen hänen toimistonsa kykyä ajatella ja työskennellä joustavasti: ”Siirryin erillisistä järjestelmistä ja työkaluista täysin, täysin integroituun kokonaisuuteen, jossa... Tilanne meni siihen pisteeseen, että ihmiset sanoivat: en tee sitä, ennen kuin minulla on sitä varten tehtävä.” Rakenteen oli tarkoitus tuoda järjestystä, mutta lopulta se loi riippuvuutta. Kuten Rajic asian ilmaisee: ”jos rakenne on liian jäykkä, yksityiskohtia on liikaa ja työkalusta ollaan liikaa riippuvaisia, se voi rajoittaa kykyäsi toimia sen ulkopuolella.”
Kun luova vapaus pelottaa
Kaikki liiallinen määrittäminen ei johdu ominaisuuksien runsaudesta tai tiukasta ylläpitäjän kontrollista. Joskus istuntoa vetävä henkilö rakentaa liikaa. Miron kaltaiset vapaamuotoiset työkalut antavat valtavan luovan vallan sille, joka toimii fasilitaattorina – eikä tätä valtaa aina käytetä maltillisesti.
Caylentin vanhempi asiakkuusjohtaja Alexa Alfonso on nähnyt Miron toimivan molemmilla tavoilla. ”Uskon, että Miro voi olla sitä”, hän sanoo, kun häneltä kysytään, kuuluuko se ylisuuriksi suunniteltujen työkalujen kategoriaan. ”Kaikki riippuu siitä, kuka taulua vetää ja mitä hän haluaa sillä tehdä... Olen nähnyt liian suunnitellun ja liian monimutkaisen Miron, joka pelotti ihmiset... ehkä fasilitaattori suunnitteli sen liian monimutkaiseksi, mikä on tavallaan tällaisen työkalun hienous ja heikkous, koska siitä voi tehdä juuri sellaisen kuin haluaa.” Työkalu, joka voi olla mitä tahansa, voi myös muuttua liian raskaaksi – ja kun osallistujat saapuvat taululle, jota he eivät osaa käyttää, yhteistyö, jota työkalun oli tarkoitus mahdollistaa, katoaa.
Olen nähnyt liian suunnitellun ja liian monimutkaisen Miron, joka pelotti ihmiset… ehkä fasilitaattori suunnitteli sen liian monimutkaiseksi, mikä on tavallaan tällaisen työkalun hienous ja heikkous
Todellinen ongelma ei yleensä ole ohjelmisto
Kaikkien näiden esimerkkien taustalla ei ole minkään yksittäisen alustan puute. Kyse on johdonmukaisesta inhimillisestä toimintamallista: kun ihmisille annetaan mahdollisuus lisätä jotakin, he lähes aina lisäävät. Lisää kenttiä, lisää automaatioita, lisää rakennetta, lisää tauluja – kunnes työkalusta, jonka piti vähentää kitkaa, on tullut sen ensisijainen aiheuttaja.
Ratkaisu tarkoittaa harvoin alustan vaihtamista. Se tarkoittaa sen hetken tunnistamista, jolloin määrittäminen muuttuu hyödyllisestä liialliseksi, sekä kurinalaisuutta lopettaa rakentaminen ennen kuin järjestelmä alkaa toimia niiden ihmisten etuja vastaan, joita sen oli tarkoitus palvella.
Haluatko lisää tällaisia näkemyksiä? Rekisteröidy maksuttomalle DPM-tilille kuullaksesi lisää samanlaisilta asiantuntijoilta.
