PDU-pisteitä tarjolla

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

Liity ProjectManagement.com:iin (ilmaiseksi) ja katso kuinka MARS-projektin ryhmää sekä riskejä hallitaan ja johdetaan. Mielenkiintoinen tarina ryhmän ohjaamisesta ja kehittämisestä sekä riskinottokyvystä.

Mars-lentoa suunnitellaan täyttä häkää, samoin fuusioreaktoria useammalla taholla sekä 4G-verkkoa Kuuhun. Kvanttitietokonetta ryhdytään rakentamaan myös Suomessa. Kilometrin korkuinen pilvenpiirtäjä kohoaa Saudeissa.

Riskit hallussa?

Projektiammattilaiset ry:n blogikirjoitukset ovat käsitelleet ansiokkaasti riskitarkastelun levittämistä kaikille projektiorganisaation tasoille. Alun esimerkeissä tehdään kuitenkin täysin uutta asiaa. Näiden projektien riskejä voidaan ainakin osittain kartoittaa, mutta minkälaisia vaikutuksia niillä on projektin toteutukseen?

Mallintamisen hyödyt

Korkean riskin projekteissa sekä yksittäisten tehtävien kestoja ja kustannuksia että tehtävien keskinäisiä riippuvuuksia on vaikea arvioida. Tarvitaan siis jonkinlaista mallinnusta.

Yksinkertaisimpia mallinnusmenetelmiä on ns. Monte Carlo -menetelmä, jossa tiettyä muuttujaa - kuten projektin kestoa tai kustannusta - simuloidaan tekemällä suuri määrä kokeita satunnaisesti valituilla arvoilla. Tulokset ovat riittävän tarkkoja, kun simulointikierrosten määrä on riittävän suuri.

Suunnitteluvaiheessa projekti lasketaan lukuisia kertoja läpi. Kullakin laskentakierroksella jokaiselle yksittäiselle projektin tehtävälle lasketaan (eli arvotaan käyttäjän antamien parametrien mukaisesti) satunnainen kustannus ja kesto tehtävälle asetetun todennäköisyysjakauman perusteella.

Lopputuloksena saadaan todennäköisyysjakaumat, jotka kertovat millä todennäköisyydellä projektin kokonaiskustannus tai -kesto pysyvät tiettyjen arvojen alla (kuva 1).

MARS1 kustannusjakauma

Kuva 1. Projektin kokonaiskustannusten todennäköisyysjakauma.

Asiantuntemus käyttöön

Mallinnuksen kannalta ratkaisevia ovat yksittäisten tehtävien todennäköisyysjakaumat sekä tehtävien väliset riippuvuudet, joten koko projektiorganisaation asiantuntemus on saatava käyttöön. Mallintamisella ei estetä tai vähennetä projektin riskejä, mutta saadaan käsitys tietyn budjetin tai keston saavuttamistodennäköisyydestä. Tiedottaminen - etenkin ulospäin - on tämän jälkeen ainakin asteen luotettavampaa.

Parempi käsitys riskeistä

Simloinnin tuloksena projektin jäsenet ymmärtävät, kuinka herkästi kustannukset ja kesto voivat poiketa alkuperäisistä arvioista ja asennoituvat sen mukaisesti. Huomio suunnataan sekä riskeihin yleensä että erityisen riskialttiisiin projektin tehtäviin ja näiden tekijöiden vaikutuksiin. Riskien käsittelystä tulee luonnollinen osa projektin läpivientiä.

Kuinka lopulta kävikään?

Päästiinkö Marsiin, saadaanko päästötöntä fuusioenergiaa ja mallinnetaanko rokotteiden kehitystä kvanttitietokoneilla? Mitä tämä kaikki sitten maksoi ja kuinka kauan kesti? Merkittävää tietoa tulevien ainutkertaisten projektien suunnitteluun - ja mallinnukseen, johon liittyvien työkalujen käyttöönotto on huomattavasti helpompaa kuin tuskailu ilman niitä.

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.

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.

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.

FacebookTwitterGoogle BookmarksLinkedin
Pin It