Aloita projektisi oikein (Suze Haworthin kanssa)

Lue tekstitys:

Kokeilemme podcastiemme tekstittämistä ohjelmiston avulla. Pahoittelemme mahdollisia kirjoitusvirheitä, sillä botti ei ole sataprosenttisen tarkka.

Ben Aston:

Tervetuloa DPM-podcastiin, jossa menemme teoriaa pidemmälle ja tarjoamme asiantuntevia projektinhallinnan neuvoja parempien digitaalisten projektien johtamiseen. Kiitos, että kuuntelet. Olen Ben Aston, The Digital Project Managerin perustaja.

Me kaikki tiedämme, että projektin alku on sen onnistumisen kannalta todella ratkaiseva, mutta se voi olla myös hyvin haastava vaihe. Epäselvyyttä on paljon. Hämmennystä on paljon. Erimielisyyksiä riittää, ja epävarmuutta on runsaasti. Projektipäälliköinä tehtävämme on saada projekti liikkeelle ja pitää se liikkeessä – ja lisäpisteitä saa siitä, jos onnistumme todella johtamaan projektia oikeaan suuntaan. Mutta mitä voimme tehdä varmistaaksemme, että lähdemme oikeaan suuntaan? Miten aloitamme asiat oikein? Siitä tämän päivän podcastissa on kyse. Jatka kuuntelemista, niin saat selville, miten voit aloittaa projektisi oikein.

Tänään seurassani on Suze Haworth. Hei, Suze.

Suze Haworth:

Hei.

Ben Aston:

Suze on yksi The Digital Project Managerin projektinhallinnan asiantuntijoista. Hän työskentelee Lontoossa itsenäisenä digitaalisten projektien senioriprojektipäällikkönä. Suze, kertoisitko hieman projekteista, joiden parissa olet viime aikoina työskennellyt?

Suze Haworth:

Kyllä. Olen tosiaan itsenäinen projektipäällikkö. Lopetin muutama viikko sitten erään sopimuksen, joka oli kuitenkin melko pitkäkestoinen sopimus eräässä toimistossa. Minulla oli siellä kaksi keskeistä roolia. Toinen oli enemmän ohjelmajohtajan rooli yhden asiakkuuden parissa. Kyseessä oli Specsavers, joka on erittäin suuri silmälasien vähittäismyyntibrändi Yhdistyneessä kuningaskunnassa ja toimii myös Pohjoismaissa ja Australiassa. Johdin senioriprojektipäällikköä kaikissa Specsaversin luovissa, käyttäjäkokemukseen liittyvissä ja digitaalisissa tehtävissä. Kyseessä oli melko suuri työohjelma. Lisäksi työskentelin Ikean projektin parissa. Se oli projekti, jossa suunniteltiin ja rakennettiin prototyyppi brändin suunnittelujärjestelmää varten.

Ben Aston:

Hienoa. Specsaversin kohdalla kyse on siis enemmän verkkokaupasta ja konversio-optimoinnista?

Suze Haworth:

Kyllä, se riippui oikeastaan markkinasta, mutta he eivät yleensä myy silmälaseja verkossa tiettyjen sääntelyvaatimusten vuoksi. Suuri osa työstä liittyi ihmisten ohjaamiseen varaamaan aika ja saapumaan myymälöihin. Mutta kyllä, kyse oli paljolti konversio-optimoinnista, kuten sanoit.

Ben Aston:

Mikä näissä projekteissa oli haastavaa? Millaisia haasteita kohtasit itse projektissa, asiakkaan kanssa tai tiimin parissa? On aina kiinnostavaa kuulla, että muillakin on samanlaisia ongelmia. Mikä oli vaikeaa?

Suze Haworth:

Specsaversin työohjelmassa aloitusajankohta oli todella kiinnostava, koska aloitin maaliskuussa, uuden vuoden alussa, ja siirryimme täysin uuteen työskentelytapaan. Aiemmin olimme työskennelleet suunnittelutoimistona heidän kehitystoimistonsa rinnalla ja toimineet heidän kaikkien scrum-tiimiensä sisällä. Jokaisessa työvirrassa oli suunnittelijan ja käyttäjäkokemuksen asiantuntijan muodostama pari. Päätimme poistaa kaikki suunnittelijamme ja käyttäjäkokemuksen asiantuntijamme scrum-tiimeistä, koota heidät yhdeksi omaksi tiimiksemme ja siirtyä kaksiraiteisempaan prosessiin. Käynnistimme niin sanotun selvitystyöraiteen toimitusraiteen yläpuolella. Toimitusraide koostui enemmän scrum-pohjaisesta kehitystiimistä.

Se antoi meille tilaa ja mahdollisuuden käyttäjätestaukseen, tutkimiseen, hypoteesien muodostamiseen ja oletusten testaamiseen käyttäjien kanssa. Lisäksi pystyimme tekemään paljon enemmän tutkimusta ja hyödyntämään dataa, mikä antoi meille enemmän liikkumavaraa toteuttaa asioita, joita käyttäjät todella halusivat. Oli siis erittäin kiinnostavaa ottaa uusi työskentelytapa käyttöön, varmistaa sen toimivuus ja saada se kunnolla käyntiin. Se oli myös melkoinen haaste, mutta todella innostavaa.

Ben Aston:

Oliko roolisi siis… Kenen rooli se oli? Tuoteomistajan? Teillä oli nämä kaksi rinnakkaista työvirtaa. Toinen liittyi strategiaan, käyttäjäkokemukseen ja suunnitteluun, ja oletan, että siellä tehtiin käyttäjätestausta käyttäjien tarpeiden tunnistamiseksi. Sen jälkeen tarpeet priorisoitiin, osa niistä siirrettiin käyttäjäkokemuksen ja suunnittelun työvirtaan ja lopulta kehitykseen. Toimiko se näin?

Suze Haworth:

Kyllä. Käyttäjäkokemuksen ja suunnittelun muodostaman parin työskentely scrum-tiimissä oli melko rajoittavaa, erityisesti kahden viikon jaksoissa. He käyttivät paljon aikaa teknisempiin asioihin. He osallistuivat pitkiin sprinttien suunnittelukokouksiin, vaikka heidän osuutensa oli usein pieni, tai seurasivat päivittäisiä kokouksia, joissa puhuttiin paljon virheistä. Asiakkaiden todellisten tarpeiden sijaan työ alkoi painottua liikaa tekniikkaan. Siksi päätimme siirtää heidät omalle rinnakkaiselle työraidalleen, jotta meillä olisi riittävästi aikaa tarkastella olemassa olevaa dataa ja tutkimusta, tunnistaa oletuksia ja muodostaa hypoteeseja siitä, miten voisimme ratkaista asiakkaiden ongelmakohtia.

Sen jälkeen pystyimme tekemään nopeasti käyttäjäkokemuksen suunnittelua tai prototyyppejä sen mukaan, mikä kyseiseen tarpeeseen sopi, ja testaamaan niitä asiakkailla nopeasti. He pystyivät vahvistamaan ratkaisun ennen kuin se siirtyi toteutukseen. Näin pystyimme tehostamaan rakentamista emmekä rakentaneet asioita, joita asiakkaat eivät halunneet. Päivitimme suunnittelu- ja käyttäjäkokemuspäätöksiä ennen kuin asiat siirtyivät sprintteihin. Teknisiä asiantuntijoita osallistui edelleen selvitystyöraiteelle, mutta heidän tehtävänsä oli enemmän teknisen toteutettavuuden arviointi sen jälkeen, kun oli varmistettu, mitä asiakas halusi ja mistä ominaisuudesta hän piti. Tarkoituksena oli tehostaa prosessia ja samalla keskittyä asiakkaan tarpeiden toteuttamiseen sen sijaan, että toteutetaan vain se, mikä on mahdollista.

Ben Aston:

Uskon, että tämä on haaste monille toimistoille, jotka yrittävät käyttää scrumia. Scrum ei tietenkään ole ainoa tapa toteuttaa ketterää projektia, mutta sitä pidetään usein yleisesti hyväksyttynä toimintatapana. Yksi toimistojen scrum-työskentelyn suurista haasteista on kuitenkin se, mitä käyttäjäkokemuksen ja suunnittelun asiantuntijoiden pitäisi sprintin aikana tehdä. Yksi vaihtoehto on, että he työskentelevät muutaman sprintin kehitystyötä edellä, mutta silloin mikään ei valmistu. Sprintin tarkoitus on, että sen lopussa kehitetään jotain toimituskelpoista ja hyväksymiskriteerit täyttävää, ja strategian, käyttäjäkokemuksen suunnittelun ja ominaisuuden rakentamisen yhdistäminen kahden viikon jaksoon on todella vaikeaa.

Siksi pidän ajatuksesta, että työ toteutetaan kahtena rinnakkaisena työvirtana ja että tuoteomistaja siirtää validoidut asiat kehitysjonoon. Näin käytössä on kaksi eri kehitysjonoa. Strategisessa jonossa kysytään, onko tämä oikea asia tehtäväksi. Toisessa jonossa tiedetään, että asia on oikea, koska se on validoitu, joten se voidaan rakentaa.

Suze Haworth:

Juuri niin. Näin rakennetaan ominaisuuksia, joiden on todettu olevan asiakkaiden haluamia, jolloin hukkaa syntyy paljon vähemmän. Prosessi on huomattavasti leanimpi, mikä on mielestäni vain hyvä asia.

Ben Aston:

Hyvä juttu. Puhutaan projektin käynnistämisestä ja projektien aloittamisesta. Haluaisin tietää, olitko mukana Ikean tai Specsaversin projektien alussa?

Suze Haworth:

Specsaversin tapauksessa kyseessä oli koko vuodeksi resursoitu tiimi, jonka kokoonpano oli määritelty. Aloitin sen jälkeen, kun työskentelytapa ja työn laajuus oli alustavasti määritelty. Tämä on yksi haasteista, joista kirjoitan artikkelissani: joskus otat vastuullesi projektin, joka on jo aloitettu tai jonka joku muu on jo määritellyt. Otin projektin haltuuni melko pian sen määrittelyn jälkeen, mutta työskentelytapa oli vasta alustavasti määritelty. Kun sitä alettiin toteuttaa, huomasin, että sitä oli säädettävä ja muutettava. Se kehittyi melko paljon alkuperäisestä suunnitelmasta, koska käytännön työ paljastaa aina asioita, jotka eivät toimi ja joita on mukautettava.

Ikean projekti taas toteutettiin vaiheittain. En työskennellyt projektin ensimmäisessä vaiheessa, vaan tulin mukaan toisessa vaiheessa, joten projekti oli aloitettu ennen kuin minä aloitin.

Ben Aston:

Näin käy usein projekteissa, jotka otamme projektipäällikköinä vastuullemme. Emme yleensä aloita aivan alusta. Se voi lisätä hämmennystä, koska projektipäällikkönä sinut tuodaan projektiin, joka on siirtynyt liiketoiminnan kehityksestä, asiakkuustiimiltä tai myynniltä. Perit suunnitelman, joka on tehty, mutta ei ehkä täysin valmis, ja johon liittyy epävarmuutta. Projektin käynnistäminen tarkoittaa siis usein myös sitä, että sinulle luovutetaan projekti jossain sen vaiheessa, ei välttämättä aivan alussa.

Puhutaan niistä asioista, jotka mainitsit artikkelissasi: ihmisten, prosessin ja tuotteen hallinnasta sekä yhteisen suunnan ja selkeyden saavuttamisesta. Kyse on siis siitä, kuka, miten ja mitä. Aloitetaan ihmisistä. Kun otat projektin haltuusi tai käynnistät sen ensimmäistä kertaa, mitä yrität tehdä ihmisten näkökulmasta, jotta projekti alkaa oikeaan suuntaan?

Suze Haworth:

Projektissa on muutamia keskeisiä ihmisryhmiä, joita täytyy ajatella. Ensimmäisenä on tiimi: ketkä työskentelevät projektin parissa? Projektin käynnistysvaiheessa määritellään, keitä projektiin varataan ja ketkä siinä työskentelevät. On tärkeää tarkastella paitsi sitä, ketkä ovat käytettävissä, myös sitä, ketkä sopivat projektiin. On huomioitava heidän osaamisensa, työskentelytapansa, projektin tyyppi ja asiakas, jonka kanssa työskennellään.

Jos tunnet tiimin jäsenet, on hyödyllistä ymmärtää, ketkä työskentelevät parhaiten yhdessä. Aina tähän ei tietenkään ole mahdollisuutta, vaan käytettävissä olevat henkilöt ratkaisevat. Silti on hyvä pohtia asiaa etukäteen, koska ihmisten työskentelytapojen ymmärtäminen auttaa myöhemmin, jos ongelmia ilmenee.

On todella tärkeää, että projektiin osallistuvat ihmiset ovat mukana alusta asti. Olen työskennellyt vuosia suunnittelijoiden, kehittäjien ja laadunvarmistuksen asiantuntijoiden kanssa, ja yksi asioista, joita lähes kaikki heistä inhoavat, on se, että he eivät ole mukana projektin alussa, eivät tiedä siitä mitään ja saavat sitten valmiiksi määritellyn asian, jonka heitä pyydetään vain suunnittelemaan tai rakentamaan. Kun heidän itsenäisyytensä poistetaan ja heille vain kerrotaan, mitä pitää tehdä, siitä tulee ongelma.

Jos aikaa ja budjettia on riittävästi, ihmisiä kannattaa ottaa mukaan edes kevyesti jo alusta lähtien. Ensimmäisen sisäisen aloituskokouksen jälkeen heidän kanssaan voi keskustella projektista, heidän ajatuksistaan, työskentelytavasta ja odotuksista. Näin he pääsevät mukaan heti alusta.

Ben Aston:

Tämä liittyy myös resursointiin. Tiimi kannattaa resursoida mahdollisimman varhain niiden ihmisten avulla, joita tarvitset ja joiden haluat osallistuvan, sekä saada heidät sitoutumaan projektiin. Ihmiset reagoivat helposti, jos he perivät projektin, jota joku muu on ajatellut, mutta ei ole ehtinyt suunnitella kunnolla. Haluamme, että ihmiset kokevat projektin omakseen. Kun heillä on omistajuuden tunne sen sijaan, että he reagoivat jonkun toisen puolivalmiiseen ideaan, saamme yleensä paljon parempia tuloksia.

Suze Haworth:

Aivan.

Ben Aston:

Siirrytään prosessiin, joka liittyy tähän. Meillä on tiimi ja tiedämme, ketkä siihen kuuluvat. Miten käytämme tiimiä projektin toteuttamiseen? Tiimissä syntyy usein erimielisyyksiä siitä, miten projekti pitäisi toimittaa, mitä prosessia, menetelmää ja työkaluja pitäisi käyttää. Miten yhtenäistät tiimin toimintaa ja navigoit lähes väistämättömissä erimielisyyksissä?

Suze Haworth:

Täydellistä, kaikille ja kaikin tavoin sopivaa prosessia ei todennäköisesti ole mahdollista löytää. Projektin aikana syntyy aina jännitteitä. Joskus perit prosessin, jota toimistosi tai organisaatiosi käyttää, tai asiakas määrää sen. Jos saat itse määritellä prosessin, voit yrittää löytää projektin ja asiakkaan kannalta sopivan toimintatavan. Jos prosessi on jo määritelty, se kannattaa käydä sisäisessä aloituskokouksessa tiimin kanssa läpi ja selittää, miksi sitä käytetään. Näin tiimi saadaan ainakin alusta asti mukaan.

Prosessia on myös tärkeää mukauttaa työn edetessä. Jos jokin ei toimi, siihen ei pidä takertua jäykästi. Tiimin täytyy voida kertoa prosessiin, työkaluihin tai viestintätapoihin liittyvistä ongelmista avoimesti. Sen jälkeen voidaan etsiä tapoja lieventää ongelmia, mukauttaa toimintaa ja viedä projektia eteenpäin.

Ben Aston:

Joustavuus on varmasti tässä onnistumisen avain. Projektipäälliköt tai tiimin jäsenet saattavat sanoa, ettei scrum toimi näin, ettei tämä ole ketterää tai että tämä on liian vesiputousmallista. Todellisuudessa sillä, mitä jokin menetelmä on tai ei ole, ei ole niin paljon merkitystä. Tärkeintä on se, mikä toimii tiimille, projektille ja asiakkaalle. Yhteen toimintatapaan ei pidä suhtautua dogmaattisesti. On kysyttävä, mikä on paras tapa toimittaa tämä työ juuri tällä tiimillä.

Projektit ovat erilaisia, joten yhden prosessin tai menetelmän soveltaminen kaikkeen on hyvin hankalaa. Uuden projektin ja asiakkaan kohdalla on aivan perusteltua suunnitella toimintatapa uudelleen.

Olemme puhuneet siitä, kuka, miten ja mitä tarkoittavat. Olemme käsitelleet tiimin ja sidosryhmien kokoamista sekä prosessin ja menetelmän joustavaa hallintaa. Projektin alussa itse tekemisen ja toimitettavan asian määrittely voi kuitenkin olla vaikeinta. Myyntitiimiltä peritään usein hyvin väljä työn laajuus tai asiakkaalta epämääräiset vaatimukset. Miten poistat projektin tai tuotteen ympärillä olevan epäselvyyden ja pääset tilanteeseen, jossa voidaan sopia, mitä toimitetaan?

Suze Haworth:

Se riippuu projektin tyypistä. Projektin alussa asioiden ei mielestäni pidä olla liian tiukasti mustavalkoisia, koska niin paljon voi muuttua ja lopputulos voi olla myöhemmin täysin erilainen. Pidän työn laajuuksista, jotka sallivat muutokset eivätkä lukitse toimitettavia asioita täysin alussa. Joissakin projekteissa kaikki on kuitenkin määritelty tarkasti etukäteen. Asiakkaan kanssa on käytävä keskusteluja, jotta vaatimukset selkiytyvät. On ymmärrettävä käyttäjien ja liiketoiminnan tarpeet sekä projektin konteksti.

Sen jälkeen vaatimuksia täytyy konkretisoida yhdessä tiimin kanssa. Tiimi on siis otettava mukaan varhain – ei vain yhtä henkilöä, vaan useita alan vastuuhenkilöitä tai tiimin jäseniä. Heidän kanssaan käydään läpi projektin laajuus ja vaatimukset ja määritellään mahdolliset rajat.

Ben Aston:

Varhaisissa määrittelytilaisuuksissa on hyödyllistä koota ihmiset yhteen puoleksi päiväksi valkotaulun, muistilappujen ja muiden välineiden äärelle. Ratkaisua voidaan hahmotella korkealla tasolla. Tavoitteena on yhteinen ymmärrys ja linjaus, koska projektin alussa ihmisillä on usein erilaisia käsityksiä siitä, mitä asiat tarkoittavat. Kun asioita piirretään ja sijoitetaan seinälle, syntyy keskusteluja ja epäselvyydet tulevat esiin.

Yhteinen kokonaiskuva auttaa kaikkia pääsemään samalle sivulle. Valkotaulusta otettu kuva voi myöhemmin toimia muistutuksena siitä, miten projektin eri osat liittyvät toisiinsa ja mitä toimitetaan. Kokonaisarkkitehtuurin hahmottaminen ja yhden toteutustavan kirjaaminen auttaa myös rajaamaan projektin alkua ja loppua. Kun projektin parametrit ja yhteinen ymmärrys kirjataan, selvitystyöstä tulee helpompaa.

Suze Haworth:

Ehdottomasti. Tällaiset työpajat ovat hienoja. Ihmisten kokoaminen samaan tilaan ja asioiden määrittely auttaa, vaikka asiat myöhemmin muuttuisivatkin. Sama kannattaa tehdä myös asiakkaan kanssa. Se on hyvä tapa käynnistää projekti, koska ymmärrätte paremmin asiakkaan näkemyksen ja asiakas näkee, miten te hahmotatte projektin. Ensin voidaan järjestää sisäinen työpaja ja sen jälkeen työskennellä asiakkaan kanssa puolen päivän tapaamisissa.

Ben Aston:

Olemme puhuneet siitä, mitä pitää hallita: ihmisistä eli tiimistä, prosessista ja menetelmästä sekä ratkaisun ja arkkitehtuurin hahmottamisesta. Samalla voidaan hahmotella budjetti, aikataulut ja onnistumisen mittarit. Vaikka nämä muuttuisivat myöhemmin, niiden kokoaminen yhteen suureen valkotauluun projektin alussa on hyödyllistä.

Joskus projektin käynnistämistä tehdään ennen kuin projekti on virallisesti hyväksytty. Silloin herää kysymys, kuinka pitkälle pitäisi edetä. Teetkö niin paljon kuin mahdollista vai oletko varovaisempi ja teet vain tarpeeksi, jotta projekti liikkuu eteenpäin? Tässä on jännite: hyväksyntä ei ehkä ole valmis, mutta ilman lisätyötä toimituspäivä voi jäädä saavuttamatta. Miten hallitset riskin siitä, että etenet liian pitkälle väärään suuntaan, verrattuna riskiin, ettet ole muutaman viikon päästä tarpeeksi pitkällä?

Suze Haworth:

Olen todennäköisesti varovaisemman lähestymistavan kannalla. Jos asiakas viivyttää hyväksyntää tai työn laajuudesta neuvotellaan edestakaisin, on tärkeää varmistaa, että asiakas ymmärtää viivästysten vaikutuksen koko projektiin. On tiedostettava riskit, jotka liittyvät siihen, ettei asioita ole vahvistettu ja että projekti voidaan käynnistää virallisesti.

Asioiden edistäminen ja suunnittelu on silti hyvä aloittaa. Varovainen lähestymistapa voi tarkoittaa, että tehdään juuri tarpeeksi, jotta projekti pysyy hieman liikkeessä. Projektin alussa on aina vauhtia: tiimi osallistuu, keskustelee ja innostuu siitä, mitä rakennetaan tai suunnitellaan. Jos vauhti hidastuu ja pysähtyy, tiimin jäsenet ja joskus asiakkaatkin siirtyvät muiden asioiden pariin ja kiinnostus laskee. Siksi on hyvä pitää vauhtia yllä.

Ben Aston:

Puhutaan näistä haasteista. Yksi tavallisista ongelmista on vauhdin puute projektin alussa. Ihmisille kerrotaan projektista, mutta se ei käynnistykään, tai epäselvyydet ja vastausta odottavat kysymykset pysäyttävät projektin. Mitä teet tilanteessa, jossa kaikki näyttää pysähtyvän?

Suze Haworth:

Se on vaikeaa, koska ihmiset on ehkä jo varattu projektiin, mutta virallista lupaa ei ole saatu eikä heitä voida vielä käyttää työhön. Jos aikaa kuitenkin on käytettävissä, tiimille kannattaa varata hieman aikaa projektin alustavaan käynnistämiseen. Taustatutkimuksen tekeminen, olemassa olevan datan tarkastelu tai kilpailijoiden tutkiminen voi käynnistää ajattelun ja pitää ihmiset mukana matalammalla tasolla siihen asti, että työ voidaan aloittaa virallisesti.

Ben Aston:

Myös lyhyt tapaaminen tiimin kanssa voi auttaa. Voi kertoa, että projektin piti alkaa tällä viikolla, mutta se ei alakaan, ja jakaa viimeisimmät tiedot. Näin tiimi pysyy mukana eikä projekti katoa heidän mielestään.

Suze Haworth:

Mikään ei ole pahempaa kuin se, että asiasta vaietaan kokonaan ja kolmen viikon tai kuukauden päästä ilmestytään ilmoittamaan, että nyt voidaan aloittaa. Tiimi kannattaa pitää mukana taustalla käytävissä asiakaskeskusteluissa, kertoa viivästyksen syy ja aloitusaika sekä se, mitä sillä välin voidaan tehdä. Keskustelu on pidettävä käynnissä.

Ben Aston:

Yksi monien projektipäälliköiden kohtaama tilanne on projektin ottaminen haltuun kesken kaiken. Silloin perimme jonkun muun suunnitelman ihmisistä, prosessista ja tuotteesta, mutta vastuu toimituksesta siirtyy meille. Mitä vinkkejä sinulla on tällaisen tilanteen selvittämiseen?

Suze Haworth:

Se on yksi suurimmista haasteista, koska projektipäällikkö ei yleensä ole mukana aivan alusta asti. Alku tapahtuu usein tarjousvaiheessa tai silloin, kun myyntitiimi määrittelee projektia. Usein projektin määrittelee projektinhallinnan tai toimituksen johtaja tai joku muu tiimin jäsen. Siksi monet projektit tulevat vastaan jo asetettujen odotusten kanssa. Olen usein työskennellyt ennalta määriteltyjen kustannusten ja hyvin väljän työn laajuuden kanssa ja joutunut sovittamaan työn budjettiin.

On tarkasteltava olemassa olevia rajoja ja selvitettävä, missä on joustovaraa. Jos kustannus on jo määritelty, työn laajuutta ja toimitettavaa on tarkasteltava realistisesti, vaikka se tarkoittaisi keskustelua siitä, että projekti on ehkä myyty liian suurena. Jos rahalle luvataan liikaa, on oltava realistinen sen suhteen, mitä voidaan toimittaa. On selvitettävä, missä asioissa voidaan joustaa ja mistä laajuudesta tai aikataulusta on keskusteltava.

Jos projekti otetaan haltuun kesken sen toteutuksen, on ensinnäkin hankittava mahdollisimman paljon tietoa projektista, tapahtuneesta, tähän mennessä toimitetusta, asiakkaasta ja kaikesta muusta olennaisesta. Sen jälkeen kannattaa tehdä lähes uudelleenkäynnistys. Järjestä uusi pieni aloitus, vaikka projekti olisi jo puolivälissä. Kokoa tiimi, tapaa asiakas ja varmista, että kaikki ymmärtävät tämän olevan uusi nollauskohta. Se on tärkeää, vaikka ihmiset kokisivat tehneensä tämän jo kerran. Näin projekti voidaan viedä eteenpäin ja voidaan ymmärtää, mikä on toiminut, mikä ei ja mitä pitäisi tehdä eri tavalla.

Ben Aston:

Uudelleenkäynnistykseen tarvittava itseluottamus on todella voimakas asia. Kun tulet projektiin etkä tiedä siitä aluksi juuri mitään, vaikeiden ja mahdollisesti tyhmiltä vaikuttavien kysymysten esittäminen paljastaa yleensä paljon epäselvyyksiä, joita muillakin tiimin jäsenillä on. Projektin edetessä ihmiset tekevät uusia oletuksia, joita ei dokumentoida. Yhteinen ymmärrys alkaa jälleen hajota. Uudelleenkäynnistyksessä voi kysyä, miten jokin asia toimii ja miten se liittyy toiseen rakennettavaan asiaan. Näin tulee lähes varmasti esiin ongelmia ja piileviä haasteita, joita kukaan ei ollut vielä ajatellut. Se voi olla erittäin hyödyllistä.

Suze Haworth:

Älä koskaan pelkää kysyä paljon kysymyksiä. Olen aina sanonut tämän uusille projektipäälliköille: kysy kysymyksiä. Älä pelkää kuulostavasi tyhmältä. On paljon parempi kysyä ja selvittää, mitä tarvitsee tietää, kuin vaieta ja yllättyä myöhemmin. Kysy siis paljon.

Ben Aston:

Tämä on hyvä neuvo projektin käynnistämiseen kokonaisuudessaan. Projektien onnistunut käynnistäminen perustuu pitkälti viestintään. Se tarkoittaa vaikeiden kysymysten esittämistä – sellaisten, joita kukaan ei oikeastaan halua kysyä, mutta joiden kaikki tietävät olevan tarpeellisia. On oltava riittävästi luottamusta kysyä vaikeita, kiusallisia ja ärsyttäviä kysymyksiä, koska niiden avulla saavutetaan selkeyttä. Kun asiat määritellään, projekti sujuu paljon paremmin ja hukkaan menee vähemmän työtä, kun kaikki ymmärtävät paremmin yhteisen päämäärän, jota kohti kuljetaan. Suze, kiitos paljon, että liityit seuraamme.

Suze Haworth:

Kiitos. Oli hienoa olla mukana.

Ben Aston:

Yhtenä DPM-asiantuntijoistamme Suze esiintyy tulevalla kurssillamme, joka alkaa helmikuussa. Kurssin nimi on digitaalisen projektinhallinnan hallinta. Se on seitsemän viikon intensiivikurssi, joka sisältää vuorovaikutteisia videotunteja, paneelikeskusteluja ja mahdollisuuden valmennustapaamisiin. Jos haluat oppia lisää projektien paremmasta käynnistämisestä, siirry osoitteeseen DPMSchool.com ja ilmoittaudu ennen kurssin täyttymistä. Jos haluat osallistua projektien käynnistämistä koskevaan keskusteluun, kommentoi julkaisua ja siirry myös TheDigitalProjectManager.comin resurssiosioon liittyäksesi Slack-tiimiimme. Siellä käydään kaikenlaisia keskusteluja projektien käynnistämisestä ja projektien hallinnasta. Ensi kertaan asti, kiitos kuuntelusta.