Mitä voit lopettaa tekemästä projekteissasi (Patrice Embryn kanssa)

Lue tekstitys:

Kokeilemme podcastiemme tekstittämistä ohjelmistolla. Antakaa anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole täysin oikeassa joka kerta.

Ben Aston:

Kiitos, että kuuntelet. Olen Ben Aston, ja tämä on Digital Project Manager -podcast.
Meille kerrotaan jatkuvasti kaikista asioista, joita meidän pitäisi tehdä, ja minä olen yksi niistä ihmisistä, jotka tekevät niin. Itsensä kehittämiseen, asioiden tekemiseen oikein ja erityisesti siihen, että näyttää tekevänsä oikeita asioita, kohdistuu valtava paine. Mutta pitäisikö meidän tehdä kaikkia näitä asioita koko ajan? Kuuntele tämä jakso loppuun saadaksesi selville, miten voit säästää valtavasti aikaa karsimalla tai vähentämällä projektipäällikön rutiineistasi joitakin asioita, joita et ehkä tarvitse jokaisessa projektissa.
Puhumme siitä, miten voit saada osan elämästäsi takaisin ja viettää vähemmän aikaa toimistolla tai työpöytäsi ääressä karsimalla kuusi asiaa, joiden tekemisessä voit säästää aikaa. Tämä podcast käsittelee ennen kaikkea pitäisi-ajattelun ja joidenkin pakkojen kahleiden karistamista sekä hieman tehokkaampaa tapaa tehdä asioita.
Tänään kanssani on Patrice Embry, joka on itse asiassa – ja tästä minun täytyy antaa hänelle tunnustusta – luultavasti aktiivisin osallistuja Slack-tiimissämme. Jos et ole vielä liittynyt, voisit keskustella Patricen kanssa juuri nyt. Voit ilmoittautua Digital Project Managerin yhteisöosiossa. Patrice on siellä lähes aina ja keskustelee jatkuvasti, joten hänet kannattaa tuntea.
Lyhyenä esittelynä: Patrice on freelance-digitaalinen projektipäällikkö. Hän on sertifioitu Scrum Master II. Hän on työskennellyt alalla erittäin pitkään monenlaisissa toimistoissa ja yrityksissä. Kuuntele muita podcastejamme saadaksesi paremman käsityksen siitä, millaisten asioiden parissa hän on työskennellyt. Hän on tehnyt kaikkea, joten hänet kannattaa tuntea.
Tervetuloa, Patrice.

Patrice Embry:

Hei. Kiitos, että kutsuit minut.

Ben Aston:

Eipä kestä. Patrice, voisitko kertoa, onko sinulla viime keskustelumme jälkeen työn alla kiinnostavia projekteja?

Patrice Embry:

Sain juuri päätökseen sovelluksen, jonka parissa työskentelin. Se auttaa ihmisiä, jotka etsivät lyhytaikaisia ja nopeasti alkavia töitä. Se on vähän kuin Care.com, mutta vielä nopeampi, ja tarkoitettu ihmisille, jotka todella tarvitsevat lyhytaikaiset työt tehdyiksi. Se oli todella kiinnostava sovellus. Se ei ole vielä täysin valmis... se on nyt beetavaiheessa, joten se ei ole kokonaan julkaistu maailman nähtäväksi, mutta projekti oli erittäin kiinnostava, koska työskentelin ihmisten kanssa ympäri maailmaa.
En ole koskaan aiemmin työskennellyt kenenkään nigerialaisen kanssa, joten tämä oli ensimmäinen kerta, kun sain tervehtiä igboksi. Se oli hauskaa.

Ben Aston:

Kuulostaa huijausprojektilta. En tarkoita itse asiaa. Nigerialaiset huijaukset ovat tietenkin klassikko. Oliko kehitystiimi siellä?

Patrice Embry:

Anteeksi?

Ben Aston:

Oliko kehitystiimi Nigeriassa?

Patrice Embry:

Kyllä.

Ben Aston:

Ai, oikeastiko?

Patrice Embry:

Kyllä. Käyttöliittymäsuunnittelija oli... käyttöliittymäkehittäjä oli Nigeriassa. Taustajärjestelmän kehittäjä oli Meksikossa ja tekninen vetäjä Ruotsissa. Sitten olin minä Philadelphian ulkopuolella ja asiakas Bostonissa. Olimme kaikki eri paikoissa.

Ben Aston:

Siinä on monta aikavyöhykettä hallittavana.

Patrice Embry:

Kyllä.

Ben Aston:

Sen on täytynyt olla hankalaa. Miten sait sen toimimaan?

Patrice Embry:

Löysin ajan, joka sopi jokseenkin kaikille. Se oli kello kahdeksan aamulla itäistä aikaa. Eurooppalaisille ystävillemme se oli hieman myöhäinen ajankohta, nigerialaiselle ystävällemme aika myöhäinen ja Meksikossa jouduttiin heräämään hieman aikaisemmin kuin hän olisi halunnut, mutta saimme sen toimimaan.

Ben Aston:

Hienoa. Oliko sovellus tarkoitettu startup-yritykselle vai...

Patrice Embry:

Niin. Se on... Luulen, että palvelu sai alkunsa naisesta, joka teki tätä muutamalle ihmiselle, minkä jälkeen muutamat muut kysyivät: ”Hei, voisitko tehdä tuon minulle?” Se jatkui ja jatkui, kunnes hän ajatteli: ”En enää pysty koordinoimaan tätä kaikkea yksin.” Sitten hän taisi päättää: ”Tehdään tästä sovellus.” Se on vielä aivan alkuvaiheessa, joten en halua kertoa siitä liikaa, mutta kun se julkaistaan, kerron siitä varmasti kaikille. Uskon, että siitä tulee ihmisille todella hyödyllinen palvelu.

Ben Aston:

Kuulostaa kiinnostavalta projektilta. Millaisia suuria haasteita kohtasit? Oliko kaikki suoraviivaista vai törmäsittekö matkan varrella hankaluuksiin?

Patrice Embry:

Se oli hieman haastava, koska asiakas ei ollut kovin perehtynyt tietokoneisiin eikä erityisen tottunut sovelluksiin. Hän osasi käyttää niitä normaalilla perustasolla. Teknologia-alalla työskentelevillä on yleensä hieman parempi ymmärrys siitä, miten asiat toimivat, joten jouduin selittämään paljon.
Se oli vähän kuin olisin selittänyt asioita ystävälle, joka ei käytä tietokonetta joka päivä. Tällaista oli jonkin verran. Joskus vasta tällaiseen projektiin todella uppoutuessa huomaa asiat, joita kukaan ei ollut tullut ajatelleeksi. Testaus, minkä vuoksi sovellus on nyt beetavaiheessa, oli todella perusteellista, koska jouduimme jatkuvasti toteamaan: ”Tätä polkua emme ole aiemmin käyneet läpi.” Se teki projektista haastavan, mutta se oli myös hauskaa. Kaikkien kanssa oli mukava työskennellä, ja idea on todella hyvä. Olen siihen melko tyytyväinen.

Ben Aston:

Mitä työkaluja käytit hallitaksesi kaikkia näitä eri aikavyöhykkeillä työskenteleviä ihmisiä? Miten käsittelit alkuperäisestä, hieman väljästä toimeksiannosta nousseita vaatimuksia ja hallitsit projektia?

Patrice Embry:

Se oli todella väljä. Ylimääräistä rahaa ei ollut paljon, mikä sopii hyvin tämänpäiväiseen aiheeseemme. Minulla ei ollut valtavasti tunteja käytettäväksi kaikkeen mahdolliseen. Jouduin valitsemaan tarkkaan, mitä tein ja mitä jätin tekemättä, koska en halunnut käyttää omaa tuntibudjettiani loppuun. Halusin säästää mahdollisimman monta tuntia varsinaiseen kehitystyöhön.
Käytimme Slackia, koska se oli ilmainen. Käytimme Trelloa, koska se oli ilmainen. Käytimme paljon Google-dokumentteja, koska ne olivat ilmaisia. Meidän piti selvittää, miten saamme ne toimimaan yhdessä ilman maksullisia ominaisuuksia, koska meidän oli pidettävä toiminta mahdollisimman kevyenä saadaksemme projektin etenemään tämän naisen ja tämän projektin hyväksi.

Ben Aston:

Miten löysit tämän projektin? Oliko kyse ystävän ystävän suosituksesta, koska kuulostaa siltä, että kyseessä oli startup-yritys...

Patrice Embry:

Niin. Tunnet minut. Mainitsit, että olen koko ajan Slackissa, eikä sinun Slackisi ole ainoa Slack, jossa olen jatkuvasti mukana. Freelancerina minun täytyy pitää yhteyskanavat avoinna kaikkiin suuntiin, jotta saan mahdollisimman paljon tietoa. Puhun monien ihmisten kanssa monista asioista.
En pysty muistamaan ulkoa kaikkien tapahtumien pitkää ketjua, joka johti tähän projektiin, mutta kyse oli varmasti monesta tällaisesta tilanteesta: ”Hei, luulen tuntevani jonkun, josta kuulin toisessa paikassa. Tietääkö kukaan, tekeekö joku tällaista?” Verkostoidun paljon, joten projektit tulevat vastaan hyvin erikoisilla tavoilla.

Ben Aston:

Kokositko projektiryhmän?

Patrice Embry:

En.

Ben Aston:

Oliko se sinun tehtäväsi?

Patrice Embry:

Ei ollut. Minut sijoitettiin ihmisjoukkoon, ja sitten yhdessä selvitimme, mitä kukin tekisi. Minun ei tarvinnut etsiä resursseja tähän projektiin. Olin erittäin tyytyväinen tiimiin, johon päädyin, ja tulen olemaan heidän kanssaan yhteydessä myös tulevaisuudessa. Toivottavasti työskentelemme vielä uudelleen yhdessä, koska arvostin todella paljon sitä, mitä kukin toi projektiin.

Ben Aston:

Hienoa. Tällaisten projektien parissa on kiinnostavaa työskennellä, koska vaikka asiakas ei olisi kovin teknisesti perehtynyt, se tarkoittaa usein myös suurta joustavuutta. On hienoa, kun asiakas luottaa sinuun eikä oikeastaan tiedä, mitä pitäisi tehdä, vaan sanoo: ”Te olette asiantuntijoita, kertokaa vain, mitä meidän pitäisi tehdä.” Silloin voi tehdä paljon oikeita asioita.
Huono puoli on se, että joutuu sanomaan: ”Kokeile painaa Ctrl+F5.”

Patrice Embry:

Tuota tuli vastaan paljon. On hyvä muistaa, varsinkin kun tehdään sovellusta suurelle yleisölle, etteivät kaikki lähde liikkeelle samalta tasolta. Oli oikeastaan hyvä asia, että jouduimme palaamaan perusteisiin, koska meidän piti muistaa ottaa perusteet huomioon myös itse sovelluksessa. Emme voineet olettaa, että ihmiset ymmärtäisivät, että sormella pyyhkäisemällä voisi nähdä lomakkeen loput kentät.
Meidän oli tehtävä selväksi, että näkymää täytyy vierittää. Se toimi tämän projektin kannalta hyvin.

Ben Aston:

Hyvä juttu. Puhutaanpa siitä, minkä mainitsit ja josta puhuin aiemmin. Keskustelimme Slackissa siitä, miten projekteja oikeasti hallitaan. Yhtäältä on teoria: Digital Project Managerissa julkaisemme artikkeleita siitä, miten projektit pitäisi toteuttaa tai mikä on oikea tapa toimia – parhaista käytännöistä, joita voimme soveltaa projekteihimme.
Ajattelin, että olisi kiinnostavaa puhua todellisuudesta eli siitä, miten hallitsemme projekteja arjessa, kun tehtävää on niin paljon. Erityisesti jos sinulla on perusteellinen projektinhallintakoulutus, kuten PMP, tunnet PMBOKin, prosessit, työkalut, erilaiset rekisterit ja tilanneraportit, kokonaisuudesta voi tulla yksi suuri hallinnollinen painajainen.
Todellisuudessa olemme jatkuvasti ylikuormitettuja. Aina olisi dokumentaatiota päivitettäväksi ja asioita tehtäväksi. On kiinnostavaa pohtia, teemmekö asioita, koska ne ovat oikeita asioita, vai käytämmekö liikaa aikaa vääriin asioihin. Puhuimme hetki sitten aloita–lopeta–jatka-ajattelusta. Mitä meidän pitäisi aloittaa? Mitä meidän pitäisi lopettaa tai vähentää? Mitä voimme jatkaa?
Haluaisin kuulla näkemyksesi siitä, mitkä asiat eivät ole neuvoteltavissa. Kun tulet projektiin, ehkä juuri sellaiseen, josta puhuit, mitkä ovat ne asiat, joista ajattelet: ”Nämä on vähintään saatava kuntoon, muuten projekti pysähtyy tai ajautuu raiteiltaan ennen kuin se on edes alkanut?”

Patrice Embry:

Minulle ne ovat aina aikataulu ja vaatimukset. Budjetti tulee niiden jälkeen. Budjetti on eri projekteissa tärkeä eri tavoin, mutta aikataulusta ei mielestäni voi koskaan luopua – tarvitaan melko yksityiskohtainen aikataulu. Vaatimuksista ei myöskään voi luopua, koska muuten et tiedä, mitä olet tekemässä, eikä tiimisi tiedä, mitä sen pitäisi tehdä. Nämä ovat kaksi ehdottomasti välttämätöntä asiaa. Minun mielestäni ne eivät ole neuvoteltavissa.

Ben Aston:

Tarkennetaan vielä: kun puhut vaatimuksista, et tarkoita työselostetta, vaan missä muodossa vaatimukset ovat?

Patrice Embry:

Hyvä kysymys, koska niiden ei välttämättä tarvitse olla dokumentissa. On kuitenkin tiedettävä, mikä on laajuus ja mitä sen ulkopuolella vielä tarvitaan. Yksi askel laajuuden yli: mitä tämän asian on tehtävä? Jos katson työselostetta, siinä pidetään yleensä joitakin asioita itsestäänselvyyksinä. Kaikkea ei ole kirjattu työselosteeseen. On olemassa toinen kerros asioita, jotka on tehtävä, joista on keskusteltava tai joita on harkittava, jotta laajuus voidaan toteuttaa. Myös ominaisuuksia tarvitaan.
Ne on määriteltävä. Ihmisten on tiedettävä, mitä ne ovat. Ne ohjaavat tekemistä. Muuten sinulla ei oikeastaan ole käsitystä siitä, mitä rakennat. Näistä vaatimuksista puhun.

Ben Aston:

Juuri niin. Minulle kyse on arviosta, aikataulusta ja työselosteesta, kun aloitan projektissa ja asetamme yhteisen lähtötason. Etsin juuri tällaista dokumentaatiota, koska jos et tiedä aikataulua tai vaatimuksia, et voi hallita ja ohjata projektia. Jos et tiedä, millainen lopputuloksen pitäisi olla, et tiedä, oletko aikataulussa.

Patrice Embry:

Mistä tiedämme, että se on valmis? Mistä tiedämme, ettei se pysähtynyt? Aivan.

Ben Aston:

Kun otat projektin vastaan, huomaat yleensä, että asiat ovat hieman vanhentuneita. Erityisesti vaatimukset tai työseloste. Joku sanoo: ”Keskustelimme siitä ja sovimme tekevämme jotain muuta.” Miten asetat lähtötason ja pidät nämä asiat ajan tasalla koko projektin ajan?

Patrice Embry:

Muistutan ihmisiä aikataulusta joka viikko tai aina, kun kokoonnumme keskustelemaan projektista. Joskus kokoonnumme useammin kuin kerran viikossa, joskus joka toinen viikko. Se riippuu projektista, mutta muistutan aina, missä kohtaa aikataulua olemme. Mikä on seuraava määräaika ja yleensä myös sitä seuraava, jotta tiedämme, mitä kohti työskentelemme.
Muistutan päättymispäivästä ja siitä, mitä kohti pyrimme. Se ei välttämättä ole julkaisupäivä, vaan esimerkiksi ajankohta, jolloin meidän on oltava laadunvarmistuksessa tai käyttäjähyväksyntätestauksessa. Muistutan kaikkia niistä asioista, ja jos jokin muuttuu, ilmoitan siitä aina. Jos jokin uhkaa myöhästyä, ihmiset kuulevat minusta eniten.
Vaatimusten osalta yritän pitää ne mahdollisimman hyvin ajan tasalla. On hyvä, jos ne ovat esimerkiksi Trellon kaltaisessa järjestelmässä, jossa voidaan jatkuvasti keskustella siitä, millainen jonkin asian pitäisi olla, nähdä asioiden kehittyminen ja tarkistaa, mikä on viimeisin sovittu toteutus jollekin ominaisuudelle. Kaikki voidaan koota yhteen paikkaan ja hakea sieltä.
Jos työskentelet näin, pidä tiedot ajan tasalla. Jos et käytä tällaisia työkaluja, pidä jonkinlainen dokumentaatio ajan tasalla asiakkaan kanssa tehdyistä päätöksistä, ajan säästämiseksi tehdyistä päätöksistä ja myöhemmin lisättävistä asioista. Dokumentaation päivittäminen on jatkuvaa, riippumatta siitä, missä muodossa dokumentaatio on.

Ben Aston:

Kyllä. Minä kirjoitan usein työselosteen ja teen sen jälkeen muutospyyntöjä tai päivityksiä työselosteeseen. Se on yleensä Word-dokumentti, joka päivitetään aina projektin suunnan muuttuessa. Haluan asiakkaan allekirjoituksen, joka vahvistaa: ”Kyllä, ymmärrän tämän muutoksen ja hyväksyn sen.”
Jäljen säilyttäminen ja asioiden seuraaminen on mielestäni erittäin tärkeää, erityisesti jos sinulla on useita asiakkaita tai epäselvyyttä siitä, kuka projektista todella vastaa.

Patrice Embry:

Ehdottomasti.

Ben Aston:

Siirrytään asioihin. Jos työseloste, vaatimukset, aikataulu ja arvio ovat niitä asioita, joista ei tingitä, puhutaan asioista, joita ei ehkä tarvitse tehdä viimeisen päälle tai suunnitella liian monimutkaisesti. Yksi artikkelissa mainitsemasi asia on yksityiskohtainen budjetti ja projektin erittely. Haluatko kertoa siitä?

Patrice Embry:

Aiemmassa työssäni kaikki oli hyvin tarkasti määriteltyä. Olin pieni ratas suuressa pyörässä, jossa oli paljon muita projektipäälliköitä tekemässä monenlaisia asioita. Meitä oli paljon, ja kaikkien piti tehdä kaikki samalla tavalla. Ohje oli: ”Näin asiat tehdään.”
Vasta siirryttyäni pienempiin toimistoihin ja freelanceriksi ymmärsin, ettei kaikkea aina voi tehdä, koska budjetin pitäminen ennallaan on silloin todella vaikeaa ja aika voi loppua. Kun työskentelin suuressa toimistossa ja teimme kaiken, mitä piti tehdä, yksi asioista oli erittäin yksityiskohtainen budjetti. Se oli vanhanaikainen. Teen edelleen budjettini melko perinteisesti. Laitan ne taulukkolaskentaan, käytän pivot-taulukoita ja ehdollista muotoilua, ja soluissa on viittauksia toisiin soluihin. Näin näkee valmistumisprosentin, jäljellä olevan työn, budjetin tilanteen ja poikkeaman ennusteista. Ennusteet tehtiin viikoittain rooleittain.
Se on melko perusteellista, ja yleensä se palvelee minua hyvin. Pystyn vastaamaan milloin tahansa mihin tahansa kysymykseen, jos pidän budjetin näin yksityiskohtaisena. Jos yksityiskohtaisen budjetin ylläpitäminen vaatii kuitenkin paljon enemmän työaikaani eikä asiakas välitä siitä, tai jos palkan maksava taho – asiakas, toimisto tai muu yhteistyökumppani – ei tarvitse sitä, on varmistettava, että tuotettu tieto vastaa todellista tarvetta.
Minulle tämä tarkoittaa sitä, etten tee budjetista ja ennusteista yhtä yksityiskohtaisia kuin olen tottunut. Kesti jonkin aikaa hyväksyä se, mutta kaikkea raportointia ei ehkä tarvitse tehdä. Jos mietit: ”Tarvitseeko minun todella tehdä tämä kaikki?”, kysy itseltäsi, mitä oikeasti tarvitset. Kuinka paljon sitä pitää tehdä? Voitko tehdä vähemmän? Haittaako lisätyö budjettia? Haittaako vähentäminen projektia? Selvitä se ja älä tee suuria budjettierittelyjä pelkästä velvollisuudentunteesta, vaan siksi, että ne hyödyttävät projektia.

Ben Aston:

Tuo on hyödyllistä. Miten yleensä määrität projektinhallintaan käyttämäsi ajan? Asetatko sen prosenttiosuutena hallinnoimasi tiimin kokonaistuntimäärästä vai tehtäväkohtaisesti?

Patrice Embry:

Aiemmin tein sen prosenttiosuutena. Suurissa toimistoissa työskentelyn, monissa paikoissa ja erilaisissa tehtävissä toimimisen sekä freelanceriksi siirtymisen etu on, että näkee monenlaisia toimintatapoja. Prosenttiosuus toimii hyvin, jos järjestelmässä on joustoa asioille, joita et osannut ennakoida. Voin käyttää prosenttiosuutta, jos minun ei tarvitse liikaa pohtia, kuinka paljon ylityötä syntyy. Huomasin kuitenkin tarvitsevani tehtäväkohtaisen tarkastelun. Olen arvioiden tekemisessä melko tarkka ja minulla on niistä vahva näkemys.
Tarkastelen yleensä koko projektin tehtäväerittelyä. Jos käytän prosenttiosuutta, lasken sen tehtävän prosenttiosuutena. En enää käytä koko projektin loppusummaan perustuvaa prosenttia, koska freelancerina ja pienemmissä projekteissa se ei ole riittävän kohdennettu. En käytä enää koko projektin prosenttiosuutta.
Se voi olla toimiva tapa, ja jos se toimii sinulla, jatka sitä. Minulla se ei viime aikoina kattanut tarpeitani.

Ben Aston:

Ymmärrän. Ongelma ei siis ollut liiallinen tuntimäärä, vaan liian vähäinen?

Patrice Embry:

Kyllä. Minulla ei ollut tarpeeksi tunteja tai...

Ben Aston:

Mitä prosenttiosuutta käytit?

Patrice Embry:

Olin tottunut työskentelemään asiakkuuspäälliköiden kanssa ja ehdotin, että asiakkuudenhallintaan lisätään 20 prosenttia koko projektista. Sen päälle vielä 20 prosenttia projektinhallintaan. Se on paljon.

Ben Aston:

Se on paljon. Yhteensä 40 prosenttia.

Patrice Embry:

Se on paljon. Prosenttiosuus ei aina huomioi kaikkea. Projektityypit, joita tein, eivät... Tämä on kokonaan oma aiheensa, mutta jos alun perin veloitettava loppusumma on väärin laskettu, prosenttiosuudella ei ole merkitystä.
Jos hinta on määritetty huonosti, prosenttiosuuskaan ei ole oikea. Minulla se ei toiminut, koska tunteja ei ollut tarpeeksi. Usein kyse ei ollut vain omista tunneistani, vaan kenelläkään ei ollut tarpeeksi tunteja. Hinnoittelu oli alun perin täysin pielessä. Siksi on tärkeää varmistaa, että arviot ovat oikein ja että projektilla tehdään voittoa. Voi olla, etteivät prosenttiosuudet sinänsä olleet ongelma, vaan se, että ne perustuivat alun perin väärään lukuun.

Ben Aston:

Aivan. Olen itse tottunut ajattelemaan, että projektinhallinnan pitäisi olla 20 prosenttia projektin kokonaiskustannuksista ja asiakkuudenhallinta sen päälle, vaikka se ei olisi aivan 20 prosenttia. Tässä tärkeää on se, että puhuimme vaatimuksista eli projektin vaatimuksista. Myös yksityiskohtainen budjetti ja ennusteet on sovitettava asiakkaaseen. Kaikkea ei tarvitse tehdä yliampuvasti tai liian monimutkaisesti.
Asiakkaan halu ja valmius maksaa vaikuttavat myös. Jos asiakas karttaa riskejä ja haluaa tietää jokaisen yksityiskohdan resurssien erittelystä ja siitä, miten kaikki jakautuu projektin aikana, asia vaatii perehdytystä – ja se maksaa.
On olemassa projektinhallintaohjelmistoja, joihin syötetään luvut alussa ja joissa ajanseuranta ja projekti on yhdistetty samaan järjestelmään. Useimmissa projekteissa kyse on kuitenkin manuaalisesta prosessista. Haemme tuntitiedot jostain, syötämme ne taulukkolaskentaan ja teemme laskelmat. Se on suuri ja kallis tehtävä.
Jos valitset kevyemmän tavan etkä tee yksityiskohtaista budjettierittelyä, miten varmistat aikataulussa ja budjetissa pysymisen? Mikä on kevyempi menetelmäsi, jos et mene näin yksityiskohtiin?

Patrice Embry:

Aiemmin olisin esimerkiksi jakanut kokonaistuntiennusteen rooleittain budjetiksi ja ennusteiksi. Olisin kirjannut toteutuneet tunnit ja muuttanut projektin loppuosan ennusteita. Jos olisin käyttänyt tällä viikolla liikaa aikaa, olisin todennut: ”Tämä on otettava jostain, joten tulevien viikkojen ennusteet muuttuvat.” Jos jokin valmistui nopeammin, olisin säätänyt ennusteita sen mukaan.
Se olisi ensimmäinen asia, jonka jättäisin pois, jos aikaa, budjettia tai kapasiteettia ei olisi riittävän perusteelliseen budjettiin. Ennusteet olisivat alussa olemassa ja näkisin tilanteen, mutta en muuttaisi jokaista ennustetta aina budjettitaulukon päivityksen yhteydessä. Minulla tämä tehtiin kerran viikossa, ja se vei melko paljon aikaa.
Hyvä puoli oli, että huomasin ongelmat varhain ja pystyin nostamaan punaisen lipun aikaisemmin. Se vie kuitenkin paljon aikaa ja maksaa rahaa. Ongelmat voi tunnistaa muillakin tavoilla. Tämä olisi siis ensimmäinen pois jätettävä asia.
Seuraavaksi jättäisin pois kaikki laskelmat, joiden avulla jokainen tietopala voidaan pilkkoa ja järjestää viidellä eri tavalla. Palaisin perusteisiin: olemmeko budjetissa, olemmeko vaarassa ylittää sen, onko jäljellä tarpeeksi tunteja tarvittaviin tehtäviin ja vastaako valmistumisprosentti suunnilleen käytetyn budjetin prosenttiosuutta? Jos kyllä, hyvä, jatketaan.
Älä vie taulukkolaskentaa tai työkalua äärimmilleen, vaan keskity perusteisiin.

Ben Aston:

Tämä on hyödyllistä. On hyvä huomata, että skaalaamme lähestymistapaamme eri projekteihin ja asiakkaille. Suuressa, paljon resursseja vaativassa projektissa kulutusnopeus on paljon suurempi. Jos budjettia kuluu 50 000 viikossa ja puolet viikosta on kulunut, olet käyttänyt jo 25 000.
Suurissa projekteissa meidän on mietittävä, miten seuraamme ja raportoimme budjettia. Se, kuinka syvälle lukuihin mennään, on sovitettava kokonaisbudjettiin.
Jos tiimi on paljon pienempi ja resursseja on vain muutama, datan tarkistamisen viivästymisen vaikutus ei tietenkään ole yhtä suuri.

Patrice Embry:

Tarkistaisin silti kaiken joka viikko. En vain analysoisi näkemääni kohtuuttoman perusteellisesti, vaan suhtautuisin lukuihin hieman enemmän sellaisinaan. Olen tavannut asiakkaita ja minulle alihankintana työskenteleviä urakoitsijoita, joissa asiakas ja minulle maksava henkilö ovat eri henkilöitä. Tämä maksava henkilö toimii enemmän asiakkuuspäällikkönä. Hän on myynyt asiakkaalle kiinteähintaisen työn ja sanoo minulle: ”En oikeastaan välitä, tässä on budjettisi, enkä ole huolissani ylityksistä.” Vastaan: ”Selvä.”
Se on hienoa, mutta jos asioilla ei ole rajoja, tilanne voi lähteä käsistä. Riippumatta siitä, halusitko minun tekevän budjetin, olisin tehnyt sen joka tapauksessa, koska olisi vastuutonta olla tekemättä. Minun täytyy pystyä osoittamaan, mitä kukin on tehnyt ja kuinka paljon aikaa siihen on käytetty. Vaikka joku sanoisi: ”Rahalla ei ole väliä”, se kuulostaa hyvältä, mutta aiheutti minulle oikeastaan hieman ahdistusta, koska mietin: ”Mistä tiedämme, teemmekö tämän oikein?”

Ben Aston:

Se on myös lähes aina harhaanjohtavaa. Kun kuulee sanat ”rahalla ei ole väliä” tai ”ylitämme budjetin, mutta älä huolehdi”, 10 000:n ja 100 000:n tai 500 000:n ylityksellä on suuri ero.

Patrice Embry:

Jonkin ajan kuluttua sitä ei enää huomaa. Budjetti voi ylittyä niin paljon, ettei sillä enää tunnu olevan merkitystä, ja kaikki jatkavat holtittomasti. Se on kamalaa. Olen ollut tällaisissa projekteissa, ja se on hirveää.

Ben Aston:

Tiimi sanoo: ”Niin, ylitimme budjetin jo kolme kuukautta sitten.”

Patrice Embry:

Sitten ei enää välitetä.

Ben Aston:

Ihmiset käyttävät projektiin lisää aikaa ja tilanne pahenee. Kun jäljellä oleva budjetti on nolla, alanko merkitä negatiivisia lukuja?
Jonkun on seurattava tätä. Sivusimme tilannepäivityksiä, jotka ovat yksi artikkelisi aiheista. Kuinka kattavia tilannepäivitysten pitäisi olla? Tilanneraportissa, jonka lähetämme asiakkaille, kerromme yleensä budjetin tilanteesta, tällä viikolla käytetyistä tunneista, meneillään olevasta työstä ja ensi viikolle suunnitellusta työstä. Mukaan voi lisätä myös budjettierittelyjä, ennusteita, riskejä ja ongelmia. Tilanneraporttiin voi laittaa lähes mitä tahansa.
Miten sovitat sen asiakkaalle?

Patrice Embry:

On kiinnostavaa, että projektipäälliköt kokevat alitajuisesti tilanneraporttien kuvastavan projektille tuomaansa arvoa. Jos raportti ei ole perusteellinen, tarkoittaako se, ettet ole hyvä projektipäällikkö?
En halua, että kukaan kysyy: ”Mitä teet kaikilla näillä tunneilla?” Joskus laitamme tilanneraporttiin kaiken osoittaaksemme oman arvomme, osoittaaksemme seuraavamme asioita tai todistaaksemme toimiston arvon. Sen päivittäminen vie paljon aikaa, eikä kaikkea ehkä tarvita.
Kun työskentelin mainitsemani sovelluksen parissa, asiakas ei ollut erityisen teknisesti perehtynyt. Hänelle tärkeää oli vain se, sujuivatko asiat hyvin, valmistuisimmeko sovittuun päivään mennessä ja odotimmeko häneltä jotakin. Hän ei halunnut olla minkään asian pullonkaula. Useimmiten hän ei edes osallistunut tilannepuheluihin, koska hänellä oli muuta tekemistä eikä asia ollut hänelle ensisijainen. Hän halusi tietää vain kolme asiaa: sujuuko kaikki, pysymmekö aikataulussa ja tarvitsetko minulta jotakin.
Laadin tilanneraportteja ja ajattelin: ”Miksi teen tätä? Tätä ei tarvita.” Kirjoitin osiot viime viikolla valmistuneesta työstä, tällä viikolla suunnitellusta työstä ja niin edelleen. Hän ei välittänyt niistä.
Haluan ajatella, että hän luotti minuun, mutta ehkä hänellä ei vain ollut aikaa. Sanotaan kuitenkin, että hän luotti minuun. Hän luotti siihen, että hoidan asiat ja halusi vain tietää, että kaikki oli kunnossa.
Tämä on yksi asiakastyyppi. Asiakkaita on monenlaisia. Olennaista on ajatella tämän projektin asiakasta ja sitä, mikä hänelle on tärkeää. Älä lisää raporttiin asioita vain osoittaaksesi arvosi tai kertoaksesi kaikesta tekemästäsi työstä. Voit luultavasti karsia tilanneraporteista melko paljon, jos keskityt vain siihen, mitä tarvitset tai mitä asiakas haluaa.

Ben Aston:

Erittäin hyvä neuvo. Kun aloitamme projektin, otamme usein edellisen projektin tilanneraportin, vaihdamme asiakkaan nimen ja päivämäärän ja päätämme: ”Tämä oli hyvä, käytetään tätä.”
Sitten huomaat, että raporttiin on lisätty tietoja, joita edellinen asiakas pyysi, ja ajattelet: ”Tuo oli hyödyllistä, tehdään niin uudelleen.” Näin tilanneraportista tulee helposti paisunut. Asiakas ei välttämättä ole kiinnostunut kaikista yksityiskohdista, vaan haluaa vain tietää, sujuuko kaikki hyvin. Annamme tietoja, joita ei oikeastaan tarvita.
Kannattaa miettiä, miten raportin voi aloittaa mahdollisimman suppeana. Jos asiakas haluaa lisää tietoa, hän voi pyytää sitä ja voimme lisätä sen. Kun tilanneraportin laatiminen alkaa viedä tunteja, sen pitäisi olla merkki siitä, että jokin ei ole kunnossa.

Patrice Embry:

Minulla on ollut asiakkaita, jotka ovat pyytäneet erilaisia tapoja tarkastella budjettilukuja tai lisätietoja tekemisestämme. Olen joutunut sanomaan heille, että budjetoin tietyn määrän aikaa tilanneraportteihin ja käytän tällä hetkellä niiden valmisteluun tietyn määrän tunteja viikossa. Jos haluat minun jatkavan näin, se onnistuu, mutta jos haluat lisäyksen, se vie vähintään tunnin lisää raporttia kohden tai puoli tuntia.
Se ei kuulosta paljolta, ennen kuin lasket, kuinka monta tuntia se merkitsee projektin aikana. Oletko varma, että haluat minun tekevän sen? Usein he vastaavat: ”Voisitko tehdä sen kerran ja katsotaan sitten, tarvitsemmeko sitä?” Tai: ”Ei se olekaan niin tärkeää, ajattelin vain, että olisi kiinnostavaa tietää.” Tällä tavalla asiakas voi muuttaa mielensä.

Ben Aston:

Aivan. Kun selität pyynnön seuraukset ja sanot: ”Jos haluat ylimääräisen tunnin viikossa seuraavien 25 viikon ajan—

Patrice Embry:

Oletko varma?

Ben Aston:

—ymmärrätkö, että se maksaa sinulle viisituhatta?” Sitten asiakas toteaa: ”Ei se ole sen arvoista.”

Patrice Embry:

Juuri niin.

Ben Aston:

Selvä, jätetään se tekemättä. Yksi poikkeus on riskialtis projekti tai hankala asiakas. Silloin en menisi aivan vähimmäistasolle, vaan nostaisin riskit esiin tilanneraportissa ja pitäisin keskustelua yllä. Emme halua tehdä raportista niin kevyttä, ettei meillä ole näyttöä siitä, että olemme ilmoittaneet mahdollisista ongelmista.
Kun projekti menee pieleen, emme halua jäädä tyhjän päälle ilman todisteita siitä, että varoitimme asiasta.

Patrice Embry:

Ehdottomasti.

Ben Aston:

Tuo on hyvä periaate.

Patrice Embry:

Nyrkkisääntö voisi olla, että asian voi poistaa vasta, kun olet varma, ettet tarvitse sitä. Sinun on oltava varma, että voit lisätä sen myöhemmin, jos tarve tulee. Varmuus voi perustua aiempaan kokemukseen asiakkaasta, vastaavanlaisesta projektista tai pitkästä työskentelystä projektipäällikkönä. Anna oman mukavuustasosi ohjata päätöstä, jotta et karsi pois jotakin todella tarpeellista.

Ben Aston:

Seuraavaksi puhutaan yhdestä kiinnostavasta aiheesta: kaikista Scrum-seremonioista. Scrumissa on seremonioita, ja ne tekevät Scrumista Scrumia. Jos olet käynyt Scrum Master -koulutuksen, opit nämä kaksi päivää. Kyse on suunnittelusta, katselmoinneista ja retrospektiiveistä. Kun kaikki lisätään projektiin, tehdään viikon sprintti tai kahden viikon sprintti ja käytetään yksi tai kaksi päivää kokouksiin, suunnitteluun ja katselmointeihin. Se vie paljon aikaa.
Ehdotat, ettei kaikkia seremonioita ehkä tarvitse tehdä koko ajan tai että niitä voi yhdistää.

Patrice Embry:

Tunnen ihmisiä, jotka suhtautuvat Scrumiin erittäin tiukasti ja hermostuvat, jos joku ehdottaa erilaista tapaa toimia. Useimmat sertifioidut Scrum Masterit ovat kuitenkin samaa mieltä siitä, ettei projektiin pidä sisällyttää tarpeettomia asioita. Jos tuotteen kehitysjonon tarkennus, sprintin suunnittelu ja sprintin katselmointi tapahtuvat eri päivinä, se voi käydä nopeasti raskaaksi, jos aikaa ja budjettia ei ole.
Paljon riippuu jälleen ajasta ja budjetista. Jos niitä on, anna mennä. Jos ei, harkitse tarkennuksen, suunnittelun ja katselmoinnin yhdistämistä. Yhdistämisestä voi saada vauhtia. Sen sijaan että lopetat yhden asian ja palaat myöhemmin projektiin suunnittelua varten, voit hyödyntää tarkennus- ja katselmointikeskustelun tuomaa jatkumoa suunnittelussa.
Jos käytät kolme tuntia asioihin, jotka voisi saada tehtyä 90 minuutissa tai tunnissa ja vartissa, asiaa kannattaa tarkastella.

Ben Aston:

On hyödyllistä muistaa, ettei näiden tarvitse aina olla erillisiä asioita. Erityisesti retrospektiiveissä, joiden tarkoitus on jatkuva parantaminen, kehitämme jatkuvasti tapaa, jolla hallinnoimme projekteja.
Artikkelissasi mainitset myös, että retrospektiivit kannattaa pitää kevyinä. Olen itse tehnyt retrospektiivejä, joissa lähetetään kysely kaikille, kerätään palaute ja tehdään tilastoja, kuten että 49 prosenttia piti projektia epäonnistuneena ja 25 prosenttia jotain muuta. Mitä sillä oikeastaan tehdään? Mitä aiot tehdä tuolle tiedolle tämän hetken jälkeen?
Asioita voi yhdistää ja retrospektiivin voi suhteuttaa tapahtuneeseen. Joskus toteamme: ”Tämä sprintti meni hyvin.”

Patrice Embry:

Kaikki on kunnossa. Kaikki on hienosti, kaksi peukkua ylös.

Ben Aston:

Silloin tällaisia raportteja ei tarvitse suunnitella liian monimutkaisiksi. Jatketaan vain eteenpäin. Me juutumme helposti ajatukseen: ”Näin minun kuuluu toimia.”

Patrice Embry:

Niin.

Ben Aston:

Sen sijaan pitäisi toimia käytännöllisesti: viedään projekti loppuun.

Patrice Embry:

Aivan. Jos tilanneraportit saavat meidät tuntemaan, että osoitamme arvomme asiakkaille ja perustelemme olemassaolomme heille, retrospektiivit voivat saada meidät perustelemaan olemassaolomme sisäisille sidosryhmille, toimiston omistajille tai yrityksen johdolle. Kysy jälleen itseltäsi: kuinka hyödyllistä tämä on ja onko se viiden työtunnin arvoista? Entä kahden tunnin? Onko minulla viisi tuntia, kaksi tuntia tai edes 30 minuuttia? Jos aikaa on 30 minuuttia, todetaan vain, oliko projekti hyvä ja mikä yksi selkeä asia meni pieleen, tunnistetaan se ja jatketaan.

Ben Aston:

Hyvä. Puhutaan lopuksi aloituskokouksista. Tämä on kiinnostava aihe. Artikkelissasi ehdotat, ettei aloituskokousta ehkä tarvita, vaan sen sijaan voidaan lähettää sähköposti. Miten se toimii? Aloitat uuden projektin, kokoat tiimin, kaikki on resursoitu ja lähetät vain sähköpostin: ”Tässä on, mitä teidän pitää tehdä.”?

Patrice Embry:

Niin.

Ben Aston:

Nähdään viikon päästä.

Patrice Embry:

Kuulostaa hullulta, mutta aloin tehdä näin työskennellessäni lääketeollisuuden toimistossa, jossa tehtiin samankaltaisia projekteja eri asiakkaille. En sanoisi, että ne olivat kaavamaisia, mutta jokaisessa puheenvuorossa tai markkinointimateriaalissa ei ollut paljon uutta. Tämä toimi erityisen hyvin painotuotteissa, joiden parissa työskentelin jonkin aikaa. Tiimit koostuivat lähes aina samoista ihmisistä, ja kaikki oli osoitettu samoille asiakkaille, joten he tunsivat roolinsa. Aloituskokouksessa yksi tehtäväni oli varmistaa, että kaikki tiesivät roolinsa.

Ben Aston:

Aivan.

Patrice Embry:

Kaikki tiesivät roolinsa jo valmiiksi. Oli kaksi suunnittelijaa, yksi kehittäjä ja yleensä kaksi asiakkuuspäällikköä. Kaikki tiesivät, mitä heidän piti tehdä. Kokoonnuimme ja totesimme: ”Minulla on niin paljon tekemistä, ettei minulla ole edes 30 minuuttia aikaa käyttää tähän aloitukseen.” Jos kaikki tietävät roolinsa, asiakkaan ja ovat tehneet vastaavan projektin aiemmin, mitä heidän pitää tietää? Heidän pitää tietää, mikä tekee tästä projektista erilaisen. Kokosin nämä asiat. Heidän piti tietää aikataulu, jonka esittelen muutenkin aloituksessa. Voin puhua aikataulusta, mutta heidän täytyy nähdä se, käsitellä sitä ja omaksua se. He eivät välttämättä pysty antamaan siitä spontaania palautetta kokouksessa, ja haluan antaa heille ensimmäiset tehtävät.
Voin tehdä tämän sähköpostilla, jos kaikki muu on ennestään tuttua. He olivat oikeastaan tyytyväisiä, etten käyttänyt heidän aikaansa siihen, että he istuvat paikallaan ja kuuntelevat minun toistavan samoja asioita. Jos projektit ovat toistettavia ja samat ihmiset tekevät samoja asioita, aloituskokousta ei välttämättä tarvita. Sen voi korvata aloitussähköpostilla. Tein niitä paljon ja ne toimivat hyvin.

Ben Aston:

Ymmärrän. Se toimii, kun kyseessä on toistettava työ. Minun projekteissani on yleensä joku uusi henkilö tai uusi elementti. Yleisemmin kannattaa kysyä: ”Mitä teemme vain siksi, että olemme aina tehneet niin?” Sinä puhut siitä, mitä ihmisten todella täytyy tietää päästäkseen työhön käsiksi. Joskus käytämme liikaa aikaa myös toimeksiantojen kirjoittamiseen.
Toimeksiannot ovat tärkeitä ja hyödyllisiä, mutta mallipohjassa on usein kohtia, joissa ajattelee: ”Minun on kopioitava tämä sama asia uudelleen ja vaihdettava kolme sanaa.” Jos tiimi on sama, kannattaa tehdä toimeksiantoprosessista tehokkaampi eikä käyttää aikaa asioiden toistamiseen.

Patrice Embry:

Niin.

Ben Aston:

Keskitytään siihen, mitä yritämme tehdä, mitä tarvitset muiden tekevän ja mitkä tehtävät pitää saada valmiiksi. Älkää lähestykö kaikkea kaavamaisesti tai samalla mallipohjalla. Tämän keskustelun tärkein oppi on kohdella jokaista projektia erityistapauksena. Se, että käytit viimeksi paljon aikaa jonkin asian tekemiseen hyvin, ei tarkoita, että sama prosessi, dokumentaatio ja perusteellisuus tarvitaan jokaisessa projektissa. Asioita voi tehdä eri tavoin. Kaikkea ei tarvitse tehdä joka kerta samalla tavalla. Sovita toimintatapa projektiin.

Patrice Embry:

Ehdottomasti.

Ben Aston:

Hienoa. Patrice, kiitos paljon osallistumisestasi. On ollut hienoa saada sinut mukaan. Jos haluat osallistua tämänpäiväiseen keskusteluun, kommentoi Patricen artikkelia tai siirry thedigitalprojectmanager.com-sivuston yhteisöosioon ja liity keskusteluun siellä. Ensi kertaan asti, kiitos kuuntelusta.