Vaikka maailmassa on paljon start up -firmoja ja pienempiä yrityksiä, joiden tuotekehitysprojektit ovat ”yhden tiimin” kokoluokkaa, lienee totta, että eniten maailmaa muuttavat uudet tuotteet ovat suurien tuotekehitysprogrammien tulosta. Vaikka pienet tiimit ovatkin ehkä yksittäin tehokkaampia kuin suuret projektiorganisaatiot, niin joskus työtä on niin paljon ja sen tekeminen vaatii niin laajaa osaamista, että suuri projektiorganisaatio on ainoa mahdollinen keino saada haluttu työ tehtyä. Välillä asioita pitää tehdä isosti.

Vaikka käytettävissä olisi isonkin yrityksen voimavarat, suuren projektin käynnistys on valtava työ – paine projektista vetovastuussa olevan niskassa on suuri. Tämänkaltaisessa ponnistuksessa on monta sudenkuoppaa, mutta haluaisin nostaa neljä mielestäni suurinta esiin:

Paljon uusia naamoja – ei vielä yhteisiä pelisääntöjä

Kun tyhjästä kasataan ryhmä ihmisiä – vaikka olisi kyse isostakin yrityksestä – on todennäköistä, että kaikki eivät tunne toisiaan tai ole tehneet aikaisemmin töitä keskenään. Mukaan saatetaan myös palkata uusia ihmisiä tai konsultteja, jos ihmisiä ei ole löytynyt. Suurena haasteena on siis se, miten porukka saadaan luottamaan toisiinsa ja tekemään töitä tehokkaasti yhdessä. Kun töitä on tehty muutaman kuukauden ajan, yhteinen sävel alkaa vihdoin löytyä, mutta ihan alussa työteho on normaalia alempi, kun vasta rakennetaan luottamusta.

Vanhat kunnon kick off -tapahtumat, joissa ihmiset pääsevät tutustumaan työn ulkopuolellakin, ovat erinomaisia tapoja saada projekti hyvin alkuun.

Luottamus syntyy, kun ihmiset oppivat tuntemaan toisensa ja toistensa toimintatavat. Tähän kannattaa panostaa alkuvaiheessa paljon. Vanhat kunnon kick off -tapahtumat, joissa ihmiset pääsevät tutustumaan työn ulkopuolellakin, ovat erinomaisia tapoja saada projekti hyvin alkuun. Hintaahan näille tapahtumille kyllä tulee, mutta se maksaa itsensä aivan varmasti takaisin. Jos ihmisten yhteen saattaminen ei ole suoraan mahdollista, niin kannattaa miettiä muita keinoja, joilla ihmiset saadaan avautumaan ja madaltamaan kynnystä keskustella toistensa kanssa.

Luottamus ja yhteiset työtavat syntyvät yhteisistä onnistumisista, lupausten pitämisestä ja hyvästä kommunikaatiosta. Team building olisi tärkeää, mutta aivan yhtä tärkeää on, että kommunikoidaan koko porukalla avoimesti, pidetään tehdyt lupaukset luottamuksen kasvamiseksi, ja kannustetaan kaikkia olemaan avoimia ja kyselemään myös tyhmiä kysymyksiä. Olisi varottava, ettei kenenkään mielipiteitä tyrmätä. Näin tiimihenki ja tehokkuus kasvaa nopeiten!

Norsulla on pitkä kärsä, mutta se ei käänny kovin ketterästi

Isoissa firmoissa on yleensä hitaammat prosessit, omat IT-osastot ynnä muuta, mikä voi tuoda projektin alkutaipaleelle yllättäviä jarrutekijöitä. Kestääkö serverien saanti kuukausia? Uusia työntekijöitä aloittaa. Mistä puhelimet ja läppärit? Onko uusille työntekijöille pakollisia koulutuksia, joidenka käyminen syö työaikaa? Näiden kanssa on osittain pakko elää – ehkä kannattaa muistaa, että isolla firmalla on sentään resursseja tehdä hankintoja ihan eri tavalla kuin pienillä. Voisi kuitenkin miettiä, että voisiko projekti saada jonkinlaisen ”hotlinen” esimerkiksi IT-hankintoihin, millä voisi nopeuttaa ostoprosessia.

Projektin jäsenten kannattaa kysellä aktiivisesti – ei oleteta, että muut tekevät asioita, vaan selvitetään, mikä asioiden todellinen tilanne on.

Voisiko esimerkiksi IT-osastolla olla yksi ihminen, joka hoitaisi projektin osalta kaikki hankinnat? Pahimmillaan projektin käynnistys jää odottamaan jotain, ja kaikki luulevat asian olevan hoidossa, mutta vasta myöhemmin huomataan, että oho, pallo on pudonnut jossain vaiheessa ja mitään ei olekaan tehty. Projektin jäsenten kannattaa myös kysellä aktiivisesti ja tuntea omasta tuskastaan omistajuutta – ei oleteta, että muut tekevät asioita, vaan selvitetään, mikä asioiden todellinen tilanne on. Tässäkin yksi yhteyshenkilö per firman tukitoiminto voisi olla hyvä idea.

Liian hidas syke alussa

Yksi kovin yleinen ongelma, joka tuntuu toistuvan helpommin sitä useammin mitä isompi hanke on, on se, että projektin alkuvaiheessa on todella hankala saavuttaa samanlainen ”syke”, mikä projektin puolivälissä on arkipäivää. Kun projektin puolivälissä jatkuva integrointi toimii vähintään päivä-, tai useimmiten nykyään jo commit-tasolla, ja tiimien sprinttirutiinit plänäyksineen ja demoinen ovat hyvällä mallilla. Projektin alussa nämä kaikki kehitystä tahdittavat rutiinit puuttuvat. CI-infran pystytys tuntuu suurelta hankkeelta itsessään, ja tiimit vasta ihmettelevät, että mitä oikeastaan pitäisi tehdä.

”Kuuluuko – kuuntelen?”

Tuntuu houkuttelevalta käyttää alussa paljon aikaa määrittelyyn, mitä oikeastaan pitäisi tehdä. Tämä onkin aivan perusteltua, mutta riskinä on se että mennään liikaa vesiputousmallin tapaisesti – ensin määrittelyvaihe ja sitten implementoidaan. Parempi olisi miettiä, miten saataisiin heti alusta (kuten ketterän kehityksen perusteesitkin korostavat) jotain toimivaa softaa aikaiseksi. Projektin alkutaipaleella on tärkeää pyrkiä kyllä määrittelemään, mitä tullaan tekemään, mutta pitäisi myös tiedostaa, mitä voidaan tehdä jo nyt, ja pyrkiä pois vesiputousmallisesta ”baseline requirement versio on kohta valmis” -ajattelusta.

Jos vain on mahdollista, pitäisi mahdollisimman aikaisessa vaiheessa pyrkiä rakentamaan ratkaisun runko.

Jos vain on mahdollista, pitäisi mahdollisimman aikaisessa vaiheessa pyrkiä rakentamaan ratkaisun runko. Parhaassa tapauksessa tiimit, jotka heti alusta lähtien juttelevat toistensa kanssa, voivat lähteä yhdessä implementoimaan komponenttiratkaisuja jopa niin, että jonkinlaista end to end -toiminnallisuutta päästään kokeilemaan hyvin pian. Se, mitä toiminnallisuutta ja kuinka näkyvää ja lopullisen näköistä se on, ei ole tärkeää. Tärkeää on saada eri tiimit ja komponentit heti alusta integroitumaan keskenään.

Vedetäänkö matto alta? Paras kerätä maton päälle mahdollisimman paljon painoa….

Olin kerran mukana projektissa, jossa johdon tavoitteena oli kasvattaa projektiorganisaatiota niin nopeasti ja isoksi että saavutettaisiin ”kriittinen massa”. Ei saa nauraa, ihan oikeasti käytettiin tuota termiä! En ole ihan varma, mitä tuon massan olisi pitänyt turvata, mutta epäilen, että yksi asia oli se, että mitä isompi hanke ja organisaatio on saatu kasvatettua, sitä hankalampi hanketta olisi johdon enää keskeyttää.

Tuossa mennään nyt metsään ja rankasti (ja niin tuossa projektissa sitten kävikin). Jos projektin vetäjien suurin pelko on se, että projekti keskeytetään, ja he miettivät lähinnä sitä miten tältä voitaisiin välttyä, eli miten luodaan vaikutelma siitä, että projekti etenee oikealla raiteella ja asioita saadaan aikaan. Silloin on selkeänä riskinä se, että ei keskitytä siihen mitä oikeasti pitäisi tehdä, jotta ratkaisusta jota kehitetään, tulisi mahdollisimman oikea. Myös projektiorganisaation oikeanlainen kasvattaminen saattaa unohtua kuten voimamieheltä, joka vain haluaa lisää massaa, mutta ei mieti lihaksia tai oikeaa voiman lisäystä.

Isossa projektissa ulkoinen apu alussa maksaa itsensä moninkertaisesti takaisin

Mitä isompi projekti, sitä tärkeämpi olisi käyttää projektin alussa ulkoista apua.

Mitä isompi projekti, sitä tärkeämpi olisi käyttää projektin alussa ulkoista apua. Ulkoinen konsultti tai coach voi ilman suurempia pelkoja nostaa esille asioita, joita yrityksen omalla palkkalistalla olevat ihmiset epäröivät tuoda esiin. Coach voi auttaa uusia tiimejä joilla ei ole vielä yhdessä tekemisen rutiineja, parantamaan toimintaansa todella tehokkaasti. Lisäksi ulkoinen valmentaja, joka ei ole sen enempää sidoksissa yhteenkään yksittäiseen tiimiin tai organisaation osaan, voi helposti löytää asioita jotka auttavat tiimien yhteistoiminnassa. Esimerkiksi hostatut retrospektivet tiimeissä tai ”retro-of-retros” ja ”scrum of scrums” ja näiden seremonioiden toimivuus voivat olla asioita joissa coach voi olla avuksi. Ulkoapäin katsoen kokonaisuus on helpompi hahmottaa, varsinkin kun coachilla ei ole varsinaista projektin deliveraabeleihin liittyvää vastuuta.

Valmentajan vaikutus on suurin aivan projektin alkumetreillä. Jos odotetaan siihen asti, kun tiimeissä alkaa esiintyä vaikeuksia tai tyytymättömyyttä, tai projekti ei saavuttanutkaan sille asetettuja odotuksia, ulkoisella avulla on vähemmän etuja. Vaikka kyllä hyvä coach voi silloinkin vielä auttaa palauttamaan projektitiimit oikealle uralle.

Contribytella on laaja kokemus sekä portfoliohallinnasta että myös tuotekehitysprojektien alkutaipaleen valmennuksista ja koulutuksista. Häviävän pienellä investoinnilla koko projektin kustannukseen verrattuna voit auttaa oman projektisi oikealle uralle. Ota meihin yhteyttä ja räätälöidään juuri sinulle sopivat palvelut!