Projektinhallinnan rautakolmiota (Iron Triangle, Triple Constraint) on perinteisesti käytetty kuvaamaan projektin rajoitteita: aika, kustannukset ja laajuus, jotka on piirretty kolmion kärkiin, sekä laatu joka on piirretty kolmion keskelle. Jos yhtä rajoitetta muutetaan, se vaikuttaa väistämättä myös muihin rajoitteisiin. Kolmion keskelle on piirretty laatu koska sitä ei ole tarkoitus muuttaa. Esimerkiksi jos projektin tuotosten toiminnallisuutta lisätään, voivat myös kustannukset kasvaa ja aikataulu pitkittyä. Rautakolmio on kuitenkin kehittynyt vuosien varrella. Se ei ole enää kolmio, siihen on lisätty kulmia. Esim. PMBOK Guide teoksen mukaan siinä on lisäksi resurssit ja riskit. Myös asiakastyytyväisyys voi olla mukana.
Kun on kysymys ketteristä projekteista, lisäisin vielä yhden kulman: hyödyt. Perinteisissä suunnitelmavetoisissa projekteissa rautakolmio määrittelee myös projektin tärkeimmät suunnitellut tavoitteet. Jos nämä tavoitteet eivät toteudu, koetaan että projekti on epäonnistunut. Projektin alussa pyritään tekemään niin hyvät suunnitelmat että ne eivät muutu projektin aikana. Hyötyjen hallinnoinnin on katsottu kuuluvan projektin ulkopuolelle.
Ketterät projektit ovat hyötyvetoisia, eli tärkeintä on saavuttaa suurin mahdollinen hyöty. Suunnittelua tehdään vain sen verran kuin on tarpeen, koska suunnitelmat muuttuvat joka tapauksessa ja kaikki uudelleen suunnittelu koetaan turhaksi työksi.
Jos palataan alkuperäiseen rautakolmioon, miten ketterä projekti siis eroaa perinteisestä projektista sen suhteen? Onko ketterässä projektissa tarkoituksenmukaista kiinnittää laatu, kustannukset, aikataulu ja tuotosten laajuus?
Oletetaan että yrityksessä suunnitellaan uutta matkapuhelinmallia joulumarkkinoille. Valmista tulisi olla noin kaksi kuukautta ennen joulua jotta puhelimia saadaan pukin kontteihin niin paljon kuin mahdollista. Ei haluta myöskään menettää kilpailuetua – kilpailijoilta on myös tulossa uusia malleja. Pari kuukautta ennen suunniteltua projektin valmistumisajankohtaa projektitiimi kertoo että se ei kykene toteuttamaan kaikkea suunniteltua toiminnallisuutta. Tässä tilanteessa otetaan rautakolmio avuksi ja mietitään miten sen rajoitteita muuttamalla selvitään parhaiten tilanteesta. Aikataulua pidentämällä saataisiin kaikki toiminnallisuus valmiiksi ennen pitkää, mutta se ei ole hyväksyttävä vaihtoehto, koska tällöin menetetään kilpailuetu. Laatu on myös houkutteleva vaihtoehto, ja usein valitettavasti juuri siitä tingitäänkin. Se ei ole kuitenkaan viisasta. Huono laatu kostautuu ennen pitkää. Riskit kasvavat, loppupeleissä työmäärä lisääntyy, kustannukset kasvavat ja markkinoille saadaan ehkä käyttökelvoton tuote joka voi vaikuttaa yrityksen imagoon pitkälläkin tähtäimellä. Kustannuksia kasvattamalla, eli resursseja lisäämällä, saadaan jollain tähtäimellä enemmän aikaan. Mutta jos esimerkin tilanne havaitaan pari kuukautta ennen suunniteltua valmistumista, uudet henkilöt eivät välttämättä ehdi kouluttautua projektityöhön ja projektitiimin työmäärää lisää uusien henkilöiden perehdyttäminen. Tuottavuus ei siis kasva riittävästi lyhyellä tähtäimellä.
Jäljelle jää toiminnallisuudesta tinkiminen. Se onkin yleensä paras vaihtoehto ketterissä projekteissa, koska niiden fokus on alusta asti hyötyjen kasvattamisessa. Toiminallisuutta tehdään jatkuvasti prioriteettijärjestyksessä hyötyihin perustuen. Vähemmän tärkeä toiminnallisuus tehdään viimeiseksi. Jos yllä olevan esimerkin tilanteessa tuotetta on tehty tällä periaatteella, tärkein toiminnallisuus on todennäköisesti jo tehty ja tuote voidaan julkaista. Mahdollisessa jatkokehitysprojektissa tehdään jäljelle jäänyt vähemmän tärkeä toiminnallisuus.
Toiminnallisuus on ketterässä projektissa rautakolmion muuttuva tekijä. Ennalta määrätyssä aikataulussa ja/tai budjetissa tavoitteena on saada aikaan vähintään tarvittava toiminnallisuus (Minimum Viable Product). Rautakolmio toimii siis myös ketterissä projekteissa, mutta fokus on hieman erilainen kuin perinteisissä suunnitelmavetoisissa projekteissa. Rautakolmio ei ole vielä aikansa elänyt.
Ketterä Projektinjohtaminen – ohjelmisto- ja tietojärjestelmäprojektien hallinta – koulutus antaa hyvän yleiskuvan ketteristä menetelmistä sekä ketterien menetelmien sijoittumisesta projektinhallinnan pelikenttään. Koulutuksen opeilla saat lisää tehoa ketteriin projekteihin sekä käytännön tietoa siitä mitä ketterät projektit merkitsevät koko yritykselle.
Tervetuloa koulutukseen Ketterä Projektinjohtaminen – ohjelmisto- ja tietojärjestelmäprojektien hallinta
Maksuton webinaari 24.5. klo 9 (kuunneltavissa myös jälkitallenteena)
Projektin tuloksen arvo -laskenta
Hannu Blomqvist
Hannu Blomqvist toimii hankejohtajana Citrus Solution Oy:ssä. Hänellä on yli 20 vuoden käytännön kokemus projektien ja ohjelmien johtamisesta. Hän on johtanut laajoja kansainvälisiä hankkeita ja ohjelmia, joilla on ollut useita osapuolia useasta yrityksestä ja monesta kansallisuudesta. Hannu tuntee hyvin sekä projektijohtamisen perinteisemmät että ketterät menetelmät. Hannu on kokenut projektinhallinta-alan kouluttaja ja puhuja kansallisissa ja kansainvälisissä tilaisuuksissa ja on luennoinut myös Aalto-Yliopistossa.