IT-projekteilla on hieman surullinen maine liittyen laajuuden arviointiin ja yleensäkin tavoitteiden saavuttamiseen. Standish Groupin vuoden 2012 CHAOS-raportin mukaan ainoastaan 39% tietotekniikkaprojekteista onnistui, 43% vietiin läpi puutteellisesti (ylittivät joko aikataulun ja/tai budjetin ja/tai joutuivat tinkimään alkuperäisistä tavoitteista ja vaatimuksista) ja 18% joko keskeytettiin tai tuloksia ei koskaan otettu käyttöön. On huomattava, että vuoden 2012 tulokset ovat CHAOS-raporttien osalta historiallisen hyviä ja esimerkiksi vuoden 2004 raportin mukaan vain 29% tietotekniikkaprojekteista onnistui.

Ongelmat juontuvat usein puutteellisista vaatimusmäärittelyistä ja korostuvat ennen kaikkea suurissa projekteissa. Standish Group on myös tutkinut onnistumiseen vaikuttavia tekijöitä ja vuodesta toiseen kahtena tärkeimpänä asiana on mainittu johdon tuki ja käyttäjien osallistaminen tai sitouttaminen, kts. oheinen blogikirjoitus. Useita mainintoja kärkisijoilla ovat saaneet myös riittävän pienet projektit ja selvät liiketoiminnalliset tavoitteet tai vaatimukset. 1990-luvun puolivälissä ratkaisukeinoksi esitetyt ketterän (agile) kehityksen menetelmät painottuvatkin paljolti näihin asioihin. Projektiryhmät jakavat isomman projektin riittävän pieniksi osaprojekteiksi, jotka toteutetaan varsin nopeasti. Lisäksi ryhmät toimivat mahdollisimman itsenäisesti ja pyrkivät vähentämään raportointia ja dokumentointia niin paljon kuin mahdollista tulosten kärsimättä.

Ketterillä menetelmillä onkin saatu hyviä tuloksia. Pienissä projekteissa ero muilla tavoilla toteutettuihin projekteihin ei keskimäärin ole merkittävä, mutta Standish Groupin vuoden 2015 CHAOS-raportin mukaan erittäin suurissa projekteissa ketterät menetelmät takasivat onnistumisen 6-kertaisella todennäköisyydellä muihin projekteihin verrattuna, kts. kirjoitus raportin keskeisistä havainnoista.

Ketterät menetelmät ymmärretään valitettavasti usein väärin. Ne eivät tarkoita nopeampaa vaan nimensä mukaisesti joustavampaa tapaa toteuttaa projekti. Usein ongelmat liittyvät enemmänkin projektin pitkään kestoon kuin vaatimusmäärittelyn ongelmiin sinänsä. Pitkään kestävään projektiin tulee lähes vääjäämättä muutoksia lainsäädännöstä, markkinatilanteesta tai muista tekijöistä johtuen. Tässä kohtaa joustavammat menetelmät ovat tehokkaampia muutosten toteuttamisen osalta.

Finnish Software Measurement Association (FiSMA) on tehnyt pitkään töitä ohjelmistoprojektien laajuuden arvioinnin ja mittariston osalta ja on kehittänyt ns. toimintopisteisiin (function points) perustuvan 'FiSMA 1.1 Ohjelmiston toiminnallisen laajuuden mittausmenetelmän', joka on saatavissa myös suomenkielisenä SFS-ISO/IEC 29881-standardina, sekä northernSCOPE-nimisen ohjelmistoprojektien laajuuden ja laadunhallintaan liittyvän menetelmän.

FiSMA 1.1. -menetelmää on kehitetty sekä tieteellisen tutkimuksen että käyttäjäpalautteen avulla ja se pohjautuu täysin toiminnallisiin käyttäjävaatimuksiin. Ohjelmiston toiminnallinen koko on oleellinen tieto sekä projektin koon että eri ohjelmistojen vertailun osalta. Toiminnalliset komponentit jaetaan 7 luokkaan ja 28 tyyppiin. Tarkempi kuvaus menetelmästä löytyy FiSMA:n sivuilta.

Australiassa luotuun southernSCOPE:een pohjautuvassa northernSCOPE-menetelmässä ohjelmistoprojektin kustannusten arviointiin on otettu oppia muilta toimialoilta. Rakennusprojekteissa työmäärä- ja kustannusarviot perustuvat tyypillisesti pinta-alaa kuvaaviin tunnuslukuihin (kuten neliömetrit), tienrakennusprojekteissa taas tiekilometrien määrään. Vastaavasti northernSCOPE:ssa arvioidaan ohjelmistoprojektin toiminnallinen koko toimintopisteinä ja lasketaan toimialakohtaisten tilastotietojen avulla keskimääräinen kustannus toimintopistettä kohden. Sekä asiakas että toimittaja sitoutuvat näin määriteltyihin kustannuksiin ja maksuperusteisiin. Myös muutosten arviointi ja muutosvaikutusten laskenta perustuvat samoihin kustannusmittareihin. Toimintopisteet toimivat myös tuloksen arvo (Earned Value) -laskennan pohjana projektin edistyessä.

Southern ja northernSCOPE-menetelmiä on kokeiltu sekä julkisella että yksityisellä sektorilla. SouthernSCOPE-menetelmän mukaisesti arvioidut projektit ovat saavuttaneet tavoitteensa keskimääräisen kustannusylityksen ollessa alle 10%. Keskimääräiset kustannus- ja aikatauluylitykset northernSCOPE:n mukaisesti arvioiduissa projekteissa ovat olleet 3%. Poikkeamat ovat hämmästyttävän pieniä verrattuna ohjelmistoprojektien tyypillisiin tuloksiin.

Kuinka nopeasti ohjelmistoprojektin koko toimintopisteinä ja vastaava projektin työmääräarvio sitten saadaan aikaiseksi? FiSMA järjesti kesällä 2013 kokeen, jossa ohjelmiston toiminnallisen koon arviointiin koulutetut 22 osallistujaa laskivat 5 eri ohjelmistoprojektin toiminnallisen koon toimintopisteinä sekä vastaavat työmääräarviot. Koon arviointi onnistui nopeimmillaan 45 sekunnissa ja vei enimmillään 8 minuuttia. Työmääräarviointi sisältäen ensimmäisen vaiheen toiminnallisen koon arvioinnin sujui nopeimmillaan alle 3 minuutissa ja vei enimmillään 18 minuuttia. Tapahtuman kaksi pääjärjestäjää loivat erikseen ns. 'opettajan ratkaisut'. Kun näiden tulokset saatiin yhtäpitäviksi, verrattiin muiden arvioita niihin. 99 kokoarviossa 110:stä poikkeama opettajan ratkaisusta oli korkeintaan 2%. Toimintopistelaskennan pioneeri Capers Jones oli itse laskenut 40 eri ohjelmiston toimintopisteet yhteensä 75 minuutissa, keskimäärin alle 2 minuuttia ohjelmistoa kohden. Koko artikkeli löytyy 4SUM Partnersin sivuilta.

Lupasin aiemmassa blogikirjoituksessani valaista hieman tarkemmin sitä, minkälaisiin pohjatietoihin tuloksen arvo - eli Earned Value -tarkastelu voi perustua. Sanasta miestä.

Olenkin muutamaan kertaan maininnut projektin ositusrakenteen (WBS (work breakdown structure)) eduista. Tällainen rakenne on monille projektiammattilaisille tuttu ja uskoisin myös monien muiden käyttävän sitä tietämättä, että kysymys on nimenomaan WBS:stä. Jos tällainen rakenne on tehty hierarkkiseksi ja tarkimman tason tehtäväpakettien laajuus asetettu sopivaksi, on tuloksen arvo -tarkastelu varsin helppoa. Tehtäväpakettien laajuus kannattaa sovittaa projektin seurantakokousten tiheyteen. Jos kokouksia pidetään parin viikon välein, niin sopiva laajuus WBS:n alimman tason tehtäväkokonaisuuksille on noin 1-2 henkilötyöviikkoa. Tällöin tehtäväpakettikohtaiseksi tiedoksi kullakin tarkasteluhetkellä riittää usein tieto siitä, onko kyseinen kokonaisuus aloittamatta, kesken vai valmis. Tuloksen arvo -laskennassa aloittamatta olevien tehtäväpakettien valmiusaste on 0%, keskeneräisten 50% ja valmiiden 100%. Vaikkei keskeneräisten tehtävien valmiusastetieto olekaan täysin tarkka, on koko projektin valmiusaste ja sen pohjalta edelleen tuloksen arvo (valmiusasteella korjattu budjetti) tiedossa kuitenkin riittävällä tarkkuudella, koska kunakin tarkasteluhetkenä projektissa on joukko aloittamatta olevia ja valmiita tehtäviä.

Entä jos riittävän tarkkaa ositusrakennetta ei ole mahdollista tehdä? Tällainen tilanne on usein tuote- ja palvelukehityksessä, jossa tehdään useita tarkentuvia suunnittelu- ja toteutuskierroksia. Kullekin kierrokselle voidaan ja on usein syytäkin budjetoida tietty osuus koko projektin kustannuksista ja toisaalta budjetti voidaan samoin jakaa projektissa tehtävien laajan tason työ- eli tehtäväalueiden mukaan. Tällaisia voivat olla esimerkiksi ohjelmistokehitys, laitekehitys ja koulutus. Näin meillä onkin tarvittava rakenne tuloksen arvo -tarkastelua varten. Ohessa esimerkki, jossa tarkastelu rajoitettu tilanpuutteen vuoksi yhteen työalueeseen.

Edelleen vaihtoehtona on sovittaa tarkastelu erillisiin katselmuskohtiin, jolloin kussakin tarkastelukohdassa lasketaan saavutettu toiminnallisuus tai valmisteltu suunnitteludokumentaatio ja tällainen valmiusastetieto toimii tuloksen arvo -laskennan pohjana. Edellytyksenä on luonnollisesti tieto siitä, kuinka suuri budjetti on alunperin suunniteltu ja varattu kuhunkin katselmuspisteeseen mennessä.

Viimeisimmät mainitut menetelmät eivät välttämättä ole aivan tarkkoja, mutta tarkoitus onkin saada edes jonkinlaista tietoa projektin edistymisestä ja valmiusasteesta ja käyttää hyväksi aikataulu- ja kustannuspoikkeamien sekä ennusteiden tarkastelussa.

Projektinhallinnan kustannus- ja myös aikatauluseurannassa on käytetty jo 1960-luvun lopulta lähtien ns. Earned Value - eli tuloksen arvo -menetelmää. Tosin termistö on vakiintunut nykyiseen muotoon vasta 1990-luvulla. Menetelmä on kuvattu projektinhallinnan standardeissa ja sitä testataan sertifikaatteja suoritettaessa. Projektinhallinnan ammattilaiset siis tuntevat menetelmän aika laajasti, mutta kovinkaan monet yritykset eivät sitä järjestelmällisesti käytä. Lisäksi siihen liittyy muutamia väärinkäsityksiä tai -ymmärryksiä, joita pyrin tässä kirjoituksessa oikaisemaan.

Tuloksen arvolla tarkoitetaan tehtyä työtä sille alunperin suunnitelluilla kustannuksilla. Englanninkielen termi 'Earned Value' onkin varsin valaiseva, koska se voitaisiin kääntää projektissa ansaituksi arvoksi tai aikaansaaduksi tulokseksi. Kun laskettua tuloksen arvoa (EV = Earned Value) verrataan todellisiin kustannuksiin (AC = Actual Cost), saadaan laskettua kustannuspoikkeama (CV = Cost Variance) kaavalla CV=EV-AC. Projektin alkuperäisen suunnitelman mukaista etenemistä taas kuvaa Planned Value (PV), joka tarkoittaa suunniteltua työtä alunperin suunnitelluilla kustannuksilla. Tästä sekä tuloksen arvosta saadaan laskettua aikataulupoikkeama (SV = Schedule Variance) kaavalla SV=EV-PV. Tuloksen arvo -menetelmän hyötynä onkin jakaa projektissa syntyneet poikkeamat yhteismitallisiksi eli samoissa yksiköissä (yleensä rahassa) lasketuiksi kustannus- ja aikataulupoikkeamaksi. Edelleen voidaan laskea sekä kustannus- (CPI = Cost Performance Index) että aikataulutehokkuusindeksit (SPI = Schedule Performance Index) kaavoilla CPI=EV/AC ja SPI=EV/PV.

Kuulostaa hienolta ja eräs sudenkuoppa onkin ajatella, että sekä kustannus- ja aikatauluseuranta hoituvat tuloksen arvo -menetelmän avulla. Se antaa aikataulupoikkeaman kuitenkin vain yleisellä tasolla, eikä kerro vielä mitään siitä, minkälaisissa tehtävissä myöhästyminen on tapahtunut. Mikäli myöhästyminen on tapahtunut aikataulun kannalta ei-kriittisissä tehtävissä, ei laskennallisesta aikataulupoikkeamasta huolimatta ole välttämättä vielä mitään ongelmaa. Mikäli se on syntynyt kriittisen polun tehtävissä, ollaan sen sijaan pahasti suunnitellusta aikataulusta jäljessä. Aikatauluseuranta vaatii mielestäni aina myös aikajanalla tehtyä tarkastelua, jossa huomioidaan kriittisen polun edistyminen. Tiivistettynä voi sanoa projektin olevan hyvällä mallilla, mikäli laskettu kustannuspoikkeama on korkeintaan lievästi negatiivinen ja kriittisellä polulla ei ole pahoja myöhästymiä.

Tuloksen arvon käyttämättä jättämistä on myös perusteltu sillä, että kustannukset - esimerkiksi yksikkökustannukset - muuttuvat niin usein, ettei menetelmästä ole hyötyä, mutta tällaiset asiat menetelmän onkin juuri tarkoitus tuoda esiin. Jos projektissa ollaan edetty alkuperäisen aikataulun mukaisesti, mutta yksikkökustannukset ovat kasvaneet alkuperäisestä projektisuunnitelmasta, ei aikataulupoikkeamaa ole syntynyt ollenkaan, koska sen molemmat tekijät (EV = Earned Value ja PV = Planned Value) lasketaan alunperin suunnitelluista kustannuksista. Syntynyt kustannuspoikkeama taas antaa tietoa siitä, kuinka iso ongelma kustannusten arvioinnissa on.

Usein väitetään myös, ettei tuloksen arvo -menetelmää voida soveltaa, koska projekteista ei ole mahdollista laatia selvää ositusrakennetta (WBS = Work Breakdown Structure). Ositusrakenne onkin varsin tärkeä projektin onnistumiselle ja se kannattaa aina tehdä, kun vain mahdollista. Osituksen tärkeyttä tarkastelen myös aiemmassa blogikirjoituksessani. Tuloksen arvo -menetelmän ei kuitenkaan välttämättä tarvitse perustua tällä lailla määriteltyihin tehtäväpaketteihin, vaan muitakin vaihtoehtoja on. Niistä lisää myöhemmin.

Niinpä. Lausahduksesta jotenkin paistaa läpi, että projekti tai projektit ovat jo käynnissä siinä vaiheessa, kun näitä toiveita esitetään. Ensin kannattaisi ehkä ohjeistaa kaikille projektiryhmille projekteissa käytettävät työskentely- tai menettelytavat, jolloin uutta projektipäällikköä ei kenties tarvittaisi ollenkaan.

Miksei tällaisia ohjeistuksia sitten aina ole luotu? Toistuvassa 'rutiinimaisessa' työskentelyssähän ohjeet ovat melko lailla itsestäänselvyys. Kyse ei välttämättä ole laiskuudesta, vaan siitä, että projektit saatetaan kokea siinä määrin ainutkertaisiksi työkokonaisuuksiksi, ettei erillistä ohjeistusta pidetä tarpeellisena. Menettelyjen ja ohjeiden koetaan usein myös jäykistävän toimintaa liiaksi. Kiistatta kuitenkin ohjeistusten ja projektitoiminnan muulla kehittämisellä on saatu erittäin hyviä tuloksia aikaiseksi. Muutamia esimerkkejä järjestelmällisen projektinhallinnan eduista on edellisessä blogikirjoituksessani.

Toisaalta projekteilla voi jo hyvin olla ainakin nimellinen projektipäällikkö, jolloin tuosta lauseesta jää ennen projektipäällikköä sanomatta 'osaava' tai 'ammattimainen'. Osaavalla voidaan tarkoittaa joltain alalta paljon asiantuntemusta ja kokemusta hankkinutta tai sitten projektinhallinnan osaavaa henkilöä. Tässä mielessä 'ammattimainen' on kenties parempi ilmaisu. Edelleen ongelmaksi jää se, miten tällainen ammattimaisuus määritetään.

Asiasta on monenlaisia mielipiteitä. Jotkut painottavat ryhmänjohtamis- ja toiset menettelytaitoja. Eräs lähestymistapa on arvioida projektipäällikön osaamista tiettyjä standardeja ja niiden pohjalta laadittuja sertifikaatteja (esim. IPMA, PMI tai PRINCE2) vastaan. Näissä vain harvemmin käsitellään todella vaikeita asioita, kuten huonontuvaa työskentelyilmapiiriä tai ristiriitatilanteita.

Entä jos jostain löytyy alansa asiantuntemusta omaava ammattimainen projektipäällikkö? Eräs kouluttajakollegani on muistuttanut tällaiseen ratkaisuun liittyvistä vaaroista useaan otteeseen. Kuilu muihin projektiryhmäläisiin voi vain olla liian suuri. Projektipäällikkö nähdään vähintäänkin outona tyyppinä, joka puhuu ihan omaa kieltään, eikä muu projektiryhmä välttämättä ymmärrä, miksi tiettyjä yhteisiä menettelytapoja ja ohjeistuksia olisi noudatettava. Kehittämisen täytyy koskettaa kaikkia projekteissa mukana olevia henkilöitä.