SMART-projektitavoitteet (Mackenzie Dysart Reason Onesta)

Lue litterointi:

Kokeilemme podcastiemme litterointia ohjelmiston avulla. Suokaa anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole sataprosenttisen tarkka.

Ben Aston:

Tervetuloa DPM-podcastiin. Menemme teorian tuolle puolen ja annamme neuvoja, jotka toimivat parempien digitaalisten projektien johtamisessa. Kiitos, että kuuntelet. Olen Ben Aston, The Digital Project Managerin perustaja.

Tietävätkö tiimisi, miksi he tekevät sitä, mitä tekevät? Entä asiakkaasi? Onko asia kristallinkirkas? Onko se täsmällinen? Onko se mitattava? Onko se saavutettavissa? Onko se realistinen? Onko se aikaan sidottu? Ovatko kaikki samalla sivulla sen suhteen, miltä projektin onnistuminen näyttää?

Muuttuisiko projektin kulku, jos se olisi hieman selkeämpi? Kyllä? Jatka siis tämän SMART-projektitavoitteiden luomista käsittelevän podcastin kuuntelemista. Se auttaa luomaan yhteisen suunnan sekä lisäämään projektiesi selkeyttä ja suuntaa.

Tänään seurassani on Mackenzie Dysart. Hän on Reason Onen vanhempi projektipäällikkö, ja kyseessä on täyden palvelun digitaalinen markkinointitoimisto. Hänellä on kaikki pätevyydet: PMP- ja CSM-sertifikaatit sekä kokemusta sekä toimisto- että asiakaspuolelta aina verkkosivustojen rakentamisesta ja sovelluksista kampanjoihin. Tervetuloa, Mackenzie.

Mackenzie Dysart:

Hei.

Ben Aston:

Kiitos, että liityit seuraamme tänään, ja kiitos hienosta projektitavoitteita käsittelevästä kirjoituksestasi. Ensimmäiseksi haluan kuitenkin tietää, mitä uutta sinulle kuuluu tänä vuonna. Millaisissa projekteissa työskentelet tällä hetkellä?

Mackenzie Dysart:

Tällä hetkellä yksi mielenkiintoisista ja hieman erilaisista asioista, joita olen saanut tehdä, on osallistuminen yrityksemme markkinointiprojekteihin. Reason One lanseerattiin hiljattain brändinä. Se on kahden aiemman toimiston, ecentricartsin ja BlueKeyn, fuusio, ja olen saanut osallistua sekä Reason Onen verkkosivuston ja brändin rakentamiseen että nyt markkinointistrategian tekemiseen ja johtajien ohjaamiseen. Kokemus on ollut melkoinen, ja se on ehdottomasti tarjonnut oppimismahdollisuuksia, koska kyseessä on ollut muutos tavanomaisesta verkkosivustoprojektista. Se on ollut hienoa.

Ben Aston:

Mitä vinkkejä sinulla on tähän? Toimistot ovat yleensä todella huonoja markkinoimaan itseään, ja oman yrityksen asiakkaana oleminen on haastavaa. Se on mielestäni aina huvittavaa. Toimistojen verkkosivustot ovat usein melko heikkoja, koska ne jäävät tärkeysjärjestyksessä viimeisiksi ja eri sidosryhmät kilpailevat keskenään. Kaikki asiakkaan painajaiset ovat läsnä omassa toimistossa. Miten siis saat tämän toimimaan? Miten saat sen toteutettua?

Mackenzie Dysart:

Olen täysin samaa mieltä siitä, että olemme itse itsemme pahin asiakas. Kokemus on ollut opettavainen. Yksi vaikeimmista asioista oli ajan varaaminen resurssiaikatauluista sellaisen asian tekemiseen, joka ei ollut tuottavaa tai laskutettavaa. On todella vaikeaa sanoa: ”Siirrämme tämän henkilön pois projektityöstä ja tuomme hänet mukaan tähän.”

Yksi suurista asioista oli siis sanoa: ”Ei.” Jouduimme käymään näitä keskusteluja ja asettamaan määräaikoja. Yksi tärkeä asia oli varmistaa, että sanoimme: ”Tämä on määräaika, jonka mukaan meidän on toimittava”, ja pidimme siitä kiinni sekä pystyimme sanomaan johtajille ei. Yhteistyökumppanit ovat hienoja, mutta joskus on vain sanottava: ”Ei. Lopettakaa. Älkää enää pyytäkö tätä. Ei.”

Jouduin siis rajoittamaan luovuutta ja sanomaan: ”Meidän täytyy olla realistisia. Selvitetään, mitä voimme tehdä tämän tietyn ajan puitteissa” ja määrittämään selkeän projektitavoitteen julkaisuajankohdalle. Se, miltä tämä näytti verrattuna tulevaisuuden tilaan, oli ratkaisevaa onnistumisen kannalta.

Ben Aston:

Entä johtajat? Oletko onnistunut määrittämään jonkinlaisen tärkeysjärjestyksen johtoryhmälle? Olen aiemmin huomannut, että luova johtaja haluaa tehdä lopulliset päätökset, mutta niin haluaa myös toimitusjohtaja, UX-johtaja ja tekninen johtaja. Miten määritit tällaisen järjestyksen sidosryhmien hallinnan ja päätöksenteon hierarkian näkökulmasta? Entä millainen matriisi – RACI-matriisi – teillä on käytössä?

Mackenzie Dysart:

Se edellytti monien ihmisten siirtämistä sisemmän piirin ulkopuolelle. Meillä on kolme yhteistyökumppania, ja he ovat hyvin kiireisiä. Meillä ei ollut aikaa odottaa, että kaikki kolme olisivat saatavilla keskusteluja varten. Heillä oli suunnitelma ja visio, joten sanoin: ”Yksi teistä toimii yhteyshenkilönämme. Meillä voi olla vain yksi tuotteen omistaja.” Aloin toteuttaa niitä hieman erikoisilta tuntuvia hyviä käytäntöjä, joita yritetään usein kiertää, koska kyseessä on sisäinen projekti. Mielestäni sisäisissä projekteissa on kuitenkin oltava vielä tiukempi, koska ihmiset vastustavat niitä sanomalla: ”Mutta tämä ei ole oikea projekti.” Todellisuudessa se on.

Yksi tärkeistä asioista oli rajata esitykset yhteen yhteistyökumppaniin, pitää mukana vain suunnittelujohtaja ja luoda tiivis, pienempi ryhmä, joka omisti projektin. Sitten johdimme sitä pienenä projektina. Meillä oli tilannekatsaukset kahdesti viikossa, tarkistuksia ja muuta vastaavaa. Varmistimme, että noudatimme tavallisia prosessejamme ja teimme sisäisen tarkistuksen ennen kuin näytimme työn ”asiakkaalle”. Näin meillä oli samat tarkistukset ja tasapainot kuin asiakasprojektissa. Vaikka projekti oli sisäinen, se oli yhtä suuri tai jopa suurempi, koska kyse oli kasvoistamme, nimestämme ja brändistämme, ja sille piti antaa sen ansaitsema arvostus.

Ben Aston:

Missä vaiheessa prosessi on tällä hetkellä?

Mackenzie Dysart:

Lanseerasimme brändin virallisesti 16. huhtikuuta, joten meillä on täysin uusi verkkosivusto. Käy ihmeessä katsomassa: reasononeinc.com. Rakennamme parhaillaan markkinointialustaamme, erityisesti hakukonemarkkinoinnin sivuja ja kattavampaa sivustoa. Brändi on kuitenkin jo ulkona vähimmäiskelpoisena versiona. Sosiaalinen media toimii, ja aloitamme sen brändäämisen. Saatat nähdä meidät joissakin konferensseissa, mutta etenemme hitaasti ja varmasti, jotta emme yritä tehdä liian paljon liian nopeasti. Haluamme tehdä kaiken hyvin.

Ben Aston:

Onnittelut siitä, että saitte jotain julkaistua. Aloittamieni toimistojen uudelleensuunnitteluprojektien ja loppuun saattamieni projektien määrät eivät täysin täsmää.

Mackenzie Dysart:

En valehtele. Alkuperäinen julkaisupäivä oli 31. joulukuuta 2018, joten myöhästyimme hieman.

Ben Aston:

Neljä kuukautta myöhässä. Se on melko kohtuullista.

Mackenzie Dysart:

Ei kovin paha.

Ben Aston:

Mitä muuta? Olemme puhuneet johtajien kanssa toimimisesta, ihmisten saatavuuden haasteista ja sisäisistä projekteista. Mitä muita haasteita kohtaat tällä hetkellä vanhempana projektipäällikkönä ja tiimiä ohjatessasi?

Mackenzie Dysart:

Aikavyöhykkeet ovat aina mielenkiintoisia. Minulla on etätiimejä, ja nyt yksi henkilö työskentelee länsirannikon aikataulun mukaan. Lisäksi meillä on Irlannissa työskenteleviä ihmisiä. Kaikkien välillä on noin yhdeksän tunnin aikaero. Jos kokouksia täytyy järjestää, käytettävissä on tunnin tai puolentoista tunnin aikaikkuna, jolloin kaikki voivat osallistua. Lisäksi kyseessä on ollut fuusio, joten muutamme kaikkia prosessejamme ja uudistamme monia asioita. Olemme oppineet paljon siitä, miten eri ihmiset työskentelevät. Tiimimallimme on muuttumassa: aiemmin pienissä tiimeissä oli yksi projektipäällikkö ja resurssit, nyt siirrymme yksiköihin, joissa on kaksi projektipäällikköä ja noin 10–12 resurssia. Näin ne voivat toimia itsenäisemmin. Työstämme parhaillaan tätä mallia ja dokumentoimme hyviä käytäntöjä. Olen perehdyttänyt uusia projektipäälliköitä, joten olen päässyt kouluttamaan enemmän. Se on ollut uutta ja innostavaa. Opin paljon, ja viime kuukaudet ovat olleet hyviä.

Ben Aston:

Kerro prosessinne päivittämisestä ja muuttamisesta. Miten hallitset sitä? Uuden hyvän käytännön luominen on hankalaa, koska heti seuraavaksi vastaan tulee poikkeustapaus, jossa uusi prosessi ei toimikaan. Jokainen projekti on erilainen, eikä yhtä prosessia voi soveltaa kaikkeen. Miten prosessinne on kehittynyt ja miten toteutit muutoksen?

Mackenzie Dysart:

Tärkeintä on kokeilu ja erehdys. Et voi vain päättää, että uusi prosessi on tietynlainen ikuisesti. Et tiedä ennen kuin kokeilet, joten siihen liittyy riskejä ja sisäisiä investointeja.

Hyvä esimerkki on selvitysvaiheemme. Uskomme vahvasti siihen, että selvitys myydään ensin erillisenä projektina. Selvitämme, millainen lopullisen työn kustannusarvion pitäisi olla, keskitymme strategiaan ja siihen, mitä sivuston parantaminen todella edellyttää, ja laadimme koko projektin virallisen kustannusarvion vasta sen jälkeen. Olemme hienosäätäneet tätä prosessia viimeiset kuusi–kahdeksan kuukautta.

Aloitimme viime vuoden loka- tai marraskuussa kolme projektia ”uudella prosessilla”. Halusimme kokeilla sitä, ja kaikki kolme etenivät samaan aikaan. Näiden kolmen selvitysprosessin perusteella opimme, ettei jokaiseen projektiin tarvita kaikkia osia. Pohdimme myös, miten voisimme rakentaa prosessin niin, että se mukautuu budjettiin ja asiakkaan tyyppiin, erityisesti silloin, kun työpajoja ei voida järjestää paikan päällä.

Palaamme siis jälkikäteen oppimaan. Projektista saadaan oppeja, samoin prosessimuutoksista. Prosessi ei ole pysyvä, vaan se mukautuu uusiin ihmisiin, asiakastyyppeihin ja teknologioihin. Selvitämme parhaillaan, mitä työkaluja käytämme. Kaikki mukautuu, mutta kyse on kokeilusta ja erehdyksestä: teet kerran, säädät, vaihdat suuntaa ja teet uudelleen, kunnes prosessi on mahdollisimman hyvä.

Ben Aston:

Kerro lisää selvitysprosessista. Mitä konkreettisia muutoksia olet tehnyt sen optimoimiseksi?

Mackenzie Dysart:

Yksi asia on edelleen se, että pyrimme järjestämään kaksi puolipäiväistä työskentelyjaksoa paikan päällä aina kun mahdollista, projektin koosta riippuen. Tämä on nykyään kaikkien projektien yhteinen käytäntö. Työskentelyjaksot ovat erittäin arvokkaita, koska niissä saadaan asiakkaalta tietoa heidän tarpeistaan, tavoitteistaan ja päämääristään. Tuotosten osalta voimme valita tilanteeseen sopivat osat. Olemme rakentaneet eräänlaisen valikon: pienemmälle asiakkaalle voimme tehdä strategiakatsauksen, tunnelmatauluja tai perusmuotoisen tietoarkkitehtuurin. Suuressa projektissa voimme puolestaan tehdä yksityiskohtaisen tietoarkkitehtuurin ja ehkä ensimmäisen suunnittelukierroksen, jotta ymmärrämme uudistuksen kokonaisuuden. Tietyt elementit pysyvät aina mukana, kuten selvitystyöpaja, strategiakatsaukset ja dokumentointi, erityisesti tietoarkkitehtuuri. Tuotosten laajuus riippuu projektin ja asiakkaan koosta, budjetista ja aikataulusta.

Ben Aston:

Onko päivitetyn prosessin rinnalle tullut uusia työkaluja projektinhallinnan työkalupakkiisi?

Mackenzie Dysart:

En virallisia työkaluja, mutta olen luonut asioita, jotka auttavat minua työssäni. Tein laskutusseurannan ja olen jakanut sen muiden projektipäälliköiden kanssa, jotta voimme seurata maksujen etenemistä. Kirjanpitomme toimii tällä hetkellä kahdessa maassa, Kanadassa ja Yhdysvalloissa, hieman eri tavoin. Johdonmukaisuuden vuoksi tein pieniä työkaluja, kuten yksinkertaisen Google-taulukon. Se helpottaa kaikkien työtä. Koska yrityksen lopullinen työkalupakki ei ole vielä valmis, olemme etsineet tapoja käyttää nykyisiä työkaluja tehokkaammin ja vähentää vaikeuksia. On helpompaa kuin joutua etsimään tietoa kahdestatoista eri paikasta, vaikka tarvitset vain kuutta.

Ben Aston:

Se on hyvä neuvo. Joskus muutoksenhalu saa ihmiset ajattelemaan, että kaikki prosessit pitää uudistaa kerralla. Parempi tapa on tunnistaa yksi tai kaksi kipukohtaa ja optimoida ne. Pienet parannukset reunoilla voivat olla erittäin hyödyllisiä.

Mackenzie Dysart:

Olen täysin samaa mieltä.

Ben Aston:

Mackenzie on kirjoittanut loistavan artikkelin, joka tarjoaa pikakurssin projektitavoitteista: määritelmät, esimerkit, tavoitteiden kirjoittamisen sekä hankalat mutta hienot SMART-tavoitteet. Niille, jotka eivät ole vielä lukeneet artikkelia: mitä projektitavoitteet ovat ja miten ne eroavat päämääristä?

Mackenzie Dysart:

Tämä on asia, jonka kanssa olen kamppaillut pitkään. ”Hankala” on varmaan oikea sana. Päämäärät, tavoitteet, suorituskykymittarit ja kaikki siihen liittyvä tulevat usein esiin. Projekteista puhuttaessa ihmiset käyttävät näitä termejä paljon, mutta niiden eroista tai vaikutuksista ei aina ole selkeää yhteisymmärrystä. Näen päämäärät joskus pilvilinnoina tai kohteina, ehkä jopa suorituskykymittareina. Asiakas määrittää ne usein sanomalla: ”Haluamme paremman käyttökokemuksen.” Se on yleinen ajatus siitä, mihin projektilla pyritään, mutta ei siitä, miten sinne päästään.

Tavoite pilkkoo tämän saavutettavaksi asiaksi. Käytämme SMART-mallia, koska tavoitteiden tulee olla täsmällisiä, mitattavia, saavutettavia, realistisia ja aikaan sidottuja. Haluamme varmistaa, että ne sisältävät selkeät asiat, joiden avulla onnistumiselle luodaan edellytykset ja projektin onnistumista voidaan mitata lopussa.

Helppo esimerkki omasta elämästä on: ”Haluan terveemmäksi.” Se on päämäärä, mutta miten aiot saavuttaa sen? Tavoitteeksi voidaan asettaa esimerkiksi kaksi litraa vettä päivässä tai kuntosalilla käyminen kolmena päivänä viikossa kolmen kuukauden ajan. Selkeät, tiiviit ja konkreettiset osat auttavat saavuttamaan päämäärän. Muuten päämäärä voi tuntua niin kaukaiselta, että tavoite toimii tikapuina, joiden avulla sinne päästään.

Ben Aston:

Projektitavoitteet auttavat siis saavuttamaan laajemmat päämäärät. Aloitatteko päämääristä ja johdatte tavoitteet niiden perusteella? Kumpi on tärkeämpi ja miten etenette?

Mackenzie Dysart:

Pidän siitä, että päämäärät tulevat mahdollisuuksien mukaan asiakkaalta. Selvitysvaiheessa pyrimme selvittämään, mitä asiakas haluaa saavuttaa. Sen jälkeen projektitiimi pilkkoo päämäärät tavoitteiksi, joiden avulla projektin onnistumista voidaan mitata. Päämäärät ovat tärkeitä, koska haluamme saavuttaa ne, mutta tavoitteet tekevät niistä konkreettisia, realistisia ja saavutettavia. Tiimi voi tarttua niihin, mitata omaa toimintaansa ja varmistaa, että se tekee oikeita päätöksiä onnistumisen saavuttamiseksi.

Ben Aston:

Miten tavoitteet määritetään selvitysvaiheessa? Jos asiakas sanoo, että hän haluaa enemmän lomakkeen täyttöjä, miten pääsette tästä varsinaiseen tavoitteeseen?

Mackenzie Dysart:

Paras tapa on esittää kysymykset käänteisesti: ”Miksi ette saa lomaketäyttöjä? Mikä lomakkeessa on nyt vialla? Millaisia lukuja näette? Mitkä ongelmat mielestänne ovat kyseessä?” Lomakkeissa on paljon vuorovaikutusta, joten on kysyttävä esimerkiksi, saadaanko riittävästi laadukkaita liidejä ja miksi lomaketäyttöjä tarvitaan lisää.

Voi olla, että kysymme väärää asiaa. On ymmärrettävä, mistä päämäärä syntyy. Johtuuko se siitä, että myynti sanoo tarvitsevansa lisää liidejä saadakseen projektille rahoitusta, vai siitä, että laadukkaita liidejä tarvitaan verkkosivuston tuoton osoittamiseen? Nämä ovat eri keskusteluja. Selvitystyöpajassa selvitämme, miksi asiakas esittää tietyn päämäärän, ja kysymme esimerkiksi, millainen sivuston pitäisi olla, miten sen pitäisi toimia ja mitkä ovat asiakkaan kipukohdat.

Sen jälkeen tiimi pohtii asiaa yhdessä: mitä kuulimme, mitkä olivat tärkeimmät havainnot, miten ongelma voidaan ratkaista ja mikä oli keskeinen haaste. Tavoitteiden kirjoittaminen ei ole yksittäisen projektipäällikön tehtävä. Koko tiimin on osallistuttava, sitouduttava ja tuotava mukaan eri näkökulmia. Sen jälkeen tavoitteet esitellään asiakkaalle osana strategiaa. Niihin voidaan palata kaikissa esityksissä ja tuotoksissa sekä asiakkaan että sisäisen tiimin kanssa.

Yksi helppo esimerkki liittyy käyttökokemukseen. Asiakas voi sanoa: ”Hyvä sisältömme on piilossa.” Yksi tavoitteemme voisi silloin olla, että tietyt tärkeät tiedot löytyvät käyttäjälle kahden tai kolmen napsautuksen päästä riippumatta siitä, missä hän sivustolla on. Tämä on otettava huomioon navigaation ja rautalankamallien esittelyssä ja arvioitava, tukevatko kaikki päätökset tavoitetta.

Ben Aston:

Eli otatte asiakkaan projektikuvauksen ja kuulustelette sitä. Esimerkiksi ”enemmän lomaketäyttöjä” johtaa kysymyksiin siitä, miksi niitä tarvitaan, keneltä niitä tarvitaan ja mitä hyötyä niiden lisääntymisestä on. Pyritte ymmärtämään liiketoimintapäämäärän ja yhdistämään sen käyttäjien tarpeisiin ja käyttäjätarinoihin.

Mackenzie Dysart:

Esimerkiksi laadukkaiden liidien määrää voidaan kasvattaa sovitulla prosenttiosuudella kuuden kuukauden kuluessa julkaisusta. Sitten kysytään, mikä estää ihmisiä täyttämästä lomaketta. Onko kenttiä liikaa? Onko lomakkeen validointi liian tarkka? Olemme testeissä huomanneet, että liian tiukka validointi saa ihmiset luovuttamaan, jos lomake hylkää heidän syöttämänsä sähköpostiosoitteen tai puhelinnumeron.

On siis parannettava lomakekokemusta niin, että käyttäjä täyttää lomakkeen mielekkäillä tiedoilla, mutta väärät lähetykset karsiutuvat. Tavoite ei ole vain lisätä laadukkaita liidejä, vaan muodostaa käyttäjätarina, joka keskittyy lomakkeen täyttämisen esteisiin ja niiden poistamiseen. Sen jälkeen tutkitaan parhaita käytäntöjä ja keskitytään elementtiin, joka vaikuttaa projektin onnistumiseen.

Ben Aston:

Miten hallitset tilanteen, jossa asiakas sanoo haluavansa kasvattaa lomaketäyttöjen määrää 500 prosentilla vain siksi, että haluaa enemmän liidejä?

Mackenzie Dysart:

Ensimmäiseksi on ymmärrettävä, mikä on realistista. Tavoitteita ei pidä tarkastella tyhjiössä, sillä kaikki liittyy kaikkeen. Verkkosivusto on ekosysteemi. Hakukonemarkkinointi voi vaikuttaa lomaketäyttöihin, jos markkinointisivuilla ei ole samaa lomaketta. On ymmärrettävä, miten tavoitteet liittyvät toisiinsa.

Suuri kasvu lyhyessä ajassa on yleensä epärealistinen. Tavoite kannattaa jakaa pienempään aikaväliin: esimerkiksi kolmen tai kuuden kuukauden kuluttua lomaketäyttöjen määrä kasvaa viisi prosenttia, mikä vastaa alan standardia. Sen jälkeen tuloksia arvioidaan uudelleen ja parannetaan jatkuvasti.

Tavoitetta voidaan toistaa, kehittää ja kasvattaa. Lopulta kasvu voi olla 300 tai 400 prosenttia, mutta se ei välttämättä johdu yksin lomakkeesta. Vaikutuksia voivat tuottaa sisältö, hakukoneoptimointi ja kaikki muu sivustolla tehty työ. Tavoite on kuitenkin rajattava realistiseksi. Sen pitää vaatia ajattelua ja ponnistelua, mutta sen on silti oltava saavutettavissa.

Ben Aston:

Kun tavoitteet ja suorituskykymittarit on määritetty, miten pidätte ne tiimin mielessä koko projektin ajan?

Mackenzie Dysart:

Olen ottanut henkilökohtaiseksi tavoitteekseni tuoda projektitavoitteet mukaan kaikkiin sisäisiin kokouksiin seuraavien kuuden kuukauden ajan. Haluan varmistaa jokaisessa esityksessä, että olemme ajatelleet tavoitteita ja palaamme niihin päätöksiä tehdessämme.

Olen myös alkanut hyödyntää Slackin kiinnitystoimintoa. Tavoitteet voi kiinnittää projektin yhteyteen tai asettaa projektin aiheeksi. Silloin ne ovat jatkuvasti näkyvillä ja muistuttavat kaikkia siitä, mitä pitää tehdä ja miten projektia tulee ajatella sen koko elinkaaren ajan.

Ben Aston:

Tavoitteiden näkyväksi tekeminen on tehokasta. Ne voi tulostaa seinälle tai sijoittaa esimerkiksi Jiran tai Trellon työjonon viereen. Sprintin suunnittelussa voi kysyä: ”Auttaako tämä tarina saavuttamaan tavoitteemme?” Jos ei, pitäisikö se priorisoida? Tavoitteet toimivat suodattimena työjonon priorisoinnissa ja työn arvioinnissa.

Niiden avulla voidaan myös perustella asiakkaalle, miksi luovia ja teknisiä päätöksiä on tehty. Kun työ perustuu sovittuihin tavoitteisiin, päätökset eivät vaikuta mielivaltaisilta. Tämä auttaa osoittamaan, että tehty työ edistää haluttua muutosta.

Ben Aston:

Missä projektitavoitteiden hallinta yleensä menee pieleen?

Mackenzie Dysart:

Kaikki voi mennä pieleen alusta lähtien, jos ihmiset eivät ymmärrä tavoitteiden arvoa. Joskus tehtävää kutsutaan tavoitteeksi vain siksi, että sen suorittaminen on helppoa. Tavoitteiden tarkoitus on ymmärrettävä ennen niiden kirjoittamista. Kaikkien on oltava samalla sivulla.

Tavoitteiden pitää olla täsmällisiä, mitattavia, saavutettavia, realistisia ja aikaan sidottuja. Näin ajatellaan jo etukäteen, miten tavoite saavutetaan, onko aikataulu realistinen ja voidaanko tekniset muutokset toteuttaa. Esimerkiksi lomakekenttien vähentäminen ei ehkä ole mahdollista, jos myynti tai muut osastot tarvitsevat kaikki tiedot. Silloin on löydettävä toinen tapa esittää sama tietomäärä.

Asiakas voi myös muuttaa ajatuksiaan. Eräs asiakkaani haluaa parantaa lomaketäyttöjä, mutta ei halua testata lomakkeessa mitään merkittävää riskien vuoksi. Silloin on kysyttävä, mikä tavoite oikeastaan on: pidetäänkö nykyinen taso vai parannetaanko sitä?

Haasteita syntyy myös, jos tiimin jäsen liittyy projektiin myöhemmin eikä ole ollut mukana tavoitteen määrittelyssä, tai jos kehitysvaiheessa houkuttelevampi tekninen ominaisuus alkaa viedä huomiota tavoitteesta. On pysyttävä tietoisena tästä koko projektin elinkaaren ajan. Tavoitteiden huolellinen määrittäminen alussa on paras tapa vähentää riskejä.

Ben Aston:

Pidän erityisesti tavoitteiden täsmällisyydestä. Artikkelissasi pilkot asian kysymyksiksi: onko tämä täsmällinen, mitattava, saavutettava, realistinen ja aikaan sidottu? Mitä täsmällisempi tavoite on ja mitä yksiselitteisemmin voidaan todeta, saavutettiinko se vai ei, sitä voimakkaampi tavoite on.

Realistinen tavoite auttaa sanomaan asiakkaalle: ”Teimme sen.” Jos tavoitetta ei saavutettu, syy voidaan selvittää. Harmaiden alueiden poistaminen auttaa osoittamaan arvon ja tulokset. Tavoitteiden ei pidä olla liian epämääräisiä epäonnistumisen pelossa. Kun ne ovat realistisia alusta lähtien, täsmällisyys on vahvuus.

Jos haluat oppia lisää SMART-projektitavoitteiden määrittämisestä, tutustu artikkeliin. Mackenzien kirjoituksessa on paljon hyödyllisiä neuvoja. Kiitos, että liityit seuraamme.

Mackenzie Dysart:

Ei mitään. Kiitos kutsusta.

Ben Aston:

Mitä mieltä olet? Oletko kokeillut kirjoittaa projektitavoitteita? Oletko käyttänyt suorituskykymittareita projekteissasi? Auttoivatko ne tiimiä pysymään oikealla kurssilla? Kerro mielipiteesi artikkelin kommenteissa. Siirry osoitteeseen TheDigitalProjectManager.com ja liity Slack-tiimiimme. Keskustelemme siellä projektien toteuttamisesta sekä projektitavoitteiden, mittareiden ja suorituskykymittareiden hallinnasta.

Jos pidit tämänpäiväisestä jaksosta, tilaa podcast ja käytä pari minuuttia rehellisen arvion jättämiseen DPM-podcastista Applen Podcasteissa. Arvostamme arvioita ja palautetta, sillä niiden avulla voimme kehittää ohjelmaa. Kiitos kuuntelusta ja kuullaan seuraavalla kerralla.