Mikä on paras projektijohtamisen malli, entä onnistuuko ketterä hanke automaattisesti? Blogissa pureudutaan IT-hankkeiden sudenkuoppiin ja menestystekijöihin. Tiedätkö, mitkä ovat projektibisneksen seitsemän kuolemansyntiä?
Projektissa on kolme tasoa
- Projektin myynti, sopimusmalli ja projektinjohtomalli. Tässä asetetaan peruskivi luottamukselle ja avoimuudelle.
- Projektinhallinta. Tämä vaatii osaamista toimittajan puolelta ja sitoutumista asiakkaan puolelta. Sekä asiakkaan että toimittajien tulee aidosti sitoutua hankkeeseen. Asiat tulevat muuttumaan puolin ja toisin. Tärkeintä on vahva ja avoin tuotejohtajuus asiakkaan puolelta, sekä tiivis sitoutuminen toimittajan puolelta.
- Järjestelmäkehitys. Vaatii paljon osaamista ja kurinalaisuutta tiimiltä. Pitää keskittyä sekä lyhyen että pitkän aikavälin tavoitteisiin. Tehdään nopeasti demottavaa ja samalla tehdään ylläpidettävää, dokumentoitua ja automatisoitua.
Projektissa voidaan epäonnistua jokaisella näistä tasoista ja ajallisesti missä tahansa vaiheessa projektia. Ainoa salaisuus onnistuneelle projektille on, ettei sitä tunaroida missään vaiheessa, millään tasolla.
Paras projektinjohtomalli? Onko vesiputous automaattinen epäonnistuminen?
Taannoin Tivin Kari Ahokas kysyi erinomaiseen Onnistumisen salaisuus projektinhallinta-artikkeliinsa, että mikä on paras malli projektinjohtamiseen. Tarkoittaako vesiputousmalli aina epäonnistuvaa projektia? Onnistuuko ketterä hanke automaattisesti?
Itse sanoisin, että IT-hanke onnistuu, kun win-win ajattelu toteutuu alusta loppuun. Eli asiakas, loppukäyttäjät, projektissa työskentelevät asiantuntijat, sekä projektiin osaa ottavat liikelaitokset ovat projektiin tyytyväisiä. Kääntäen projekti voidaan munata minä hetkenä hyvänsä ensimmäisistä keskusteluista aina loppuraporttiin. Ei ole mitään neutraalia tilaa, missä projekti ei enää voisi epäonnistua. Vähän samalla tavalla kuin ihminen pysyy pystyssä. Tietoinen ja tiedostamaton hermosto käskyttävät lihaksia jatkuvasti, jotta ihminen pysyy pystyssä. Älykästä, hienovaraista ja jatkuvaa. Voimalla tilannetta ei pelasteta kuten voi nähdä etälamauttimella pysäytettävästä ihmisestä. Vaikka kaikki lihakset jännittyvät sähkövirran avustamina ja täysillä, niin henkilö kaatuu silti. Ainoa kysymys on, että kaadutaanko naamalleen vai selälleen.
Itse sanoisin, että onnistuneessa hankkeessa yhdistyvät onnistunut liiketoiminnallinen, projektihallinnollinen ja ohjelmistokehitysosaaminen.
Sopimus ja liiketoiminta
Sopimuksista olen kirjoittanut jo legendaarisessa blogissani. Ehkä jatkaisin tuota vanhaa ajatteluketjuani, että erilaiset sopimusmallit siis luonnollisesti sopivat erilaisiin hankintoihin. Jos hankitaan yksinkertaista ja pientä kokonaisuutta, niin toki helpointa on edetä kiinteällä hinnalla. Jos taas tehdään jotain ennen näkemätöntä ja suurta, niin työ kannattaa vaiheistaa sekä sopimus-, projektitasolla.
Mitkä tekijät yhdistävät onnistuneita hankkeita?
Onnistuneissa projekteissa on monia onnistumisen elementtejä.
Win-win ajattelu heijastuu joka tasolla psykologisena turvallisuutena. Uskalletaan sanoa mieltä vaivaavista asioista, sanotaan niistä niin, että kukaan ei suutu ja toisaalta ei suututa, kun asioista sanotaan. Oli kyse sopimuksesta, projektin vedosta tai teknisestä asiasta, niin asiaan pitää uskaltaa puuttua.
Sopimus tukee kaikkien osapuolien liiketoiminnallisia tavoitteita. Sopimusteknisesti siis heijastellaan win-win ajattelua. Sopimusmalli määrittää kuka kantaa riskin. Tämä ei ota kantaa projektin onnistumiseen vaan osapuolien sitoutumiseen.
Projektinjohtoprosessi on sopiva valittuun toimintaympäristöön. Jos tehdään pieniä MVP -kokeiluja, niin edetään kevyesti ja jos kyseessä on pitkä, mutkikas hanke, niin sitten panostetaan rakenteisiin enemmän. Projektille on myös varattu perustellusti aikaa ja rahaa suhteessa tavoiteltuihin ominaisuuksiin ja laatuun. Ohjelmistokehityksessä on suuri potentiaali siinä, että voidaan tehdä nopeasti jotain kokeiltavaa. Kannattaa ehdottomasti käyttää ketterän kehityksen menetelmiä ja jatkuvan integraation sekä jatkuvan toimituksen menetelmiä, jos voi. Projektin epäonnistuminen johtunee harvoin projektimallista. Yleisempiä syitä on luottamuksen puute ja kommunikaatio-ongelmat, sekä toisaalta ihan raaka osaamisen puute.
Projektin vedossa osoitetaan luottamusta, yhteistyötä, puhalletaan yhteen hiileen, parannetaan jatkuvasti ja nöyrästi, sekä tsempataan hyvään yhteishenkeen ja motivaatioon. Asiapuolella tehdään jatkuvasti jotain kokeiltavaa ja hypisteltävää, mihin asiakas voi antaa palautetta. Demot ja hypistelyt toimivat katalyyttina keskustelulle siitä, että mitä asiakas oikeasti haluaa. Ollaanko nyt varmasti ymmärretty molemmin puolin oikein. Lopuksi uskalletaan muuttaa isojakin kokonaisuuksia, jos homma meinaa mennä metsään. Iso muutos voi olla myös projektin ennenaikainen lopettaminen. Tämä on aina fiksumpi päätös, kuin uusi Olkiluoto 3.
Teknisellä puolella osoitetaan ymmärrystä ja innostusta DevOps ajatteluun. Julkaisut valuvat portaittain kehitys – testi – tuotantoympäristöt. Asioita voidaan viedä ja ottaa pois tuotannosta vaivattomasti pienissä, hallittavissa paloissa. Sekä Dev, että Ops puolia mittaroidaan ja hallitaan automaattisesti. Kaikki mahdollinen testeistä julkaisuprosessiin automatisoidaan. Tästä on toki etukäteen enemmän vaivaa, mutta vältytään manuaalisilta virheiltä ja viivästyksiltä jatkossa. Siinä missä projektinjohto ensimmäisenä unohtaa jatkuvaan parantamiseen ohjaavat retrospektiivit, niin kehitystiimit etsivät tekosyitä, miksi kyseisessä projektissa tai toimintaympäristössä asiat eivät olisi automatisoitavissa. Ja näin syntyy teknistä velkaa projektin loppua kohti.
Projektibisneksen seitsemän kuolemansyntiä
- Ylpeys: ollaan tehty tää ennenkin, älkää tulko meille kertomaan
- Ahneus: epärealistiset odotukset ja osapuolien huijaaminen
- Himo: Katse ei pysy pallossa, kun koko ajan olisi jotain kiinnostavampaa tehtävää ja fokus tavoitteeseen katoaa
- Kateus: Katse ei pysy pallossa, koska muut tekevät asiat paremmin ja fokus tavoitteeseen katoaa
- Ylensyönti: Asiat pitää priorisoida ja tehdä pienissä paloissa
- Viha: Oletetaan että joku tekee asioita ilkeyttään, muulla kuin win-win asenteella. Tämä ”blame frame” pysäyttää kaiken hyvän. Epäluottamuksen löytää aina edestään.
- Laiskuus: ei olla valmiita elinikäiseen oppimiseen ja jatkuvaan epämukavuusalueella vierailuun.
Hankkeen voi pelasta vaikka synnit päätään nostaisivatkin. Hankkeen tulevaisuudesta tulee keskustella avoimesti kaikkien sidosryhmien kesken ja käydä läpi millaisia riskejä on realisoitunut. Tämän jälkeen aivoriiheillään mahdollisia vaihtoehtoja eteenpäin. Vaihtoehdoista valitaan muutama skenaario ja arvioidaan paljonko aikaa sekä rahaa takaisin raiteille pääseminen vie. Voiko tilanteen kääntää jollain tavalla mahdollisuudeksi tai eduksi? Tämän jälkeen pohditaan, että onko meillä toisaalta varaa tai kanttia keskeyttäkään projektia.
Miten onnistumista voi mitata?
Jos sekä tilaaja, toimittaja että loppukäyttäjät ovat it-hankkeeseen tyytyväisiä, sitä ei voi pitää epäonnistuneena. Samoin projekti voi valmistua kriteerien mukaisesti – ja osoittautua käytännössä sudeksi.
Projektinjohtoprosessiin tulee sisään rakentaa projektin aika-raha-sisältö-laatu mittarointi. Tämä on hygieniatekijä. Reaaliajassa tiedetään läpinäkyvästi, että minkä verran aikaa ja rahaa on mennyt, mikä on projektin vauhti eteenpäin kyseisellä kulutustahdilla, ja mitkä ovat seuraavat tavoitteet. Teknisellä puolella on paljon hyviä automatisoitavia mittareita, kuten testikattavuus, luotettavuus ja tehokkuus sekä laadullisia mittareita kuten käytettävyys, ylläpidettävyys ja siirrettävyys. Kun nämä hygieniamittarit on saatu alta pois, niin keskitytään mittaroimaan aitoa win-win kyvykkyyttä; kokeeko asiakas, loppukäyttäjä ja tiimiläiset saavansa projektista riittävää lisäarvoa? Tässä usein tuoteomistajalla on vahva rooli kehitystiimin ja kohdeorganisaation välisenä liimana.
Merkittävin asia, minkä projektin osapuolet voivat tehdä hankkeen onnistumisen eteen, on ajaa läpinäkyvyyttä ja win-win ajattelua avoimesti joka käänteessä. Haetaan ratkaisuja, jotka tuottavat lisäarvoa loppukäyttäjälle, asiakasorganisaatiolle, projektitiimille ja toimittajaorganisaatiolle. Projektin aikana kannattaa joka tasolla pitää katse pallossa loppuun asti. Ensin tehdä käynnissä oleva projekti kunnialla valmiiksi ja vasta sitten keskittyä seuraavaan. Pohdi mikä on oleellista ja keskity tekemään se hyvin. Näin et voi epäonnistua.
