Yhä suurempi osa projekteista tehdään ketterin menetelmin. Päätös mallista voi olla toimittaja suositus tai asiakkaan vaatimus. Usein taustalla on tarve korjata aikaisemman projektimallin ongelmakohtia. Tarkastelen tässä kirjoituksessa tilannetta yksittäisten projektien näkökulmasta, jolloin kyse ei suoranaisesti ole ketterästä organisaatiosta tai koko organisaation siirtymisestä toimimaan jonkun ketterän metodologian mukaisesti. Koko organisaation muutoksessa on aina kyse toiminnanmuutoshankkeesta, jolla on oma tavoite. Tällaista tavoitetta ei tulisi asettaa yksittäiselle toimitusprojektille.
Oletko ollut tilanteessa, jossa sinistä taivasta vasten piirtynyt auringon valossa hehkuva alppimaisen terävä arvoa tuottavan projektikolmion silhuetti olikin lässähtänyt pohjoissuomalaiseksi sumun peittämäksi tunturiksi.
Seuraavan kehityshankkeen alussa on käyty keskustelu, miten tilanteen toistuminen voidaan välttää. Analyysissä paljastuu haasteita liiketoiminnan tarpeen ymmärtämisessä ja muuntamisessa vaatimuksiksi. Muutoksia on tullut odotettua enemmän ja niiden hallinnassa on ollut ongelmia. Molemmat osapuolet toivovat parempaa kommunikaatiota. Myös päätöksenteon viiveet ovat ainakin toimittajan mielestä vaikuttaneet kustannuksiin ja aikatauluun. Asiakas toivoo jatkossa toimintaan ketteryyttä, joilla juuri näihin osa-alueisiin voidaan tuoda parannusta. Lessons learnt -tapaamisen muistiinpanoissa todetaan lyhyesti, että tavoitellut hyödyt eivät toteutuneet täysimittaisina.
Ketteryyteen kannattaa pyrkiä
Ketterien mallien tuomien hyötyjen toteutumiseen uskotaan kuitenkin vahvasti ja hyvä niin, koska onnistuneiden ketterien projektien määrä on kuitenkin suuri. Vuonna 2015 julkaistun Agile is the new normal – Adopting Agile project management –raportin raportin mukaan ketterään kehitykseen uskotaan ja ketterät mallit leviävät voimakkaasti. Pääosin ketteriä menetelmiä projektityössään hyödyntäviä yrityksiä on 16%. Oman kokemukseni mukaan yksi keskeinen ohjaava tekijä ketterän projektimallin käyttöönottoon on nimenomaan ratkaista joku aikaisemman projektin ongelma ja ongelmaa lähdetään ratkaisemaan Hybrid tai Leaning toward agile -tyyppisesti eli ottamalla käyttöön ketterien menetelmien osa-alueita.
Määritelmä on varsin väljä ja voi käytännössä kattaa mitä vain kokeiluja erilaisista iteraatiomalleista jatkuvaan integrointiin. Määrittelyllä ei tässä yhteydessä ole merkitystä, vaan kyselytutkimus vain vahvistaa organisaatioiden kiinnostuksen ketteriä menetelmiä kohtaan.
Lähde: https://techbeacon.com/survey-agile-new-norm
Ketterällä mallilla on paremmat mahdollisuudet onnistua
Onnistuneen projektin toteutus on menetelmästä riippumatta haastavaa. Myyntivaiheen odotusarvot, sopimuksen sisältö ja miten sisältö on ymmärretty, johdon tuki, ammattitaitoinen toteutus, osallistuva ja osoitettuihin tehtäviin sitoutunut asiakas, riippuvuuksien hallinta, muuttuva toimintaympäristö. Vaikuttavia tekijöitä on lukemattomia.
Nämä tekijät vaikuttavat projektin onnistumiseen metodologiasta huolimatta, mutta CHAOS-raportin perusteella ketterillä malleilla onnistumiseen on kuitenkin paremmat mahdollisuudet erityisesti suurissa projekteissa.
Lähde: Standish Groupin CHAOS-raportin pohjana on 10 000 projektin tiedot.
https://www.infoq.com/articles/standish-chaos-2015
Millä keinoin parannat onnistumisen edellytyksiä
Koko kirjoituksen lähtökohtana oli se, voiko projekti onnistua, jos ketteryys on vain toimittajan puolella. Käännän tarkastelukulmaa hieman ja katsotaan, mitkä tekijät ovat projektin kannalta merkittäviä. Chow ja Cao tutkimuksessaan A survey study of critical success factors in agile software projects ovat listanneet onnistumisen kannalta kriittiset tekijät, jotka pohjautuvat agile manifeston periaatteisiin.
- Delivery strategy (toimitetaan toimiva ohjelmisto säännöllisesti)
- Agile Software Engineering Techniques (arkkitehtuuri, yksinkertaisuus, laadun jatkuva huomiointi)
- Team Capability (motivoitunut tiimi)
- Project Management process (kommunikointi, tasaisen toimitustahdin ylläpito)
- Team environment (itseorganisoituvat tiimit)
- Customer involvement (Liiketoiminnan edustajien ja ohjelmistokehittäjien tulee työskennellä yhdessä päivittäin koko projektin ajan)
Tutkimuksen perusteella onnistumisen kannalta ratkaisevat tekijät vaihtelevat projektin osa-alueittain. Tulokset ovat ennustettavia ja tukevat kokemusperäistä tietoa. Onnistumisessa on merkittävää, että toiminnassa on olemassa yhteinen riittävällä tasolla määritetty tilanteeseen sopiva toimintamalli. Agile software engineering techniques ja Delivery strategy ovat onnistumisen kannalta merkittävässä asemassa samoin kuin Project management process. Nämä kaikki ovat vahvasti sovitun mallin toteuttamiseen liittyviä tekijöitä.
Toinen kokonaisuus on Team environment ja Team capability. Näiden osa-alueiden kohdalla liikutaan enemmän tiimin rakentamisen realiteettien ja johtajuuden alueella. Ihmisten merkitystä ei menetelmillä voi korvata.
Kolmas merkittävä tekijä on asiakkaan osallistuminen. Arvon tuottamisen kannalta asiakkaan osallistuminen on ratkaisevassa asemassa, sillä asiakkaan vaikutus on merkittävin juuri muutoksen laajuuden ja arvon määrittelyssä. Projektinhallinnan kannalta juuri tuolla laajuudella on valitettavasti selkeä linkitys niin aikatauluun ja kustannuksiin.
Jos ketteränä mallina käytetään Scrum-mallia on asiakkaan merkittävin rooli tuoteomistaja (Product owner). Henrik Svenbrant on kuvannut analyysissään A process analysis of customer value in agile projects osallistumisen nelikenttänä.
Kuvassa oikealla ylhäällä asiakkaat osallistuvat suoraan aktiivisimmin eli toimivat ”puhtaimmin” tuoteomistajan –roolissa, Laajassa kehityshankkeessa tuoteomistaja sijoittuu usein vasemmalle ylös. Tuotteella voi olla yksi tuotteen omistaja, joka vastaa priorisoinnista, mutta hänellä on tukenaan avustavia toimialan tuntevia henkilöitä.
Alhaalla asiakkaat ovat mukana epäsuoraan. Oikean reunan asiakkaat ovat tietoisia käytettävästä ketterästä mallista, kehitysjaksoista ja osallistuvat ainakin sprintkatselmointitilaisuuksiin. Vasemmalla alhaalla asiakas ei ole käytännön tasolla tietoinen, miten kehitystysprosessi tapahtuu. Nämä asiakkaat voivat määritellä vaatimuksia projektin alussa, kuten vesiputousmallissa on tapana, mutta eivät aktiivisesti osallistu kehitysjaksojen aikaiseen työhön.
Mitä voin projektipäällikkönä tehdä?
Projektipäällikön tehtävänä on tuottaa arvoa asiakkaalle määritetyn kehyksen sisällä. Siinä ketteryydellä ei ole itseisarvoa vaan arvo syntyy onnistuneen toteutuksen tuloksena. Chown ja Caon menestystekijöiden ymmärtäminen sekä Svenbrantin matriisi antavat projektipäällikölle työkaluja ohjata toteutusta sellaiseen suuntaan, että tavoitellut hyödyt toteutuvat.
Tunnista tilanteenne kriittisten menestystekijöiden suhteen. Vie läpi tarvittavat parannukset. Tutkimuksen pohjalta vaikuttaa, että oman tiimin tai tiimien toimintaa panostaminen parantaa onnistumisen edellytyksiä kaikilla projektin osa-alueilla.
Tunnista asiakkaan tilanne yhdessä asiakkaan kanssa. Vie läpi tarvittavat muutokset ja pääsääntöisesti pyri tukemaan asiakkaan siirtymistä nelikentässä kohti täyttä osallistumista. Toimi edelleen tiiminä, ei syytöksiä, ei uhkaa. Keskustele onko asiakkaalla mahdollisuutta kehittyä PO-roolissa. Mitä se edellyttää ja miten kehitystä voidaan tukea. Jos kehittyminen ei projektin aikana ole realistista, mieti miten voit pienentää tuosta aiheutuvaa riskiä. Minkä tyyppinen asiantuntija soveltuu tuoteomistajan työpariksi. Indikoi, miten matala epäsuora osallistuminen vaikuttaa tiimin suorituskykyyn ja myyntivaiheessa keskusteltuun backlogiin.
ajatuskatkoja 
Vastaa