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.

Projektiyhdistys on jälleen Projektipäivien yhteydessä 10-11.11.2015 palkinnut ansiokkaita projekteja. Vuoden projektiksi valittiin Vincit Oy:n hanke ”Google Glass -pysäköinninvalvonta”. Vaikka projekti oli kooltaan pieni, se vakuutti tuomariston innovatiivisuudellaan, uutuustekijöillään ja monikulttuurisuudellaan. Projektin lopputuotteena synnytettiin älylasisovellus, jonka avulla voi nähdä parkkimaksun voimassaolon. Projektiorganisaatio koostui eri maista tulleista opiskelijoista.

Kunniamaininnan saivat lisäksi ”Kantolan tapahtumapuisto” -projekti Hämeenlinnassa ja ”Lähiruokaa resurssiviisaasti julkisiin keittiöihin” -projekti Jyväskylässä. Kantolan tapahtumapuisto on Hämeenlinnaan vanhalle tehdasalueelle toteutettu monipuolinen ja lajissaan Suomen suurin vapaa-ajan alue, jonka toteutti Ramboll Oy. Tuomaristo arvosti erityisesti hankkeessa kehitettyä kustannustehokasta maaperän puhdistusratkaisua. Kustannukset putosivat lähes 90 prosenttia alkuperäisestä arviosta, jolloin hankkeen toteuttaminen tuli ylipäätään mahdolliseksi. Lisäksi projekti toteutettiin tiukassa aikataulussa.

Jyväskylän ammattikorkeakoulun hallinnoimalla "Lähiruokaa resurssiviisaasti julkisiin keittiöihin" -pilottihankkeella onnistuttiin edistämään lähiruoan käyttöä Jyväskylän kaupungin ruokapalveluissa. Samalla luotiin liiketoimintaedellytyksiä paikalliselle kalastukselle, kalanjalostukselle ja lähiruoan verkkotukkukaupalle. Hankkeen erityisenä ansiona tuomaristo piti yhteistyöhön perustuvaa paikallista vaikutusta.

Yhteistä palkituille projekteille olivat uudet ja innovatiiviset ratkaisut joko projektin lopputulosta tai projektityöskentelyä koskien sekä projekteihin luotu ongelmanratkaisuilmapiiri. Tätä on projektijohtaminen parhaimmillaan. Palkituista projekteista voi lukea tarkemmin Projektiyhdistyksen sivuilta.

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.

Lopetanpa lässyttämisen ja tarkastelen vaihteeksi esimerkkejä onnistuneista projekteista. Projektiyhdistys on valinnut vuoden projektin jo vuodesta 1995 alkaen ja esittelee edellisvuosien voittajia omalla sivullaan.

Edellisen, vuoden 2014 kilpailun voitti Ramboll CM Oy rakennuttajakonsultin ominaisuudessa puurakenteisella Göstan Paviljonki -projektilla. Tuomariston päätös perustui muun muassa projektin erinomaiseen onnistumiseen tavoitteiden, aikataulun ja kustannusten osalta, lisäksi luova muutos- ja ristiriitatilanteiden johtaminen vaikutti valintaan. Projektia on kuvattu omassa Projektitoiminta-lehden artikkelissa.

Vuonna 2013 vuoden projekti -kilpailun voitti Destia Oy:n Kantatie 51 -hanke. Destian valintaa puolsivat kaksi merkittävää tekijää: sidosryhmien taholta tulleet haasteet ja paineet projektin toteutukselle sekä projektin suuri kokonaistaloudellinen vaikutus perustuen matka-aikojen lyhentymiseen, onnettomuusriskien pienenemiseen ja polttoaineen kokonaiskulutuksen pienenemiseen kyseisellä tieosuudella. Projektitoiminta-lehden rtikkeli Destian projektista.

Vuoden projektiteko 2012 oli kehitysyhteistyöprojekti nimellä 'ICT-tukea Tansaniaan'. Suurin osa tuetuista viidestä koulutuksen ja tutkimuksen kehitysprojekteista eteni päätavoitteen mukaisesti vaiheeseen, josta ne pystyivät etenemään itsenäisesti. Projekti oli taloudellisesti ja aikataulullisesti onnistunut, vaikka toteutusympäristö sähkökatkoineen ja projektikulttuurin puutteineen oli uusi ja haasteellinen. Projektitoiminta-lehden artikkeli voittajasta.

Seuraava vuoden projekti julkistetaan Projektipäivillä Messukeskuksessa 10.-11.11.2015.

Myös tietotekniikan alalta on valittu vuoden ICT-hankkeita. Vuoden 2013 palkinnon sai Lahden kaupungin uusi toiminnanohjausjärjestelmä. Kaupungin lisäksi projektiin osallistuivat it-palvelutalo Atos ja Kuntien Tiera.

Vuoden 2012 ICT-hanke -palkinnon vei Atoksen ja sen kumppaneiden Academican ja Helsingin Energian ”Vihreä konesali & pilvipalvelukeskus Suvilahteen lämmittämään helsinkiläiskoteja hukkaenergialla” -projekti. Valinnan tehnyt asiantuntijaraati piti hanketta vaativana ja kiitteli Atoksen, Academican ja Helsingin Energian toimivaa kumppanuutta. Hyvän yhteistyön ansiosta hanke eteni ennätysajassa suunnittelusta toteutukseen: itse rakennus- ja testausvaihe kesti ainoastaan 4-5 kuukautta. Aikaa ja ympäristöä säästettiin myös sillä, että konesali rakennettiin uusiokäytettävään rakennukseen, Helsingin Energian vanhaan sähköasemaan.

Mielenkiintoinen esimerkki onnistuneesta projektista on myös työsuojeluhallinnon valvontatietojärjestelmän kehittämishanke, jossa käytettiin taannoisessa blogikirjoituksessani esitettyä toimintopistemenetelmää (FiSMA 1.1).

Toivoa on.

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.