Joskus projektit ajautuvat raiteiltaan yksinkertaisesti siksi, että ryhdymme niihin liian hätäisesti. Ben Aston keskustelee Maik Stettnerin kanssa siitä, miten voimme käyttää projektin aloitusasiakirjaa eli projektikuvausta saadaksemme kaikki projektin alussa samaan ymmärrykseen ja tehdäksemme projektien käynnistystilaisuuksista tehokkaampia.
Tämä podcast on osa The Digital Project Managerissa julkaistua artikkelia.
Voit lukea artikkelin täältä.
Lue litterointi:
Kokeilemme podcastiemme litterointia ohjelmiston avulla. Pahoittelemme mahdollisia kirjoitusvirheitä, sillä botti ei ole sataprosenttisen tarkka.
Ben Aston:
Kiitos, että kuuntelet. Olen Ben Aston, ja tämä on The Digital Project Manager -podcast. Tämän podcastin tarjoaa Clarizen, yritysten projekti- ja salkunhallintaohjelmistojen johtava toimittaja. Vieraile osoitteessa clarizen.com ja lue lisää.
Jos projektista voi taata yhden asian, se on se, ettei se koskaan etene suunnitelman mukaan. Mutta miksi projektit ajautuvat raiteiltaan? Joskus yksinkertaisesti siksi, että ryhdymme projekteihin liian nopeasti. Näemme projektin määräajan lähestyvän, joten aloitamme projektin jonkinlaisessa sokeassa paniikissa. Kun asiat alkavat mennä pieleen, ihmettelemme, miksi näin tapahtui.
Meillä on yleensä projektin taustat, strategia, yksityiskohdat, vaatimukset ja onnistumisen mittarit mielessämme, mutta teemme helposti oletuksen, että myös kaikkien muiden pitäisi tietää ne. Todellisuudessa tiimimme ei todennäköisesti tiedä niitä, jos asioita ei ole dokumentoitu.
Tänään puhumme työkalusta, jonka avulla kaikki voidaan saada samalle sivulle projektin alussa. Kyseessä on projektin aloitusasiakirja, jota kutsutaan maailmassamme ehkä yleisemmin projektisuunnitelmaksi. Kerromme, miten voit laatia projektin aloitusasiakirjan ja käyttää sitä projektiesi tehostamiseen.
Tänään seurassani on Maik Stettner, yksi ystävistäni ja kollegoistani. Maik on yksi The Digital Project Managerin vakituisista projektinhallinnan asiantuntijoista. Tervetuloa, Maik.
Maik Stettner:
Hei. Mitä kuuluu?
Ben Aston:
Hyvää. On hienoa saada sinut mukaan. Maik, puhutaan ensin sinusta ja kerrotaan kaikille hieman tarinastasi, sillä työskentelemme tietenkin yhdessä ja olemme työskennelleet jo, kuinka kauan — viisi vuotta?
Maik Stettner:
Nyt on kulunut neljän ja viiden vuoden väliltä.
Ben Aston:
Kun palkkasin Maikin, muistan ajatelleeni: ”En tiedä, pystyykö tämä kaveri siihen.” Sinulla on hieman erilainen tausta, etkä tule perinteisestä toimistomaailmasta. Kerro siis tarinasi. Miten sinusta tuli projektipäällikkö digitaaliseen toimistoon?
Maik Stettner:
Minulla on yhteensä noin kymmenen vuoden kokemus eri aloilta. Aloitin alun perin pelien ja julkaisutoiminnan parissa hallinnoimalla pelien julkaisuja Euroopassa ja Pohjois-Amerikassa. Sen jälkeen siirryin muille aloille, kuten lääketieteellisiin tietokantoihin, mutta työskentelin jatkuvasti ohjelmistokehityksen ja projektinhallintaan liittyvien asioiden parissa erilaisten tiimien kanssa. Urani aikana sain myös jonkin verran kokemusta toimistotyöstä sovelluskehityksen ja verkkokehityksen parissa. Kun keskustelimme ensimmäisen kerran yhdessä työskentelystä, siirryin käytännössä täysipäiväisesti verkkokehityksen ja toimistotyön pariin.
Ben Aston:
Niin.
Maik Stettner:
Olen työskennellyt nykyisessä yrityksessäni FCV:ssä noin neljän vuoden ajan. Johdan nykyään toimiston projektinhallintatiimiä ja vastaan projektien kokonaisvaltaisesta toimittamisesta sekä siitä, että asiakkaat ovat tyytyväisiä tuottamiimme tuloksiin.
Ben Aston:
Hienoa. Niille kuuntelijoille, jotka ovat samanlaisessa tilanteessa — esimerkiksi projektipäälliköille, joilla on kokemusta ohjelmistojen hallinnasta ja jotka harkitsevat siirtymistä digitaaliseen toimistoon — millainen siirtymä oli sinulle? Kun siirryit ohjelmistomaailmasta digitaalisen projektinhallinnan maailmaan toimistossa, mitkä olivat keskeiset erot ihmisten tai projektien hallinnassa?
Maik Stettner:
Ensinnäkin yhtäläisyyksiä on paljon. Asiat, joita kohtaat muissa ohjelmistokehitystoimistoissa tai projektinhallintaan liittyvillä aloilla, tulevat vastaan myös toimistossa. Tiimit ovat monimuotoisia, projektit ajautuvat eri syistä raiteiltaan ja samoja taktiikoita voi käyttää tilanteiden korjaamiseen.
Yksi keskeisistä eroista oli aluksi ajan ja materiaalien erittäin tarkkaan hallintaan sekä pienempiin työvaiheisiin keskittyminen suurten toimituskokonaisuuksien sijaan. Asiakkaat, erityisesti omalla alallani, haluavat enemmän läpinäkyvyyttä ja hallintaa pienempiin työn osiin. Tämä edellyttää yksityiskohtaisempaa raportointia ja enemmän työtä sen eteen, että asiakkaalle selitetään tarkasti, mitä tehdään ja miten luottamus syntyy.
Se oli minulle tärkein ero, mutta oli kiinnostavaa huomata, että vaikka työskentelisit täysin eri alalla, ongelmat ovat melko samanlaisia riippumatta siitä, työskenteletkö tietokantaprojektin, pelin tai verkkosivuston parissa. Aiemmassa työssä opittuja asioita, kuten hyvää viestintää ja projektipäällikön tavanomaisia parhaita käytäntöjä, voi soveltaa alalta toiselle. Sillä ei ole väliä, mitä rakennat.
Ben Aston:
Kerro sitten roolistasi nyt. Et johda ainoastaan projekteja vaan myös tiimejä ja projektinhallintatiimiä. Kun hallinnoit projektisalkkua, useita erilaisia projekteja ja niiden ristiriitaisia resurssivaatimuksia, millaisia haasteita kohtaat PMO-tiimin johdossa?
Maik Stettner:
Roolini on nykyään kokonaisvaltaisempi. Varmistan, että kaikki etenee, ja yksi tärkeimmistä painopisteistäni on resurssien hallinta: oikeat ihmiset oikeaan tehtävään ja oikeaksi ajaksi.
Usein on tehtävä kompromisseja, kun asiat kestävät odotettua kauemmin mutta toinen projekti on jo suunniteltu. Silloin on hallittava muutoksia ja varmistettava, että asiakkailla on suora yhteys minuun. Kokonaisvaltaisessa ja korkeamman tason roolissa on kuitenkin riski, että olet ainoa henkilö, joka vastaa eskaloinneista. Se ei ole rooli, jossa haluat olla jatkuvasti, sillä silloin ihmiset soittavat lähinnä ollessaan vihaisia.
On silti hyvä osallistua aktiivisesti erilaisiin projekteihin, rakentaa luottamusta ja samalla varmistaa, että organisaation toimintatavat ovat kunnossa. Tämä koskee resursointia, operatiivista toimintaa ja yleistä yhteistyötä, sillä meillä on useita toimistoja.
Meille on tärkeää varmistaa esimerkiksi se, että Toronton ja Victorian toimistojen ihmiset pystyvät työskentelemään hyvin yhdessä. Se muodostaa suurimman osan painopisteestäni. Minulla on silti asiakkaita, joiden kanssa työskentelen läheisesti, ja teen edelleen paljon projektinhallintaa, koska se on intohimoni. Pidän ihmisten kanssa työskentelystä enkä aio luopua siitä.
Ben Aston:
Palataan resurssienhallinnan haasteeseen. Miten toimit, jos sinulla on kaksi ristiriitaista projektia, kaksi projektipäällikköä, molemmilla perjantain määräaika ja molemmat tarvitsevat samoja resursseja? Millainen on priorisointiprosessisi?
Maik Stettner:
Katson ensin projektin prioriteettia. Onko meillä määräaikoja? Lupasimmeko asiakkaalle jotakin? Pitääkö projektin olla julkaistu tiettynä päivänä? Onko aikataulussa joustoa?
Myös sillä on merkitystä, onko jokin asia esimerkiksi vahvistettu sopimuksessa. Onko projekti vain kiireinen ja halutaanko asiakkaalle tehdä palvelus? Se on hyvä asia, jos aikaa on, mutta jos toinen projekti julkaistaan kolmen päivän kuluttua, emme todennäköisesti voi ottaa ketään pois siitä.
Tämä on lähtökohta. Ihannetilanteessa tällaista ei tapahdu, koska projektipäällikön pitäisi ennakoida ylitykset ja lisätä aikatauluun puskuria. Odotan myös tiimiltäni, että se puolustaa tarvitsemiaan resursseja.
Usein ihmiset ovat liian ystävällisiä ja sanovat: ”Voit saada tämän henkilön päiväksi.” Lopulta kaikkien työt kuitenkin siirtyvät. En kannata resurssien ryöstämistä, mutta resurssipalavereissa odotan ihmisten puolustavan tarvitsemaansa aikaa ja siirtävän ongelman resurssipäällikölle ratkaistavaksi.
Ben Aston:
Ehkä tämä on kanadalainen resurssiongelma.
Maik Stettner:
Kanadalainen pattitilanne, aivan varmasti.
Ben Aston:
Kanadalaiset ovat liian ystävällisiä, ja eurooppalaisina voimme sanoa sen. Vai saavatko vain kanadalaiset vitsailla näistä ihmisistä?
Maik Stettner:
Aivan. Näen heidät ehdottomasti eri tavalla myös Euroopassa.
Ben Aston:
Olen aina kiinnostunut työkaluista. Oletko viime aikoina löytänyt tai alkanut käyttää jotakin työkalua, josta ajattelet: ”Tämä on mahtava. Miksemme ottaneet tätä käyttöön aiemmin?” Millainen työkalupakkisi toimii hyvin?
Maik Stettner:
Käytämme melko tavanomaista ajanhallinnan ja MS Projectin työkalupakkia, mutta MS Project tuntuu usein asiakkaasta liian raskaalta. Kokeilemme nykyään paljon pilvipohjaisia tuotteita. Projectista on esimerkiksi Office 365 -versio. Tarkastelemme myös muita ajanhallinnan ja resurssienhallinnan ohjelmistoja. Täydellistä ratkaisua en ole löytänyt, koska prosessimme on melko räätälöity ja osittain myös manuaalinen.
Henkilökohtaisesti uskon, ettei tarpeisiimme ihanteellisesti sopivaa työkalua ole olemassa. Tavoitteeni olisi rakentaa tai hankkia jotakin ja räätälöidä se yksilöllisiin tarpeisiin.
Ben Aston:
Mitä työkaluista mielestäsi puuttuu, jotta ne olisivat käyttökelpoisia? Vai onko prosessi niin monimutkainen, etteivät työkalut vielä pysty vastaamaan siihen?
Maik Stettner:
Ei välttämättä. Prosessi on melko suoraviivainen. Etsin työkalua, joka yhdistää yksinkertaisen ajanhallinnan, tuntien kirjaamisen ja ihmisten työaikalistat resurssisuunnitteluun. Sen pitäisi myös yhdistyä taloudelliseen näkökulmaan. Aikaa ja materiaaleja käytettäessä laskenta on helppo: tuntimäärä kerrottuna laskutushinnalla. Tämän jälkeen koko raportointiputki pitäisi saada toimimaan samalla tavalla.
Se kuulostaa helpolta, mutta keskeneräisten projektien todennäköisyyteen ja muutoksiin liittyy paljon huomioitavaa. Ne voivat vääristää raportointia ja lisätä manuaalista työtä niin paljon, etteivät mittarit enää täsmää. Täydellistä ratkaisua en ole vielä löytänyt.
Ben Aston:
Puhutaan kirjoittamastasi artikkelista projektin aloitusasiakirjoista eli projektisuunnitelmista. Kuten johdannossa mainitsin, projektit menevät pieleen usein siksi, ettemme aloita niitä kunnolla. Oletamme, että tiimi tietää asiat, tai annamme sille joukon asiakirjoja ja sanomme: ”Mene yhteiselle levylle lukemaan ne. Kaikki on siellä.” Kuvittelemme, että tiimi perehtyy niihin ja pääsee ajan tasalle. Kun projekti epäonnistuu näyttävästi, emme tiedä miksi, vaikka todellinen syy on se, ettei tiimi ymmärrä projektia.
Puhutaan siis siitä, miten voimme laatia parempia projektisuunnitelmia tai, projektinhallinnan kielellä, projektin aloitusasiakirjoja. Voitko kertoa prosessistasi projektien käynnistämisessä ja siitä, mihin projektin aloitusasiakirja tai projektisuunnitelma sijoittuu? Milloin laadit sen ja miten pääset tilanteeseen, jossa voit kirjoittaa sen?
Maik Stettner:
Oletetaan, että sinulla on uusi asiakas. Olet innostunut, koska yleinen sopimus on allekirjoitettu. Se voi olla korkean tason puitesopimus tai muu sopimus, jossa todetaan, että yrityksesi ja toinen yritys alkavat työskennellä yhdessä. Seuraava askel on selvittää, miten tämä muutetaan konkreettisiksi vaiheiksi ja ehdoiksi.
Yleensä mieleen tulee työseloste. Ongelmana on se, että projektin alkuvaiheessa kaikki on vielä erittäin yleisellä tasolla ja vain arvio siitä, mitä lopulta tullaan tekemään. Projektin aloitusasiakirja ja aloituspalaverit ovat hyviä tapoja tutustua asiakkaaseen ja selvittää, onko olemassa muita tekijöitä, joita ei huomioitu alkuperäisessä työselosteessa tai projektisuunnitelmassa.
Kun ensimmäinen työseloste on laadittu ja tiimi on päättänyt toimistomme sisällä, mitä tehdään, järjestämme sisäisen aloituksen. Sen jälkeen järjestämme asiakkaan kanssa ulkoisen aloituksen, jossa käydään läpi, mitä tehdään, ketkä kuuluvat tiimiin, miten teemme yhteistyötä ja mikä on määritelty laajuus.
Projektin aloitusasiakirja tai projektisuunnitelma on seuraava askel kohti konkreettisempaa suunnittelua. Alkuvaiheessa sitä on kuitenkin käsiteltävä elävänä asiakirjana, sillä yksityiskohdat eivät ole vielä täysin selviä. Se on erinomainen työkalu liiketoimintaympäristön kuvaamiseen ja projektin perusparametrien selkeyttämiseen sekä asiakkaalle että sisäiselle tiimille.
Ben Aston:
Artikkelissasi kerrot, että asiakirjan tulisi sisältää taustaa, projektin parametrit, projektin rakenne, projektin vastuuhenkilöt ja riskienhallinnan. Puhutaan ensin taustasta. Miten annat tiimille riittävästi taustatietoa ilman, että sekoitat tai kuormitat ihmisiä liialla tiedolla?
Maik Stettner:
Kyse on siitä, miksi asiakas tekee projektin ja mitä ongelmia korkean tason näkökulmasta ratkaistaan. Mitkä ovat liiketoiminnan tavoitteet? Halutaanko myyntiä kasvattaa tai yleisölle kertoa, mitä yritys tekee? Onko kyseessä brändiuudistus? Keskeinen kysymys on, miten onnistuminen määritellään ja mistä tiedämme projektin lopussa onnistuneemme.
Tavoite voi olla esimerkiksi paremmat myyntikeskustelut tai itsepalvelusivusto, joka tuo sisällön sisällönhallintajärjestelmään. On tärkeää luoda perusta ja varmistaa, että tiimi tietää, mitä kohti se työskentelee. Vaikka vaiheet eivät vielä olisi yksityiskohtaisesti määriteltyjä, tausta auttaa kehystämään kokonaisuuden.
Jos työskentelet esimerkiksi brändiuudistusprojektissa, jonka tavoitteena on yrityksen uudelleensijoittaminen, ja projektin lopussa joku kysyy, miksei myynti kasvanut, voit palata asiakirjaan ja todeta, ettei se ollut projektin tavoite. Projektin tausta toimii muistiona siitä, mitä alun perin keskusteltiin, ja auttaa varmistamaan yhteisen näkemyksen asiakkaan kanssa.
Ben Aston:
Tuo on hyödyllinen näkökulma. Projektin tausta on tärkeä erityisesti silloin, kun luodaan jotakin uutta: miksi asiakas toteuttaa projektin, mitä ongelmaa ratkaistaan, mitkä ovat liiketoiminnan tavoitteet ja miltä onnistuminen näyttää. Tämä taustatieto auttaa tiimiä suunnittelemaan ratkaisua.
Puhutaan projektin parametreista. Miten rajaat projektia ja millä tavoin tiimin rajoittaminen voi olla hyödyllistä?
Maik Stettner:
Asiantuntijoita ei pidä rajoittaa liikaa. Jos annat heille kuitenkin täysin vapaat kädet, he saattavat työskennellä aivan eri projektin parissa kuin mitä kuvittelit. On tärkeää antaa raamit ja perusasiat, kuten budjetti, aikataulu ja yleinen suunnitelma. Ihannetilanteessa osa tiimistä on ollut mukana arviossa, joten asioiden ei pitäisi tulla heille yllätyksenä.
Tiimin on tärkeää ymmärtää, ettei kyse ole rajoituksesta vaan siitä, mitä on sovittu toimitettavan asiakkaalle tietyllä budjetilla. Jos joku tarvitsee enemmän aikaa, tiimin tehtävä on selvittää, miten työ voidaan silti toteuttaa. Keskustelun on hyvä olla avointa. Älä anna tiimille vaikutelmaa, että vaikeutat heidän työtään, vaan mahdollista heidän onnistumisensa ja varmista, että he tietävät sinun tukevan heitä budjetin muutoksissa, riskeissä ja aikataulumuutoksissa.
Lopulta tiimin on voitava luottaa toimitukseen ja olla innostunut projektin aloittamisesta aivan kuten asiakkaankin, sillä myös tiimi haluaa saada työn tehtyä.
Ben Aston:
Puhutaan vielä yhdestä asiasta, jonka projektin aloitusasiakirjaan voi sisällyttää: projektin työnjakorakenteesta ja resurssisuunnitelmasta. Projektin alussa moni asia on vielä epäselvä. Miten laadit alustavan suunnitelman ennen kuin tiedät tarkasti, miten projekti etenee?
Maik Stettner:
Rehellisesti sanottuna se on siinä vaiheessa todennäköisesti paras arvio. Se perustuu työselosteeseen tai tiimin tekemään arvioon. Monet asiat ovat vielä avoinna: reagoiko asiakas nopeasti, kuinka monta tarkistuskierrosta tarvitaan ja niin edelleen. Suunnitelma ei välttämättä toteudu sellaisenaan.
Suunnitelman arvioiminen auttaa kuitenkin toimistoa ja muita projektitiimejä varaamaan oikeat resurssit ja pitämään tiimin vakaana. Myös kunnianhimoinen alustava suunnitelma auttaa hahmottamaan kokonaisuutta ja ymmärtämään, mitä tiimin on tehtävä.
Tarvitaanko esimerkiksi suunnittelija, jota et ollut huomioinut? Kun tiimi keskustelee näistä asioista varhain, projektipäällikkö ymmärtää toimitukseen liittyvät yksityiskohdat, osaa esittää oikeat kysymykset ja ohjata asiakasta. Karkea suunnitelma tai arvio on parempi kuin ei suunnitelmaa lainkaan, koska sitä voidaan tarkentaa ajan kuluessa.
Ben Aston:
Suunnitelma on siis parempi kuin ei suunnitelmaa, koska sitä voidaan aina kehittää. Jos aloitat projektin ilman suunnitelmaa, riippuvuuksia tai asiakkaan roolia on vaikea hahmottaa. Kun tuot tiimille suunnitelman, se antaa lähtökohdan keskustelulle, vaikka tiimi sanoisi: ”Maik, olet hullu. Miten ihmeessä toteutamme tämän?” Jonkinlainen suunnitelma on parempi kuin tyhjä paperi.
Projektisuunnitelma tai projektin aloitusasiakirja kuulostaa vakavalta asiakirjalta, mutta sen ei tarvitse olla suuri ja muodollinen dokumentti. Tarjoamme siinä pohjan, parametrit ja suunnitelman. Millaisia muotoja projektisuunnitelma voi saada ja miten sen rooli kehittyy projektin elinkaaren aikana?
Maik Stettner:
Laatimani opas on esimerkki siitä, mitä asiakirjaan voi sisällyttää. Tietty vähimmäistieto siinä pitäisi olla, mutta asioita voi toteuttaa myös muilla tavoilla. Esimerkiksi riskienhallinta voidaan käsitellä erikseen. Myös RACI-matriisi voidaan yhdistää tilanneraportteihin.
Asiakirjan ei tarvitse aina olla erittäin muodollinen. Tärkeintä on, että kaikki hyväksyvät sen. Se voidaan julkaista esimerkiksi SharePointissa tai Basecampissa, sitä voidaan päivittää ja sen ympärillä voidaan keskustella. Jos projektin aikana huomataan, että myyntiin liittyvä näkökulma jäi pois, se voidaan lisätä asiakirjaan. Tällä voi tietysti olla vaikutuksia projektin laajuuteen.
Kunhan kyseessä on kirjallinen asiakirja tai jopa muodollinen sähköpostiviesti, jonka ihmiset voivat hyväksyä ja jonka olemassaolo tunnustetaan, se on yleensä riittävä. Kaikkien ei tarvitse allekirjoittaa ja leimata sitä, mutta vähintään kaikkien pitää hyväksyä se, koska se määrittää, mitä toimitetaan ja minkä perusteella työskennellään.
Ben Aston:
Jos tämän kuuntelemisen jälkeen ajattelet, että kaikki kuulostaa hyvältä mutta mistä pitäisi aloittaa, hyvä uutinen on se, että Maik on laatinut erittäin hyvän mallin projektisuunnitelmaa tai projektin aloitusasiakirjaa varten. Tutustu artikkeliin ja lataa se. Maik, kiitos paljon osallistumisesta. On ollut hienoa saada sinut mukaan.
Maik Stettner:
Kiitos kutsusta.
Ben Aston:
Ole hyvä. Yhtenä DPM-asiantuntijoistamme Maik esiintyy tulevalla kurssillamme, joka alkaa syyskuussa ja jonka nimi on Digitaalisen projektinhallinnan hallinta. Jos tarvitset projektinhallintakoulutusta, tutustu kurssiin. Se on seitsemän viikon intensiivikurssi, joka sisältää vuorovaikutteisia videotunteja, viikoittaisia tehtäviä, ryhmäkeskusteluja ja mahdollisuuden valmennustapaamisiin. Siirry osoitteeseen digitalprojectmanagerschool.com ja ilmoittaudu ennen kuin kurssi täyttyy.
Jos haluat osallistua projektin aloitusasiakirjoja tai projektisuunnitelmia koskevaan keskusteluun, siirry digitalprojectmanager.com-sivuston resurssiosioon ja liity Slack-tiimiimme. Siellä käydään monia kiinnostavia keskusteluja. Muista myös kommentoida artikkelia ja jakaa se. Kiitos kuuntelusta.
