PDU-pisteitä tarjolla

Kerää koulutuksista PMI:n (Project Management Institute) PDU-pisteitä

Projektien kuntoon laittamiseen ei tarvita useamman päivän koulutuksia tai 500-sivuisia kirjoja. Muutaman perusasian varmistaminen auttaa pitkälle.

  1. Määritä mitä projektissa tehdään. Tähän on olemassa omia työkaluja, kuten WBS eli Work Breakdown Structure, jonka käyttöperiaatteita valaistaan tarkemmin Wikipedian artikkelissa. Kyse on hierarkkisesta projektin työrakenteesta. WBS:n avulla varmistetaan, että kaikki tarvittava työ projektissa tulee tehtyä ja samalla huolehditaan siitä, että projektiin kuulumaton työ jää sen ulkopuolelle. Vastuut voidaan samoin kohdistaa WBS:n määrittämille tehtäväalueille ja -paketeille. Kaikista projekteista ei pystytä kovinkaan helposti laatimaan selkeää työ- tai tehtävärakennetta, mutta silloinkin se olisi hyvä pyrkiä tekemään ainakin yleisten työ- tai tehtäväalueiden osalta.
  2. Suunnittele ja selvitä, miten projektissa kertyy kuluja eri aikajaksoina. Toisin sanoen laadi projektille budjetti, joka tulisi aina ymmärtää aikajanalla esitettynä kustannuslaskelmana. Kun projektin erilaiset kustannuserät kuten materiaali-, työ-, laite-, johdon kustannukset jne. liitetään WBS:n kuvaamaan projektin työrakenteeseen, saadaan projektille ns. tilikartta, jossa sarakkeina voivat esimerkiksi olla WBS:n kuvaamat tehtäväpaketit ja riveinä projektin kustannuserät. Tilikartta sellaisenaan on varsin kätevä työkalu projektin kustannusseurantaan.
  3. Mieti tehtävien suoritusjärjestys ja määritä näin saadun aikajanakaavion perusteella projektin aikataulukriittiset tehtävät. Toisin sanoen tunnista ns. kriittinen polku eli pisin toisistaan riippuvien tehtävien ketju, joka määrittää samalla projektin lyhimmän mahdollisimman läpivientiajan nykyisellä resurssien käytöllä. Tämä auttaa kohdistamaan erityisesti aikataulukriittisissä projekteissa huomion läpivientiajan määrääviin tehtäviin.
  4. Seuraa projektin etenemistä eli valmiusastetta todellisten kustannusten ja ajankäytön lisäksi. Yksinkertaisimmillaan valmiusasteen seuranta voi pohjautua WBS:n määräämään työ- tai tehtävärakenteeseen, jossa tehtäväpaketit jaotellaan aloittamatta oleviin, keskeneräisiin ja valmiisiin. Kaikille keskeneräisille tehtäväpaketeille voidaan esimerkiksi antaa suoraan valmiusasteeksi 50%. Vaikka yksittäisten tehtäväpakettien osalta tällainen arvio ei olekaan tarkka, antaa se kuitenkin usein koko projektin valmiusasteesta riittävän tarkan kuvan. Ns. ketterien menetelmien mukaisesti ohjatuille projekteille on omat valmiusasteen seurantamenetelmänsä, kuten burn down chart.
  5. Arvioi pitävätkö projektin käynnistyksen yhteydessä tehdyt lähtöoletukset edelleen paikkansa projektin suunnittelun ja toteutuksen edetessä. Näitä ovat esimerksi projektien väliseen tärkeysjärjestykseen, resurssien käytettävissä olevaan työaikaan sekä markkina- ja kilpailutilanteeseen liittyvät oletukset. Mikäli kyseiset oletukset eivät ole enään paikkansapitäviä, tulisi niitä käsitellä riskienhallinnan keinoin.

Standish Group on tutkinut nimenomaan tietotekniikkaprojektien onnistumiseen vaikuttavia tekijöitä, mutta joitain johtopäätöksiä niistä voidaan vetää myös muihin projekteihin. Standishin listoilla ovat vuodesta toiseen toistuneet muutamat yhteiset tekijät. 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 välitavoitteet ja selvät projektin tai liiketoiminnan tavoitteet, luonnollisesti myös osaava henkilöstö. Viimeisten vuosien tutkimuksissa esille ovat tulleet myös ketterät (agile) prosessit.

Useat näistä tekijöistä ovat yhteisiä viime aikoina suosiota saaneille projektien johtamisopeille, kuten ketterät menetelmätlean projektinhallinta ja Critical Chain -menetelmä. Huolimatta siitä, käyttääkö jotain näistä johtamisopeista vai omia aivojaan, niin kannattaa ainakin harkita seuraavia toimenpiteitä.

Huomio projektin tuottamaan hyötyyn. Projektipäällikön tärkeimpiä tehtäviä ennen projektin aloitusta on varmistaa asiakkaalta tai loppukäyttäjiltä, mitä hyötyjä tai tuloksia he odottavat projektilta. Projektin suunnittelun ja toteutuksen aikana toimenpiteitä tulee arvioida tästä näkökulmasta ja karsia turhat hyötyä lisäämättömät toimet pois.

Tulosten jakaminen sopivan pieniksi välitavoitteiksi. Projektiryhmän jäsenten motivaatiota on huomattavasti vaikeampi ylläpitää, jos mittatikut ovat hamassa tulevaisuudessa. Pienten välitavoitteiden saavuttaminen antaa tunteen edistymisestä. Isojen tehtäväkokonaisuuksien työmäärien ja aikataulujen arviointi on lähes mahdotonta. Vaikka pienten tehtäväpakettien työmääräarvioissa epäonnistuttaisiinkin, ei se kuitenkaan kaada koko projektia.

Ohjaaminen ja vastuunjako tulosten kautta. Edellä mainittujen välitavoitteiden kautta asia hoituu osin luonnostaankin, mutta tähän on usein syytä kiinnittää erikseen huomiota. Kustakin osa-alueesta vastaavalla ryhmällä on myös parhaat edellytykset arvioida, millä keinoilla asetettuihin välitavoitteisiin tai -tuloksiin parhaiten päästään.

Sidosryhmät mukaan suunnitteluun. Projektiryhmä, loppukäyttäjät sekä mahdolliset muut projektissa mukana olevat tahot hyväksyvät todennäköisemmin projektin tavoitteet sekä projektisuunnitelman, jos he ovat olleet mukana suunnittelutyössä. Tämä ei tarkoita sitä, että heidän tulisi olla jokaisessa suunnitteluvaiheessa mukana alusta loppuun. Projektiryhmän omaa asiantuntemusta on laatia saatujen tietojen ja palautteen nojalla toimiva projektisuunnitelma.

Johtamishuomio mahdollisimman kitkattomaan tulosten ja tehtävien siirtoon. Projektipäällikön tehtävänä ei niinkään ole ärsyttää projektiryhmän jäseniä kyttäämällä sitä, kuinka hyvin he omassa työssään edistyvät, kuin luoda mahdollisimman toimivat ja tehokkaat menetelmät tulosten ja tehtävien siirtoon eri alueista vastaavien ryhmien välillä. Samalla ryhmät saavat tunteen siitä, että johtotasolla on mahdollisuuksien mukaan purettu edistymisen esteitä.

Tehtävät tärkeysjärjestykseen ja ylimääräisen kuorman poistaminen. Montako samanaikaista tehtävää tai vastuualuetta kullakin ryhmällä tai projektin jäsenellä on? Niitä ei tarvitse olla kuin muutama, kun työskentely muuttuu varsin tehottomaksi. Siirryttäessä takaisin aiemmin keskeytettyyn toiseen tehtävään tai projektiin on huomioitava sekä mieleenpalautukseen että hyvän työskentelyrytmin aikaansaamiseen vaadittava aika. Henkilökohtaiset erot voivat olla suuria ja on varsin mahdollista, että 'tyhjäkäyntiin' kuluu vaihdoksen yhteydessä vähintään tunti. Projektityössä keskimääräiseksi teholliseksi työajaksi on usein laskettu n. 70%, joka on 7,5 tunnin päivästä reilu 5 tuntia. Teoreettisesti kolmen samanaikaisen tehtävän tai projektin hoitaminen jättäisi n. 1h 45min tehollista työaikaa kutakin tehtävää varten, mutta 'tyhjäkäynti' huomioiden tehollinen työaika tehtävää kohden tippuu helposti noin tuntiin päivässä tai jopa sen alle.

Tyytyväisyysmittaukset myös projektin aikana. Harmillisen usein työ- tai asiakastyytyväisyyttä mitataan vasta projektin päätyttyä. Hyvällä johtajalla ja projektiryhmällä on varmasti kohtuullisen oikea käsitys siitä, kuinka hyvin projekti on edistynyt eri sidosryhmien mielestä, mutta tuskin kuitenkaan kaikkien asioiden osalta.

Jatkuva toiminnan arviointi ja kehittäminen. Kun projekti on jaettu sopivan pieniin välitavoitteisiin, on tämäkin helpompaa. Pienet parannukset myös omaksutaan huomattavasti helpommin kuin suuret toiminnan muutokset. Todennäköisesti nykyisissä menettelyissä on paljon hyvääkin. Miksi niitä muuten olisi otettu käyttöön?

Koulutus sopivan pienissä osissa projektin aikana. Edelliseen kohtaan viitaten toiminnan kehittämiseen liittyvään projektiryhmän jäsenten koulutukseen on hyvä varata säännöllisesti oma aikansa. Tämä ylläpitää projektiryhmän motivaatiota ja pienissä osissa saadut opit on myös helppo testata ja ottaa käyttöön. Koulutukseen ja opiskeluun voi käyttää aikaa esimerkiksi odotettaessa muista alueista vastaavien ryhmien tuloksia.

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.

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.

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.

Money icons made by Kiranshastry from www.flaticon.com
Wall-clock icon made by srip from www.flaticon.com