Pienet projektit – pahin päänsärky

Usein pienet asiat synnyttävät suurimmat haasteet ja näin käy usein myös pienten projektien kanssa.

Projektin suhteellinen pienuus voi helposti erehdyttää asioiden aliarviointiin ja ottamaan asioita itsestäänselvyyksinä. Usein ongelmaksi muodostuu – yllättäen – että koetetaan saada aikaan liian paljon ja liian nopeasti. Pienistä puroista syntyy suuri virta ja ongelmat kertaantuvat useiden rinnakkaisten pienten projektien yhteydessä.

Pieni projekti täyttää kaikki projektin tunnusmerkit: se on tilapäinen ja aikarajattu, sillä on määrätty lopputulos ja sen toteuttajat ovat tiedossa. Pienessä projektissa toteuttajia on vähän, budjetti on pieni, prioriteetti saattaa olla matala ja tavoitteena on ehkä nopea suoritus. Tyypillisesti pienen projektin toteuttajia kuormittavat samaan aikaan myös muut hankkeet.

Pienen projektin ongelmat liittyvät tyypillisesti toteutuksen suunnitteluun ja työmäärien arviointiin, toteutuksen seurantaan, muutoshallintaan, viestintään sekä resurssien hallintaan. Nämä ongelmat näkyvät uudelleensuunnittelun tarpeena, asetettujen aikataulu- ja kustannustavoitteiden pettämisenä sekä resurssien ylikuormittumisena.

Siispä organisaation on syytä miettiä yhtenäinen malli pienten projektien hallintaan siinä missä suurtenkin:

  • Muodosta rakenne pienten projektien hallintaan vakioimalla käytetyt dokumenttipohjat. Tällöin varmistetaan, että kaikki yksityiskohdat tulevat huomioitua.
  • Vakioi toimintamalli pienille projekteille. Tällä luodaan yhtenäinen tapa toimia ja edellytykset ketterälle ja nopealle toteutukselle.
  • Suunnittele tekeminen tarkoituksenmukaisella tarkkuudella. Hyvä sääntö on, että suunnittelu viedään sellaiselle tasolle, että tehtävien sisältö, työmäärät ja riippuvuudet voidaan luotettavasti määrittää ja työmäärien toteutumista voidaan seurata.
  • Luo edellytykset tekemisen priorisoinnille. Projekteja on käynnissä lukuisia samanaikaisesti. Ylikuormitus- ja muutostilanteissa tulee olla käytettävissä riittävät tiedot projektien kriittisyydestä, jotta resurssien kohdistaminen on optimaalista. Näkyvyys käynnissä olevaan ja suunniteltuun tekemiseen on tärkeää.
  • Viestitä uutterasti tapahtumista projektien ylitse. Näin varmistat, että päättyvistä projekteista ja tehtävistä vapautuvat resurssit siirtyvät alkavien tehtävien pariin sujuvasti ja resurssien käyttö on tehokasta.

Käytännön kokemus on, että kaikki organisaation toteuttamat projektit kannattaa luokitella organisaatiolle sopivilla kriteereillä pieniin (Small), tavanomaisiin (Ordinary) ja suuriin (Large) projekteihin (SOL!). Kullekin projektiluokalle on erikseen kuvatut rakenteet ja menettelytavat.

Kokonaistilanteen hallinta edellyttää tietojärjestelmää, jossa hallitaan organisaation kaikki projektit koosta riippumatta. Pienten projektien kohdalla tietojen ajantasaisuus, kustannus- ja kuormitustarkastelut projektien ylitse ja erilaiset mittarit ongelmaprojektien esiin nostamiseksi sekä tekemisen priorisointiin ovat järjestelmän keskeisiä ominaisuuksia. Joustavia ja eri mittakaavan projekteihin soveltuvia järjestelmiä on useita – annamme näistä mielellämme lisätietoja!

Mallikas projektin muutoshallinta on kaikkien osapuolien etu

Muutos tarkoittaa projektissa mitä tahansa muutosta projektin suunniteltuihin tuotoksiin. Muutokset aiheuttavat toteutuessaan usein kasvavan työmäärän sekä uhkaavat projektin budjettia ja aikataulua. Projektipäällikön pitää osata tasapainoilla muutoshallinnassa projektin aikataulun, käytettävissä olevien resurssien, budjetin ja asiakastyytyväisyyden välillä.

Muutoshallinnan käytännöt

Muutoshallinnan käytännöt kuvataan projektisuunnitelmassa tai erillisessä suunnitelmassa. Muutoslokissa ylläpidetään listaa projektille esitetyistä muutoksista. Ehdotetut muutokset dokumentoidaan muutospyynnöiksi, joiden tarkoitus on kuvata ja arvioida pyydetty muutos, muutoksen vaikutukset projektiin, määritellä muutoksen toivottu toteutusaikataulu sekä tarjota vaihtoehdot muutoksen toteuttamiselle. Muutoshallintaan liittyvät käytännöt hillitsevät ylettömiä muutoshaluja, mutta näin muutokset tulevat myös analysoitua laadukkaammin ja muutoksen tarpeellisuus harkittua paremmin.

Päätöksenteko

Säntillinen toiminta projektissa edellyttää, ettei kaikkia muutostoiveita toteuteta heti, vaan noudatetaan muutoshallinnan käytäntöjä ja kerätään ehdotuksia muutoslokiin koko projektin ajan. Muutosehdotukset käsitellään ja hyväksytään tai hylätään sovittujen käytäntöjen mukaan yleensä projektin ohjausryhmän kokouksissa säännöllisesti. Projektilla on paremmat onnistumisen edellytykset, kun tehdään läpinäkyvää muutoshallintaa ja päätetään toteutettavista muutoksista yhdessä asiakkaan kanssa.

Suunnitelman päivittäminen ja versiointi

Kun muutokset hyväksytään projektin ohjausryhmässä, projektisuunnitelmaan tehdään tarvittavat muutokset (aikataulu, työmäärät, kustannukset, lopputuotokset) uudelle suunnitelmaversiolle. Näin suunnitelmaan dokumentoidaan, ettei projektia tehdä enää aikaisemman suunnitelman laajuuden mukaisesti. Versiointia käyttämällä jää suunnitelmasta talteen alkuperäinen versio sekä kaikki keskeiset hyväksytyt muutokset projektin ajalta. Versioinnin tuloksena myös projektin onnistumisen arviointi on helppoa projektin päätyttyä.

Projektipäällikön yksi tärkeimmistä tehtävistä on pitää projektin muutokset ja laajuus tiukasti hallinnassa, jotta saavutetaan onnistunut lopputulos, johon asiakas on tyytyväinen.

Projektin riskienhallinta – turhaa mörköjen maalausta?

Riskienhallintaa pidetään usein negatiivisena ja jopa mörköjen turhana maalailuna. Huomiota menee turhan paljon asioihin, jotka voivat mennä pieleen sen sijaan, että projektiryhmässä keskityttäisiin innokkaasti ja motivoituneesti projektin tuotosten toteuttamiseen ja tavoitteiden saavuttamiseen. Pitäisi kuitenkin muistaa, että riskienhallinnan avulla pidetään negatiiviset asiat poissa itse projektista ja varmistetaan projektin onnistuminen.

Omissa projekteissani toimiva ratkaisu riskienhallinnan varmistamiseksi on ollut sopivan projektiryhmän jäsenen nimeäminen vastaamaan projektin riskirekisterin ylläpidosta ja riskienhallinnan käytäntöjen toteuttamisesta. Riskirekisteri tulee näin käsitellyksi säännöllisesti ja muutamaan kertaan eri kokoonpanolla. Näin olemme saaneet riittävän laajan näkemyksen projektin riskien tilanteesta ja vaadittavista toimenpiteistä. Tarvittavat toimenpiteet on myös saatu toteutettua paremmin aikataulussa.

Riskienhallinnan toteuttaminen, kuten muutkin projektikäytännöt, on aloitettava heti projektin alussa ja käytännöistä on pidettävä kiinni. Riskienhallinnan suunnitelma kuvaa, kuinka projektin riskienhallinta organisoidaan ja kuinka sitä toteutetaan. Suunnitelmassa on määritelty mm. metodologia, roolit ja vastuut, riskien kategorisointi, todennäköisyyden ja vaikutuksen määritelmät, toleranssit ja seurannan käytännöt. Riskienhallinnan suunnitelma ei kuvaa tai ota kantaa yksittäisiin projektin riskeihin, vaan ne on listattu projektin riskirekisterissä. Rekisterissä on riskeistä määritelty vähintään jokaisen riskin kuvaus, todennäköisyys, vaikutus, vakavuus ja riskin arvo (€) sekä määritelty riskienhallintatoimenpiteet ja vastuut.

Ja sitten on ne positiiviset projektin riskit, joilla voi olla suuri positiivinen merkitys ja vaikutus – ei vain projektille vaan myös organisaatiolle laajemmin. Näiden riskien toteutuminen on projektissa varmistettava, koska nekin jäävät usein liian vähälle huomiolle vain sen takia, että ne ovat riskejä.

Uuden vuoden lupauksena pitää aina haastaa itseään parantamaan omia juurtuneita toimintatapoja. Voisiko riskienhallinta olla osa-alue, jolla teet parannusta? Mitkä muutokset ja toimintatavat parantaisivat riskienhallintaa omissa projekteissasi?

Ota yhteyttä, autamme mielellämme.

Apua, projektini on kriisissä!

Vähemmälle kirjoittelulle tuppaavat jäämään ne projektit ja hankkeet, joissa on koettu suurimmat vaikeudet ja haasteet, vaikka niistä olisikin opittavissa suurimmat viisaudet. Tarkoitan niitä projekteja, jotka eivät syystä tai toisesta ole menneet minkään oppikirjan tai taiteen sääntöjen mukaan.

Case-projektissa, johon hyppäsin kesken kaiken asiakkaan puolelle projektipäälliköksi tietojärjestelmän käyttöönottoprojektiin, ei ollut saatu tuotettua asiakkaan tavoittelemia väli- ja lopputuloksia. Projekti oli kriisissä. En kuitenkaan kirjoita tässä vaikeuksien syistä, vaan niistä keinoista, joilla saavutimme lopulta projektin tavoitteet.

Mitkä asiat auttoivat meitä saavuttamaan tavoitteemme?

  1. Projektiryhmän jäsenten roolit ja vastuut ovat selkeät
    • Selkiytimme roolit ja vastuut. Kaikille tehtiin selväksi, mitkä ovat niin osapuolien (asiakas ja toimittaja) kuin projektiryhmän jäsenten roolit ja vastuut projektissa.
    • Osapuolien väliset työparit määriteltiin ja parien työskentelytavat selkiytettiin. Asiantuntijat kommunikoivat suoraan keskenään määritellyn tavoitteen saavuttamiseksi.
  2. Projektin tavoitteista on selkeä yhteisymmärrys
    • Projektin omistajien sekä keskeisten sidosryhmien kanssa varmistimme, että projektin tavoitteet olivat ajan tasalla.
    • Priorisoimme projektin omistajien kanssa järjestelmään toteutettavien toiminnallisuuksien tärkeysjärjestyksen, jotta saisimme nopeasti tärkeimmät ominaisuudet käyttöön.
  3. Projektissa on yhteinen realistinen aikataulu
    • Pidimme suunnittelutyöpajan, jossa laadimme projektille yhteisen, inhorealistisen toteutusaikataulun, jossa oli kaikkien osapuolien kaikki tehtävät. Projektissa ei ollut tätä ennen ollut kunnollista aikataulua eikä asiakkaalla ollut tietoa, mitä piti tehdä ja milloin.
    • Vaiheistimme käyttöönotettavan järjestelmän ominaisuudet, jotta saisimme tärkeimmät ominaisuudet käyttöön mahdollisimman pian. Näin asiakas pääsisi hyötymään projektin tuloksista mahdollisimman aikaisin.
    • Vaiheistimme ja tasasimme käyttöönotot eri aikavyöhykkeille välttyäksemme järjestelmän ylikuormittumiselta. Järjestelmällä oli kymmeniä tuhansia käyttäjiä lähes sadassa maassa.
  4. Yhteisistä toimintatavoista on sovittu ja niistä pidetään kiinni
    • Yhteiset kaikkia osapuolia koskevat toimintatavat ja -käytännöt ovat tärkeitä ensimmäisestä päivästä lähtien.
    • Asioiden kaunistelu oli yksi keskeinen haaste toimittajan puolelta. Tämän asian ilmentymät ehkäisivät yhteisen projektihengen syntymisen – olimme kahta leiriä loppuun asti. Kaikki keskustelut ja sähköpostit piti dokumentoida ja tallentaa huolellisesti.
    • Oman porukan motivointi ja tsemppaaminen oli tärkeä osa päivittäistä projektipäällikön työtä. Oli tärkeää tarjota mahdollisuus ”tuulettaa” tuntemuksia säännöllisesti mutta myös jämäkästi tuottaa vastuullamme olevat tuotokset säntillisesti.
    • Otimme vastuuta projektissa enemmän kuin mitä sopimuksessa oli sovittu.
  5. Projektin tilannekokous pidetään säännöllisesti viikoittain
    • Kun saimme yhteisen aikataulun myötä näkyvyyden, mitä tuotoksia osapuolien pitää saada milloinkin aikaan, oli tietenkin helpompi ohjata tekemistä ja tuottaa tarvittavia tuotoksia.
    • Projektissa oli pidetty aiemminkin viikoittain tilannekokouksia, mutta nyt kokouksissa voitiin keskittyä riitelyn sijaan projektin tavoitteisiin ja tuotoksiin.
    • Kriittisillä tuotoskokonaisuuksilla, joiden toteuttamisessa oli ollut vaikeuksia, pidettiin erillinen tilannekokous viikoittain. Nämä henkilöt eivät osallistuneet projektin tilannekokoukseen, koska heitä koskivat vain tiettyjen teknisten kokonaisuuksien toteuttaminen
  6. Projektilla on vahva omistaja
    • Projektilla oli asiakkaan puolella useampi omistaja ja projektin ohjausryhmällä oli kokoa ehkä enemmän kuin olisi ollut tarvetta.
    • Tiivistimme ohjausryhmän kokoonpanoa. Tiukensimme yhteistyötä keskeisen omistajan kanssa, jolle projektin tuotokset toivat suurimman hyödyn. Omistaja tuki, mahdollisti ja kannusti projektia esimerkillisesti.
    • Asiakkaan organisaatio tuki projektia myös muuten esimerkillisesti. Kaikki halusivat auttaa projektia onnistumaan. Yhteishenki ja projektikulttuuri olivat upeita.

Millä keinoin olet itse selviytynyt haastavista projekteista? Jätä kommentti tai ota yhteyttä, mikäli tarvitset apua. Ota yhteyttä »

Pienin askelin eteenpäin projektitoiminnan kehittämisessä

Olemme tyypillisesti kunnianhimoisia hankkeidemme tavoitteiden asettamisessa, mutta liian kunnianhimon takia moni sinänsä hyödyllinen hanke jää käynnistämättä. Tämä pätee myös oman toiminnan kehittämiseen. Toiminnan kehittämishankkeissa merkityksellistä on, että ongelmien tiedostaminen ja pienetkin edistysaskeleet parantavat suorituskykyä ja edistävät toiminnan laatua.

Toimivin väline pienissäkin muutoshankkeissa on toiminnan mallintaminen prosessikaaviona. Etuna on, että toteutuksessa voidaan edetä ketterästi ja iteratiivisesti, työ on läpinäkyvää ja että loppudokumentaatio syntyy tekemisen myötä. Samalla syntyy myös lähtökohta jatkokehitykselle.

Alla on esitetty viisi pääkohtaa pienen ja hyvin rajatun projektitoiminnan kehityshankkeen tueksi:

  1. Rajaa kokonaisuus ja määritä realistinen tavoite. Määritä tavoitteet ja lopputulokset. Pienikin saavutus vie asiaa eteenpäin ja kaikkea ei tarvitse saavuttaa kerralla. Selkeä ja rajattu kokonaisuus on myös helppo perustella, ottaa käyttöön ja kehittää edelleen.
  2. Tunnista roolit ja määritä vastuut. Keihin kehityshanke vaikuttaa tavalla tai toisella? Oleellista on määrittää myös toiminnalle omistaja. Huomaa, että projektitoiminnan prosessit ulottuvat organisaation eri toimintojen ylitse ja omistajuuden tulee heijastaa tätä.
  3. Erittele toiminnassa syntyvät väli- ja lopputuotokset. Tuotosten tavoitteena on vakioida toimintaa sekä luoda mitattavuutta ja edellytykset objektiiviseen päätöksentekoon toiminnan päätöksentekopisteissä.
  4. Määritä tehtävät ja tapahtumat sekä näiden riippuvuudet. Päätä kuvaustaso ja rajaa kaavioissa käytettyjen symbolien joukko mahdollisimman suppeaksi. Tarkenna mallia karkeammasta hienompaan. Testaa ja analysoi mallin toimintaa. Huomioi erityisesti päätöksentekopisteet. Priorisoi ja yksinkertaista. Tunnista ongelmapisteet: selvitä syyt ja luo ratkaisut yhdessä sidosryhmien kanssa.
  5. Ota käyttöön sovitut käytännöt ja luo edellytykset jatkokehitykselle. Selkeä ja hyvin jäsennelty toteutus tukee toimintamallin vakiinnuttamista osaksi organisaation toimintaa ja toimii perustana jatkokehitykselle. Hyvän omistajan hallinnassa prosessia kehitetään ja ylläpidetään niin, että se vastaa aina parhaalla mahdollisella tavalla organisaation tarpeita.

Kauneuskilpailu

On jälleen aika kilpailla valtionhallinnon IT-konsultoinnin puitesopimustoimittajan asemasta vuosille 2015 – 2019. Tuttujen kesken tarjouskilpailu tunnetaan myös ”kauneuskilpailuna”.

Haukkuma ”kauneuskilpailu” on vakavasti otettava sanapari. Mieleen nousee viimevuosina lehdissä kirkuneet otsikot julkishallinnon epäonnistuneista IT-hankkeista. Aiheesta ovat keskustelleet kaikki valtamediat ja monet bloggarit. Merkittävin asian esiin nostanut taho on Valtiontalouden tarkastusvirasto. VTV:n mukaan yhtäältä on ollut kyse siitä, osataanko IT-projekteja ostaa, ja toisaalta siitä, osataanko niitä johtaa. Ongelmat ilmenivät toteutusaikataulujen pettämisenä, ohjauksen riittämättömyytenä, kustannusarvioiden epätarkkuutena sekä riskianalyysien puutteena ja suppeutena (Valtiontalouden tarkastusviraston tarkastuskertomus 3/2013).

Yksi puitejärjestelyjen osa-alueista on ”Projektinhallinta- ja integraattoripalvelut”. Tämän osa-alueen sisältö on tarjouspyynnössä määritelty termein budjettivalvonta, aikatauluvalvonta, projekti-/hankejohtaminen, toimittajasuhteiden hallinta, toimittajakoordinointi, projektihallinta, portfolion hallinta jne. Yleisesti ottaen kohdealueen määrittely on tehty hyvin ja on varsin kattava. Tarvekin on mitä ilmeisin.

Tarjouskilpailusta tekee kauneuskilpailun tapa, jolla puitesopimustarjoukset pisteytetään ja toimittajat laitetaan paremmuusjärjestykseen ja valitaan. Pisteytys perustuu hintaan (40%) ja laadullisiin tekijöihin (60%). Hinnan osalta pisteitä saa eniten se, joka on halvin. Laadun osalta se, joka on laadullisesti paras.

Laatupisteitä tarjoajat saavat tarjotun henkilöstön koulutuksesta, kokemuksesta, käyttöasteesta ja kielitaidosta. Kokemuksella on suurin painoarvo (75%), koulutus tulee toisena (15%) ja seuraavina ovat samanarvoisina laskutusaste ja kielitaito (molemmat 5%). Lähes maksimipisteet, 95, voi siis saada oikean ikäinen off-shore tohtori, jolla on korkea ulkomainen käyttöaste ja joka ei osaa suomea. Tällaiset resurssit ovat tunnetusti myös hyvin edullisia.

Mikä tarjouskilpailun pisteytyksessä erityisesti kuitenkin kummastuttaa on se, että projektinhallinnan osaamisalueella ei anneta lainkaan painoarvoa sille, onko tarjotulla henkilöillä arviointiin perustuvaa näyttöä projektijohtamisen osaamisesta. Erinomaisia kansainvälisiä standardeja olisi tarjolla useampiakin. Tunnetuimpia näistä ovat IPMA ja PMI. Myös PRINCE2 on viimevuosina saanut yhä vankemman aseman sertifioinnissa.

Jyväskylän Yliopistossa tehtiin muutama vuosi sitten ansiokas pro gradu-tutkielma ”Julkishallinnon IT-kehityshankkeiden epäonnistuminen ja siihen johtavat syyt”. Vertailemalla gradun havaintoja ja puitesopimustoimittajien kauneuskilpailua voi vain hämmästellä puitejärjestelyn valintakriteeristöä. Ymmärrän toki tarjouskilpailun laatijoiden tuskan ja valintaprosessin vaikeuden. Kuitenkin odottaisin syvällisempää paneutumista projektijohtamisen osa-alueeseen. Onnistunut projektinhallinta ja johtaminen on IT-projektien keskeisin menestystekijä. Halvin projektipäällikkö on erittäin harvoin paras.