Kokenut IT-projektipäällikkö
Kokenut projektipäällikkö tunnistaa kipukohdat ja mukauttaa menetelmät tilanteen mukaan

Menestyvän projektipäällikön salaisuus piilee usein siinä, että hän saa luotua sujuvat yhteistyökuviot liiketoiminnan ja IT-yksikön välillä. Tämä tarkoittaa mm. toimivaa tiedonkulkua, jossa jokainen organisaation osa saa tarvitsemansa tiedot projektin etenemisestä silloin, kun tietoa tarvitaan. Projektipäällikkö huolehtii siitä, että projektille on määritetty selkeät liiketoimintavaatimukset ja varmistaa, että projekti tuottaa aidosti arvoa yritykselle.

Tuotteen kehitysjonosta, eli Product Backlogista luodaan tiekartta myynnille. Talouden vuosibudjetista hahmotellaan sprinttien eli kehitysjunien koot. Samalla projektipäällikön on pidettävä huolta siitä, ettei jouduta ketteryysansaan. Kehitystiimit ovat ehkä vannoutuneita ketteryyden kannattajia ja alihankkijat saattavat toimia luontevasti sprinttien maailmassa. Jos kuitenkin liiketoimintapuolella päätöksentekomekanismit ja suunnittelu eivät vielä taivu siihen, että tuoteomistajina jatkuvasti priorisoidaan Backlogia, niin lopputulos ei silti ole kovin ketterä.

Parhaiten ovat onnistuneet ne projektit, joissa toiminta on mukautettu organisaation ja projektin sisällön mukaan. Kokenut projektipäällikkö tunnistaa organisaation kipukohdat ja soveltaa juuri siihen projektiin parhaiten toimivat käytännöt. Usein tämä tarkoittaa sitä, että vaatimusmäärittely ja julkaisunhallinta toimivat vesiputousmallisesti, kun taas varsinainen kehitystyö viedään läpi ketterästi. Paketoidaan ketteryys ympäröivään vesiputousmaailmaan.

Onnistuneen projektin resepti

Kun projekteja käynnistetään, määritetään useimmiten sisältö, aikataulu ja budjetti. Miten silti tehdä projektista ketterä? Toimiva konsepti voi olla antaa liiketoiminnan pysyä suhteellisen vesiputousmaisena, mutta viedään kehityssyklit ketterästi läpi. Ketteryys paketoidaan projektin sisälle ja sen ulkopuoliset asiat saavat pysyä ennallaan. Menestyksen resepti voidaan jakaa neljään vaiheeseen.

1. Projektin laajuus ja vaatimusten määrittely

Tavoitteiden ja vaatimusten määrittäminen on onnistuneen projektin ensimmäinen askel. Sidosryhmien odotukset selvitetään ja loppuasiakkaiden käyttötarpeet sekä tekniset reunaehdot käydään läpi. Esiselvitysvaihe on hieman kiistelty käsite, koska ketterän filosofian mukaan tätä ei tehdä ollenkaan, vaan tuoteomistaja valitsee käyttäjätarinat ja priorisoinnit projektin kuluessa.

Kokemus on osoittanut, että ilman selkeätä visiota kehitystiimi ei välttämättä ymmärrä mitä ongelmaa ollaan ratkaisemassa. Ratkaisut voivat olla teknisesti onnistuneita, mutta ne eivät ratkaise itse perusongelmaa. Määrittelyvaiheessa vastataan seuraavaan kysymykseen: mikä on se ydinhyöty, joka meidän tulee saavuttaa, vaikka matkan varrella moni asia ehtiikin muuttua?

Tämä vaihe voi siis toimia melko vesiputousmallisesti, kunhan pidetään mielessä, että tavoitteena ei ole täydellinen maailma. Voidaan vaikkapa määritellä, että on tarve luoda itsepalveluportaali, mutta jätetään portaalin yksityiskohdat kehitystiimille, koska vielä tässä vaiheessa ei tiedetä täysin, mikä toimii ja mikä ei.

2. Projektin tuotokset ja tiedottaminen

Puhtaasti ketterässä mallissa MVP, eli pienin julkaisukelpoinen tuote syntyy pikkuhiljaa kehityksen jo startattua. Usein on kuitenkin tarve tietää jo paljon aikaisemmin mitä on tulossa, esimerkiksi myynnin ja markkinoinnin valmistautumista varten. Tätä voidaan ratkaista käyttämällä heti alussa enemmän aikaa Product Backlogin rakentamiseen ja priorisointiin. Rakennetaan riittävän tarkka tiekartta ja aikataulu liiketoiminnan tarpeille, vaikka kehitystiimi ei itse vielä tarvitsisi niin yksityiskohtaista tietoa.

Tässä vaiheessa tuodaan siis vesiputousmaailma mukaan ketterään kehitykseen, mutta toki vain sille tasolla, josta on aidosti lisäarvoa. MVP:n määrittäminen auttaa tiedottamisessa ja se helpottaa Business Casen päivittämisessä sekä budjetin varmistamisessa. Tiekartan avulla projektin omistajalle voidaan osoittaa, mitä on tulossa ja missä vaiheessa. Ainakin liiketoimintavaatimusten kokonaisuudet ja käyttäjätarinat kannattaa määritellä valmiiksi ja tuoda selkeästi esiin niiden tuoma lisäarvo.

Jos ajatuksena on ostaa kehitystyö kumppanilta, niin sopimusneuvotteluja on helpompi käydä, kun projektin suuruusluokka ja laajuus ovat jo tiedossa.

3. Kehittäminen ja testaaminen

Olettaen, että kehitystiimi tuntee ketterät toimintamallit ja on sitoutunut niihin, voi tätä vaihetta pitää täysin ketteränä. Sprinttien tai kanban-taulujen kautta kehitystä viedään eteenpäin siten, että tuoteomistaja on aktiivisesti mukana priorisoimassa ja hyväksymässä muutokset. Mutta koska projektin päätuotokset on jo pääpiirteiltään määritelty, niin muutokset ovat harvemmin niin suuria, että tiekartta tai budjetti menisivät tässä vaiheessa kokonaan uusiksi. Liiketoiminnan näkökulmasta saadaan mitä alun perin tilattiinkin, ja muut yksiköt voivat edetä omissa suunnitelmissaan sovitusti.

4. Julkaisut ja ylläpito

Jotta liiketoiminta pystyy suunnittelemaan asiakasviestintää, hinnoittelua ja vastaavia asioita, on uudet palvelukokonaisuudet otettava hallitusti käyttöön. Täysin ketterässä organisaatiossa julkaisupäivämäärät eläisivät sen mukaan, miten kehitystiimi saa tärkeimmät tehtävät valmiiksi. Usein kuitenkin julkaisupäivämäärät lyödään ensin lukkoon, esimerkiksi vuodeksi eteenpäin ja projektin tulee noudattaa niitä.

Ketterässäkin projektissa pitää siis usein mukautua valmiiksi aikataulutettuihin käyttöönottoihin. Jos julkaisukelpoiset kokonaisuudet on jo heti alussa hahmoteltu tiekartalle, julkaisusuunnittelu voi nojata niihin. Tässäkin onnistumisen salaisuus on siinä, että jätetään riittävästi joustovaraa. Tiedetään, milloin itsepalveluportaali otetaan tuotantokäyttöön, jolloin muutokset muihin järjestelmiin ja asiakkaisiin voidaan valmistella ja aikatauluttaa. Ymmärretään samalla, että lista julkaistavista toiminnallisuuksista voi vielä muuttua kehityksen aikana.

Ylläpidossa on yleensä tarve jatkuviin pieniin parannuksiin ja korjauksiin. Ketterän mallin jatkuva tuotantoon vienti (DevOps) puree tähän poistamalla isojen käyttöönottojen tuomat katkokset ja riskit. Jos ketteryyttä riittää, niin ei ole esteitä sille, miksei isojen julkaisujen välissä voisi viedä pienet korjaukset ja lisäykset ketterästi tuotantoon asti.

Hankepäällikkö Mats

Mats Lindstedt

Reflectorin tuore konsultti Mats Lindstedt tuo mukanaan yli 20 vuoden kokemuksen projektinhallinnasta. Mats tutustui projektimaailmaan Ericssonin ja Siemensin isojen järjestelmähankkeiden kautta. Nämä olivat vuosia kestäviä hankkeita, joissa koordinointiin tuhansien ihmisten työpanoksia ympäri maailmaa. Sen jälkeen ovat mukaan kuvaan tulleet ketterät ja nopeat kehityshankkeet, asiakastoimitusprojektit ja julkisen sektorin EU-rahalla tuetut hankkeet.

Reflector on ICT-talo, jonka ykköstehtävä on auttaa asiakkaitamme liiketoiminnan isoissa ja pienissä muutoshankkeissa. Ketterästi ja riippumattomasti.

Jaa artikkeli

Voisit pitää myös näistä:

strateginen kehittäminen

DevOps ja projektin tietoturva

DevSecOps: lisää mystisiä kirjainlyhenteitä. Rakettitiedettä? Ei laisinkaan, mutta silti monimutkaista. Voidaanko tähän panostaa liikaa? Ei varmastikaan. Mitä “Sec” tarkoittaa tässä yhteydessä? Se on

Lue lisää
Yritysarkkitehtuuri konsultti

Datan hyötykäytön anatomiaa

Miten dataa pitäisi hyödyntää? Mikä osa datasta on relevanttia ja mikä voidaan sivuuttaa? Miten ihmiset liittyvät datan hyödyntämiseen? Näihin kysymyksiin nykypäivän dataintensiivisessä ympäristössä

Lue lisää
Kokonaisarkkitehtuuri Reflector

Ota yhteyttä, mietitään yhdessä juuri teille parhaat ratkaisut

Täytä tiedot ja siirry lataamaan tutkimus

Kokonaisarkkitehtuuri Reflector

Get in touch!