IT-projektien laajuuden arviointi - tuurilla oikein?

Kai Koskinen

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. 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.

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äkestoiseen 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 kannalta.

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 (www.fisma.fi).

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 arviossa 110:stä poikkeama opettajan ratkaisusta oli korkeintaan 2% ja 93 tapauksessa työmääräarvio poikkesi opettajan ratkaisusta korkeintaan 20%. 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.  

Kai Koskinen
Projektinhallinnan kouluttaja ja valmentaja
DiscoverIT
www.projektijohtaminen.fi
SIG-16 vetäjä

Palaa otsikoihin