CPM Creative Project Management

Transkriptio

1 eli projektien ja hankkeiden luova johtaminen ketteryyttä, gantteja ja tikettejä yhdistellen Pasi Malmi Karel Åkerlund

2 CPM Creative Project Management eli projektien ja hankkeiden luova johtaminen ketteryyttä, gantteja ja tikettejä yhdistellen 1

3 Copyright 2013 Pasi Malmi, HTT Toimittaja ja konseptin tarkistus: Karel Åkerlund, KM CPM konsepti: PLUS Akatemia Oy ISBN (rengaskirja) ISBN (PDF) Kustantaja: PLUS Akatemia Oy Pihkatie 3 A HELSINKI Sähköposti: info@plusakatemia.com Rekisteröitymällä PLUS Akatemian kotisivuilla CPM hyödyntäjäksi, saat uusimman sähköisen pdf version omaan käyttöösi. 2

4 Sisällys 0 1 JOHDANTO CPM Creative Project Management menetelmän hyödyt eri kohderyhmille Kirjan rakenne ja etenemisjärjestys Mitä luovuus on ja miten CPM hyödyntää luovuutta? PROJEKTINHALLINNAN PERUSKÄSITTEET Peruskäsitteet sekä projektien kytkeytyminen strategiseen johtamiseen Projektin organisoinnin peruskäsitteitä Projektin vaiheet ja projektinhallinnan osa-alueet Projektinhallintamenetelmät sekä niiden jaottelua ja vertailua Ganttin menetelmä Vesiputousmalli PMBOK Prince Protoileminen ja iteratiiviset kehitysmallit Inkrementaalinen projektitoteutus sekä paranneltu vesiputous Scrum Lean ja IPMA CREATIVE PROJECT MANAGEMENT MENETELMÄN YLEISKUVAUS Projektien monimutkaisuusluokitus sekä vaihtoehtoiset ohjausratkaisut Gantt-ohjaus CPM -mallissa Aikataulu- ja kustannusennusteiden laskenta valmiusasteen ja etenemisvauhdin pohjalta Valmiusasteen laskenta Valmiusasteeseen perustuvat työmäärä-, aikataulu- ja kustannusennusteet Ketterän julkistusprojektin scope-ennusteet Erilaisten tehtävien ja projektien jakautuminen päävaiheisiin KETTERIEN KEHITTÄMISHANKKEIDEN JOHTAMINEN CPM:SSÄ Ketterän kehittämishankkeen tavoitteet ja osatehtävät Hankkeen organisaatio sekä ohjaus säännöllisillä kokouksilla Organisaatiokaavio Organisaation toimielinten ja roolien täsmennykset CPM:ssä Ketterien kehittämishankkeiden ohjaus säännöllisillä kokouksilla Ketterän kehittämishankkeen aloitus, toteutus, ohjaus ja päätös Yleiskuvaus ja peruskäsitteet Hankkeen aloitus askel askeleelta Ketterän kehittämishankkeen toteutus ja päätös Ketterän kehittämishankkeen ohjaus Ketterän julkistusprojektin aloitus, toteutus, ohjaus ja päätös

5 4.4.1 Ketterien julkistusprojektin tyypit ohjauksen näkökulmasta Ketterän julkistusprojektin aloitus Ketterän julkistusprojektin toteutus, ohjaus ja päätös Sprinttien aloitus, toteutus, ohjaus ja päätös Yhteenvetokaavio Sprintin aloitus Sprintin toteutus sekä päivittäisjohtaminen Edistymiskatselmukset, valmiusaste ja tekninen velka Sprintin päätös eli luovutuskatselmus ja toimintatapojen kehittämistyöpaja Miksi sprintit kestävät 4 viikkoa ja miksi ne jakautuvat neljännessprintteihin? Sprinttien luova käyttö ilman kytkentää tuotejulkistuksiin TEHTÄVIEN, TIKETTIEN JA TEHTÄVÄSALKKUJEN JOHTAMINEN Aihepiirin yleiskuva Yksittäisen ison tehtävän johtaminen Atomististen tehtävien johtaminen Miten atomistiset tehtävät syntyvät erilaisille tehtävälistoille? Atomististen tehtävien ohjauksen tavoitteita ja suosituksia Vesiputoustehtävien ohjaus tiketeillä ja ITIL:illä Määrämuotoiset vesiputoukset, ITIL ja Lean Vapaamuotoisten pienoisvesiputousten johtaminen Tehtäväsalkun johtaminen GANTT-KAAVIOIDEN HYÖDYNTÄMINEN CPM:SSÄ Mille osa-alueille Gantt-kaaviot soveltuvat? Ison ja monimutkaisen hankkeen johtaminen Gantt-kaavioilla Projektien ohjaus integroidulla Gantt-ohjausjärjestelmällä eli IGO:lla Integroitu Gantt-ohjausjärjestelmä Projektin Gantt-kaavion sekä aikatauluennusteen laadinta IGO:lla Viikottaiset aikataulu-, työmäärä- ja kustannusennusteet IGO:lla Gantt-ohjauksen ruma totuus suomalaisissa projekteissa Edulliset Gantt-ohjauksen ratkaisut YHTEENVETO CPM :N SUOSITTELEMISTA TEHTÄVIEN JA PROJEKTIEN HALLINTAJÄRJESTELMISTÄ

6 1 Johdanto 1.1 CPM Creative Project Management menetelmän hyödyt eri kohderyhmille CPM Creative Project Management on luova ja innovatiivinen projektinhallintamenetelmä, jolla johdetaan ja ohjataan - hyvin erilaisia ja eri kokoluokkiin kuuluvia projekteja - ketteryyttä, gantteja ja tikettejä yhdistellen sekä - helposti laskettavia aikataulu-, kustannus- ja scope-ennusteita 1-4 kertaa kuukaudessa hyväksi käyttäen. Vaikka CPM onkin luova ja uusi menetelmä, se on silti huomattavasti monia aiempia menetelmiä ja ohjausjärjestelmiä jämäkämpi, realistisempi ja systemaattisempi. CPM:n tarjoaa projektien ohjausryhmien jäsenille sekä projektisalkun johtajille keinon hallita monista eri menetelmillä johdetuista projekteista muodostuvaa kaaosta selkeiden seurantamenettelyjen ja mittarien avulla. Samalla se myös auttaa projektien aloituspäätöksen sekä mahdollisen keskeytyspäätöksen tekemisessä. CPM myös auttaa tekemään parempia sopimuksia tilanteessa, jossa projektitoteutus ostetaan yhdeltä tai useammalta toimittajalta. Projektien omistajille ja projektipäälliköille CPM tarjoaa välineen käynnissä olevien projektien tehokkaampaan ohjaukseen, jossa ohjauspäätökset oikeasti perustuvat kunnollisiin kokouskäytäntöihin sekä aikataulu- ja kustannusennuseisiin ilman, että kokouksiin sekä ennusteiden tuottamiseen kuluu kohtuuttomasti aikaa. Myös riskien, ongelmien ja muutosten tehokkaampaan hallintaan löytyy keinoja CPM:n avulla. Lisäksi CPM tarjoaa innovatiivisia sopimusmalleja, jotka siirtävät osan kustannusriskistä toimittajalle, mutta säilyttävät projektin silti ketteränä. Projektien sisäisten tiimien vetäjille ja scrum mastereille CPM tarjoaa kunnollisen näkemyksen siitä, mihin laajempaan kokonaisuuteen heidän tiiminsä ja sprinttinsä liittyvät sekä miksi projektien ohjausryhmän sekä organisaation johdon on saatava 1-4 kertaa viikossa tietyt aikataulu-, kustannus- ja scope-ennusteet. CPM tarjoaa myös helpot mallit ja menetelmät näiden ennusteiden tekemiselle. Lisäksi CPM ohjeistaa tiiminvetäjät siihen, miten päivittäisiä kokouksia, viikkopalavereja sekä joka neljäs viikko pidettäviä kokouksia kannattaa yhdistellä. Lisäbonuksena scrum mastereille ja tiiminvetäjille CPM tarjoaa selkeän ja helppotajuisen kasvupolun kohti isompien projektien vetovastuuta. Tämän lisäksi CPM tarjoaa organisaatioiden laatupäälliköille sekä projektinhallinnan kehittämisestä vastaaville henkilöille keinon organisaation projektinhallintamenetelmistön nopeaan ja isoon kehitysaskeleeseen tilanteessa, jossa perinteisten ohjausmallien yhdistäminen uusiin ketteriin menetelmiin tuntuu vaikealta. CPM:n perusta muodostuu tästä kirjasta sekä sitä tukevista koulutusmateriaaleista ja harjoituksista. Niiden tueksi CPM tarjoaa projektisuunnitelman mallidokumentit hyvin erilaisia ja erityyppisiä projekteja varten, kuten esimerkiksi 5

7 - Ylläpitotiimin toteutusvastuulle tulevia pienkehitysprojekteja varten - Ketteriä projekteja ja isoja ketteriä (isoja) kehittämishankkeita varten - Ganttin menetelmillä ohjattavia projekteja varten - Ganttia ja ketteryyttä yhdistäviä isoja ja monimutkaisia hankkeita varten Lisäksi CPM:ään kuuluuvat projektien ohjausjärjestelmien kehittämistä koskevat white paper ohjeistukset mm. siitä, miten erilaisia projektinhallintaohjelmistoja kannattaa yhdistellä ja kehittää CPM:n suosittelemien toimintatapojen toteuttamiseksi. White paperit tarjoavat siten apua ja ohjeita myös organisaatioiden ohjausjärjestelmien ja työkaluohjelmistojen kehittäjille sekä uusia ja innovatiivisia ratkaisuja kehittäville ohjelmistoyrityksille ja integraattoreille. 1.2 Kirjan rakenne ja etenemisjärjestys CPM:n taustalta löytyy Pasi Malmin sekä Karel Åkerlundin vuosikymmenten mittainen kokemus erilaisista projektinhallintajärjestelmistä, niiden kehittämisestä sekä yli 300 projektin ohjausryhmän jäsenenä, projektisalkun johtajana tai auditoijana toimimisesta. Tämä tarkoittaa sitä, että CPM perustuu vähintäänkin mutkan kautta perinteisiin projektinhallintamenetelmiin kuten PMBoK, Prince2, iteratiivis-inkrementaaliset menetelmät, Scrum, Lean, Kanban, CMMI, ITIL sekä projektisalkun johtamisen teoria ja projektien käynnistämiseen liittyvä päätösporttimalli. Jotta lukijan olisi helpompi omaksua CPM sekä kytkeä mallissa esiintyvät ideat aiempiin projektinhallinnan menetelmiin, tämä kirja alkaa projektinhallinnan peruskäsitteiden kertauksella sekä merkittävimpien projektinhallintamallien kuvaamisella (luku 2). Sen jälkeen luvussa 3 esitetään nopea yleiskatsaus CPM-mallin kaikkiin keskeisiin vaiheistus-, ohjaus- ja organisointimenettelyihin sekä siihen, miten niitä sovelletaan erilaisissa ja eri monimutkaisuustasoa edustavissa tehtävissä ja projekteissa. Tämän luvun tarkoituksena on tarjota lukijalle oivallus siitä, miksi projektien systemaattinen ohjaus helppoja ennustamismenetelmiä hyödyntäen on niin tärkeää ja miten ohjaus voidaan toteuttaa lähes samanlaisia periaatteita noudattaen hyvin erilaisissa projekteissa. Kirjan loppuosassa käsitellään tarkemmin sitä, minkälaisella organisaatiolla, kokousmenettelyillä, ennusteilla ja ohjausjärjestelmillä eri tyyppisiä projekteja kannattaa johtaa. 1.3 Mitä luovuus on ja miten CPM hyödyntää luovuutta? Luovuus on kykyä uusien ideoiden keksimiseen sekä vanhojen ideoiden ja menetelmien yhdistelemiseen uudella innovatiivisella tavalla. Luovuuden edistäminen ja tehokas hyväksikäyttäminen edellyttävät yleensä rönsyilevän ja innostuneen ideoinnin kannustamista ja turhan byrokratian poistamista mutta kustannusten kurissa pitäminen ja tehokas tuloksiin pääseminen edellyttävät samalla kuitenkin luovuuden ohjaamista ja luovuusprosessin määrämuotoista valvontaa. Tämän vuoksi CPM-projektinhallintaan kuuluvat olennaisina osina: - Projektinhallinnan erilaisten lähestymistapojen luova yhdistäminen toisiinsa 6

8 - Satojen eri organisaatioissa toimiviksi havaittujen projektinhallintakäytäntöjen luova yhdisteleminen toisiinsa - Byrokratian ja turhien projektiohjeistusten karsiminen - Tiukka kurinalaisuus siinä, miten luovasti ja ketterästi johdettuja projekteja aloitetaan, ohjataan ja lopetetaan tavalla, joka mahdollistaa organisaation kaikkien erilaisten projektien yhteismitallisen johtamisen sekä projektisalkun optimoimisen. Luovuus ilmenee projekteissa hieman eri tavoin projektin ideointivaiheessa, määrittelyvaiheessa ja toteutusvaiheessa. Ideointivaiheessa tärkeää on tuottaa riittävä määrä innovatiivisia ideoita, joista jotkut saattavat sisältää niin suurta uutuusarvoa, että syntyy merkittävää kilpailuetua, laadun kehitystä tai kustannushyötyä tuottava projekti. Projektin määrittely- ja suunnitteluvaiheessa luovuus on yleensä hyvä rajoittaa siihen, että vaihtoehtoisia projektisopimus- ja hinnoittelumalleja sovelletaan luovasti sopimusneuvotteluissa ja lisäksi projektinhallintamenetelmiä yhdistellään projektiin luovasti siten, että kullekin osa-alueelle saadaan käyttöön paras mahdollinen ratkaisu. Toteutusvaiheessa luovuus liittyy erityisesti siihen, miten projektissa esiin nousseisiin teknisiin ja viestinnällisiin haasteisiin, ihmisten johtamisen ongelmiin sekä kustannus- ja aikatauluongelmiin saadaan ideoitua nopeita ja tehokkaita ratkaisuja. Näiden luovien ratkaisujen tueksi CPM tarjoaa ongelmia aktiivisesti esiin nostavia raportointimenettelyjä ja palautekeskusteluja, jotka pakottavat projektipäällikköä, projektin omistajaa sekä tiiminvetäjiä luoviin ratkaisuihin, jotka silti toteutetaan selkeiden pelinsääntöjen puitteissa ilman, että luovuuden nimissä viedään pohja pois projektin systemaattiselta, ennusteisiin perustuvalta johtamiselta. Projektipäällikön näkökulmasta luovuutta tarvitaan siihen, jotta projektipäällikkö osaisi a käyttää CPM:ssä kuvattuja vaihtoehtoisia toiminta-tapoja luovasti ja kuhunkin tilanteeseen sopivasti. Tämä edellyttää projektipäälliköltä tutustumista kaikkiin CPM:ään sisältyviin tehtävä- ja projektityyppeihin sekä niiden toteutus- ja ohjausmenetelmiin. 7

9 2 Projektinhallinnan peruskäsitteet 2.1 Peruskäsitteet sekä projektien kytkeytyminen strategiseen johtamiseen Projekti on joukko samaa tavoitetta palvelevia tehtäviä, joiden avulla pyritään täyttämään asetetut tavoitteet ennalta asetettuun määräpäivään mennessä. Projekteilla on lähes aina asetetun valmistumispäivän lisäksi myös ennalta määrätty kustannusarvio, jonka puitteisa projektin tulisi pysyä. Projekteille asetetut tavoitteet kytkeytyvät usein organisaation strategisiin tavoitteisiin ja kehittämisohjelmiin, mutta eivät kuitenkaan aina. Projektinhallinta tarkoittaa niitä toimenpiteitä tai prosesseja, jotka on suoritettava sen varmistamiseksi, että projekti saavuttaa asetetut tavoitteet määräpäivään mennessä ja mielellään niillä resursseilla, jotka projektin käyttöön alun perin annettiin. Projektiorganisaatioita ovat sellaiset yritykset ja julkisorganisaatiot, joissa käytetään jatkuvasti ja merkittävissä määrin projekteja toiminnan ohjauksen ja kehittämisen välineenä. Projektiorganisaatioissa kullakin työntekijällä on periaatteessa vakituinen linjaesimies, mutta työntekijät työskentelevät tosiasiallisesti suurimman osan ajastaan projekteissa. Projektisalkku on joukko projekteja, joita valvotaan ja ohjataan yhtaikaisesti ja samoja raportointikäytäntöjä ja ohjausperiaatteita noudattaen. Projektisalkun johtamisella pyritään varmistamaan, että salkkuun otetaan mukaan vain sellaisia projekteja, jotka ovat kustannus-hyötytarkastelun mukaan kannattavia, joilla ei ole liian korkeaa riskitasoa ja jotka ovat organisaation strategiaa vahvasti tukevia. Mikäli organisaatiolla on käynnissä satoja projekteja yhtaikaa, projektit jaetaan yleensä useisiin rinakkaisiin projektisalkkuihin siten, että samassa salkussa on samaan aihepiiriin, asiakkaaseen tai toimintaalueeseen liittyviä projekteja. Ohjelma (program, programme) on joukko samaa strategisen tason tavoitetta palvelevia projekteja, joilla on melko paljon keskinäisiä riippuvuuksia siten, että kyseinen projektijoukko on päätetty asettaa yhteisen johdon (program management) alaisuuteen. Ohjelman aikana toteutetut projektit voivat antaa ohjelman johdolle uutta tietoa ja näkemyksiä, jotka vaikuttavat hankkeen tavoitteiden tarkentamiseen tai muuttamiseen. Kriitikoiden mukaan ohjelman käsite on turha, koska kaikki ohjelmat voidaan mieltää joko isoiksi projekteiksi taikka toisiinsa liittyvistä projekteista muodostuviksi projektisalkuiksi. Hankeella tarkoitetaan toisinaan valmisteluvaiheessa olevaa investointia, jolle haetaan hankerahoitusta sekä käynnistyslupaa. CPM:ssä hankkeella tarkoitetaan kuitenkin isoa projektia (endeavour), joka muodostuu useista alemman tason projekteista tai muista isoista tehtäväkokonaisuuksista. Ohjelmajohtaminen on strategisen johtamisen piiriin kuuluva menetelmä, jossa samaa strategista tavoitetta palvelevat projektit ja projekti-ideat (yleensä kehittämisprojektit) kootaan yhteen ohjelmiksi, joiden puitteissa ohjelmien tavoitetta palvelevia projekteja aloitetaan, toteutetaan ja lopetetaan. 8

10 Strateginen johtaminen on johtamisoppi, jossa täsmennetään organisaation toiminta-alue ja keskeiset asiakasryhmät, määritellään organisaatiolle joukko strategisia kehittämistavoitteita sekä annetaan alemman tason organisaatioyksiköille tehtäväksi täsmentää omaan toiminta-alueeseesa liittyviä kehittämistavoitteita sekä perustaa projekteja, ohjelmia ja/tai projektisalkkuja. Organisaation strategia ja strategiset tavoitteet Projektisalkku tai ohjelma 1 Projektisalkku tai ohjelma 2 Projektisalkku tai ohjelma N Projekti 1 Projekti 2 Projekti 3 Projekti N Kuten kuvasta näkyy, organisaatio voi perustaa strategiansa toteuttamista varten yhden tai useampia projektisalkkuja tai kehittämisohjelmia ja kunkin salkun tai ohjelman alla voi olla monia projekteja. Päätösporttimalli (control gate model) on projektien strategiseen johtamiseen sekä projektisalkun johtamiseen tarkoitettu malli, jonka mukaan projektit pitää aloittaa askel askeleelta kustannushyötyarviota ja riskianalyysia tarkentaen sillä tavoin, ettei suoraa päätä ilman kunnollisia valmisteluja sitouduta suurten ja riskialttiiden projektien toteutukseen. Päätösporttimallissa projektin valmistelu etenee vaiheittain ja jokaisen vaiheen jälkeen päätetään, jatketaanko projektin valmistelua eteenpäin kohti toteutusta ja kohti yhä suurempia kustannuksia. 2.2 Projektin organisoinnin peruskäsitteitä Projektin organisaatio on projektin kestoajaksi perustettu väliaikainen rakennelma, joka muodostuu henkilöistä, rooleista ja toimielimistä sekä johtosuhteista ja viestintäkanavista. Projektiorganisaation jäseniksi nimitetään toisaalta täysipäiväisesti työskenteleviä henkilöitä, mutta toisaalta myös osa-aikaisia sekä tukirooleissa toimivia henkilöitä, jotka on annettu projektin käyttöön joko joko projektin käynnistäjäorganisaation tai yhteistyökumppaneiden toimesta. Projektin organisaatiokaavioon kannattaa kuvata projektin ylin johto, projektin vetäjä sekä projektin vetäjän suorassa alaisuudessa olevat henkilöt tai tiimit. Hyvä organisaatiokaavio kuvaa yksiselitteisellä tavalla sen, kuka toimii kenenkin alaisuudessa ja mitä pääreittejä pitkin organisaation sisäinen viestintä tapahtuu. Tämä on tärkeää siksi, että selkeyttämätön ja rajoittamaton viestintä saattaa aiheuttaa projektipäällikön ja muiden avainhenkilöiden tukehtumisen liiallisen sähköpostitulvan alle. 9

11 Ohjausryhmä Projektin omistaja Projektipäällikkö Tiimin 1 Tiimi 2 Tiimi 3 Tiimi N Ohjausryhmän vastuulla on projektin ylätason johtaminen kuten esimerkiksi päätökset projektin tai kehittämishankkeen käynnistämisestä, alkuvaiheen päätösporttien hyväksymisestä sekä projektin hyväksytyn budjetin ylittävien muutospyyntöjen sekä riskinhallintatoimenpiteiden toteuttamisesta. Tilanteen vaatiessa ohjausryhmän vastuulla on myös tehdä päätös projektin keskeyttämisestä tai projektipäällikön vaihtamisesta. Ohjausryhmän tehtävänä on lopulta myös tehdä päätökset projektitoimituksen hyväksymisestä sekä siitä, onko projektin päätösvaiheen kaikki toimet suoritettu siten, että projekti voidaan päättää. Projektipäällikön vastuulla ovat ne projektinhallinnan osa-alueet, joita ei ole määritelty ohjausryhmän vastuulle. Projektin omistaja on projektipäällikön tärkein tukihenkilö ohjausryhmässä. Projektin omistaja ja projektipäällikkö valmistelevat yhdessä ohjeusryhmän kokoukset ja projektin omistajalle on yleensä annettu myös valtuudet tehdä sellaisia nopeita ohjauspäätöksiä, joilla projektin edistyminen varmistetaan ja projektiin liittyvät pienet riskit ja ongelmat ratkaistaan. Projektin omistajaa kutsutaan ketterissä projektinhallintamenetelmissä toisinaan myös product owneriksi, koska hän omistaa projektin tuloksena syntyvän tuotteen tai julkistuksen. Tiimin jäsenten vastuulla on toteuttaa ne tehtävät, jotka on projektin tehtävälistoissa, projektiryhmän kokouksissa taikka projektin resurssisuunnitelmassa ja tiiminjäsenen toimenkuvassa määritelty hänen vastuulleen. Vapaamuotoisesti ja Scrum-tyyppisesti ohjatuissa projekteissa tiimin jäsenet voivat ottaa omalle vastuulleen tehtäviä myös omaehtoisesti, esimerkiksi katsomalla mitä tehtäviä tiimin tehtävälistalla on avoimena. Jos toteutustiimejä on enemmän kuin yksi, niille kannattaa yleensä nimetä kullekin tiimin vetäjä, scrum master tai tekninen projektipäällikkö. Mikäli projektipäällikön alaisena toimii projektipäälliköitä, häntä kutsutaan yleensä hankepäälliköksi tai projektijohtajaksi. CPM:n suosittelema kehittämishankkeiden toteutusorganisaatio on kuvattu tarkemmin luvussa

12 2.3 Projektin vaiheet ja projektinhallinnan osa-alueet Projektinhallinta tarkoittaa niitä toimenpiteitä tai prosesseja, jotka on suoritettava sen varmistamiseksi, että projekti saavuttaa asetetut tavoitteet määräpäivään mennessä ja mielellään niillä resursseilla, jotka projektin käyttöön alun perin annettiin. Projektin vaiheita ovat karkealla tasolla aloitus, toteutus ja päätös. Aloitus, Initiation Toteutus, Execution Päätös, Closing Toteutusvaiheen aikana projektipäällikön tulee johtaa toteutusta, mikä tarkoittaa käytännössä projektiryhmän jäsenten, projektitoimittajien sekä sidosryhmiin kuuluvien henkilöiden johtamista, motivointia ja sitouttamista. Tämän lisäksi projektipäällikön pitää yhdessä ohjausryhmän kanssa systemaattisesti ohjata projektia. Kolmas toteutuksen aikainen johtamistehtävä tai prosessi on suunnitelmien täsmentäminen. Lopuksi projektipäällikön tehtävänä on päättää tai sulkea projekti, mikä edellyttää sitä, että kaikki projektin toteutuksen sisälle määritellyt vaiheet ja tehtävät ovat valmistuneet. Suunnitelmien täsmentäminen Aloitusvaiheessa projektipäällikön tehtävänä on projektin asteittain tarkentuva suunnitteleminen siihen asti, kunnes projektin ohjausryhmä on antanut projektille tarvittavat resurssit ja luvan projektin toteutusta varten sekä hyväksynyt projektisuunnitelman. Aloitusvaiheen johtaminen: Kustannus-hyötyvertailun, vaatimusluettelon sekä projektisuunnitelman asteittain tarkentuva laadinta. Toteutuksenjohtaminen raportointi tehtävät Systemaattinen ohjaus ohjausjärjestelmien avulla Projektin päättäminen Vaikka projektin aloitusvaihe periaatteessa jo tuottaa toteutuksen johtamista varten tarvittavat suunnitelmat, tehtävärakenteet ja tehtävälistat, on kuitenkin yleistä, että suunnitelmia halutaan täsmentää tai joudutaan täsmentämään toteutusvaiheen edistyessä. Suunnitelmien täsmentäminen tuottaa toteutusvaiheen tehtävärakenteisiin ja tehtävälistoille uusia, tarkemmalla tasolla kuvattuja tehtäviä. 11

13 Systemaattinen ohjaus kytkeytyy toteutuksen johtamiseen siten, että projektipäällikkö ja projektiryhmä tuottavat 1-4 kertaa kuukaudessa raportointietoa systemaattista ohjausta varten. Tärkein raportointitieto muodostuu projektien tehtävien valmiusasteesta ja jäljellä olevista työmääristä, joiden avulla voidaan laskea projektille päivitetty kustannusennuste ja aikatauluennuste. Muuta raportointitetoa ovat tiedot projektiin kohdistuvista riskeistä, ongelmista ja muutospyynnöistä. Kun raportointiteto on kerätty ja tietoihin perustuvat ennusteet on laskettu, projektipäällikön tehtävänä on laatia toimenpide-ehdotukset aikataulu- ja kustannusongelmien sekä muiden esiin nousseiden ongelmien ratkaisemiseksi. Lisäksi projektipäällikön tulee tehdä ehdotukset siitä, miten projektin isoimpia yksittäisiä riskejä pitäisi hallita ja mitkä projektille asetetut merkittävät muutospyynnöt tulisi ottaa toteutettaviksi. Kun kaikki ongelmat, riskit ja muutospyynnöt on projektipäällikön toimesta purettu toimenpideehdotuksiksi, projektipäällikkö päättää yhdessä projektin omistajan tai ohjausryhmän kanssa, mitkä toimenpide-ehdotuksista otetaan toteutettaviksi eli mitkä siirtyvät projektiryhmän toteutusvastuulle tehtävien muodossa (kuvan oikeanpuoleinen nuoli alhaalla). 2.4 Projektinhallintamenetelmät sekä niiden jaottelua ja vertailua Ganttin menetelmä Projektinhallintamenetelmällä tarkoitetaan menetelmää, prosessiohjeistoa, ohjeistoa tai mallia, joka määrittelee, miten projekti tulisi aloittaa, toteuttaa ja päättää sekä minkälaisia toteutuksen vaiheistusmalleja sekä johtamis- ja ohjausmenetelmiä projektissa tulisi soveltaa. Seuraavassa kuvataan lyhyesti tunnetuimmat projektinhallintamenetelmät sekä lisäksi pari ohjeistoa, jotka eivät aivan täytä projektinhallintaohjeiston määritelmää. Ganttin menetelmä koostuu siitä, että projektille muodostetaan tehtävärakenne (work breakdown structure), joka määrittelee tehtävien kestoajat, toteutusresurssit ja toteutusjärjestystä ohjaavat riippuvuudet. Sen jälkeen menetelmässä lasketaan projektinhallintaohjelmiston avulla aika-akselille sijoitettu Gantt-kaavio sekä korostetaan sen sisään punaisella värillä kriittinen polku (ks. kuva alla). Syys Loka Marras Joulu Tammi Helmi 12

14 Kriitinen polku kuvastaa niitä tehtäviä, joiden viivästyminen samalla myös viivästyttäisi koko projektia. Projektipäälliköiden tulisi kiinnittää kriittisen polun varrella olevien tehtävien aikataulun pitämiseen aivan erityistä huomiota. Tämän vuoksi Ganttmenetelmään kuuluu ajatus siitä, että Gantt-kaaviota päivitetään 1-4 kertaa kuukaudessa syöttämällä projektinhallintaohjelmistoon kunkin tehtävän toteutuneet ja jäljellä olevat työmäärät. Tämän jälkeen ohjelma laskee Gantt-kaavion ja kriittisen polun uudestaan sekä antaa samalla ennusteen projektin uudesta valmistumispäivästä. Menetelmään kuuluu myös ajatus siitä, että Gantt-laskentaan erikoistunut projektinhallintaohjelma pitää kirjaa projektille annettujen resurssien kuormituksesta ja kustannuksista siten, että Ganttin päivittäminen tuottaa samalla projektille myös päivitetyn kustannusennusteen sekä resurssien kuormitusennusteen Vesiputousmalli Projektinhallinnan vesiputousmalli on alun perin kehitetty IT-alan ohjelmistoprojekteja varten. Siinä projekti jaetaan toisiaan tiukasti seuraaviin vaiheisiin, joita oli alkuperäisessä vesiputousmallissa noin tusinan verran. Vesiputousmallilla tavoitellaan ihannetta, jonka mukaan projekteissa ei pitäisi edetä ilman huolellisia ja pitkälle vietyjä suunnitelmia toteutusvaiheeseen. Vesiputousmallin massiivista 12-portaista vaihejakoa on yleensä yksinkertaistettu siten, että IT-projektit jaetaan nykyisin suunnilleen seuraaviin vaiheisiin: Määrittely Suunittelu Toteutus Malli olettaa, että projektin aloittaminen tapahtuu määrittelyvaiheen aivan alussa (tai juuri ennen sitä) ja että projekti päätetään ja suljetaan käyttöönottovaiheen valmistuttua (tai heti sen jälkeen). Vesiputousmalli on perinteisen Gantt-ohjauksen ystävä siten, että vaiheet seuraavat toisiaan Gantt-kaavion kuvaamalla tavalla ja lisäksi vaiheiden sisällä tehtävärakenteet kuvataan yleensä Gantt-kaavioina. Vesiputousmalli soveltuu erityisen hyvin rakennusprojekteihin, joissa lainsäädäntö vaatii, että suunnitelmat on ensin hyväksyttävä ennen toteutuksen alkua ja joissa toteutusvaiheen tulokset on riittävän hyvin testattava tai katselmoitava ennen käyttöönottoa. Vaikka vesiputousmalli on alun perin kehitetty ohjelmistoprojekteja varten, se soveltuu kuitenkin erityisen huonosti suuriin ohjelmistoprojekteihin. Tutkimusten mukaan vesiputousmallilla toteutetuista ohjelmistoprojekteista suurin osa myöhästyy ja vaikka ne valmistuisivat ajoissa, toteutus ei yleensä vastaa kunnolla loppukäyttäjien toiveita. Ongelmat syntyvät siitä, että suurissa vesiputousmallilla toteutetuissa tietojärjestelmäprojekteissa loppu- 13 Testaus Käyttöönotto

15 käyttäjät näkevät projektin lopputuloksena syntyvän järjestelmän vasta parin vuoden päästä projektin aloituksesta. Tällöin on jo liian myöhäistä antaa sellaista asiakaspalautetta, joka hyödyllisellä tavalla ohjaisi projektitoteutusta asiakasta paremmin hyödyttävään suuntaan PMBOK PMBOK on melko pitkälti Gantt-menetelmän pohjalle rakentuva amerikkalainen projektinhallintaohjeisto, joka jakaa projektinhallintaprosessit aloitusprosesseihin (initiation and planning), toteutuksen johtamiseen (managing execution), systemaattiseen ohjaukseen (monitoring and control) sekä projektin päättämiseen (closure). Erillinen toteutusvaiheen aikainen suunnitelmien täsmennysprosessi siis puuttuu prosessikartasta. Aloitusvaiheen johtaminen: Käynnistysluvan saanti ja projektin suunnittelu Toteutuksenjohtaminen raportointi ohjaustoimenpiteet Systemaattinen ohjaus Projektin päättäminen PMBOK:in hyvänä puolena on se, että se kuvaa noin 500-sivuisen kirjan muodossa kaikki projektinhallinnan osa-alueet ja projektipäällikön perustehtävät. Huonona puolena on se, että PMBOK antaa ymmärtää, että projektin aloituslupa, annetaan vain kerran ja sen jälkeen projektilla on lupa jatkaa loppuun asti. Tämä ei ole projektisalkun johtamisperiaatteiden mukaista, koska salkun taitava riskinhallinta edellyttää sitä, että projektin keskeyttämistä harkitaan vakavasti useaan kertaan projektin valmistelu- ja aloitusvaiheessa sekä osin myös toteutuksen aikana. PMBOK ei myöskään anna ohjeita siitä, minkälaisella tarkemman tason vaihejaolla toteutusvaihetta tulisi jäsentää ja ohjata eli PMBOK ei ota kantaa siihen, pitäisikö toteutus suorittaa vesiputousmaisesti edeten vai joitain uudempia ketteriä projektinhallintamenetelmiä soveltaen. Tämä jättää PMBOK:in melko ympäripyöreäksi projektinhallintaohjeistoksi sekä asettaa vaatimuksen sille, että PMBOK:ia projektinhallintansa pohjana käyttävät organisaatiot tekevät PMBOK:ista aika pitkälle räätälöidyn version omaa toimialaansa ja omien projektiensa erityispiirteitä varten. 14

16 2.4.4 Prince2 Prince2 on englantilainen projektinhallintamenetelmä, jossa on tiedostettu se, että projekti on yleensä mahdotonta suunnitella tarkan Gantt-kaavion muotoon aivan projektin aloitusvaiheessa. Tämän vuoksi alussa tuotetaan ainoastaan karkeamman tason suunnitelmat, projektin toteutusvaiheen jako alemman tason vaiheisiin (stages) sekä tarkempi tehtävärakenne ja toteutussuunnitelma ensimmäistä stagea varten. Samalla kun ensimmäistä stagea toteutetaan, suoritetaan myös seuraavaan stageen kohdistuvaa tarkempaa suunnittelua. Seuraavassa on esitetty Prince2:n kuvaamat johtamisprosessit yksinkertaistetussa muodossa. Suunnitelmien täsmentäminen Aloitusvaiheen johtaminen: Starting up a project Initiating a project Toteutuksenjohtaminen vaihe vaiheelta Projektin päättäminen Systemaattinen ohjaus 15

17 Prince2:n etuna PMBOK:iin verrattuna on se, että siinä suositellaan toteutuksen jakamista alemman tason vaiheisiin. Ongelmana on edelleen kuitenkin se, että projektipäälliköille ei kerrota, millä periaatteilla nämä alemman tason vaiheet pitäisi muodostaa eli pitäisikö vaiheistus tehdä vesiputousmallin tyylisesti vai uudempia ketteriä menetelmiä hyödyntäen. Toisena ongelmana Prince2:ssa on se, että projektinhallintaa ohjaavat prosessikaaviot ovat hyvin monimutkaisia ja niihin liittyvät ohjeistukset ovat yhteen laskettuna yli tuhatsivuisia. Tämän vuoksi Prince2 ei ole kovin suosittu projektinhallintamenetelmä Iso-Britannian ja YK:n ulkopuolella Protoileminen ja iteratiiviset kehitysmallit Protoileminen (rapid prototyping) on ohjelmistoprojekteja varten kehitetty menetelmä, jolla pyritään torjumaan vesiputousmalliin liittyvä hitaan asiakaspalautteen ongelma. Protoilussa toteutusvaihe käynnistetään nopean prototyypin laatimisella koko projektitoimitusta koskien. Alussa prototyyppi voi sisältää esimerkiksi pelkän visuaalisen mallin siitä, miltä lopullinen projektitoimitus näyttäisi. Tämä visuaalinen malli on tietojärjestelmien alalla yleesä käyttöliittymäprototyyppi, jonka avulla loppukäyttäjä näkee, miltä järjestelmä voisi näyttää valmiina. Seuraavassa vaiheessa prototyyppiin lisätään toiminnallisuutta, joka saa prototyypin muistuttamaan yhä enemmän lopullista projektitoteutusta. Kun loppukäyttäjät näkevät käytännössä prototyypin avulla, miten projektilla tavoiteltu ohjelmisto käyttäytyy, he 16

18 pystyvät antamaan palautetta järjestelmän ulkonäöstä, järjestelmän toiminnoista ja järjestelmään liittyvistä käsittelysäännöistä sekä järjestelmän yhteensopivuudesta organisaation työproessien kanssa. Lopulta prototyyppi on jo niin valmis, että se kattaa kaikki lopullisen tietojärjestelmän ominaisuudet ja siinä on jäljellä vain melko vähän puutteita ja virheitä. Tässä vaiheessa ohjelmisto voidaan yleensä ottaa pilotoitavaksi, samalla kun ohjelmistoon liittyviä viimeisiä virheitä ja puutteita korjaillaan. Edellä kuvattua mallia kutsutaan usein protoilemisen sijasta myös iteratiiviseksi ohjelmistokehitysmalliksi. Iteraatiot ovat spiraalin keskipistestä käynnistyviä kehityskierroksia, joiden aikana tavoiteltua toteutuksen arkkitehtuuria ja toiminnallisuutta kehitetään vähitellen yhä paremmaksi, kunnes asiakas lopulta hyväksyy toimituksen. Toiminnallisen osa-alueen 3 kehittäminen Toiminnallisen osa-alueen 4 kehittäminen Toiminnallisen osa-alueen 2 kehittäminen Suunnitelmien ja arkkitehtuurin kehittäminen Iteratiivisen menetelmän hyvänä puolena on se, että asiakkaat näkevät myös pitkäkestoisissa projekteissa lopputuloksena toimitettavan järjestelmän tms. tuotteen jo ensimmäisen iteraatiokierroksen jälkeen ja pystyvät antamaan arvokasta palautetta projektiryhmälle. Tämä on hyvin tärkeä asia, koska loppukäyttäjät eivät yleensä kykene antamaan riittävän hyvää palautetta pelkästään katselmoimalla satojen tai tuhansien sivujen mittaisia määrittelydokumentteja (jotka kertovat, miltä valmis järjestelmä tulee näyttämään). Iteratiivisen menetelmän huonona puolena on se, että saman asian tekeminen peräkkäin monena iteraationa on kallista. Erityisen kalliiksi iteratiivinen menetelmä muodostuu, jos loppukäyttäjät alkavat rönsyillen ideoida järjestelmään suuria muutoksia vaiheessa, jossa järjestelmä muutoin olisi jo melko valmis. Tämän vuoksi iteratiivisen menetelmän käyttö rajoitetaan yleensä siihen, että kustakin projektitoimitukselta vaaditusta ominaisuudesta toteutetaan vain 3-4 iteraatiota, jotka ovat tyypillisesti - Visuaalinen malli tai prototyyppi - Toiminnallinen prototyyppi - Betaversio (joka sisältää virheitä ja puutteita) - Lopullinen versio Toiminnallisen osa-alueen 1 kehittäminen 17

19 2.4.6 Inkrementaalinen projektitoteutus sekä paranneltu vesiputous Inkrementaalinen projektitoteutus on iteratiivisten toteutusmallien ohella toinen ketteristä projektinhallintamalleista. Siinä projekti aloitetaan määrittelyvaiheella, jonka aikana toteutetaan myös muut projektinhallintaan kuuluvat aloitusvaiheen toimet. Määrittelyvaiheen valmistuttua projektin varsinainen toteutus jakautuu toimituseriin, jotka ovat lopullisen projektitoimituksen valmiita, käyttöönottokelpoisia osia. Vaikka projekti siis kestäisi kolme vuotta, inkrementaalinen toteutus yleensä antaa asiakkaalle ensimmäisen käyttökelpoisen toimituserän jo muutaman kuukauden kuluttua aloitus- ja määrittelyvaiheen valmistumisesta. Tämä on suuri etu verrattuna vesiputousmalliin, jossa toteutusvaihetta saattaa kulua jopa pari vuotta ennen kuin asiakas näkee mitään valmista. Jos projektinhallintamenetelmä on puhtaasti inkrementaalinen, jokainen toimituserä valmistuu kerralla ilman iteraatioita. Esimerkkinä puhtaasti inkrementaalisesta projektinhallintamenetelmästä on jäljempänä kuvattava Scrum, joka tuottaa käyttöönottokelpoisia tai muulla tavoin valmiita toimituseriä 1-2 kertaa joka kuukausi. Yleensä, kun organisaatiot ottavat käyttöön inkrementaalisen projektinhallintamallin, ne kuitenkin ottavat siihen mukaan jonkin verran iteratiivisia piirteitä. Näin on tehty mm. WM-datan kehittämässä Ruori-mallissa, joka jakaa projektin seuraaviin vaiheisiin. Määrittely - ja aloitusvaihe Tekninen proto Inkrementti 1 Inkrementti 2 Inkrementti N Projektin päätös Mallin etuna on PMBOK:iin ja Prince2:een verrattuna se, että projektin toteutusvaihe on jaettu tarkemmin alemman tason vaiheisiin (vrt. stages) ja näiden vaiheiden luonne on selkeästi ohjeistettu siten, että kunkin vaiheen tulee tuottaa käyttöönottokelpoinen toimituserä. Mikäli projekti sisältää myös useita viikkoja kestäviä asennuksia, koulutuksia tms. käyttöönottotöitä, voidaan käyttöönotot toteuttaa inkrementtien kehityksen kanssa rinnakkain siten, että inkrementin 2 toteutuksen ja testauksen kanssa rinnakkaisesti etenee inkrementti 1:n käyttöönotto. Iteratiivisiin menetelmiin verrattuna Ruori-malli on kustannustehokkaampi, koska Ruorissa iteraatioita tehdään vain hallittu määrä ja hyväksyttyjen määrittelyjen ja teknisen proton jälkeen sovittua ja hyväksyttyä toiminnallisuutta ei enää muuteta ilman selkeitä pelinsääntöjä. Tällä vältetään iteratiivisen mallin se ongelma, että asiakas muuttaa hallitsemattomasti jo kertaalleen toteutettuja ominaisuuksia. 18

20 2.4.7 Scrum Scrum on 1990-luvulla kehitetty ohjelmistoprojektien hallintaan tarkoitettu menetelmä, jolla pyritään välttämään vesiputousten, Gantt-ohjauksen, PMBOK:in ja Princen ongelmat. Scrum-projektit alkavat sillä, että product owner (projektin omistaja) laatii toteutettavaa releasea (eli tuotejulkistusta) koskevan priorisoidun product backlogin (eli vaatimusluettelon). Tämän jälkeen projektia varten koottu scrum team (eli projektiryhmä) tekee kullekin vaatimukselle karkean työmääräarvion, joka ilmaistaan pisteytyksellä (story points). Toteutusvaiheen sisällä projekti jakautuu 2-4 viikon mittaisiin sprintteihin, joiden kunkin aikana on tarkoitus tuottaa asiakkaalle valmis ja käyttökelpoinen osatoteutus projektilla tavoiteltavasta kokonaistoimituksesta. Kunkin sprintin alussa pidetään suunnittelukokous (sprint planning meeting), jossa päätetään tarkemmin, mitä vaatimuksia (backlog items) sprintin aikana toteutetaan ja mitä ko.tason tehtäviä on suoritettava näiden vaatimusten toteuttamiseksi. Toteutusta johdetaan melko itseohjautuvasti siten, että projektiryhmä pitää joka päivä noin 15 minuutin mittaisen palverin (daily scrum), jossa seurataan valmistuneita ja keskeneräisiä tehtäviä sekä tehtävien toteutusta haittaavia esteitä ja ongelmia. Itseohjautuvuutta lisää se, että projektiryhmän jäsenet ottavat oma-aloitteisesti sprintin tehtävälistalta toteutettavakseen tehtäviä sitä mukaa, kun saavat aiemmat tehtävänsä valmiiksi. Tämän itseohjautuvuuden vuoksi Scrum-tiimin sisällä ei tarvita varsinaista projektipäällikköä vaan tiimin töiden edistymistä varmistelee Scrum master, jonka keskeisimpänä tehtävänä on projektin etenemistä haittaavien esteiden poistaminen. Suunnitelmien täsmennys: Product backlogin sekä sprinttikohtaisten tehtävälistojen täsmentäminen joka sprintin alussa Scrum-projektin aloitus: Product back-login eli priorisoidun vaatimusluettelon ja työmääräarvioiden laadinta Toteutuksen johtaminen daily sprinteillä ja itseohjauksella Systemaattinen ohjaus sprint review- ja sprint retrospective - kokousten sekä Velocitylaskelmien avulla Projektin päättäminen kun deadline koittaa Scrum-projektin systemaattinen ohjaus tapahtuu projektin omistajan eli product ownerin toimesta. Ohjauksen keinoja ovat kunkin sprintin lopussa pidettävät Sprint review ja 19

21 Sprint retrospective kokoukset sekä kunkin sprintin lopussa laadittavat Velocityyn perustuvat ennusteet. Scrum-projektit pyritään yleensä lopettamaan etukäteen asetettuna määräpäivänä, jolloin product owner julkaisee projektitoimituksen (release). Ideana on se, että projekti toteuttaa kyseiseen päivään mennessä joukon product ownerin tärkeimmiksi priorisoimia ominaisuuksia ja vaatimuksia. Mahdollisesti puuttumaan jääneet toteutetaan myöhemmin, uusissa Scrumin avulla johdetuissa projekteissa. Edellä kuvatulla simppelillä Scrum-mallilla on neljä melko vakavaa ongelmaa. Ensimmäinen ongelma liittyy siihen, että product owner joutuu vain toivomaan, että projektiryhmä saisi riittävän määrän ominaisuuksia valmiiksi projektin valmistumismääräpäivään mennessä. Tähän liittyy yleensä se, että projektiryhmä tekee töitä tuntipalkalla (ei urakkapalkalla) ja siksi kaikki projektitoteutukseen liittyvä riski jää product ownerille sekä projektin omistajaorganisaatiolle. Tätä ongelmaa pahentaa se, että Scrum-tiimien jäsenet monesti vastustavat kaikkea perinteistä projektinhallintaa niin paljon, että haluavat aktiivisesti unohtaa kaikki ne toimintaperiaatteet ja ohjeet, joita vanhoihin malleihin sisältyy. Kolmantena ongelmana on se, että scrum masterit ja scrum tiimit keskittyvät yleensä niin aktiivisesti sprinttien toteutukseen, että systemaattinen ohjaus jää usein täysin tekemättä. Tätä pahentaa se, että product ownerit ovat usein niin kokemattomia, etteivät ymmärrä systemaattisen ohjauksen ja velocityyn perustuvien ennusteiden tärkeyttä. Neljäs ongelma muodostuu siitä, että simppelissä Scrumissa ei hahmoteta sitä, että Scrum-projektin aloituspäätöstä tehtäessä tulisi olla olemassa näkemys projektin kokonaiskustannuksista tarkasteltava julkistus (release) sekä kaikki julkistusta seuraavat jatkoprojektit (uudet releaset) mukaan lukien. Myös Scrum-projektin keskeytyspäätöksen tulisi perustua pitkän aikajänteen ennusteisiin siitä, paljonko koko back-login tai ainakin kaikkein tärkeimmiksi luokiteltujen vaatimusten toteuttaminen maksaisi ja kestäisi. Tämä tekee scrum-projekteista usein huomattavan lyhytjänteisiä sekä sokeita projekteihin ja kehittämishankkeisiin liittyville pidemmän aikajänteen kustannushyötylaskelmille. Edellä kuvatut Scrumin ongelmat on korjattu luvussa 4, jossa esittellään CPM:n suosittelema täsmennetty menetelmä ketterien kehittämishankkeiden, julkistusprojektien ja sprinttien johtamiselle Lean ja IPMA Lean-johtamisfilosofia sekä IPMA/NCB eivät ole varsinaisia projektinhallintamenetelmiä, mutta projektipäälliköiden on silti syytä tuntea ne ainakin alustavalla tasolla. Lean-johtamisfilosofia pyrkii organisaation tuotanto- ja palveluprosessien parantamiseen, tehostamiseen ja vauhdittamiseen. Tavoitteena on erityisesti vähentää tuhlausta ja jätettä, jotka ilmenevät seuraavilla seitsemällä tavalla: - kuljetukset - varasto - liike eli tavaran tai vastuun siirtely paikasta toiseen 20

22 - odotusaika - ylituotanto - yliprosessointi ja - vialliset tuotteet Projektinhallinnan näkökulmasta olennaista lean-filosofiassa on erityisesti se, että tavaraa ja vastuuta ei saisi siirrellä turhaan paikasta toiseen ja lisäksi odotusajat tehtävien, sprinttien, toimituserien ja erilaisten päätösten välillä eivät saisi hidastaa projektin kokonaisaikataulua. Lisäksi on huomattava, että odotusaikaa on myös se aika, jonka asiakas joutuu projektin käynnistämisen jälkeen odottamaan ennen projektin tai siinä tuotettavien julkistusten tai toimituserien valmistumista tuotantokäyttöä varten. Kolmas merkittävä projektinhallintaan liittyvä vaatimus on yliprosessoinnin välttäminen. Tämä tarkoittaa sitä, että prosessikartoista ei saisi tehdä liian monimutkaisia eikä mitään pelkkää toteutusvaihetta palvelevia dokumentteja ja suunnitelmia saisi viedä liian tarkalle tasolle (koska niistä ei ole toteutuksen jälkeen hyötyä enää kenellekään). IPMA on kansainvälisen projektinhallintayhdistys, joka on kehittänyt National Competence Baseline nimisen ohjeistuksen (NBC), jolla määritetään, minkälaisia pätevyyksiä projektipäälliköiden pitäisi hankkia itselleen sekä millaisilla pätevyyksillä varustettuja projektipäälliköitä projektien johtoon tulisi valita. IPMA:n suurin merkitys on siinä, että se tarjoaa projektipäälliköille koulutusmateriaalia yleisten projektinhallintavalmiuksien kasvattamiseen sekä lisäksi sertifiointijärjestelmän, jonka avulla projektipäälliköt voivat osoittaa sijoittumisensa kokemustasoille D, C, B tai A. Sertifikaattien avulla projektipäälliköt voivat osoittaa uusille asiakkaille (ja työnantajille) sen, että heillä on todellista testien ja käytännön kokemusten vahvistamaa osaamista joko pienempien tai isompien projektien johtamisesta. Ongelmana on kuitenkin se, että esimerkiksi isojen projektien johtamistaitoja kuvastava B-tason sertifikaatti vanhenee jo muutamassa vuodessa. Tämä sitoo projektipäälliköt jatkuvaan sertifikaattien uusimiskierteeseen. Toisena ongelmana on se, että IPMA ei sisällä sellaisia käsitteitä, apuvälineitä ja ohjeita, jotka soveltuisivat ketteriä projektien ja hankkeiden suunnittelemiseen, toteutukseen ja ohjaukseen. 21

23 3 Creative Project Management menetelmän yleiskuvaus 3.1 Projektien monimutkaisuusluokitus sekä vaihtoehtoiset ohjausratkaisut CPM on projektinhallintamenetelmä, joka määrittää projektien vaiheistusta, organisointia, ja ohjausta varten ketterät ja skaalautuvat mallit, joiden avulla voidaan johtaa eri kokoisia tehtäviä ja projekteja hyvin erilaisissa tilanteissa. Alla oleva taulukko kuvastaa, miten tehtävien monimutkaisuus kasvavaa kohti isoja projekteja mentäessä. Toteutuksen jäsennys Organisointi Ohjaus ja suositeltava maksimikesto Atomistiset pikkutehtävät kesken/valmis yksi toteuttaja pp seuraa tehtävien hallintajärjestelmällä (1 vko) Tehtäväketjut tehtävä valmistuu toteutustiimi tekee, pp seuraa tikettijärjestel- (tiketit) 4-12 askeleella pp valvoo män avulla (6 vkoa) Isot tehtävät (tasainen vauhti) kesken/valmis Sama kuin yllä Valmiusaste ja siitä lasketut ennusteet (1-2 v) Tehtäväsalkut ja 1 vaihe, joka sisältää toteutustiimi(t), pp Sama kuin yllä (sprintin sprintit ison joukon pikku- ja projektin omistaja kesto 4 vkoa, tehtäväsalkun tehtäviä tai tikettejä (tai scrum-roolitus) maksimikesto 40 viikkoa) Julkistus tai 2-10 peräkkäistä sama kuin yllä + Sama kuin yllä (julkistuksen toimituserä sprinttiä (tai salkkua) ohjausryhmä maksimikesto 40 viikkoa) Ketterästi tehdyt Monta julkistusta tai Sama kuin yllä Sama kuin yllä isot projektit toimituserää (maksimikesto 3 vuotta) Gantt-projekti 5-25 päätason Sama kuin yllä + Sama kuin yllä + aikataulu- tehtävää mahdollisesti seuranta tuntiseuranta- projektitoimisto järjestelmään kytketyllä Gantt-kaaviolla (1 vuosi) Iso Gantt-projekti (tai hanke) 5-15 osaprojektia Sama kuin yllä + toteutuksen ohry Sama kuin yllä Monimutkainen Monta yllä mainit- Sama kuin yllä + Työkustannusennusteet iso projekti (tai tua, keskenään eri- projektitoimisto valmiusastelaskennalla, hanke) laista isoa tehtävää hanketason aikataulu (osin rinnakkain) Gantt-kaavion avulla 22

24 Edellisessä taulukossa esiintyvä monimutkaisuuden kasvu on esitetty alla olevaan kaavioon visuaalisessa muodossa. Iso ja monimutkainen projekti sekä sen jakautuminen erilaisiin ja eri tavoilla ohjattuihin osiin Ketterä kehittämisprojekti (tai useampia) Gantt- Julkistus 1 Julkistukset 2-N Sprint1 Sprint2 Sprint 3-N Tehtäväsalkku projekti(t) ja niiden päätason tehtävät Yksittäiset isot tehtävät Paljon atomistisia tehtäviä Paljon tikettejä Päätasolla iso ja monimutkainen projekti jakautuu ketteriin kehittämisprojekteihin sekä niiden kanssa rinnakkaisesti eteneviin Gantt-projekteihin. Näiden keskenään täysin eri tavalla ohjattujen kokonaisuuksien rinnalla on aina myös pienistä, kokouksissa päätetyistä tehtävistä muodostuva tehtäväsalkku, joka voi periaatteessa sisältää atomististen tehtävien lisäksi myös tikettejä. Tikettejä voi syntyä projektiryhmän vastuulle myös ketterissä kehittämisprojekteissa, joissa jotkin julkistukset on jo otettu tuotantokäyttöön siten, että kehittämisprojektin resurssit ovat edelleen vastuussa ongelmien ja virheiden korjaamisesta. Näiden lisäksi iso ja monimutkainen projekti voi sisältää isoja yksittäisiä tehtäviä, jotka kannattaa pitää hankkeen päätasolla näkyvissä itsenäisinä kokonaisuuksinaan, mutta joita ei kannata lähteä sisäisesti pilkkomaan pienemmiksi kokonaisuuksiksi. Esimerkkinä tällaisista tehtävistä ovat mm. tasaisella vauhdilla ja tasaisilla resursseilla etenevät asennustehtävät, joissa asennuskohteita on satoja tai tuhansia ja joiden kokonaiskesto saattaa nousta jopa 6 18 kuukauteen. Vaikka edellä kuvattu tehtävien, organisaatioiden ja ohjausjärjestelmien paljous saattaa vaikuttaa ensi silmäyksellä kaoottiselta, CPM tarjoaa kaaoksen hallintaan hyvän apuvälineen: Kun projektipäällikkö oppii kunnolla tehtävien ja projektien valmiusastelaskennan, hän pystyy helposti hallitsemaan kaikki erityyppiset projektit (paitsi Ganttit) valmiusasteesta johdetuilla ennusteilla. Näiden ennusteiden tuottaminen on pääsääntöisesti niin helppoa, että päivitetyt, koko ison ja monimutkaisen projektin kokonaistyökustannuksia ja kokonaiskestoa kuvaavat laskelmat on mahdollista tarjota ohjausryhmän käyttöön viikoittain. Tämä on suuri parannus aikaisempiin johtamismenetelmiin, joissa ennusteet olivat tyypillisesti niin vaivalloisia, että niitä tuotettiin 23

25 ohjausryhmälle vain kerran kuukaudessa ja siltikin ennusteiden toteutus oli pikemminkin taidetta ja arvailua kuin selkeisiin faktoihin perustuvaa laskentaa. CPM ei kuitenkaan poista projektipäälliköiltä mahdollisuutta intuitioon ja kokemukseen perustuviin ennusteisiin. Niiden rinnalle tarjotaan kuitenkin helpot ja tarkat laskentamenetelmät, jotka tuottavat objektiivisemman vertailuennusteen. Kahden eri ennusteen rinnakkaisella esittämisellä saadaan estettyä tilanne, jossa tiimin jäsenten, tiiminvetäjien ja osaprojektien vetäjien intuitiivinen optimismi heijastuu koko projektia koskeviksi optimistisiksi aikataulu- ja kustannusennusteiksi, joihin ohjausryhmä alkuun luottaa täysin, mutta lopulta menettää täysin luottamuksensa projektipäällikön kykyyn hallita aikatauluja (mikä johtaa usein projektipäällikön vaihtamiseen, projektitoimittajan vaihtamiseen tai tiukkoihin sopimusneuvotteluihin juristien läsnä ollessa). 3.2 Gantt-ohjaus CPM -mallissa CPM-mallissa Gantt-kaavioita käytetään ensisijaisesti isojen ja monimutkaisten hankkeiden johtamiseen tilanteessa, jossa hankkeen osaprojekteilla ja päätason tehtävillä on ajallisia riippuvuussuhteita ja hankkeen kokonaisaikataulu on haasteellinen. Alla on yksinkertaistettu esimerkki isosta julkisen sektorin hankkeesta, jonka valmistumisen takarajaksi asetettiin alun perin vuoden 2014 loppu. Aloitus AN-laitteen julkistus AN-ohjelman 1. julkistus AN-laitteen sarjatuotanto (vähintään 3000 kpl) Laitteiston ja ohjelman asennus 3000 linja-autoon Back-endin julkistus julkistus Käyttäjäkoulutukset j. 1 AN-ohjelman 2. julkistus Käyttäjäkoulutukset j. 2 Hankkeen kokonaisaikataulun seurannan kannalta on välttämätöntä seurata systemaattisesti sitä, miten hankkeen punaisella merkitty kriittinen polku ja valmistumisennuste kehittyvät. Esimerkiksi yllä olevassa pullonkaulana näyttäisi olevan AN-ohjelmiston 1. julkistuksen aikataulu, mutta lähes yhtä mahdollista on se, että hanke viivästyy AN-laitteen kehityksessä ilmenevien aikatauluongelmien tai Back-endin julkistuksen viivästymisen vuoksi. Minkä tahansa em. osa-alueen viivästyminen viivästyttää samalla koko hanketta. Gantt-ohjausta on suositeltavaa soveltaa aikataulukriittisten hankkeiden päätason ohjauksen lisäksi lähinnä vain sellaisten osaprojektien tai tehtävien johtamiseen, jotka 24

26 jakautuvat sisäisesti monimutkaisella tavalla toisiinsa kytkeytyviiä tehtäviin, joiden johtaminen ketterästi sprinteillä ei onnistu. Edellä kuvatussa hankesuunnitelmassa ainoa tämänkaltainen osuus näyttäisi muodostuvan osaprojektista AN-laitteen julkistus. ANohjelmiston sekä back-endin kehitystyö voidaan hoitaa ketterien kehittämisprojektien avulla. Asennus- ja koulutusprojektit voidaan tarvittaessa myös johtaa ilman Ganttkaavioita, esimerkiksi ketterinä projekteina, tehtäväsalkkuina tai yksittäisinä tasaisesti edistyvinä projekteina, joiden tarvitsee raportoida lähinnä vain se, kuinka monta käyttäjää on koulutettu viikon aikana tai kuinka monta asennusta kyseisen viikon aikana on tehty. Ketterien projektien ohjausta on kuvattu tarkemmin luvussa 4, isojen tehtävien sekä tehtäväsalkkujen johtamista luvussa 5 ja Gantt-ohjausta luvussa 6, 3.3 Aikataulu- ja kustannusennusteiden laskenta valmiusasteen ja etenemisvauhdin pohjalta Valmiusasteen laskenta Projektin tai tehtävän valmiusasteen laskenta voidaan perustaa - syntyneisiin hankintakustannuksiin - syntyneisiin työkustannuksiin - käytettyihin työtunteihin - tai hyötypisteisiin CPM suosittelee hyötypisteisisiin perustuvaa valmiusastelaskentaa, koska valmiusastetta tulisi tarkastella mahdollisimman pitkälti syntyneiden tulosten ja hyötyjen näkökulmasta, ei niinkään siitä näkökulmasta, paljonko projektille on tuotettu kustannuksia tai paljonko projektille on tehty töitä. Hyötypisteen käsite kytkee valmiusastelaskennan samalla myös tyylikkäästi earned value käsitteeseen, jolla mitataan tehtävien ja projektien tuottamia hyötyjä. Myös earned valuen laskenta perustuu CPM:ssä projektin synnyttämiin saavutuksiin ei siihen, paljonko projektiin on panostettu kustannuksia. Tehtävien ja projektien valmiusasteet lasketaan seuraavalla kaavalla Valmiusaste = Saavutetut hyötypisteet / Tavoiteltujen hyötypisteiden kokonaismäärä Hyötypisteet määritellään eri tyyppisille ja tasoisille tehtäville hieman eri tavoin, mutta niitä voivat olla mm. - kullekin projektia koskevalle vaatimukselle lasketut toimintopisteet - kullekin projektia koskevalle vaatimukselle arvioidut tarinapisteet (story points) tai alkuperäiset työmääräarviot - atomistisen tehtävän tai tiketin alkuperäinen työmääräarvio - ison tehtävän yksittäiset hyötyä tuottavat askeleet Toimintopisteet, tarinapisteet ja ison tehtävän hyötyä tuottavat askeleet kuvastavat melko tiiviisti asiakkaan saamia hyötyjä, kun taas tehtävien työmääräarviot kytkeytyvät 25

27 asiakkaan saamiin hyötyihin lähinnä siten, että asiakas, projektipäällikkö tai palvelupäällikkö ei välttämättä anna lupaa tehtävän tai tiketin käynnistämiselle, ellei hän usko hyötyjen ylittävän kustannuksia. Hyötypisteiden arviointi tulisi tehdä ennen tehtävän toteutusta, eikä toteutuksen aikana kannata yleensä tuhlata aikaa tehtävän hyötypisteiden nostamiseen, vaikka huomattaisiin, että tehtävä olikin kymmenen kertaa vaikeampi kuin alun perin arvioitiin. Mikäli tavoitteena on laskea jonkin useista tehtävistä muodostuvan kokonaisuuden, kuten esimerkiksi sprintin tai tehtäväsalkun valmiusaste, tämä valmiusaste on laskettava alhaalta ylöspäin, jakamalla toteutuneiden alimman tason tehtävien hyötypisteet kaikkien alimman tason hyötypisteiden määrällä. Tällä tavoin voidaan laskea esimerkiksi sprintin valmiusaste: Valmistuneiden tehtävien alkuperäiset työmääräarviot Sprintin valmius% = Sprintin kaikkien tehtävien alkuperäiset työmääräarviot Vastaavalla tavalla voidaan laskea myös yksittäisen julkistusprojektin tai useasta julkistuksesta muodostuvan kehittämishankkeen valmiusaste Valmistuneiden vaatimusten yhteenlasketut hyötypisteet Valmius% = Vaatimuslistan kaikkien hyötypisteiden summa Yksittäisen ison tehtävän valmiusaste lasketaan jakamalla hyötyä tuottavien askelten määrä kaikkien hyötyaskelten määrällä. Jos siis tehtävän kukin askel muodostuu yhdestä asennuksesta ja asennuksia on yhteensä 240, lasketaan valmiusaste seuraavalla kaavalla: Valmistuneiden hyötyaskelten määrä Ison tehtävän valmius% = Vaadittujen hyötyaskelten kokonaismäärä Myös Gantt-projekteissa on mahdollista suorittaa valmiusasteen laskentaa edellä kuvattuja periaatteita noudattaen, laskien erikseen kunkin päätason tehtävän tuottamat hyötypisteet sekä jakamalla saatu summa projektin tavoitteeksi asetettujen hyötypisteiden kokonaissummalla. Tätä menetelmää on toisinaan pakko käyttää silloin, kun organisaatiolla on käytössään Gantt-ohjausjärjestelmä, joka ei integroidu tuntiseurantajärjestelmään. Tällöin projektipäällikön on pakko laskea Gantt-projektin valmiusaste Excel-taulukossa, johon hän kokoaa kunkin Gantt-projektin (päätason) tehtävän toteutuneet hyötypisteet sekä kokonaishyötypisteet sekä lopulta laskee valmiusasteen seuraavasti: Päätason tehtävien tähän mennessä tuottamat hyötypisteet Gantt-projektin valmius% = Päätason tehtävien tavoittelemien hyötypisteiden summa 26

28 Tätä laskentakaavaa voitaisiin käyttää myös silloin, kun iso ja monimutkainen projekti tai hanke muodostuu monista erilaisista päätason tehtävistä, jotka kukin ovat projekteja, tehtäväsalkkuja tai isoja tehtäviä. Hankkeen valmiusasteen laskenta ei kuitenkaan ole mikään itsetarkoitus: Tärkeämpää on ennustaa hankkeen työmääräkustannukset ja aikataulu kokonaisuudessaan, mikä onnistuu alemman tason tehtävien valmiusasteesta johdetuilla ennusteilla Valmiusasteeseen perustuvat työmäärä-, aikataulu- ja kustannusennusteet Kun tehtävän, sprintin, julkistuksen, kehittämishankkeen tai ison tehtävän aloituspäivä, valmiusaste ja tähän mennessä kertyneet työkustannukset (tai työtunnit) tiedetään, voidaan tulevia työmääriä ja työkustannuksia sekä tehtävän viimeistelyyn kuluvaa aikaa ennustaa lineaarisesti extrapoloiden eli rakentamalla ennusteet nykyisen etenemisvauhdin varaan. Tämä edellyttää sitä, että tarkasteltavan tehtäväkokonaisuuden voidaan ennustaa etenevän melko tasaisella vauhdilla, joka on yhtä suuri kuin aiempi keskimääräinen etenemisvauhti. Jos tämä ennakko-olettamus hyväksytään, voidaan tehtävän tai projektin tulevaa kestoa ja kustannuksia ennustaa seuraavalla kaaviolla, jossa vihreä käyrä kuvastaa hyötyjen kertymistä tähän asti ja punainen katkoviiva saavuttaa tavoitellut kokonaishyötypisteet hetkellä, joka kuvastaa tehtävän, sprintin, julkistuksen tai tarkasteltavan ison tehtävän valmistumisajankohtaa: 27

29 Tavoitellut kokonaishyötypisteet Hyötypisteiden summa nyt Aika Nykyhetki Valmistumis- ajankohta Vastaavalla tavalla on mahdollista ennustaa myös projektin kokonaistyökustannuksia. Tällöin kaavioon merkitään tähän asti toteutuneet kustannukset ja katsotaan, minkä tason ne saavuttavat tehtävän valmistumisajankohtaan mennessä: Kustannusten summa tehtävän päätökseen mennessä Kustannusten summa nyt Aika Nykyhetki Valmistumis- ajankohta Vaikka edellä kuvatut kuvaajat ovatkin visuaalisesti helppotajuisia ja hyödyllisiä varsinkin jos hyötyjen ja kustannusten edistymistä kuvaavat käyrät ja ennusteviivat sijoitetaan samaan kuvaajaan, on niiden ylläpitäminen melko vaivalloista. Niiden sisältämä tieto ei myöskään ole sillä tavoin strukturoitua, että pienten tehtävien kuvaajista voitaisiin salamannopeasti laskea sprintin kuvaaja, josta laskettaisiin sen jälkeen julkistusten, kehittämisprojektien yms. korkeamman tason tehtävärakenteiden aikatauluja kustannusennusteet. 28

30 Tämän vuoksi lineaariset, nykyiseen etenemisvauhtiin perustuvat ennusteet, kannattaa tehdä Excelillä seuraavia yhtälöitä apuna käyttäen. Kuten Excel-mallit yleensä, tämäkin malli muodostuu aika monesta yhtälöstä, jotka kaikki on ymmärrettävä ja sen jälkeen kytkettävä toisiinsa. Valmiusasteen laskenta etenee Excel-taulukossa seuraavien vaiheiden ja yhtälöiden kautta: Laske yhteen alimman tason tehtävien hyötypisteet ja merkitse tämä ylemmän tason tehtävän (esim. sprintin, julkistuksen, tehtävälistan tai ison tehtävän) kokonaishyötypistemääräksi. Kun kokonaishyötypistemäärä on kertaalleen laskettu, sitä ei tarvitse laskea enää uudestaan, ellei tämän ylemmän tason tehtävän alle synny kokonaan uusia alemman tason tehtäviä. Laske yhteen alimman tason tehtävien tai hyötyaskelten tähän mennessä tuottamat hyötypisteet. Tämä laskenta kannattaa tehdä siten, että hyötypisteiden määräksi arvioidaan nolla, ellei asiakas ole muodollisesti hyväksynyt tehtävää tai hyötyaskeleita esimerkiksi viikkopalaverissa, toteutuksen ohjausryhmässä tai ohjausryhmässä. Laske tarkasteltavan tehtävän tai projektin etenemisvauhti kaavalla Kertyneet hyötypisteet Etenemisvauhti = Kuluneet työpäivät jossa kuluneet työpäivät voivat olla hieman epätarkemmissa laskelmissa kalenteripäiviä (jotka saadaan laskettua Excelissä vähentämällä nykypäivästä tehtävän aloituspäivä) tai tehollisia työpäiviä, joista on poistettu viikonloput, kesälomat ja vapaapäivät. Yleensä etenemisvauhdin laskennassa riittää se, että käytetään kalenteripäiviä, ellei tehtävän toteutus mene pahasti päällekkäin kesä- tai joululoman tms. ajanjakson kanssa. Kun etenemisvauhti tiedetään, voidaan jäljellä oleva kestoaika laskea kaavalla (Tavoitellut hyötypisteet tähän mennessä kertyneet hyötypisteet) Jäljellä oleva aika = Etenemisvauhti Sen jälkeen tehtävän tai projektin päätöspäivä on helppo laskea Excelissä lisäämällä nykypäivään jäljellä olevien päivien määrä. Tehtävän valmistumishetki = Nykyhetki + jäljellä oleva aika Mikäli tarkastellaan huomattavan isoja tehtäviä, voidaan etenemisvauhdin sekä jäljellä oleva aika laskea viikoissa tai kuukausissa. Tällöin on yleensä hyvä jättää heinäkuu kokonaan pois laskelmista. Sen jälkeen tehtävän tai projektin päätöspäivä on helppo laskea Excelissä lisäämällä nykypäivään jäljellä olevien päivien määrä. Mikäli tarkastellaan huomattavan isoja tehtäviä, voidaan etenemisvauhdin sekä jäljellä oleva aika laskea viikoissa tai kuukausissa. Tällöin on yleensä hyvä jättää heinäkuu kokonaan pois laskelmista. CPM suosittaa sitä, että kustannusten ennustamisessa keskitytään työkustannusten ennustamiseen. Ostoista aiheutuvia kustannuksia tulee kontrolloida muutoshallinnan avulla. Muutoshallinnalla varmistetaan, ettei budjettiin sisältymättömiä kustannuksia otetaa toteutettaviksi ilman ohjausryhmän lupaa ja etteivät projektin mahdolliset 29

31 toimittajat muuta sovittuja hintoja ilman asiakkaan lupaa. Mikäli muutoshallintaprosessi ei aiheuta hankintakustannuksiin muutoksia, ostojen ja hankintojen kustannusennuste säilyy samana koko projektin ajan, eikä siihen tarvitse kiinnittää huomiota. Tehtävän tai projektin työkustannukset voidaan ketterästi toteutetuissa projekteissa ennustetaa laskemalla työkustannusten kertymisvauhti kaavalla Kertyneet työkustannukset Työkustannusten kertymisvauhti = Kulunut aika sekä laskemalla sen jälkeen jäljellä olevat työkustannukset laskea kaavalla Jäljellä olevat kustannukset = Jäljellä oleva aika * Työkustannusten kertymisvauhti Tässäkin voidaan aikaa mitata tilanteen mukaan joko päivissä, viikoissa tai kuukausissa. 3.4 Ketterän julkistusprojektin scope-ennusteet Mikäli tarkastelemme ketterää julkistusprojektia, jonka aikataulu on asetettu täysin kiinteäksi ja jossa toteutuksen laajuus sen sijaan joustaa, on aikataulu- ja kustannusennusteet korvattava scope-ennusteilla, joilla ennustetaan, mitkä projektin vaatimuslistalle asetetut vaatimukset ehditään toteuttaa annetun aikataulun puitteissa. Scope-ennusteiden tekeminen perustuu kahteen työvaiheeseen, joista ensimmäinen on kumulatiivisen työmääräarvion laskeminen jokaiselle vaatimukselle. Kumulatiivinen työmääräarvio tarkoittaa sitä, paljonko tarkasteltavan vaatimuksen toteutus sekä kaikkien sitä korkeammalla prioriteettitasolla olevien vaatimusten toteutus yhteensä vaatii työtä. Tämä laskenta on helpointa toteuttaa Excelissä. Edellytyksenä on se, että kaikki vaatimukset on merkitty eri prioriteetille ja lajiteltu siten, että vaatimusten esitysjärjestys kuvaa yksiselitteisesti vaatimusten toteutusjärjestystä. 30

32 Vaatimus Prioriteetin järjestysluku Työmääräarvio (h) Kumulatiivinen työmääräarvio (h) Tärkeimmän vaatimuksen kuvaus Toiseksi tärkeimmän vaatimuksen kuvaus Kolmanneksi tärkeimmän vaatimuksen kuvaus Vaatimuksen N kuvaus N h (= tehtävän työmäärä + summa yllä olevista) Tämän jälkeen projektipäällikkö laskee yhteen kehittämishankkeen aikana valmistuneiden vaatimusten alkuperäiset työmääräarviot (eli hyötypisteet) ja jakaa tämän summan käytettyjen päivien määrällä. Tällä tavoin saadaan laskettua tähän astinen etenemisvauhti. Kun kehittämishankkeen tai julkistusprojektin käytettävissä olevien (jäljellä olevien) työpäivien määrä tiedetään, voidaan scope-ennuste laatia seuraavalla kaavalla Ennustettu scope = Toteutuneet hyötypisteet + jäljellä olevat päivät * etenemisvauhti jossa ennustettu scope kuvastaa sitä kumulatiivista hyötypistemäärää (alkuperäisten työmääräarvioiden summaa), mikä on valmiina projektin ennalta asetettuna päätöspäivänä. Tämän jälkeen projektipäällikkö katsoo sarakkeesta Kumulatiivinen työmääräarvio sen vaatimuksen, mihin saakka toteutus ehtii valmistua määräpäivään mennessä. Loput vaatimuksista on pakko jättää joko toteuttamatta tai toteuttaa myöhemmin käynnistettävillä uusilla julkistusprojekteilla. 31

33 3.5 Erilaisten tehtävien ja projektien jakautuminen päävaiheisiin Tehtävät ja projektit jäsennetään CPM:ssä aloitusvaiheeseen, toteutusvaiheeseen ja päätökseen. Jos tehtävä on yksinkertainen, kuten esimerkiksi atomistinen tehtävä, tiketti tai pitkä tehtävä, aloitus ja päätös tehdään vain yhteen kertaan ja myös ohjaus on melko yksinkertaista. Tehtävän aloitus: 1. Tehtävän määrittely 2. Työmäärä- tai hyötypistearvion laadinta 3. Vastuuhenkilön nimeäminen Toteutusvaihe: - tehtävän toteutus joko yhtenä vaiheena (atomistiset tehtävät) tai usean peräkkäisen askeleen kautta (tiketit sekä isot tehtävät) Tehtävän päättäminen Tieto tehtävän tilasta Tehtävän etenemisaskelten hyväksyminen Tehtävän ohjaus Jos taas kyseessä on iso, ketterästi toteutettava kehityshanke tai iso Gantt-hanke, joka sisältää ketteriä kehityshankkeita, aloitus ja päätös tehdään moneen kertaan: - Hanke aloitetaan ja lopulta päätetään, kun kaikki hankkeeseen sisältyvät ketterät kehittämisprojektit tai Gantt-projektit ovat valmiita. - Ketterä kehittämisprojekti aloitetaan kertaalleen melko huolellisin valmisteluin ja se päätetään aikanaan, kun kaikki kehittämisprojektiin kuuluvat julkistukset tai toimituserät on saatu valmiiksi ja käyttöön otetuiksi. - Julkistukseen tai toimituserään tähtäävä ketterä projekti aloitetaan melko ripeästi ja se päätetään siinä vaiheessa, kun kaikki sovitus sprintit on toteutettu tai kun kaikki välttämättömiksi luokitellut vaatimukset on toteutettu. - Sprintit aloitetaan sprint planning kokouksella ja ne päätetään tasan neljän viikon kuluttua. - Sisällöltään joustamattomat tehtäväsalkut ovat kuten sprintit, mutta ne päätetään vasta, kun kaikki salkkuun asetetut tehtävät ovat valmistuneet tai kun projektin omistaja on antanut luvan tehtäväsalkun sulkemiselle. Seuraava kaavio kuvastaa ketterän kehittämishankkeen vaiheistusta aloitukseen, toteutukseen ja päätökseen. Kuvaa tarkasteltaessa on muistettava, että toteutusvaihe 32

34 sisältää useita eri tasoisia tehtäväkokonaisuuksia, jotka kukin aloitetaan ja päätetään erikseen. Aloitusvaiheen johtaminen: 1. Ideointivaihe 2. Määrittelyvaihe 3. Kilpailutusvaihe 4. Proof of concept Toteutusvaihe: 1-5 toimituserää, jotka jakautuvat kukin 2-10:een neljän viikon mittaiseen sprinttiin Projektin päättäminen 1. Viimeisen toimituserän julkistus tai käyttöönotto 2. Kehityshankkeen purkaminen ja lopetus. testi- ja katselmustulokset sekä riskit ja ongelmat sprinttien ja toimitusten hyväksymiset sekä riskien ja ongelmien hallintatehtävät Ketterän kehittämishankeen systemaattinen ohjaus 1. Sprinttien sekä julkistusten tai toimituserien valmiusasteen seuranta sekä aikatauluja kustannusennusteet 2. Toteutettujen vaatimusten, sprinttien ja toimituserien hyväksyminen 3. Vaatimusten siirto myöhempiin julkistuksiin, lisäresurssien hankinta tai projektin lopettaminen, jos edistymisvauhti ei ole riittävä tai jos kustannukset ovat liian suuret. 4. Muut riskien, ongelmien ja muutosten hallintapäätökset 33

35 4 Ketterien kehittämishankkeiden johtaminen CPM:ssä 4.1 Ketterän kehittämishankkeen tavoitteet ja osatehtävät Kehittämishankkeiksi kutsutaan CPM:ssä sellaisia pitkäkestoisia projekteja, joissa kehitetään tuotetta, järjestelmää, palvelua tai toimintatapaa. CPM suosittelee kehittämishankkeille ketterää toteutustapaa, - jossa hankkeen toteutus jakautuu toisiaan seuraaviin korkeintaan puolen vuoden mittaisiin julkistusprojekteihin (releases) - joista jokainen jakautuu sisäisesti 4 viikon mittaisiin sprintteihin - jotka jakautuvat kukin viikon mittaisiin neljännessprintteihin. Tässä luvussa kuvataan ketterän kehittämishankkeen sekä siihen sisältyvien julkistusprojektien ja sprinttien aloitus-, toteutus-, ohjaus- ja päätösmenettelyt sekä suositeltava organisaatiomalli. Mallin esittely aloitetaan sprinteistä, joista edetään toimitus- ja julkistusprojektien kautta kehittämishankkeen ohjaamiseen kokonaistasolla. Tässä luvussa oletetaan, että kaikki kehittämishankkeeseen sisältyvät osuudet on ohjattu ketterästi. Myöhemmin luvussa 6.2 kuvataan, miten isoja hyvin erityyppisistä osista muodostuvia hankkeita johdetaan. Iso ja monimutkainen projekti sekä sen jakautuminen erilaisiin ja eri tavoilla ohjattuihin osiin Ketterä kehittämisprojekti (tai useampia) Gantt- Julkistus 1 (tai toimituserä 1) Sprint1 Sprint2 Sprint 3-N Julkistukset 2-N Tehtäväsalkku projekti(t) ja niiden päätason tehtävät Yksittäiset isot tehtävät Paljon atomistisia tehtäviä Paljon tikettejä 4.2 Hankkeen organisaatio sekä ohjaus säännöllisillä kokouksilla Organisaatiokaavio Ulkomaisessa projektinhallintakirjallisuudessa ei useinkaan erotella toisistaan hankkeita ja monimutkaisia projekteja, vaan niille molemmille sovelletaan samanlaista 34

36 organisaatiota. Vain siinä tapauksessa, jos hanke muistuttaa pikemminkin projektisalkkua kuin isoa projektia, kannattaa hankkeelle soveltaa projektiorganisaatiosta poikkeavaa organisaatiomallia Seuraavassa on kuvattu CPM:n suosittelema ketterän kehittämishankkeen organisaatio, jota on mahdollista soveltaa myös muihin isoihin projekteihin ja hankkeisiin. Organisaatiokaaviota on mahdollista myös hieman karsia siten, että tuloksena saadaan ketterän julkistusprojektin tai pienehkön Gantt-projektin ohjaukseen tarvittava organisaatio. Karsiminen voi tapahtua mm. poistamalla projektitoimisto sekä korvaamalla toteutuksen johtoryhmä pelkällä projektin omistajalla tai product ownerilla. Jos julkistusprojekti on pieni ja selvitään alle 15 hengen projektiryhmällä, voidaan projekti toteuttaa monesti ilman tiiminvetäjiä, jolloin projektiryhmän jäsenet toimivat suoraan projektipäällikön alaisuudessa. Ohjausryhmä Toteutuksen johtoryhmä Inforyhmä Projektipäällikkö Projektitoimisto Tiimin 1 vetäjä Tiimin 2 vetäjä Tiimin 3 vetäjä Tiimin N vetäjä Tiimin jäsenet Tiimin jäsenet Tiimin jäsenet Tiimin jäsenet Organisaation toimielinten ja roolien täsmennykset CPM:ssä Ohjausryhmään valitaan mahdollisimman pieni joukko henkilöitä, jotka kykenevät omalla panoksellaan merkittävästi tukemaan hankkeen tai projektin edistymistä. Parhaimmillaan ohjausryhmän koko on 2-4 henkeä, koska muutoin kokouksista tulee yleensä liian jäykkiä ja pitkäkestoisia ja ohjausryhmä ei enää haluakaan kokoontua riittävän usein. Mikäli ohjausryhmään on halukkaita yli 4 henkeä, nämä ylimääräiset henkilöt tulisi nimetä ohjausryhmän varajäseniksi, joilla on läsnäolo-oikeus kokouksissa, mutta joiden aikataulukiireet eivät estä ohjausryhmän kokousten varaamista. 35

37 Ohjausryhmän vastuulla on hankkeen tai projektin ylätason ohjaus, kuten esimerkiksi päätökset erilaisten aloitus-, toteutus- ja päätöstoimenpiteiden hyväksymisestä sekä projektia uhkaavien aikataulu-, kustannus- ja laajuusongelmien sekä muiden merkittävimpien riskien ja ongelmien ratkaisutoimenpiteistä. Ohjausryhmän puheenjohtajana toimii joko projektin omistaja eli projektitoteutuksen tuotosten pääasiallinen omistaja ja hyödyntäjä tai projektin päärahoittaja (sponsori). Ohjausryhmän puheenjohtaja muodostaa projektista tai hankkeesta kytkennän organisaation ylemmille ja strategisemmille tarkastelutasoille. Joissain tapauksissa ohjausryhmä voidaan korvata organisaation ylemmän johdon valitsemalla projektien ohjausryhmällä, joka johtaa tarkasteltava hanketta sekä useita muita rinnakkaisia hankkeita projektisalkun johtamisen tai ohjelmajohtamisen näkökulmasta. Tällöin ohjausryhmä tarvitsee päätöksiään varten tiedot varsin kvantitatiivisessa muodossa, esimerkiksi aikataulua-, kustannuksia-, hyötyjä- sekä kokonaisriskitasoa kuvaavina tunnuslukuina. Inforyhmä muodostuu joukosta henkilöitä, joilla on erityistä kiinnostusta projektin tuloksia tai edistymisvauhtia kohtaan, mutta jotka eivät silti mahdu projektille asetettuun 2-4 hengen ohjausryhmään. Inforyhmään voivat kuulua mm. projektissa tuotetun julkistuksen tai toimituksen pääkäyttäjä(t) sekä projektista riippuvaisten muiden projektien projektipäälliköt. IT-projekteissa ja muissa teknisissä projekteissa inforyhmään voidaan kutsua henkilöitä, jotka ovat vastuussa organisaation teknologiavalinnoista ja kokonaisarkkitehtuurista. Inforyhmän jäsenille lähetetään tiedoksi (lähes) kaikki ohjausryhmällekin menevät materiaalit, kuten edistymisraportit sekä kokousten esityslistat (agendat) ja pöytäkirjat (muistiot). Inforyhmälle tulee tarjota myös pääsy projektin keskeisiin dokumenttivarastoihin ja tietojärjestelmiin. Lisäksi inforyhmän jäsenille tarjotaan mahdollisuus osallistua projektin luovutuskatselmuksiin. Mikäli osa inforyhmään nimetyistä henkilöistä olisi kovasti halunnut jäseneksi ohjausryhmään, voidaan tehdä päätös siitä, että kaikki inforyhmän jäsenet nimetään ohjausryhmän varajäseniksi. Inforyhmän jäseniä voidaan myös käyttää arvokkaina resursseina projektissa tuotettujen suunnitelmien ja käyttöohjeiden katselmoimiseen. Toteutuksen johtoryhmän vastuulla on valmistella ohjausryhmää varten tarvittavat toimenpide-ehdotukset projektissa tai hankkeessa ilmeneviin riskeihin ja ongelmiin liittyen. Erityisen tärkeitä ovat ne ratkaisuehdotukset, jotka liittyvät aikatauluongelmien, kustannusongelmien tai toteutuksen laajuutta ja laatua koskevien ongelmien ratkaisemiseen. Lisäksi toteutuksen johtoryhmän tehtävänä on varmistaa, että projektilla toimitetut tuotokset, sprintit ja julkistukset on testattu, katselmoitu ja viimeistelty niin hyvin, että ne voidaan toteutuksen johtoryhmän kokouksissa hyväksyä. Toteutuksen johtoryhmä muodostuu pienimmillään pelkästä projektipäälliköstä ja projektin omistajasta tai product ownerista. Toteutuksen johtoryhmää voidaan tarvittaessa laajentaa (yhdellä) asiakkaan teknisellä asiantuntijalla sekä (yhdellä) toteutuksen asiakaskuntaa edustavalla pääkäyttäjällä tms. käyttäjänäkökulman asiantuntijalla. Lisäksi johtoryhmään voidaan tuoda mukaan projektitoimituksesta vastaavan toimittajayrityksen projektipäällikkö ei kuitenkaan mielellään enää toimittajayrityksen alihankkijoiden projektipäälliköitä. Toteutuksen johtoryhmään ei kannata nimetä projektitoteutuksesta 36

38 vastaavien tiimien vetäjiä (esim. teknisiä projektipäälliköitä), koska muutoin käy epäselväksi, johtaako projektipäällikkö tiiminvetäjiä vai johtavatko tiiminvetäjät projektipäälliköitä. CPM:ssä toteutuksen johtoryhmä merkitään ohjausryhmää avustavaksi elimeksi. Tällä pyritään varmistamaan se, että toteutuksen johtoryhmästä ei muodostu haitallista ja jäykkää välikerrosta, joka eristää projektipäällikön ja ohjausryhmän puheenjohtajan liian kauas toisistaan. Projektipäällikön vastuulla ovat mm. seuraavat tehtävät: - hankkeiden-, projektien sekä sprinttien aloitusvaiheessa tapahtuvien suunnittelu- ja valmistelutoimenpiteiden johtaminen - toteutustiimien johtaminen (tiiminvetäjien sekä kokousmenettelyjen avulla) - aikatauluun-, kustannuksiin ja toteutuksen laajuuteen liittyvien ennusteiden ja ongelma-analyysien tekeminen sekä ongelmien korjausehdotukset - projektin muiden ongelmien sekä riskien ja muutospyyntöjen analysointi sekä niihin liittyvien toimenpide-ehdotusten laatiminen - projektin vaatimuslistalle sekä erilaisille tehtävälistoille asetettujen tehtävien toteutuksen seuranta - hanke- ja projektiorganisaation purkaminen projektin tultua päätösvaiheeseen. Tiimien jäsenten vastuulla on toteuttaa ne tehtävät, jotka on projektin tehtävälistoissa, projektiryhmän kokouksissa taikka projektin resurssisuunnitelmassa ja tiiminjäsenen toimenkuvassa määritelty hänen vastuulleen. Ketterissä projekteissa tiimin jäsenet voivat ottaa omalle vastuulleen tehtäviä myös omaehtoisesti, esimerkiksi katsomalla mitä tehtäviä tiimin tehtävälistalla on avoimena. Jos toteutustiimejä on enemmän kuin yksi, niille nimetään kullekin tiimin vetäjä jota voidaan kutsua myös scrum masteriksi tai tekniseksi projektipäälliköksi. Mikäli projektipäällikön alaisena toimii teknisiä projektipäälliköitä, projektipäällikköä on luontevampi kutsua hankepäälliköksi tai projektijohtajaksi. Projektitoimistoon voivat kuulua esimerkiksi projektiassistentti, laatupäällikkö, testausasiantuntija, käytettävyysasiantuntija ja projektin arkkitehti. Kaikkein isoimmissa hankkeissa projektitoimisto palvelee vain kyseistä hanketta, mutta monissa tapauksissa organisaatiolla on kaikkia projekteja yhtaikaisesti tukeva projektitoimisto, joka tukee kutakin projektia hieman epäsuoremmin ja epäkonkreettisemmin esimerkiksi katselmoimalla ja projektisuunnitelmia sekä laatusuunnitelmia tai tarjoamalla tukea projektinhallintaohjelmistojen käyttöön. Projektitoimistojen osalta on varmistettava se, että siitä aiheutuvat palkkakustannukset huomioidaan projektin budjetissa mieluiten siten, että projektitoimiston työntekijöiden työtunnit on huomioitu projektin työmääräarvioissa, jonka lisäksi työtunnit kirjataan tuntiseurannassa kullekin projektitoimiston tukemalle projektille. Mikäli projekti toteutetaan asiakkaan ja toimittajan tiiviillä yhteistyöllä, projektipäälliköitä ja tiimien vetäjiä voi olla kutakin kaksi hekilöä asiakkaan ja toimittajan. 37

39 Tällöin on tärkeää täsmentää projektisuunnitelmaan, miten projektipäällikkövastuut jakautuvat asiakkaan ja toimittajan kesken. 38

40 4.2.3 Ketterien kehittämishankkeiden ohjaus säännöllisillä kokouksilla Seuraavassa on CPM:n suosittelema malli siitä, millaisilla kokouksilla ketterien hankkeiden, julkistusten ja sprinttien ohjaus tulisi toteuttaa. Kokoontuva elin ja muut osallistujat Kokouksen tiheys (ja kesto) Kokousta varten raportoitavat asiat Ohjauspäätökset Ohjausryhmän kokous Joka 4. viikko (2 h) Aikataulu-, kustannus- ja scope-ennusteet sekä riskit ja ongelmat sekä ratkaisuehdotukset Ongelmien ratkaisuehdotuksista päättäminen. Esitettyjen isomman tason muutosten hyväksyminen tai hylkääminen. Toteutuksen johtoryhmän kokous Joka 4. viikko (2 h) Sama kuin yllä Ratkaisu- ja muutosehdotusten valmistelu Luovutuskatselmus (omistaja, pp, projektiryhmän jäsenet sekä mahd. myös sidosryhmien edustajia. Joka 4. viikko (2 h) Sama kuin yllä + valmistuneet vaatimukset ja niihin liittyvät testi- ja katselmustulokset Sprinttien ja julkistusten hyväksymiset sekä teknisen velan käsittelyä koskevat päätösesitykset Edistymiskatselmus (pp + projektin omistaja) Viikoittain (1 h) Sama kuin yllä + valmistuneet vaatimukset ja niihin liittyvät testi- ja katselmustulokset Sama kuin yllä + nopeavaikutteiset ongelmien ratkaisupäätökset (atomististen tehtävien käynnistys) Tiiminvetäjien kokous (pp ja tiiminvetäjät) 2-3 kertaa / vko (15 min) Tiimien riippuvuudet ja koordinointitarpeet Atomististen tehtävien käynnistäminen. Tiimipalaveri (tiimin jäsenet + tiimin vetäjä) Joka päivä (15 min) Tiimin jäsenten valmiiksi saamat ja keskeneräiset työt sekä ongelmat Tieto siitä, kuka tekee mitäkin tehtävää ja mitkä ongelmat ja riskit tulee ratkaista pp:n ja projektin omistajan toimesta. Näiden kokousten esityslistalle ei pidä laittaa projektin tekniseen toteutukseen liittyviä suunnittelu- ja ongelmanratkaisutehtäviä, koska muutoin ohjaukselle ei jää aikaa. Teknisen toteutuksen suunnittelu- ja ongelmanratkaisu tulee hoitaa erillisissä työpajoissa, 39

41 joille tosin voidaan varata kokoustilaa ja kalenteriaikaa välittömästi ohjauskokousten yhteyteen: Esimerkiksi tiimipalavereja sekä tiiminvetäjien kokouksia varten tulee varata kokoustilaa 60 minuuttia, jotta tiimin jäsenillä on mahdollisuus jäädä ratkomaan esiin nousseita teknisiä ongelmia. Samalla tavoin myös luovutuskatselmus ja toteutuksen johtoryhmän kokous kannattaa niputtaa peräkkäin siten, että luovutuskatselmuksen jälkeen toteutuksen johtoryhmän jäsenet jäävät paikan päälle ratkomaan mahdollisia tekniseen velkaan tai aikatauluihin ja kustannuksiin liittyviä ongelmia. Pienemmissä yhden ainoan toteutustiimin vastuulla olevissa kehittämishankkeissa voidaan jättää toteuttamatta taulukkoon merkityt tiimipalaverit. 4.3 Ketterän kehittämishankkeen aloitus, toteutus, ohjaus ja päätös Yleiskuvaus ja peruskäsitteet Ketterä kehittämishanke toteutetaan 2-5 peräkkäisellä julkistusprojektilla, joiden kunkin tavoitteena on tuottaa tuotejulkistus, palvelujulkistus, uuden prosessiohjeen julkistus tai projektitoimutuksen asiakkaalle toimitettava käyttöönottokelpoinen toimituserä. Seuraava kaavio tiivistää sen, miten ketterät kehittämishankkeet, aloitetaan, toteutetaan ohjataan ja päätetään CPM-menetelmällä: Aloitusvaiheen johtaminen: 1. Ideointivaihe 2. Määrittelyvaihe 3. Kilpailutusvaihe 4. Proof of concept Toteutusvaihe: 2-5 peräkkäin toteutettavaa ketterää projektia, jotka kukin tuottavat joko julkistuksen tai toimituserän Kehittämishankkeen päättäminen 1. Viimeisen toimituserän julkistus tai käyttöönotto 2. Kehittämishankkeen purkaminen ja lopetus. testi- ja katselmustulokset sekä riskit ja ongelmat sprinttien ja toimitusten hyväksymiset sekä riskien ja ongelmien hallintatehtävät Ketterän kehittämishankeen systemaattinen ohjaus 1. Julkistusten tai toimituserien valmiusasteen seuranta sekä aikataulu- ja kustannusennusteet toimituserää sekä koko kehittämishanketta koskien. 2. Toteutettujen vaatimusten, sprinttien ja julkistusten hyväksyminen 3. Vaatimusten siirto myöhempiin julkistuksiin ym. ongelmanratkaisupäätökset. 4. Muut riskien, ongelmien ja muutosten hallintapäätökset Seuraavissa luvuissa kuvataan tarkemmin ketterän kehittämishankkeen aloituksen, toteutuksen ja päätösvaiheen eteneminen sekä toteutusvaiheeseen liittyvät ohjausmenettelyt. 40

42 4.3.2 Hankkeen aloitus askel askeleelta Isojen projektien ja hankkeiden aloittamisvaihe kannattaa toteuttaa nopeasti ja systemaattisesti askel kerrallaan siten, että kunkin askeleen tai alemman tason vaiheen jälkeen seuraa päätösportti, jossa hanke joko lopetetaan tai vaihtoehtoisesti sille annetaan lupa jatkaa kohti toteutusvaihetta ja yhä suurempia kustannuksia. Päätösporttien avulla vältetään se, että suuren innostuksen vallassa sitoudutaan huomattavan ison hankkeen toteuttamiseen, ilman kunnollisia kustannus-hyötylaskelmia sekä riskianalyyseja. Vaikka aloitus etenee alemman tason vaiheiden sekä päätösporttien kautta, aloitus on silti CPM:ssä mahdollista tehdä myös varsin kevyesti ja nopeasti, kuten seuraavassa taulukossa olevista suuntaa-antavista kestoajoista ja kustannuksista käy ilmi: Alemman tason vaihe Ideointi Määrittely Kilpailutus ja sopimus POC eli proof of concept Tehtävät ja tuotokset Alustava business case. RFI eli lisätietopyyntö toimittajille. Omistajan nimeäminen Ideavaiheessa tehdyn business casen tarkentaminen alustavan projktisuunnitelman muotoon. Projektitoteutusta koskevien vaatimusten kokoaminen vaatimusluetteloksi. RFP eli lopullinen tarjouspyyntö. Saapuneiden tarjousten arviointi ja toimittajien valinta. Kustannus- ja hyötylaskelmien sekä projektisuunnitelman päivittäminen tarjousten pohjalta. Sopimusten laadinta ja allekirjoitus. Ehdotetun teknologian ja ratkaisumallin kokeileminen yhdellä sprintillä, prototyyppitasolla. Projektisuunnitelman sekä kustannus-hyötyarvion täsmentäminen. Resurssien kiinnitys hankkeeseen. Kesto Kustannus ( ) päivää Portti Aloitusvaiheen kokonaiskesto kaikki alemman tason vaiheet huomioiden vaihtelee seitsemästä päivästä aina 95 päivään, hankkeen laajuudesta riippuen. Mikäli hankkeesta ei järjestetä tarjouskilpailua eikä riskien minimoimiseen tarkoitettua POC:ia, aloitusvaiheen kestoajan tulisi pysyä alle 35 päivässä. Aloitusvaiheen kustannukset vaihtelevat noin 5000 eurosta aina noin euroon asti, mutta tässä korkeammassa hinnassa on mukana jo varsin laaja vaatimusmäärittely, yhden sprintin laajuinen POC sekä kilpailuvaiheessa käytetylle konsultille maksettava korvaus. Vaikka edellä kuvatun mallin mukaan toimittaessa saattaa käydä joskus niin, että organisaatio kuluttaa ideointiin, määrittelyyn, kilpailutukseen sekä ratkaisumallin alustavaan testaukseen ja sen jälkeen keskeyttää hankkeen toteutuksen, on tämä kuitenkin parempi ratkaisu, kuin että hanke päätettäisiin käynnistää tilanteessa, jossa vaatimusluettelo ja projektisuunnitelma ovat pahasti keskeneräisiä ja valitun teknologian on havaittu aiheuttavan miljoonien eurojen riskejä (ks. luku 2.1). Seuraavassa on kuvattu aloitusvaiheen eteneminen hieman tarkemmin. 41

43 Ideointivaihe Hankkeen ideointivaiheen tavoitteena on laatia alustava business case, jonka lisäksi on jo tässä vaiheessa syytä ottaa yhteyttä mahdollisiin projektitoimittajiin lisätietojen saamiseksi (RFI eli request for information). Business case kannattaa laatia hankesuunnitelman mallidokumenttia käyttäen, kuitenkin siten, että nimeksi laitetaan Business case tai Alustava hankesuunnitelma. Dokumentista täytetään pelkästään Executive summary tyyppinen johdantoluku, jossa kuvataan - hankeen avulla tavoiteltavat kustannussäästöt ja rahamääräiset hyödyt sekä strategiset hyödyt (kytkien strategiset hyödyt organisaation määrittelemään strategiaan) - hankkeen kestoaika sekä ohjausmalli (ketterä, gantt vai molemmat yhdessä) - alustava resurssisuunnitelma ja alustava kustannusarvio - hanketoteutukselle asetettavat vaatimukset (mitä tehdään) sekä rajaukset karkealla tasolla - hankkeen omistaja ja/tai sponsori sekä kustannuspaikka ja sidosryhmät - hankkeen vaikutukset sidosryhmiin sekä sidosryhmiltä hankkeelle vaaditut panokset - hankkeen arvioitu riskitaso, joka saattaa olla melko suuri, koska kustannuksia ei yleensä tässä vaiheessa vielä kunnolla tunneta - mikä organisaatioyksikkö ja kustannuspaikka ottavat projektin vastuulleen. Mikäli projekti sijoittuu johonkin projektisalkkuun, on tässä vaiheessa laskettava myös kaikki projektisalkun johtamisessa tarvittavat tunnusluvut, ellei näitä ole jo kuvattu Business casessa. Ideointivaiheen lopussa laaditaan projektin omistajaa ja/tai sponsoria varten arvio siitä, paljonko määrittelyvaiheen toteutus maksaisi ja kestäisi sekä pyydetään valtuudet hankepäällikön nimeämiseen. Lopussa toteutuu ensimmäinen päätösportti, jossa omistaja ja/tai sponsori päättävät, sallitaanko projektin edetä määrittelyvaiheeseen Määrittelyvaihe Kun ideointivaihe päättyy, CPM:n mallidokumentteihin perustuva alustava hankesuunnitelma täsmentää jo sen, tuleeko projektille projektipäällikkö, hankepäällikkö, projektijohtaja vai product owner (tuotekehityksen johtaja). Vaikka vaihtoehtoja projektipäällikön tehtävänimikkeelle ja toimenkuvalle on monia, kutsutaan näitä kaikkia vaihtoehtoja yksinkertaisuuden vuoksi projektipäälliköiksi. Projektipäällikön nimeää yleensä projektin omistaja määrittelyvaiheen alussa. Mikäli projektin toteutuksessa halutaan käyttää avaimet käteen periaatteella toimivaa projektitoimittajaa, kukin toimittajaehdokas nimeää yleensä RFI:n saatuaan jonkun projektipäällikön ottamaan projektin suunnittelun omalle vastuulleen. Hankkeen määrittelyvaihe etenee kahtena rinnakkaisena prosessina, jotka ovat vaatimusluettelon laadinta sekä hankesuunnitelman tekeminen. 42

44 Vaatimusluettelon (product backlog) avulla täsmennetään se, mitä vaatimuksia hankkeen tuottamien julkistusten tai toimituserien on täytettävä. Vaatimukset voivat olla luonteeltaan toiminnallisia vaatimuksia tai käyttötarinoita tyyliin Käyttäjän on voitava maksaa palvelun avulla laskuja tai Tuotteen on tarjottava asiakkaalle reaaliaikaista tietoa siitä, milloin kulkuneuvo saapuu seuraavalle pysäkille. Vaatimusluettelo voi sisältää myös ei-toiminnallisia vaatimuksia, joita voivat olla mm. tekniset vaatimukset, käytettävyysvaatimukset, laatuvaatimukset sekä lakien, asetusten ja standardien asettamat vaatimukset. Toimintojen ja prosessien kehittämishankkeessa vaatimusluettelo voi sisältää luettelon niistä prosesseista ja toiminnoista, jotka kehittämishankkeella tulisi uudistaa. Mikäli hanke halutaan toteuttaa huomattavan ketterästi eli ilman jäykkää muutoshallintaa, vaatimusluettelo voidaan kuvata karkealla tasolla siten, että kukin vaatimus mahtuu yhteen Excel-taulukon soluun. Tällöin haittana on se, että vaatimusten määrittely jää niin karkealle tasolle, että projektitoimittajat eivät yleensä pysty sitoutumaan vaatimusten toteuttamiseen urakkahinnalla. Jos siis tavoitteena on projektin omistaja-organisaation riskin pienentäminen urakkahinnoittelua käyttämällä, vaatimusmäärittely pitää viedä hieman pidemmälle. Tällöin tavoitetasona voi olla esimerkiksi tietojärjestelmäprojekteissa se, että järjestelmälle laaditaan käyttötapakuvaukset, joissa kuvataan myös suunnilleen se, kuinka monella eri näytöllä ja käsittelysäännöllä käyttötapaukset toteutetaan. Tämä määrittelytaso mahdollistaa toimintopistelaskennan sekä sen, että projektitoimittajat sitoutuvat toimintopisteisiin perustuviin urakkahintoihin. Vaatimusluettelon tallennuspaikkana voi toimia Excelin lisäksi myös Scrum-projektien ohjauksessa käytetty product back-login hallintaväline kuten Scrumworks. Perinteisissä kiinteällä hinnalla ostettavissa tietojärjestelmäprojekteissa käytetään toisinaan myös vaatimusten hallintaohjelmia, joista voidaan mainita mm. Rationalin Requisite Pro. Vaatimustenhallintatyökalujen tarkoituksena on helpottaa sen valvomista, että kaikki vaatimukset perustuvat joihinkin liiketoiminnallisiin tavoitteisiin ja että kaikkiin toiminnallisiin vaatimuksiin on vastattu tarkempien suunnitelmien kuten käyttötapakuvausten (use case), käyttötarinoiden (user story) tai visualisoitujen prototyyppien avulla. Hankesuunnitelman tekeminen alkaa siitä, että alustava Business case tallennetaan hankesuunnitelmaksi, jonka jälkeen johdantoluku päivitetään siten, että tavoitteet, rajaukset, riippuvuudet, sidosryhmät, kustannukset ja hyödyt tulevat paremmin täsmennetyiksi. Tämän jälkeen täsmennetään hankkeen karkean tason vaiheistus ja aikataulu sekä päätason tehtävät ja osaprojektit yhteen ainoaan korkeintaan 15 riviä korkeaan aikataulukaavioon. Hankesuunnitelman kolmas luku kuvaa hankkeen organisaation ja kokousmenettelyt. Viimeisissä luvuissa täsmennetään - hankkeen sekä siihen kuuluvien osatehtävien ja projektien raportointi- ja ennustamismenettelyt sekä riskien, ongelmien ja muutosten hallinta. - Viestintäsuunnitelma ja laatusuunnitelma - sprinttien, osaprojektien, toimituserien sekä julkistusten katselmointi- ja hyväksymismenettelyt. - hankkeen päätösvaiheen tehtävien kuvaus (ks. luku 4.3.3) 43

45 Kilpailutus- ja sopimusneuvotteluvaihe Kilpailutus ja sopimusneuvottelut muodostavat tärkeän vaiheen, jonka aikana projektitoimittaja(t) käyttävät parhaan osaamisensa laskeakseen projektille mahdollisimman alhaisen ja realistisen työmääräarvion sekä realistisen aikataulun. Vaiheen alussa lähetetään tarjouspyynnöt sekä vastataan mahdollisten toimittajien esittämiin kysymyksiin. Tarjouspyynnön liitteenä tulee lähettää CPM-menetelmän mallidokumentteihin perustuva - vaatimusluettelo - alustava hankesuunnitelma sekä - sopimusluonnos Sopimusluonnoksella täsmennetään mm. kehittämishankkeen hinnoittelumalli ja maksupostit. CPM suosittelee sellaista sopimusmallia, jossa toimittajat laskuttavat asiakaalta jokaisen sprintin jälkeen sprintin aikana tehdyt työtunnit tavoitehintaisesti siten, että tuntilaskutusta alennetaan, jos sprintin aikainen etenemisvauhti on ollut alhaisempi kuin sopimuksen allekirjoittamishetkellä sovittu etenemisvauhti. Alennusten tulee olla niin suuria, että maksimialennuksella toimittajayritys kykenee juuri ja juuri maksamaan projektiryhmän palkat, mutta ei saa projektista mitään katetta. Jos maksimialennukset ovat tätä pienempiä, toimittajayritykset saattavat kilpailutus- ja sopimusneuvotteluvaiheessa arvioida hyötyjen syntymisvauhdin huomattavan epärealistisella ihan vain voittaakseen tarjouskilpailun. Jos taas maksimaalinen alennusprosentti nostetaan liian suureksi, tämä kiristää tunnelmaa projektiryhmän ja projektin omistajan välillä sekä kannustaa projektiryhmää salaamaan sen teknisen velan, joka projektin aikana on syntymässä. Tarjouksille varatun ajan umpeuduttua tarjoukset tarkastetaan ja osa niistä hylätään suoralta kädeltä tiettyjen ennalta asetettujen periaatteiden mukaisesti. Tämän jälkeen loput tarjouksista pisteytetään, jonka jälkeen parhaat pisteet saanut projektitoimittaja voittaa tarjouskilpailun. Toisinaan pisteytyksiä kuitenkin hieman väännetään ja käännetään, jotta ostajaa miellyttävä toimittaja saataisiin valittua kilpailun voittajaksi. Toimittajilla, jotka kokevat itsensä kaltoin kohdelluiksi, on oikeus valittaa asiakkaan tekemistä toimittajavalinnoista markkinaoikeuteen, mikä saattaa pidentää kilpailutus- ja sopimusneuvotteluvaiheen kestoa jopa yli puolella vuodella. Kun paras toimittaja on saatu selville, hankesuunnitelma sekä siihen sisältyvät aikataulut ja kustannuslaskelmat on syytä päivittää yhteensopivaksi voittaneen tarjouksen kanssa, jotta hankesuunnitelma voidaan laittaa hankesopimuksen liitteeksi. Hankesuunnitelman asettaminen sopimuksen liitteeksi on tärkeää, koska hankesuunnitelman avulla toimittajat voidaan pakottaa noudattamaan systemaattisia ja läpinäkyviä johtamis-, raportointi- ja ohjausmenettelyjä: Ilman tällaista sitoumusta asiakas ei pysty kunnolla näkemään, edistyykö toimittajien lupaama projektityö alun perin luvatulla vauhdilla vai tuleeko projekti myöhästymään ja/tai ylittämään kustannusarvion. 44

46 Ratkaisumallin alustava testaus eli POC Ratkaisumallin alustava testaus eli proof of concept (POC) kannattaa toteuttaa hankkeissa, joiden osalta on tunnistettu uuteen teknologiaan, arkkitehtuuriin tai valittujen tuotteiden yhteensopivuuteen liittyviä riskejä. POC kannattaa kustannussyistä toteuttaa yleensä lopullista hankeorganisaatiota pienemmällä projektiryhmällä, jonka koko voidaan usein rajata vain muutamaan kokeneeseen asiantuntijaan. POC:in ajallinen kesto kannattaa yleensä rajata yhteen sprinttiin taikka yhteen 3-5 viikon mittaiseen Gantt-ohjauksella toteutettuun tehtävään Ohjausryhmän tehtävät aloitusvaiheessa Ohjausryhmän tehtävänä on varmistaa, että kustannus- ja hyötyarvio (business case), vaatimusluettelo ja hankesuunnitelma (liitteineen) täsmentyvät päätösporttien läpi kuljettaessa niin, että ohjausryhmä kykenee tekemään päätökset projektin jatkamisesta tai keskeyttämisestä luotettavaan tietoon perustuen. Mikäli projektipäällikkö tai projektitoimittajat eivät kykene tuottamaan uskottavia aikataulu- ja kustannusennusteita aloitusvaiheen kuluessa, ohjausryhmän on syytä lopettaa hanke tai vaihtaa projektipäällikköä ja/tai projektitoimittajaa. Tämä on erittäin tärkeää, koska suoritettujen tutkimusten mukaan 90 % projektien epäonnistumisen siemenistä kylvetään jo projektin aloitusvaiheessa ja yleensä nämä epäonnistumista edistävät tekijät liittyvät siihen, että kustannus- ja aikatauluarviot on laadittu taitamattomasti ja liian optimistisesti taikka projektille ei ole suunniteltu kunnollista ohjausjärjestelmää Lean-filosofian soveltaminen aloitusvaiheeseen Monet organisaatitot ja johtamisoppaat suosittelevat, että projektin tai hankkeen aloituspäätöksen jälkeen laadittaisiin muodollinen toimeksianto (ns. Project Directive), jolla projektin toteutusvastuu siirretään ja ohjeistetaan projektipäällikölle. Tämä ajatus siitä, että on olemassa vain yksi ainoa päätös projektin toteuttamisesta sotii kuitenkin päätösporttimallia sekä asteittain tarkentuvan päätöksenteon ideaa vastaan. Jos siis Project Directiveä tai haluttaisiin käyttää, se tulisi toteuttaa asteittain tarkentuen. Lisäksi on huomattava, että Project Directive sisältää melko paljon samoja tietoja kuin Business Case, mikä aiheuttaa päällekkäistä dokumentaatiotarvetta. Tämä puolestaan sotii turhan yliprosessoinnin eliminoimiseen tähtäävää Lean-johtamisfilosofiaa vastaan (ks. luku 2.4.8). Tämän vuoksi CPM suosittaa, että suunnitteludokumentaatio rajataan Vaatimusluetteloon sekä Business caseen. Näistä jälkimmäinen uudelleen nimetään Hankesuunnitelmaksi määrittelyvaiheen aikana, jolloin dokumenttia samalla täsmennetään. 45

47 4.3.3 Ketterän kehittämishankkeen toteutus ja päätös Ketterän kehittämishankkeen toteutus aloitetaan hankkeen aloitusvaiheen jälkeen. Toteutusvaihe etenee toisiaan seuraavien toimituserien julkistamiseen tähtäävien julkistusprojektien kautta (ks. luku 4.4). Julkistusprojektien rinnalle on yleensä pakko rakentaa käyttöönottoprojekteja, joilla peräkkäiset julkistukset otetaan käyttöön siten, että julkistusta 2 kehiteltäessä otetaan samalla käyttöön julkistus 1. Aloitus Julkistusprojekti 1 Julkistusprojekti 2 Julkistusprojekti 3 Käyttöönotto 1 Käyttöönotto 2 Käyttöönotto 3 Tiketeillä johdettavat ongelmien ja virheiden korjaustehtävät Päätös Koska julkistetut tuotteet tai järjestelmät siirretään käyttöönoton aikana tuotantoon, on projektiryhmän vastattava yleensä myös tuotannossa oleviin järjestelmiin liittyvien ongelmien ja virheiden korjauksista. Tämä vastuu siirretään kuitenkin kehittämishankkeen edetessä vähitellen erilliselle ylläpito-organisaatiolle. Kun viimeinen käyttöönottoprojekti on valmistunut ja kun viimeisen julkistuksen mahdollisesti sisältämät (merkittävät) virheet on korjattu, kehittämishanke siirtyy päätösvaiheeseen, jonka aikana projektipäällikkö kerää tyytyväisyysarviot sidosryhmiltä, kirjoittaa hankkeen loppuraportin sekä kutsuu koolle ohjausryhmän päätöskokouksen. Tässä kokouksessa ohjausryhmä antaa muodollisen luvan projektin päättämiselle. Luvan saatuaan projektipäällikkö purkaa projektiorganisaation ja vapauttaa kaikki muutkin projektin resurssit kuten tilat, laitteet ja lisenssit muuhun käyttöön Ketterän kehittämishankkeen ohjaus Ketterän kehittämishankkeen ohjaus perustuu erittäin keskeiseltä osin aikataulu-, kustannus- ja scope-ennusteiden laskentaan (luvuu ) sekä kyseisiin ennusteisiin perustuviin ongelma-analyyseihin ja toimenpide-ehdotuksiin. Toimenpide-ehdotusten tulisi edetä ohjausryhmän kokousta edeltävien ja valmistelevien alemman tason kokousten aikana aikataulua-, kustannuksia tai scopea koskeviksi muutosehdotuksiksi sekä konkreettisten atomististen tehtävien perustamiseen asti. Atomististen tehtävien käynnistys voidaan hyväksyä tiiminvetäjien kokouksissa sekä projektin edistymiskatselmuksissa, mutta isommat muutokset on syytä jättää ohjausryhmän päätettäviksi. 46

48 Toisena projektien ohjauksen osa-alueena on projektin muiden ongelmien ja riskien analysointi sekä korjaavien toimenpiteiden suunnittelu. Tältäkin osin ohjaus edellyttää ongelmien ja riskien kuvaamisen ja luetteloinnin lisäksi sitä, että toimenpiteet viedään konkreettisiksi atomistisiksi tehtäviksi asti, ja kullekin tehtävälle asetetaan vastuuhenkilöt ja valmistumispäivät. Pelkkä ongelmien ja riskien passiivinen luettelointi ja luokittelu sekä riskien ja ongelmien huolestunut silmäily ohjausryhmän kokouksissa eivät vielä ole ohjaustoimenpiteitä. Ohjausvaikutus alkaa vasta siitä, kun riskeistä ja ongelmista johdetaan atomistisia tehtäviä ja muutosehdotuksia, joiden edistymistä projektipäällikkö ja ohjausryhmä systemaattisesti seuraavat. Mikäli ongelmien ratkaisutoimet ovat kustannusvaikutuksiltaan vähäisiä, niiden toteutuksesta päätetään tiiminvetäjien kokouksissa tai projektin edistymiskatselmuksissa. Isommista riskien ja ongelmien hallintatoimenpiteistä päättää ohjausryhmä. Kolmantena ohjauksen osa-alueena on projektipäällikön, projektitoimittajan ja projektiryhmän kyvykkyyttä koskevien tilannearvioiden tekeminen, joka saattaa perustua esimerkiksi testituloksiin ja auditointeihin tai aikataulu-, kustannus- ja scope-ennusteisiin taikka projektipäällikön kyvyttömyyteen tuottaa edellä mainittuja ennusteita. Tältä osalta ohjaus tarkoittaa ohjausryhmän valmiutta tiukkohin päätöksiin siitä - pitääkö projektipäällikkö vaihtaa? - pitääkö projektitoimittajaa vaihtaa? - pitääkö tuntilaskutteinen projekti muuttaa kiinteähintaiseksi? - pitääkö käynnissä oleva projekti tai hanke keskeyttää? Mikäli ohjausryhmä ei ohjaa projektia tai hanketta huolellisesti laadittujen aikataulu-, kustannus- ja scope-ennusteiden pohjalta, ohjausryhmän jäsenten ja erityisesti puheenjohtajan tulee henkilökohtaisesti ottaa vastuu projektin mahdollisesta epäonnistumisesta. 47

49 4.4 Ketterän julkistusprojektin aloitus, toteutus, ohjaus ja päätös Ketterien julkistusprojektin tyypit ohjauksen näkökulmasta Ketterällä julkistusprojektilla tarkoitetaan 4 viikon mittaisisiin sprintteihin jaksotettuja projekteja, joiden tavoitteena on saada aikaan julkistus tai asiakastoimitus. Julkistus (release) viittaa suurelle asiakasjoukolle tarkoitettuun tuote- tai palvelujulkistukseen, kun taas asiakastoimituksen käsite olettaa, että asiakkaita on vain yksi. CPM:ssä tuotejulkistuksia ja asiakastoimituksia kutsutaan yksinkertaisuuden vuoksi nimellä julkistusprojekti. Aloitusvaiheen johtaminen: 1. Määrittelyvaihe 2. Kustannusennuste 3. Sopimusneuvottelut Toteutusvaihe: Jakautuu 2-10:een neljän viikon mittaiseen sprinttiin Projektin päättäminen 1. Julkistus- tai käyttöönottotyöt 2. Toteutumattomia vaatimuksia kuvaavan listan päivittäminen. testi- ja katselmustulokset sekä demot ja ongelmat sprinttien hyväksymiset ja uudet riskinhallintatehtävät Projektin systemaattinen ohjaus 1. Toteutettujen vaatimusten ja sprinttien hyväksyminen 2. Projektin valmiusasteen seuranta sekä aikataulu- ja kustannusennusteet 3. Vaatimusten siirto myöhempiin julkistuksiin (tai projektin lopettaminen), jos edistymisvauhti ei ole riittävä tai jos kustannukset ovat liian suuret. Ketterä julkistusprojekti voi olla luonteeltaan aikarajoitettu (time boxed), joustava tai haastava. Näiden vaihtoehtojen välinen valinta tulisi toteuttaa hankesuunnitelmassa ja projektisopimuksessa (ks. luku ) tai viimeistään ketterää julkistusprojektia kuvaavassa projektisuunnitelmassa. Aikarajoitetuissa julkistusprojekteissa toteutetaan ennalta sovittu määrä sprinttejä, joiden jälkeen projektilla tuotettu lopullinen toimituserä (release) julkistetaan. Aikarajoitetuissa projekteissa etuna on se, että projektin omistaja (product owner) tietää jo projektin alussa projektin kestoajan. Myös kustannukset ovat ennustettavissa hyvin tarkalla tasolla. Projektin omistajan näkökulmasta riskiksi jää se, että projektiryhmä(t) saavat ehkä toteutettua alkuperäisen vaatimusluettelon vaatimuksista vain pienen osan. 48

50 Joustavan aikataulun julkistusprojektissa periaatteena on se, että sprinttejä toteutetaan niin kauan kunnes koko vaatimuslista on toteutettu tai kunnes projektin omistaja arvioi, että vaatimuslistalla jäljellä olevien alemman tason vaatimusten tuottama lisähyöty jää pienemmäksi kuin mitä niiden toteutuksesta aiheutuvat kustannukset. Haastavasti aikataulutetuissa julkistusprojekteissa projektiryhmän tulisi toteuttaa tietyn aikataulun puitteissa kaikki ne vaatimukset, jotka on luokiteltu prioriteetiltaan kriittisiksi. Mitä suurempi osa vaatimuksista on luokiteltu kriittisiksi, sen haastavampaa on projektin ohjaus sekä vaatimusten toteutus annetun aikataulun puitteissa. Jos nämä kriittiset vaatimukset kuitenkin saadaan asetetulla aikataululla täytettyä, projekti muuttuu loppuosaltaan joustavaksi tai aikataulurajoitetuksi. Kaikki edellä mainitut julkistusprojektit edellyttävät kuitenkin sitä, että projektipäällikkö osaa soveltaa luvuissa esitettyjä aikataulun, kustannusten ja scopen ennustamismenetelmiä Ketterän julkistusprojektin aloitus Seuraavassa on kuvattu ne julkistusprojektin aloitusvaiheen tuotokset ja tehtävät, jotka on saatava valmiiksi joko julkistusprojektia edeltävässä hankesuunnitteluvaiheessa (ks. luku 4.3.2) tai viimeistään julkistusprojektin aloitusvaiheessa: Projektiryhmän kokoaminen ja ensimäisen projektisuunnittelutyöpajan varaaminen ovat toimenpiteitä, joilla varmistellaan se, että projektiryhmän jäsenet ovat projektin käytössä ja pääsevät nopeasti perille siitä, mitä projektilla tavoitellaan. Vaatimusluettelon täsmentäminen tarkoittaa sitä, että projektin omistaja (product owner) priorisoi vaatimusluettelon vaatimukset, jonka jälkeen projektipäällikkö tai erikseen valittu määrittelyasiantuntija täsmentää ne yhdessä projektin omistajan kanssa. 49

51 Projektisuunnittelutyöpaja tähtää siihen, että projektiryhmän jäsenet tutustuvat projektin tavoitteisiin, vaatimuksiin, aikatauluun ja sidosryhmiin sekä sen jälkeen tarkastavat ja viimeistelevät vaatimuksia koskevat työmäärä- ja hyötypistearviot suunnittelupokeria käyttäen. Suunnittelupokeri etenee siten, että kaikki ryhmän jäsenet nostavat yhtaikaisesti työmäärän suuruutta kuvaavan kortin, johon merkitty kokoluokitus, joka kuvastaa tehtävän vaatimaa työtuntimäärää sekä kalenteriaikaa olettaen, että yksi ainoa henkilö toteuttaisi tehtävän (ks. seuraava oleva taulukko): Kokoluokka Vaadittu kalenteriaika yhdeltä toteuttajalta Työmääräarvio tunneiksi tai hyötypisteiksi muutettuna XXS 1 h 1 h XS 0,5 pv 3,5 h S 1,5 pv 7,5 h M 5 pv 37,5 h L 3 viikkoa 115 h XL 2 kk 330 h XXL Puoli vuotta 990 h Projektisuunnittelutyöpajan jälkeen projektipäällikön on helppo laskea yhteen kaikkien vaatimusluetteloon sisältyvien vaatimusten edellyttämä kokonaistyömäärä. Jotta työmääristä ei tulisi epärealistisen optimistisia, kannattaa vaatimusluettelon aivan alkuun lisätä muutamia työympäristön ja toteutusarkkitehtuurin perustamiseen liittyviä vaatimuksia, joille asetetaan riittävän isot työmäärät. Tämä on erityisen tärkeää silloin, kun julkistusprojektia ei ole edeltänyt ketterän kehittämishankkeen aloitusvaiheessa suoritettu POC (ks. luku ). Projektisuunnitelman laadinta on periaatteessa helppoa, kun käytetään CPM-menetelmän tarjoamia mallidokumentteja. Vaikeinta on lähinnä se, että projektipäällikkö joutuu laskemaan projektille täsmennettyyn vaatimusluetteloon ja täsmennettyihin työmääräarvioihin perustuvat päivitetyt aikataulu-, kustannus- ja scope-ennusteet (ks. luvut ), joiden pohjalta projektin omistaja ja ohjausryhmä päättävät, annetaanko projektille lupa siirtyä toteutusvaiheeseen vai keskeytetäänkö koko projekti sekä mahdollisesti samalla myös koko kehittämishanke. Keskeyttämisen mahdollisuuden tulisi olla ohjausryhmän ja projektiryhmän mielessä koko ajan realistisena vaihtoehtona. Muutoin päädytään helposti tilanteeseen, jossa ohjausryhmä on sitoutunut toteuttamaan Hieno järjestelmä 2015 nimisen hankkeen vuoden 2015 loppuun mennessä, mutta projektiryhmän jäsenet pystyvät jo heti alkuun näkemään, että järjestelmän toteutus kestää vähintään vuoteen 2017 asti tai vaihtoehtoisesti järjestelmän vaatimuslistasta on karsittava pois yli puolet. Mikäli ohjausryhmällä ei ole uskallusta julkistusprojektin tai koko hankkeen keskeyttämiseen ensimmäisen julkistusprojektin aloitusvaiheen jälkeen, 50

52 projektiin syntyy salailun ja vääristelyn kulttuuri, jossa johdolle ei uskalleta kertoa projektin ja kehittämishankkeen todellisia aikataulu-, kustannus- ja scope-ennusteita. Aikataulu-, kustannus- ja scope-ennusteet lasketaan julkistusprojektin alkuvaiheessa siten, että kaikkien projektia koskevien vaatimusten karkeat työmääräarviot lasketaan yhteen. Sen jälkeen lasketaan, kuinka monta työmääräpistettä julkistusprojektin ja sitä seuraavien myöhempien julkistusten tulisi saada valmiiksi annetun ajan puitteissa. Tästä saadaan laskettua vaadittu etenemisnopeus (työtuntia per päivä) Työmääräarvion kokonaissumma Vaadittu etenemisnopeus = Projektille tai hankkeelle varattujen päivien määrä Vaadittua etenemisnopeutta verrataan sen jälkeen siihen, mikä on varatun projektiryhmän maksimikapasiteetti (työtuntia per päivä) 7,5 h * Tiimin koko * Tiimin jäsenten keskimääräinen allokaatio% Maksimikapasiteetti = Projektille tai hankkeelle varattujen päivien määrä jossa allokaatioprosentilla tarkoitetaan sitä, kuinka suuren prosentuaalisen osan tiimin jäsenet keskimäärin kykenevät käyttämään projektin töihin päivittäin (ottaen huomioon myös projektin ulkopuoliset työt, koulutustilaisuudet, kehittämiskeskustelut, lyhennetyt työajat sekä sairastamiseen ja sairaiden lasten hoitoon kuluva aika). Mikäli vaadittu etenemisnopeus on suurempi kuin projektiryhmän maksimikapasiteetti, projektin omistajan ja projektipäällikön on yhdessä joko - siirrettävä julkistusprojektin vastuulle asetettuja vaatimuksia myöhemmissä julkistuksissa toteutettaviksi - lisättävä projektille resursseja tai - pidennettävä julkistusprojektin kestoaikaa Jos julkistusprojekti on luonteeltaan aikataulultaan joustava, voidaan julkistuksen pituutta kasvattaa ongelmitta. Jos taas julkistuksella on hyvin tiukka (time boxed) aikataulu, ongelma ratkaistaan yleensä siirtämällä vaatimuksia myöhempiin julkistuksiin. Jos julkistusprojekti on aikataulullisesti haastava eli aikataulua ei voida kasvattaa ja vaatimusten toteutusta ei voida siirtää seuraaviin julkistuksiin, jää ainoaksi vaihtoehdoksi resurssien määrän lisääminen. Ohjausryhmän kannalta on erittäin tärkeää saada tietää tämänkaltaiset projektin aikatauluongelmat jo julkistusprojektin alkuvaiheessa, jotta projekti voidaan joko keskeyttää tai vaihtoehtoisesti sille saadaan riittävät resurssit, joilla projektin valmistuminen aikataulussa voidaan varmistaa. Lopuksi projektin omistaja ja projektipäällikkö viimeistelevät ja päivittävät projektisopimukset siten, että aikataulu-, kustannus- ja scope-laskelmilla havaitut ongelmat tulevat sopimuksessa ja sen liitteenä olevassa projektisuunnitelmassa sekä vaatimusluettelossa ratkaistuiksi. Projektisopimus olisi hyvä tulostaa ja allekirjoittaa tässä vaiheessa uudelleen, mikäli aikatauluihin-, kustannuksiin tai scopeen on tullut selviä muutoksia. Mikäli organisaatiolla on vaikeuksia saada allekirjoituksia korkean tason 51

53 kiireisiltä johtajilta, tulisi ohjausryhmän puheenjohtajalle tai projektin omistajalle antaa valtuudet sopimusten allekirjoittamiseen. Muussa tapauksessa käy helposti niin, että ylemmän tason johtajat jäävät norsunluutorniinsa ja projektin todellisuus etääntyy pahasti siitä, mistä sopimuksissa on virallisesti sovittu Ketterän julkistusprojektin toteutus, ohjaus ja päätös Ketterän julkistusprojektin toteutusvaihe muodostuu 2-10:stä toisiaan seuraavasta sprintistä, joiden toteutus, päivittäisjohtaminen ja ohjaus on kuvattu luvussa 4.5 ja kokousmenettelyt luvussa Julkistusprojektin ylätason ohjaus perustuu varsin pitkälti projektin aikataulu-, kustannusja scope-ennusteisiin, joiden laadintaa on kuvattu luvuissa Muut ohjausmenettelyt on kuvattu varsin pitkälti jo ketteriä kehittämishankkeita kuvaavassa luvussa 4.3.4, jossa kuvataan mm. riskien, ongelmien ja muutosten hallintamenettelyt. Ketterä julkistusprojekti päätetään ohjausryhmän päätöskokouksessa, joka pidetään välittömästi viimeisen sprintin luovutuskatselmuksen (sprint review) ja kehittämiskokouksen (sprint retrospective) jälkeen. Päätöskokouksessa esitellään viimeisen vaatimuslistan valmiustilanne julkistusprojektin päätöshetkellä, kertynyt tekninen velka sekä aikataulu- ja kustannusennusteet siitä, paljonko toteuttamatta jääneiden vaatimusten toteutus nykyisellä toteutustiimillä ja etenemisvauhdilla kestäisi ja maksaisi. Lisäksi viimeisen kehittämiskokouksen tuottamat projektinhallinnalliset lessons learned opetukset kirjataan muistioksi sekä välitetään organisaation projektinhallintamenetelmien kehittämisvastaavien sekä muiden käynnissä olevien projektien tietoon. Vastaavasti projektissa opitut tekniset uudet asiat ja innovaatiot muistioidaan ja välitetään organisaation käytössä olevista teknologioista ja arkkitehtuurista vastaavien henkilöiden sekä muiden käynnissä olevien projektien tietoon. 52

54 4.5 Sprinttien aloitus, toteutus, ohjaus ja päätös Yhteenvetokaavio Seuraava kaavio kuvastaa sprintin aloitusta, toteutusta, ohjausta sekä päätöstä karkealla tasolla. Tarkemmat ohjeet eri vaiheita varten on esitetty seuraavissa kappaleissa. Aloitusvaiheen johtaminen: 1. Vaatimusten ottaminen sprintissä toteutettaviksi 2. Sprintin tehtävälistan teko ja tehtävien työmääräarvioiden laadinta Toteutusvaihe: - ihmisten päivittäisjohtaminen ja daily scrumit - tiiminvetäjien kokoukset pari kertaa viikossa Vaatimuksia koskevien Päivitetty tehtävälista toteutusten hyväksymiset Systemaattinen ohjaus viikkopalavereissa - sprintin valmiusasteen laskenta - vaatimusten (back-log itemien) hyväksyminen - riskinhallintatehtävien perustaminen - ongelmanhallintatehtävien perustaminen Sprintin päättäminen 1. Final sprint review 2. Sprint retrospective 3. Toteuttamattomien vaatimusten sekä teknisen velan tarkennettu työmääräarvio Sprintin aloitus Sprintiksi määritellään CPM:ssä joukko tehtäviä, jotka toteutustiimi suorittaa 4 viikon mittaisen ennalta asetetun määräajan kuluessa. Tehtävien välillä oletetaan olevan varsin vähän ajallisia riippuvuuksia siten, että tehtävälistan tehtävät voidaan suorittaa lähes missä järjestyksessä tahansa. Sprintit aloitetaan projektipäällikön johtamalla sprintin suunnittelukokouksella (sprint planning meeting), johon osallistuu jokaisesta toteutustiimistä scrum master, tiiminvetäjä tai työmäärien arviointiin erikoistunt asiantuntija. Suunnittelukokouksessa otetaan tarkasteluun projektitoteutusta koskeva vaatimusluettelo sekä valitaan siitä toteutettavaksi joukko kaikkein kriittisimpiä ja kiireellisimpiä vaatimuksia, joiden toteutusvastuu samalla alustavasti jaetaan toteutustiimeittäin. Tätä valintaa tehtäessä on huomiotava ketterän projektin alussa tehdyt vaatimuksia koskevat työmääräarviot (hyötypistearviot). Lisäksi on huomioitava projektin aiempien sprinttien aikana laskettu etenemisnopeus eli se, paljonko hyötypisteitä projektiryhmä on tähän mennessä keskimäärin saanut toteutettua sprinttiä kohden. Aikaisempi etenemisnopeus rajoittaa sitä, kuinka paljon vaatimuksia alkavan sprintin vastuulle kannattaa laittaa. Välittömästi sen jälkeen kukin tiimi pitää sisäisen tehtävälistan laadintatyöpajan, jonka alussa tarkistetaan, voiko tiimi ottaa vastuulleen sille suunnitellut vaatimukset sprintin 53

55 aikana toteutettaviksi vai onko työmääräarvioita koskeva näkemys päivittynyt niin paljon, että toteutuslistalta pitää poistaa jotain tai sinne pitää lisätä jotain. Tämän jälkeen tiimi muodostaa itselleen kattavan tehtävälistan, jonka toteutus samalla varmistaa, että kaikki sprintille otetut vaatimukset tulevat toteutettua. Tehtävälistaa muodostettaessa yhdenkään tehtävän kesto ei saisi nousta yli viiden päivän, ellei toteuttajaksi valita keskimääräistä selvästi kokeneempaa ja luotettavampaa henkilöä. Tehtävälistan ylläpito voidaan toteuttaa joko ketteriin projekteihin erikoistuneilla työkaluilla (esim. Scrumworks) tai yleiskäyttöisillä tehtävlistan hallintaohjelmilla (esim. Jira). Jotta sprintin kokonaisvalmiusastetta olisi mahdollista seurata, tulee tehtävien suunnittelutyöpajan aikana myös kirjata ylös kunkin tehtävän työmääräarvio Sprintin toteutus sekä päivittäisjohtaminen Toteutusvaihetta johdetaan joka päivittäisillä tiimipalavereilla (daily scrum) sekä pari kertaa viikossa toistuvilla tiiminvetäjien kokouksilla (scrum of scrum). Tiimipalaveri (daily scrum) on tiiminvetäjän ohjaama tai fasilitoima minuutin mittainen päivittäinen kokous, jossa jokainen tiimin jäsen vuorotellen ja hyvin nopeasti kertoo - valmiiksi saamansa tehtävät (jotka viimeistään tässä vaiheessa kirjataan valmiiksi tehtävälistaan) - aloittamansa tehtävät (joiden vastuuhenkilöksi hän on merkinnyt itsensä tehtävälistaan) - kohtaamansa ongelmat, riskit ja hidasteet, joiden ratkomiseen hän tarvitsee tiiminvetäjän tai jonkun muun asiantuntijan apua Mikäli tiimin jäsenet sijaitsevat hajautetusti useilla eri paikkakunnilla, tiimipalveri pidetään Lyncillä, Skypellä tai muulla telekonferenssi- ja chat-toiminnon sisältävällä työkalulla siten, että kukin tiimin jäsen raportoi yllä mainitut kolme asiaa omalla vuorollaan yhtenä ainoana (etukäteen valmisteltuna) chat-viestinä. Tästä menettelystä on erityisen suurta apua, jos toteutustiimiin kuuluu jäseniä Suomesta, Intiasta, Ranskasta, Kiinasta yms. maista siten, että englannin kielen erilaiset aksentit ja murteet vaikeuttavat olennaisesti tiiminjäsenten välistä kommunikaatiota. Kun tiimin jäsenet ovat kertoneet oman tilanteensa 10 minuutissa, kokouksen osallistujat saavat palata takaisin töihinsä lukuun ottamatta tiiminvetäjää sekä niitä henkilöitä, jotka ovat raportoineet ongelmia, riskejä tai hidasteita tai jotka haluavat vapaaehtoisesti jäädä tiimipalaverin jatkoille auttamaan edellä mainittujen ongelmien ratkomisessa minuutin ajan. Tiimipalaverin jatko-osuuden aikana tulisi varmistaa, että jokaiseen ongelmaan löytyy välitöntä apua ja jos ei löydy, ratkaisemattomat ongelma ja riskit kirjataan ylös tehtävälistalle ja asetetaan väliaikaisesti selkeästi nimetyn vastuuhenkilön vastuulle (jos vastuuhenkilöä ei löydy, vastuuhenkilöksi merkitään tiimin vetäjä). 54

56 Tiiminvetäjien kokous on pari kertaa viikossa pidettävä kokous, jossa tiimien vetäjät yksitellen esittelevät oman tiiminsä tehtävälistan valmiusasteen sekä ne esiin nousseet ongelmat, riskit ja riippuvuudet, joihin tiiminvetäjä tarvitsee apua ohjausryhmältä, projektin omistajalta tai muilta tiimeiltä. Mikäli kokouksessa ilmenee, että tiimit kykenevät auttamaan tai tukemaan toisiaan ongelmien ratkomisessa, kyseisten tiimien edustajat jäävät heti tiiminvetäjien kokouksen jatkoille pariksi kymmeneksi minuutiksi ongelmia ratkomaan Edistymiskatselmukset, valmiusaste ja tekninen velka Sprinttejä ohjataan osaksi jo tiimikokouksilla ja tiiminvetäjien kokouksilla, mutta ohjauksen keskeisin väline ovat silti viikoittaiset edistymiskatselmukset (weekly review), valmiusastelaskenta sekä teknisen velan kertymistä kuvaavat tarkastelut. Sprintin edistymiskatselmuksessa projektipäällikkö esittelee projektin omistajalle (product ownerille) sprintin valmiusasteen (%), valmistuneet ominaisuudet (jos projektin omistaja haluaa) sekä havaitut ongelmat ja riskit ja niiden ratkaisemiseksi laaditut toimenpide-ehdotukset. Edistymiskatselmuksiin ei kannata kutsua kaikkia projektiryhmän jäseniä eikä yleensä edes monesta tiimistä muodostuvassa projektissa kaikkia tiiminvetäjiä, koska muutoin kokouksiin kuluu liian paljon aikaa viikoittain ja lisäksi on vaarana, että projektin omistaja alkaa mikromanageerata projektiryhmää liikaa pienillä ja yksityiskohtaisilla pyynnöillä. Edistymiskatselmusten tavoitteena on tuottaa selkeitä päätöksiä siitä, minkälaisilla keinoilla sprintin aikatauluongelmia, teknisiä ongelmia, viestintäongelmia, laatuongelmia sekä resurssiongelmia aiotaan ratkoa. (Pelkkä ongelmien seuranta huolestunut ilme kasvoilla ei täytä ohjauksen määritelmää). Tiimikokouksissa, tiiminvetäjien kokouksissa sekä edistymiskatselmuksissa päätetyt ongelmien ratkaisutoimenpiteet kirjataan projektin yhteiselle tehtävälistalle, joka sisältää riskien, ongelmien ja riippuvuuksien hallintaan liittyvät toimenpiteet sekä kaikki ne muut tehtävät, joita ei ole laitettu minkään tiimin tehtävälistalle. Jokaiselle tehtävälle tulee määritellä vastuuhenkilö ja valmistumisen määräpäivä. Mikäli projektin omistaja haluaa projektin menestyvän, hänen tulisi ottaa melko suuri joukko niistä ongelmien ja riskien hallintatoimenpiteistä itselleen, joille ei ole löytynyt vastuuhenkilö tiiminvetäjien kokouksissa. Sprintin valmiusastelaskenta on helppoa, jos käytössä on sellainen tehtävälistan hallintaohjelma, joka summaa automaattisesti kaikkien valmistuneiden tehtävien hyötypisteet (alkuperäiset työmääräarviot) ja toisaalta sprintin kaikkien tehtävien hyötypisteet. Tällöin sprintin valmiusaste saadaan kaavalla Valmiusaste = Valmistuneet hyötypisteet / Tehtävälistan kaikkien tehtävien hyötypisteet Valmiusaste on mahdollista laskea myös tarkemmin, laskien kaikille käynnissä oleville tehtävälle tehtävän toteutuneisiin ja jäljellä oleviin työtunteihin perustuva Earned value sekä jakamalla sen jälkeen kaikkien tehtävien Earned valueiden summa toteutuneiden työmäärien ja jäljellä olevien työmäärien summalla. Tämä on kuitenkin hieman liioittelua, varsinkin, jos sprintin tehtävälista on perustettu CPM:n ohjeiden mukaisesti 55

57 siten, että tehtävien kestoaika on korkeintaan 4 työpäivää: Kun sprintti koostuu sopivan pienistä tehtävistä, sprintin etenemistä kannattaa seurata vain valmistuneiden tehtävien tuottamat hyötypisteet huomioiden. Valmiusaste sinänsä kertoo jo jonkin verran siitä, tuleeko sprintti saavuttamaan asetetut tavoitteet annetun aikataulun puitteissa. Jos esimerkiksi sprintin kestoaika on 4 viikkoa ja aikaa on kulunut 2 viikkoa, ei 30% valmiusaste lupaa hyvää. Tarkemman näkemyksen antamiseksi projektipäällikkö voi laskea tiimin etenemisvauhdin Toteutuneiden työtuntien määrä Etenemisvauhti = Toteutuneiden päivien määrä jossa toteutuneiden työtuntien määrä tarkoittaa käynnissä olevan sprintin aikana sprintin tehtäville kodistuneiden työtuntien määrää ja toteutuneiden päivien määrä sitä, kuinka monta päivää sprintti on ollut käynnissä. Tämän jälkeen voidaan laskea skenaario sille, kuinka monta päivää kestäisi kaikkien sprintin tehtävien toteutus Valmistumattomien tehtävien työmääräarvioiden summa Kesto = Etenemisvauhti ja tältä pohjalta voidaan laskea ennuste sprintin valmistumispäivämäärälle olettaen, että kaikki tehtävät tehdään valmiiksi asti. Valmistumispäivä = Nykypäivä + jäljellä oleva kesto Valmistumispäivää koskevan ennusteen täsmentämiseksi on syytä ottaa edistymiskatselmuksissa tarkasteluun myös se tekninen velka, joka joka sprintin aikana on kertymässä. Tekninen velka tarkoittaa niitä pieniä teknisiä ongelmia ja puutteita, jotka on ratkaistu väliaikaisilla quick and dirty -ratkaisuilla ja joiden tuomia haittoja asiakas ei luultavasti heti huomaa, mutta jotka silti olisi syytä korjata myöhemmässä vaiheessa. Projektipäällikön tulee varmistaa, että teknisen velan korjaustehtävät kirjataan ylös sprintin tehtävälistalle uusiksi tehtäviksi jolloin ne heikentävät sprintin valmiusastetta tai vaihtoehtoisesti erilliselle teknisen velan seurantalistalle, jolloin tekninen velka on erikseen kerrottava projektin omistajalle edistymiskatselmuksissa Sprintin päätös eli luovutuskatselmus ja toimintatapojen kehittämistyöpaja Kun sprintille varattu aika päättyy (tai kaikki sprintin tehtävät on tehty), siirrytään sprintin päätösvaiheeseen, joka muodostuu luovutuskatselmuksesta sekä kehittämistyöpajasta. Luovutuskatselmukseen (sprint review) osallistuvat kaikki tiimin jäsenet, projektipäällikkö sekä projektin omistaja (product owner). Mikäli projektilla on kytkentöjä muihin projekteihin, luovutuskatselmukseen kannattaa kutsua myös keskeisten sidosprojektien edustajat. Tämä on tärkeää erityisesti silloin, kun toteutetaan järjestelmä- 56

58 integraatioprojektia, johon osallistuu useita eri toimittajia ja alihankkijoita, joiden tuotteet ja ohjelmat pitäisi saada toimimaan virheettömästi yhteen. Luovutuskatselmuksen alussa projektipäällikkö esittelee projektin omistajalle ja sidosryhmille projektin testitulokset (minuutti), dokumentaatiota koskevat katselmustulokset ja katselmusten pohjalta tehdyt korjaukset (minuutti) sekä syntynyttä teknistä velkaa koskevat kirjaukset (minuutti). Sen jälkeen projektin omistaja voi paneutua näihin aiheisiin syvemmin tai siirtyä katsomaan demonstraatiota, jossa hänelle esitellään valmistuneet tuotokset (back-log items). Testitulosten, katselmustulosten ja teknisen velan perusteella projektin omistaja joko hyväksyy tai hylkää esitellyt tuotokset (backlog items). Hän voi halutessaan myös hylätä koko sprintin tuotokset. Luovutuskatselmuksen valmistelu saattaa olla suuritöinen tehtävä, koska luovutettavien tuotosten testaus saattaa edellyttää manuaalista reggressiotestausta sekä automaattisten testitulosten tulkintaa (yhteensä jopa 5-20 tuntia). Dokumentaation katselmuksiin puolestaan voi kulua parin eri henkilön aikaa pari tuntia. Lisäksi projektipäällikön tulee jo ennen luovutuskatselmusta laskea myös projektin kokonaisvalmiusaste sekä erilaisia kustannus-, aikataulu- ja scope-ennusteita, mikäli sprintti on osa laajempaa ketterästi toteutettua projektia. Nämä valmistelutoimenpiteet vaativat projektipäälliköltä pari tuntia. Kun näihin tuntimääriin lisätään vielä itse luovutuskatselmuksen työmäärä tilanteessa, jossa 15-henkisen projektiryhmän kaikki jäsenet osallistuvat 2 tuntia kestävään luovutuskatselmukseen, saadaan sprintin päätöskustannuksiksi helposti jopa 60 tuntia. Jos kyseessä on projektitoimittajan tuntilaskutuksella järjestämä tiimi, sprintin päätöskustannukset nousevat helposti lähelle 5000 euroa. Tämän vuoksi on tärkeää, että sprinttien pituutta ei lyhennetä alle 4 viikon, jotta sprintin päätöskustannuksista ei synny liikaa overheadia. Toisaalta on myös tärkeää, ettei sprintin luovutuskatselmusta karsita liian pienen osanottajajoukon tilaisuudeksi, koska toteutustiimin motivaation kannalta on tärkeää demonstroida oman työnsä tulokset sprintin asiakkaille ja sidosryhmille. Toimintatapojen kehittämistyöpaja (Sprint Retrospective) on 1,5 2 tuntia kestävä kokous, joka pidetään sprintin lopussa ja johon osallistuu koko projektiryhmä. Kokouksen tavoitteena on selvittää mitkä työmenettelyt ja toimintatavat ovat olleet niin hyviä, että niitä kannattaisi mainostaa myös muille projektiorganisaation projekteille sekä organisaation projektinhallinnan kehittämisestä vastaavalle laatupäällikölle tai projektinhallintaprosessin omistajalle. Toisena tavoitteena on miettiä, millä toteutuksen osa-alueilla projektiryhmän pitäisi kehittää toimintatapoja etenemisvauhdin nostamiseksi tai teknisen velan syntymisen ehkäisemiseksi. Toimintatapojen kehittämistyöpajalla ei ole kuitenkaan valtuuksia tehdä muutoksia projektin ohjausmenettelyihin, joita ovat mm. valmiusasteen ja etenemisnopeuden laskenta sekä teknisen velan käsittely. Tämä on tärkeää tehdä selväksi projektiryhmän jäsenille, koska ketteristä menetelmistä innostuneilla scrum-mastereilla ja projektiryhmillä on muutoin taipumus poistaa sprint retrospective kokouksissa lähes kaikki projektia koskevat ohjausmenettelyt koska ohjaus tuntuu heistä turhalta byrokratialta. 57

59 4.5.6 Miksi sprintit kestävät 4 viikkoa ja miksi ne jakautuvat neljännessprintteihin? Hyvin johdetut sprintit alkavat suunnittelukokouksella (sprint planning meeting) ja ne päätetään luovutuskatselmuksella sekä toimintatapojen kehittämistyöpajalla. Kaikkiin näihin kokouksiin osallistuvat kaikki projektiryhmän jäsenet. Mikäli projektiryhmässä on 20 jäsentä ja mikäli kukin em. kokouksista kestää 2 tuntia, pelkkiin pakollisiin kokouksiin kuluu tiimiltä aikaa 120 tuntia. Tämän lisäksi luovutuskatselmus vaatii usein huolellisia testaus-, katselmus- yms. valmistelutoimenpiteitä, joihin kuluu helposti yli 20 tuntia työaikaa. Tämä tarkoittaa sitä, että sprintin aloituksesta ja lopettamisesta aiheutuvat pakolliset overhead kustannukset voivat nousta jopa 140 tuntiin, joka merkitsee rahassa mitattuna yli euron kustannuksia per sprintti (olettaen, että tunnin hinta on 80 ). Tämän vuoksi on tärkeää, että sprintin pituutta ei lyhennetä esimerkiksi 1-2 viikkoon. Sen sijaan, on syytä toteuttaa sprinttien lyhytjänteisempi ohjaus viikkotasolla pidettävillä edistymiskatselmuksilla, jotka ovat luovutuskatselmuksen kevennettyjä versioita ja joihin ei osallistu niin paljon henkilöitä Sprinttien luova käyttö ilman kytkentää tuotejulkistuksiin Yleensä on ajatuksena, että joukko peräkkäisiä sprinttejä muodostaa tuotejulkistuksen, jonka valmistuminen päättää sprinteistä muodostuvan tuotejulkistusprojektin tai Scrumprojektin. Sprinttejä on kuitenkin mahdollista käyttää myös Gantt-kaavioiden avulla johdettujen isompien projektien apuna tai osavaiheina. On esimerkiksi mahdollista sopia, että isohko projekti alkaa tasan neljä viikkoa kestävällä määrittelysprintillä, jonka aikana laaditaan projektitoteutusta ohjaava vaatimusluettelo sekä merkitään vaatimuksille alustavat työmääräarviot. Toisena esimerkkinä sprinttien käytöstä on neljän viikon mittainen protoiluvaihe, jonka aikana tuotetaan ensimmäinen proof of concept, jolla varmistutaan valitun teknologian soveltuvuudesta. Kolmantena esimerkkinä voi olla vaikkapa neljän viikon mittainen hyväksymistestaus, jonka aikana projektilla tuotettua järjestelmää testataan tuotanto-olosuhteissa sellaisessa tilanteessa, jossa varsinaisen toteutusvaiheen aikana tuotanto-olosuhteissa testaaminen on ollut syystä tai toisesta mahdotonta. Sprinttien käyttö opettaa projektiorganisaatiolle tiukkoihin 4 viikon mittaisiin määräaikoihin sopeutumisen kulttuuria sekä sitä, että isotkin projektit on mahdollista jakaa 4 viikon mittaisiin itsenäisiin sprintteihin, joista osa etenee peräkkäin ja osa taas rinnakkain. Etuna on myös se, että sprinttien edistymiselle on olemassa hyvät seurantamenetelmät, jotka eivät lainkaan vaadi Gantt-kaavioiden laskemista ja päivittämistä. 58

60 5 Tehtävien, tikettien ja tehtäväsalkkujen johtaminen 5.1 Aihepiirin yleiskuva Tässä luvussa ohjeistataan ne tehtävät, tiketit ja tehtäväsalkut, jotka on kuvattu seuraavaan malliin punaisella korostuksella. Iso ja monimutkainen projekti sekä sen jakautuminen erilaisiin ja eri tavoilla ohjattuihin osiin Ketterä kehittämisprojekti (tai useampia) Gantt- Sprint1 Julkistus 1 Sprint2 Sprint 3-N Julkistukset 2-N Tehtäväsalkku projekti(t) ja niiden päätason tehtävät Yksittäiset isot tehtävät Paljon atomistisia tehtäviä Paljon tikettejä 5.2 Yksittäisen ison tehtävän johtaminen Yksittäisiksi isoiksi tehtäviksi määritellään sellaiset tehtävät, jotka ovat kestoajaltaan pitkiä, mutta joiden edistyminen on todennäköisesti varsin tasaista. Esimerkkinä tällaisesta tehtävästä voi olla vaikkapa viisi tuntia kestävä tietoliikennekytkentä, joka täytyy toteuttaa erikseen noin 400:ssa eri kiinteistössä. Koska etenemisvauhti oletetaan tasaiseksi, ei tehtävää tarvitse välttämättä jakaa alemman tason osatehtäviin varsinkaan, jos tehtävä on delegoitu erillisen toimittajayrityksen vastuulle ja jos toimittaja ottaa vastuun siitä, että tehtävä etenee sovitulla toteutusvauhdilla. Yksittäisten isojen tehtävien toteutusta ohjataan valmiusasteen ja edistymisvauhdin laskennalla sekä etenemisvauhdista johdetulla tehtävän jäljellä olevaa kestoaikaa koskevalla laskelmalla (ks. luku 3.3). Mikäli tehtävän etenemisvauhti on liian hidas, projektipäällikön ja ohjausryhmän tehtävänä on antaa tehtävälle lisää resursseja tai vaatia, että tehtävän toteutuksesta vastaava toimittaja hankkii lisää resursseja sekä esittää uuden realistisen aikatauluarvion. 59

61 5.3 Atomististen tehtävien johtaminen Miten atomistiset tehtävät syntyvät erilaisille tehtävälistoille? Projektinhallintakirjallisuus antaa projektien johtamisesta monesti hyvin viisaan ja järjestelmällisen vaikutelman: Tehtävät kirjataan tehtävärakenteeseen ja sen jälkeen tehtävien valmiutta seurataan systemaattisesti viikoittain. Totuus on kuitenkin toisenlainen eli projektinhallintaohjelman tehtävärakenteella ja Gantt-kaaviolla hallitaan tosiasiassa vain pieni osa projektin tehtävistä. Loput tehtävistä syntyvät monilla eri tavoilla ja niitä hallitaan (tai jätetään hallitsematta) monia eri työkaluja ja menetelmiä käyttäen. Seuraavassa on kuvattu projektipäällikön kaikki erilaiset tehtävälistat sellaisessa varsin yleisessä tilanteessa, jossa atomististen tehtävien hallinta on pahasti puutteellista: Kokouksissa sovitut tehtävät: Projektilla on viikoittainen viikkopalaveri ja sen lisäksi projektipäällikön alaisuudessa toimii viisi tiimiä, joilla kullakin on omat viikkopalaverinsa. Lisäksi projektin ohjausryhmä kokoontuu joka neljäs viikko. Näistä palavereista syntyy yhteensä 6,25 kokousmuistiota per viikko. Jos projektipäällikkö ja tiiminvetäjät ovat taitamattomia, he eivät osaa puristaa kokouksissa aikaiseksi selkeitä toinenpide-ehdotuksia, jotka vastuutetaan selkeästi nimettyjen henkilöiden vastuulle. Jos kokousten vetäjät ovat huolimattomia, kokouksissa sovitut tehtävät kirjataan korvien väliin tai ne kirjoitetaan käsin erilaisille lippusille, lappusille ja ruutuvihkoihin. Jos projektipäällikkö sen sijaan on huolellinen ja ammattitaitoinen, hän tuottaa jokaisessa kokouksessa noin uutta tehtävää jokaista kokoukseen käytettyä tuntia kohden. Nämä uudet (atomistiset) tehtävät projektipäällikkö kirjaa joko kokousmuistion lopussa olevaan avoimet tehtävät taulukkoon tai vaihtoehtoisesti johonkin Jiran tai Sharepointin tyyppiseen atomististen tehtävien hallintajärjestelmään. Kolmantena vaihtoehtona on tehtävien kirjaaminen Excel-taulukkoon, josta projektipäällikkö voi aina tilannekohtaisesti suodattaa näkyviin vain kyseisen kokouksen tai tiimin vastuulla olevat tehtävät tai hän voi lajitella tehtävät tekijäkohtaiseen järjestykseen tehtävien seurannan helpottamiseksi. Riskien ja ongelmien hallintatehtävät: Pätevään projektinhallintaan kuuluu systemaattinen riskien ja ongelmien hallinta, joka muodostuu kolmesta päävaiheesta: 1) Riskin tai ongelman analysointi, 2) lyhyen ja yleisluontoisen hallintasuunnitelman tekeminen sekä 3) atomististen tehtävien käynnistäminen yleisluontoisen hallintasuunnitelman toteuttamiseksi (ks. luku 5.3). Suullisesti sovitut sekä spontaanisti mieleen juolahtaneet tehtävät ovat monesti sellaisia, että tehtävän vastuuhenkilö joko yrittää muistaa tehtävän ilman tehtävän kirjaamista ylös mihinkään tai vaihtoehtoisesti merkitsee ne omaan Outlookin tehtävlistaansa taikka oman matkapuhelimensa tehtävälistaan jos hän ei ole sillä hetkellä Outlookin ääressä. Näiden tehtävien joukossa on yleensä myös projektiin kuulumattomia tehtäviä tyyliin tee veroilmoitus tai osta uudet kesärenkaat. Sähköpostitse saapuvat tehtävät ovat monesti varsin hankalia, koska sähköpostit saattavat olla huonosti otsikoituja ja samassa sähköpostissa saattaa olla useita eri tehtäviä. Tämän lisäksi sähköpostien osalta on joskus vaikea ratkaista, vaatiiko sähköpostin lähettäjän kuvaama ongelma ratkaisua sinulta vai joltain muulta vastaanottajalta ja 60

62 vaatiiko se ratkaisua nyt heti vai joskus myöhemmin. Sähköpostitse saapuvien tehtävien osalta suositeltava ratkaisuehdotus on se, että - tehtävät toteutetaan välittömästi sähköpostin lukemisen yhteydessä tai - tehtäviä sisältävät sähköpostit raahataan Outlookin tehtävälistalle ja niille annetaan selkeä prioriteetti sekä tehtävää paremmin kuvaava nimi - tai vaihtoehtoisesti tehtävän sisältävä sähköposti merkitään punaisella lipulla (ja sille annetaan kuvaavampi nimi). Palvelupyyntöjen hallintaohjelmat saattavat lähettää projektiryhmän jäsenille tehtäväpyyntöjä myös silloin, vaikka henkilö olisi varattu projektin käyttöön % panoksella. Tällöin kyseessä on usein se, että henkilö on tukiryhmän jäsenenä tai muussa tukiroolissa jollekin toiselle projektille, joka ajoittain tarvitsee hänen osaamistaan. Kyseessä voi olla ongelmatilanteen ratkaisu (incident) tai palvelupyyntö jotain sellaista erityisosaamista koskien, joka on organisaatiossa harvinaista (ja jota kyseinen toinen projekti ei voi saada omasta piiristään). On myös mahdollista, että kyseessä on iso projekti, jonka toimituseristä osa on jo viety tuotantokäyttöön siten, että projektiryhmän jäsenillä on näihin toimituseriin liittyen ylläpitotehtäviä. Tällöin tukipyynnöt saapuvat usein asiantuntijoille palvelupyyntöjen hallintaohjelman kautta (tai toisinaan myös puhelinsoittojen tai sähköpostien muodossa). Viestintäsuunnitelma on projektisuunnitelmaan sisältyvä tai sen liitteeksi tuleva dokumentti, jonka tulisi kuvata viestinnän kohderyhmät, vastuuhenkilöt sekä toimenpiteet ja aikataulut. Tämä tarkoittaa sitä, että joissain tilanteissa viestintäsuunnitelma tai sen liitteenä oleva Excel-tiedosto sisältää joukon viestintään liittyviä tehtäviä, jotka projektipäällikön ja muiden vastuuhenkilöiden on muistettava. Dokumentaatiosuunnitelma sekä muut projektin tuotosten seurantalistat (deliverables list) ovat tyypillisesti Excel-dokumentteja, joihin on merkitty kunkin projektissa toimitettavan dokumentin tai muun tuotoksen nimi sekä vastuuhenkilö. Nämä dokumentit ovat kukin eräänlaisia tehtäviä, koska joidenkin nimettyjen vastuuhenkilöiden pitäisi kirjottaa, katselmoida ja hyväksyä ne. Dokumentaatiosuunnitelmiin merkitään yleensä dokumentin tms. tuotoksen tila sekä se, mikä seuraava toimenpide Katselmuspöytäkirjat ja kommentit ovat määrämuotoisia pöytäkirjoja tai hieman vapaamuotoisempia kommentteja siitä, millä tavoin katselmoitua kohdetta pitäisi parantaa tai korjata. Nämä pöytäkirjat ja kommentit sisältävät selkeämmin tai epäselvemmin ilmaistuja tehtäviä, jotka dokumentin omistajan tulisi huomioida dokumentin viimeistelyssä. Virhekuvaukset ovat projektitoteteutuksen testaajien taikka automaattisten testaustyökalujen tuottamia raportteja tai kuvauksia, jotka edellyttävät virheen korjaamista. Ohjelmistoprojekteissa virhekuvaukset ylläpidetään monesti aivan eri työkalussa kuin projektiin liittyvät muut tehtävät. Silti, jokainen virhekuvaus on epäsuora tehtävän toimeksianto: Virheet pitää korjata. 61

63 5.3.2 Atomististen tehtävien ohjauksen tavoitteita ja suosituksia Ihannetilanteessa kaikki atomistiset tehtävät tallennettaisiin samaan paikkaan, jota kutsutaan toistaiseksi nimellä Jira, koska Jira on yksi varteenotettava vaihtoehto atomististen tehtävien tallennuspaikaksi. Muita vaihtoehtoja ovat mm. Sharepoint, Quality Center, MS Project Server sekä MS Service Managerin tyyppiset tikettien ohjausjärjestelmät. Kun tehtävät on tallennettu Jiraan, projektipäällikön tai tiiminvetäjien on mahdollista systemaattisesti varmistaa, että - jokaiselle tehtävälle on nimetty vastuuhenkilö tai vaihtoehtoisesti on sovittu tiimin kanssa, minkälaisilla periaatteilla kukin tiimin jäsen ottaa vastuuttamattomia tehtäviä omalle toteutusvastuulleen - jokainen tehtävä on jollain tavoin edistynyt viimeisen viikon aikana - tehtäville, joiden toteutus on kestänyt yli viikon, on määritelty jokin vastuuhenkilön hyväksymä selkeä deadline Tehtävien seurannan ja tiedottamisen kannalta olisi myös tärkeää ottaa jokaista viikkopalaveria varten snapshot eli tilannekaappaus siitä, mitkä kyseisen kokouksen vastuualueeseen kuuluvat tehtävät ovat valmistuneet viimeisen viikon aikana ja mitkä vielä ovat auki. Viimeisen viikon aikana valmistuneiden tehtävien snapshot on tärkeä siksi, että sen avulla projektipäällikkö näkee, saavatko tiimit edistymään tehtävälistalle asetettuja tehtäviä vai onko tehtävälistalla taipumus vain kasvaa ja kasvaa. Vaikka kaikkien tehtävien saaminen samaan Jiraan on tavoittelemisen arvoista, se on silti usein hieman epärealistista, koska Outlookin tehtävälistaan, sähköposteihin, katselmuspöytäkirjoihin, viestintäsuunnitelmiin, riskilistoihin yms. paikkoihin sisältyvien tehtävien kokoaminen samaan paikkaan vaatii projektipäälliköltä vaivannäköä ja projektiryhmän jäseniltä uuden työskentelytavan opettelemista. Tämän vuoksi realistisempi lähestymistapa on se, että vain tietyt projektiin kiinteästi liittyvät tehtävät kirjattaisiin Jiraan seurannan helpottamiseksi ja loppujen sallitaan olla sekalaisiin paikkoihin tallennettuina. Näitä kiinteästi projektiin liittyviä tehtäviä ovat mm. - Riskinhallintatehtävät ja ongelmanhallintatehtävät - Katselmoitujen dokumenttien ym. tuotosten korjaustehtävät - Viestintäsuunnitelmassa alustavasti kuvattujen viestintätoimenpiteiden täsmennetyt tehtäväkuvaukset Edellä kuvattujen atomististen tehtävien kirjaaminen Jiraan tarjoaa samalla mahdollisuuden myös ohjausryhmätason seurannan tehostamiseen: Esimerkiksi kunkin riskin osalta voidaan projektinhallintaohjelmaan merkitä, kuinka monta riskinhallintatehtävää on aloitettu ja kuinka moni niistä on valmistunut. Tällä tavoin ohjausryhmä pääsee eroon tilanteesta, jossa se seuraa riskejä passiivisesti ilman mahdollisuutta sen kontrollointiin, tehdäänkö riskien hallitsemiseksi todella jotain. Mikäli projektiryhmään tai ohjausryhmään kuuluu sellaisia ulkopuolisia tahoja, joille ei voida avata pääsyä projektin Jiraan, projektipäällikön on lähetettävä tehtävien vastuuhenkilöille henkilönimen mukaan lajiteltu tehtävälista esimerkiksi PDF-muodossa 62

64 pari kertaa viikossa. Mikäli tämä menettely otetaan käyttöön, voidaan jakeluun ottaa mukaan myös organisaation sisäiset vastaanottajat (joilla olisi pääsy Jiraan ), koska tehtävien karhuaminen edistää niiden toteuttamista ja lisäksi karhuttujen tehtävien lista tarjoaa tiimien jäsenille mahdollisuuden nähdä, mitä muut ovat tekemässä. 5.4 Vesiputoustehtävien ohjaus tiketeillä ja ITIL:illä Määrämuotoiset vesiputoukset, ITIL ja Lean Vesiputoustehtäviä on kahta loogisesti erilaista lajia, jotka ovat määrämuotoiset ja vapaamuotoiset vesiputoustehtävät. Määrämuotoisissa vesiputoustehtävissä tehtävän tyyppi voi olla esimerkiksi Muutospyyntö, Pienkehitysprojekti tai Laitetilaus ja tällöin tehtävän tyyppi ohjaa sitä, minkälaisten vaiheiden kautta tehtävän toteutus etenee. Määrämuotoisten vesiputoustehtävien etenemisvaiheiden suunnitteluun kannattaa hakea vihjeitä ITIL:istä, joka on IT-alan palveluiden toteutukseen ja organisointiin tarkoitettu ohjeisto. Muutospyynnöt ja pienkehitysprojektit etenevät yleensä perinteisen vesiputousmallin mukaisesti siten, että tehtävän toteutus jakautuu minimitasolla: - Määrittelyyn - Suunnitteluun - Toteutukseen - Testaukseen - ja käyttöönottoon Tarkemmalle tasolle vietynä malli voi sisältää tuplasti enemmän vaiheita, mutta tämä ei silti tee mallista välttämättä byrokraattista tai kankeaa, mikäli vaiheiden yli hyppääminen sekä myöhemmästä vaiheesta aikaisempaan paluu sallitaan. Alla on esimerkki tarkemmalle tasolle viedystä pienoisprojektien ohjaukseen tarkoitetusta vesiputousmallista: - Ideointi - Määrittely - Työmääräarviointi - Priorisointi ja toteuttamispäätös - Suunnittelu - Toteutus - Testaus - Käyttöönotto - Hyväksyntä Kun projekteja ohjataan vesiputousmaisesti etenevien tehtävien avulla, on tärkeää täsmentää se, miten vastuu tehtävästä ja sitä kuvaavasta tiketistä siirtyy tehtävän 63

65 asiakkaan, tehtävän toteuttajan ja tehtävän ohjauksesta vastaavan projektipäällikön tai palvelupäällikön välillä. Tämä edellyttää em. roolien ja niiden vastuiden tarkempaa määrittelyä: Asiakkaan vastuulla on yleensä - tehtäväideoiden keruu ja täsmentäminen sekä tikettijärjestelmään kirjaaminen - toteutusluvan antaminen vesiputoustehtäville työmääräarvion valmistumisen jälkeen - käyttöönottoluvan antaminen tehtävän tuotoksille testausvaiheen jälkeen (sekä mahdollisesti osallistuminen testaukseen) Toteuttajan vastuulla on yleensä - määrittelyjen täsmentäminen sekä työmääräarvion tekeminen - projektitoimituksen toteutus ja testaus (mahdollisesti yhdessä asiakkaan kanssa) - määrittelyihin, työmääräarvioihin, toteutukseen ja testaukseen kuluneen työajan raportointi tikettijärjestelmään (ellei järjestelmä kirjaa työaikaa automaattisesti) - määrittelyjä, työmääräarviota, toteutusta tai testausta koskevan vastuun siirto ennalta sovittujen pelinsääntöjen mukaan jolle kulle muulle toteuttajalle (jos tarve vaatii) Palvelupäällikön tai projektipäällikön vastuulla voi olla joitain seuraavista tehtävistä - projekti-ideoiden tarkastaminen sekä antaminen jollekin toteuttajalle määrittelyä ja työmääräarviota varten - määrittelyjen ja työmääräarvioiden tarkastaminen sekä tiketin siirto asiakkaalle toteuttamisluvan antamista varten - testaustulosten tarkastaminen ja tiketin siirto asiakkaalle käyttöönottoluvan antamista varten - tikettien valvonta sen varmistamiseksi, että minkään tiketin toteutus ei jumiudu ja että tikettejä ei delegoida sellaisille henkilöille, jotka eivät aktiivisesti aio tehdä jotain projektin valmistumisen edistämiseksi. Näiden roolien lisäksi on mahdollista, että vesiputoustehtäviä varten nimetään erikseen määrittelijä tai pääsuunnittelija, joka erikoistuu pelkkiin määrittelyihin ja työmääräarvioihin sekä mahdollisesti testaaja, joka erikoistuu testaukseen. Useiden pitkälle erikoistuneiden roolien määrittely sekä vesiputouksen jakaminen moniin eri henkilöiden toteuttamiin vaiheisiin voi johtaa tilanteisiin, joissa tikettien siirtyminen erityisasiantuntijalta aiheuttaa huomattavia viiveitä siksi, että seuraava vastuuhenkilö ei heti huomaa tiketin siirtymistä hänen vastuulleen tai vastuuhenkilö on ylikuormitettu, sairas, koulutuksessa tms. Pitkissä tehtäväketjuissa viipeet kertautuvat moninkertaisiksi ja on mahdollista, että kokonaistyömäärältään seitsemän tuntia kestävän tehtävän suoritus vaatiikin seitsemän viikkoa kalenteriaikaa. (Tämä on todellinen esimerkki IT-alalta tilanteessa, jossa asiakas haluaa tilata palveluorganisaatiolta uuden serverin). 64

66 Tämänkaltaisten viipeiden torjuntaa pidetään erityisen tärkeänä mm. Lean-johtamisfilosofiassa (ks. luku 2.4.8). Viipeiden torjumiseksi tulisi välttää tikettien käsittelyvastuun jakamista liian monelle eri roolille, liian moniportaisen vesiputouksen tekemistä sekä sitä, että palvelupäällikkö liian vahvasti mikromanageeraa sitä, kuka palvelutiimin jäsenistä toteuttaa mitäkin töitä. On myös pyrittävä siihen, että palvelutiimin jäsenille annetaan valta toteuttaa joitain työ vaiheita ilman, että toteutukselle täytyy erikseen saada lupa palvelupäälliköltä tai asiakkaalta Vapaamuotoisten pienoisvesiputousten johtaminen Jotkut tehtävien ja palvelupyyntöjen hallintajärjestelmät kuten esimerikisi Jira ja Service Manager sallivat sen, että projektipäällikkö tai palvelupäällikkö muodostaa tehtävälistalle vapaamuotoisia vesiputouksia eli toisiaan seuraavista atomistisista tehtävistä muodostuvia ketjuja. Tästä ominaisuudesta on hyötyä silloin, jos usein toistuu tilanteita, joissa projektiryhmä yhdessä toteaa, että - ensin henkilön I pitää tehdä toimenpide X - sen jälkeen henkilö J tekee toimenpiteen Y - ja lopulta henkilö K tekee toimenpiteen Z. Tällöin olisi tärkeää saada kirjattua tehtävien hallintajärjestelmään koko tehtäväketju vastuuhenkilöineen. Muutoin vaarana on se, että tehtävä typistyy pelkäksi atomistiseksi tehtäväksi X, joka epähuomiossa suljetaan projektin viikkopalaverissa ilman, että samalla muistetaan, että tehtävän Y valmistumisen pitäisi käynnistää toimenpiteet Y ja Z. 5.5 Tehtäväsalkun johtaminen Atomistista tehtävistä sekä tiketeistä voidaan muodostaa tehtäväsalkkuja, joita ohjataan Jiran tai Service Managerin tyyppisillä tehtävien ja tikettien hallintaohjelmilla. Kunkin tehtäväsalkun osalta projektipäällikön tulisi seurata salkun kokonaisuutta kuvaavia tunnuslukuja vähintään kerran kuukaudessa. Näitä tunnuslukuja ovat mm. - avattujen tehtävien määrä yhteensä sekä viimeisen kuukauden tai sprintin aikana - valmistuneiden tehtävien määrä yhteensä sekä viimeisen kuukauden/sprintin aikana - valmistuneiden tehtävien tuottamat hyötypisteet (alkuperäiset työmääräarviot) sekä toteutuneet työmäärät (mikäli toteutuneita työmääriä seurataan) - avointen tehtävien määrän muutos viimeisen kuukauden aikana (kasvaako määrä vai pieneneekö se) - avointen tehtävien kokonaismäärä - yli viikon kestäneiden tehtävien osuus kaikista tehtävistä 65

67 Tunnuslukujen avulla projektipäällikkö voi seurata joko koko projektia tai kutakin alaisuudessaan toimivaa tiimiä ja selvittää, onko tiimin työskentelyssä jotain seuraavia melko tyypillisiä ongelmia: 1. Tehtäviä avataan liian vähän eli alle per kuukausi per tiimi, mikä viittaa tehottomiin kokouskäytäntöihin ja siihen, ettei tehtäviä kirjata ylös kunnolla. 2. Tehtäviä syntyy selvästi nopeammalla tahdilla kuin niitä suljetaan, mikä saattaa viitata siihen, että toteutustyöt on huonosti vaiheistettu ja suunniteltu taikka siihen, että projektiryhmällä tai tietyllä tiimillä on liian vähän resursseja projektin tavoitteisiin ja aikatauluihin verrattuna. 3. Tehtäväsalkun kuvaaman sprintin valmiusaste ja etenemisvauhti ovat heikompia kuin pitäisi olla (tämä päättely perustuu valmiusasteen ja etenemisvauhdin laskentaan toteutuneiden hyötypisteiden tai työmäärien pohjalta). 4. Tietyt tiimit ja ketkä henkilöt eivät saa valmiiksi vastuulleen asetettuja tehtäviä. Tämä ongelma voidaan ratkaista siten, että ongelmatiimeille ja ongelmahenkilöille annetaan jatkossa aikaisempaa pienempiä ja lyhytkestoisempia tehtäviä ja lisäksi henkilöiltä vaaditaan tarkemmat työmääräarviot ja valmistumisennusteet kullekin tehtävälle. 66

68 6 Gantt-kaavioiden hyödyntäminen CPM:ssä 6.1 Mille osa-alueille Gantt-kaaviot soveltuvat? Gantt-kaaviot soveltuvat isojen ja monimutkaisten hankkeiden päätason rakenteen kuvaamiseen sekä hankkeen alle sijoittuvien yksittäisten projektien kuvaamiseen tilanteissa, joissa kyseistä projektia on tehtävärakenteen monimutkaisten riippuvuussuhteiden vuoksi vaikeaa tai mahdotonta johtaa ketteränä kehittämishankkeena tai yksittäisenä ketteränä julkistusprojektina. Iso ja monimutkainen hanke sekä sen jakautuminen erilaisiin ja eri tavoilla ohjattuihin osiin Ketterä kehittämishanke (tai useampia) Gantt- Sprint1 Julkistus 1 Sprint2 Sprint 3-N Julkistukset 2-N Tehtäväsalkku projekti(t) ja niiden päätason tehtävät Yksittäiset isot tehtävät Paljon atomistisia tehtäviä Paljon tikettejä Mikäli organisaatiolla on käytössään korkeatasoinen ja kallis Clarityn tyyppinen projektinhallintaohjelma, joka on integroitu saumattomasti organisaation tuntiseurantajärjestelmään, projektipäällikkö voi käyttää Gantt-kaavioita hieman laajemmin ja huolettomammin projektien johtamiseen kuin tilanteessa, jossa organisaatiolla on käytössään vanhasta ja kankea ERP- tai tuntiseurantajärjestelmä, jonne syötetyt tunnit eivät siirry automaattisesti projektinhallintajärjestelmään ja Gantt-kaavioihin. 67

69 6.2 Ison ja monimutkaisen hankkeen johtaminen Gantt-kaavioilla Ganttin menetelmä perustuu tehtävärakenteen suunnitteluun, tehtävien kestoaikojen laskentaan, tehtävien välisten riippuvuuksien määrittelyyn sekä projektin kriittisen polun ja kokonaisaikataulun laskentaan (ks. luku 2.4.1). Myös Gantt-kaavioilla ohjatut hankkeet tulisi aloittaa aiemmin kuvattuja aloitusmenettelyjä noudattaen (ks. luku 4.3.2). Ison ja monimutkaisen hankkeen johtaminen Ganttin menetelmällä on yleensä yksinkertaisempaa kuin yksittäisen projektin ohjaus Gantt-kaavion ja kriittisen polun laskennan avulla. Tämä johtuu siitä, että hankkeen Gantt-kaavioon kuvataan vain noin karkeimman tason tehtävää tai osaprojektia, joiden kunkin aikataulu-, työmäärä- ja kustannusennusteet lasketaan erikseen, hanketason Gantt-kaavion ulkopuolella. Hanketason Gantt on siis kaavio, johon projektipäällikkö tai hankepäällikkö syöttää yleensä manuaalisesti tiedot alemman tason osaprojektien ja tehtävien kestoaikaa koskevista ennusteista. Kun osaprojektien ja tehtävien kestoajat ja riippuvuudet on kuvattu, Gantt-kaavion laskentaohjelma (esim. MS Project) laskee koko hankkeelle uuden ennustetun valmistumispäivän sekä kuvaa samalla sen, mitkä osaprojektit tai tehtävät sijoittuvat hankkeen kriittiselle polulle alku 2012 loppu 2013 alku 2013 loppu 2014 alku 2013 loppu Aloitus AN-laitteen julkistus AN-laitteen sarjatuotanto (vähintään 3000 kpl) AN-ohjelman 1. julkistus Laitteiston ja ohjelman asennus 3000 linja-autoon Back-endin julkistus julkistus Käyttäjäkoulutukset j. 1 AN-ohjelman 2. julkistus Käyttäjäkoulutukset j. 2 Päätös Tuotannossa ilmenevien ongelmien ja virheiden käsittely tikettien avulla 68

70 Jos Gantt-kaavioon uhkaa tulla yli 15 riviä, se ei enää ole havainnollinen. Tämän vuoksi ohjausryhmien on hyödyllistä hahmottaa monimutkaisten hankkeiden kokonaiskuva CPM-menetelmän suosittelemalla tiivistetyllä ja selkeytetyllä hankekaaviolla, jossa kukin looginen tehtäväkokonaisuus omalle rivilleen ja vieläpä siten, että palkkien sisällä on esitetty tekstimuodossa se, mitä palkin etenemisen aikana tapahtuu alku 2012 loppu 2013 alku 2013 loppu 2014 alku 2013 loppu Aloitus Päätös AN-laitejulkistus 1 julkistus AN-ohjelman 1. julkistus AN-laitteen sarjatuotanto (vähintään 3000 kpl) AN-ohjelman 2. julkistus Laitteiston ja AN-ohjelman asennus 3000 ajoneuvoon Infosysteemin 1. julkistus Infosysteemin 2. julkistus Infosysteemin 2. julkistus Back-endin julkistus 1 Back-endin julkistus 2 Uuden toimintatavan 1. julkistus Uuden toimintatavan 2. julkistus Koulutusjakso 1 Koulutusjakso 2 Tuotannossa ilmenevien ongelmien ja virheiden käsittely tikettien avulla Hankekaavio säilyy hallittavana ja käsitettävänä, koska siinä on allekkaisia rivejä alle kymmenen. Havainnollisuutta lisää, että aikataulultaan kriittiset ja/tai kriittisen polun varrelle sijoittuvat palkit varjostetaan punaisella värillä. Jos rivit esitettäisiin perinteisenä Gantt-kaaviona, rivejä tulisi 17, mikä vaikeuttaisi kokonaisuuden hahmottamista. Tämän lisäksi normaaleissa Gantt-kaavioissa kunkin tehtävän selitetekstit sijaitsevat erikseen vasemmassa laidassa, jolloin palkin ja selitteen yhdistäminen toisiinsa on vaikeahkoa (ks. seuraava kuva). 69

71 Kuvausteksti 1 Kuvausteksti 2 Kuvausteksti 3 Kuvausteksti 4 Kuvausteksti 5 Kuvausteksti 6 Kuvausteksti 7 Kuvausteksti 8 Kuvausteksti 9 Kuvausteksti 10 Kuvausteksti 11 Kuvausteksti 12 Kuvausteksti 13 Kuvausteksti 14 Kuvausteksti 15 Kuvausteksti 16 Kuvausteksti 17 Koska markkinoilla ei toistaiseksi ole projektinhallintaohjelmia, jotka mahdollistaisivat CPM:n suosittelemien hankekaavioiden automaattisen laskennan, projektipäälliköt joutuvat käytännössä suorittamaan kriittisen polun laskennan sekä aikatauluennusteet ensin yllä kuvatulla sekavamman näköisellä Gantt-kaaviolla. Tämän jälkeen heidän täytyy manuaalisesti päivittää CPM-järjestelmän suosittelemaa hankekaaviota. Hankekaavion automaattisen laskentaohjelman toteutus ei kuitenkaan olisi kovin hankala tehtävä. Ongelmaksi tulee lähinnä se, että tehtävien kuvaukset eivät aina mahdu palkkien sisään. Tämä ongelma voitaisiin ratkaista siten, että palkkien sisään merkitään lyhyet kuvaukset ja tarkempi kuvaus on saatavilla esimerkiksi viemällä hiiri kyseisen palkin päälle. Määriteltäessä ihanteellista hankekaavion laskenta- ja kuvausohjelmaa, on mielessä pidettävä myös se, että kukin hankkeen osaprojekteista tai tehtävistä on yleensä vastuutettu eri projektipäällikön vastuulle. Tällöin olisi tarkoituksenmukaista, että hankekaavion laskentaohjelma kävisi hakemassa kunkin projektipäällikön osaprojekteittain laatimista Gantt-kaavioista tai Excel-taulukoista tiedot kunkin osaprojektin tai tehtävän ennustetusta jäljellä olevasta kestoajasta sekä ennustetuista jäljellä olevista kustannuksista. Tämä ei ole teknisesti vaikeaa, koska jo nykyisinkin MS Projectin ja Excelin tiedostoihin voidaan hakea syöttötietoja muista MS Projectin ja MS Excelin tiedostoista. 6.3 Projektien ohjaus integroidulla Gantt-ohjausjärjestelmällä eli IGO:lla Integroitu Gantt-ohjausjärjestelmä Integroiduiksi Gantt-ohjausjärjestelmiksi (IGO) määritellään CPM:ssä sellaiset PlanView n ja Clarityn tyyppiset monipuoliset projektinhallintaohjelmat, jotka sisältävät - Gantt-kaavioiden ja kriittisen polun laskentaan perustuvat aikatauluennusteet - Koko projektiorganisaation kattavan resurssienhallintaratkaisun - Ratkaisumallin siihen, miten riskien, ongelmien ja muutosten hallinta tulisi hoitaa - Integraation työtuntiseurantajärjestelmään 70

72 - Mahdollisuuden ennustaa projektin kokonaiskustannuksia viikoittain, käyttäen lähtötietona tuntiseurannasta saatuja toteutuneita työtunteja sekä projektiryhmältä saatua tietoa jäljellä olevien työtuntien määrästä. IGO:jen keskeisenä tavoitteena on yhdistää organisaation resurssien, projektien ja kustannusten hallinta integroiduksi kokonaisuudeksi siten, että, että projektien aikataulut ja kustannukset saadaan ennustettua melko tarkasti ja kohtuullisen vaivattomasti joka viikko, minkä lisäksi IGO:n avulla saadaan kaikille työntekijöille mahdollisimman tasainen 7-8 tunnin päivittäinen työkuorma Projektin Gantt-kaavion sekä aikatauluennusteen laadinta IGO:lla Myös Gantt-kaavioilla ohjatut tehtäväkokonaisuudet tulisi aloittaa aiemmin kuvattuja aloitusmenettelyjä noudattaen (ks. luvut sekä 4.4.2). Kun hanke tai projekti on jo päätetty aloittaa, sille varataan henkilöresurssit organisaation resurssipoolista, jota ylläpidetään IGO:ssa. Resurssivaraukset tehdään prosentteina ilmaistuilla allokaatiolla eli käyttöasteilla. Kun resurssit on jaettu kaikkien organisaation projektien kesken tietyillä allokaatioilla, voidaan välittömästi nähdä karkealla tasolla se, milloin resurssit ovat ylikuormitettuja tai vajaakäytössä ja keitä henkilöitä nämä ongelmat koskevat. Tämän jälkeen kunkin projektin Gantt-kaaviota aletaan tarkentaa siten, että projektin alle muodostetaan tehtävärakenne ja kunkin päätason tehtävän alle aktiviteetteja eli alemman tason tehtäviä. CPM suosittelee, että päätason tehtäviä olisi korkeintaan 15. Näistä tehtävistä yhden kannattaa olla nimeltään Aloitus ja yhden nimeltään Päätösvaihe. Tämän jälkeen edetään aikataulusuunnitteluun. Suunnittelu alkaa sillä, että alemman tason tehtävien kestoajat ennustetaan alustavasti sillä oletuksella, että tehtävällä olisi vain yksi ainoa toteuttaja. Tämän jälkeen tehtävien välille määritellään etenemisjärjestys eli käytännössä se, minkä muiden tehtävien pitää olla toteutettuina ennen tehtävän aloitusta. Lopuksi koko projektille lasketaan Gantt-kaavio sekä siihen perustuva aikatauluennuste ja kriittinen polku. Tätä alustavaa Gantt-kaaviota täsmennetään sen jälkeen siten, että kullekin tehtävälle kiinnitetään vähintään yksi toteutusresurssi. Kun resurssit on kiinnitetty, projektipäällikkö tarkastaa resurssisuunnitelmasta, ovatko jotkut henkilöt ylibuukattuja tehtäville siten, että heidän kuormituksensa nousee projektin aikana yli sadan prosentin tai yli sen tason, jolla heidät on annettu projektin käyttöön. Jos ylikuormitusta ilmenee, projektipäällikön pitää - poistaa ylikuormitettu henkilö joidenkin tehtävien toteutusvastuusta (sekä laittaa tilalle joku toinen resurssi) - lisätä ylikuormitetun henkilön tueksi jokin toinen resurssi tietyille tehytäville - tai pidentää tehtävien kestoaikoja niin paljon, että ylikuormituksesta päästään eroon Jos tehtävien kestoaikoja pidennetään, tästä saattaa syntyä muille projektin tehtäville ongelmia, jotka pitää kukin ratkoa yllä kuvatuin keinoin. Näiden optimointien jälkeen projektipäälliköllä on käytössään tarkennettu ja optimoitu resurssisuunnitelma sekä 71

73 aikataulusuunnitelma. Tämän lisäksi IGO laskee myös projektin kokonaistyökustannukset sekä siirtää ne projektin budjettiin Viikottaiset aikataulu-, työmäärä- ja kustannusennusteet IGO:lla Jotta projektipäälliköllä ja ohjausryhmällä olisi käytettävissään tuoreita ennusteita ja ongelma-analyyseja projektin ohjaustoimenpiteistä päättämiseksi, projektipäällikön pitää kerran viikossa päivittää resurssisuunnitelmaa tarkastamalla ettei projektin resursseille ole tulossa ylikuormitusta esimerkiksi siksi, että jotkin tehtävät ovat viivästyneet siten, että sama henkilö joutuu tekemään yhtaikaisesti kahta eri aktiviteettia 100% allokaatiolla. Samalla kun ylikuormitustilannetta tarkkaillaan, projektipäällikön tulee päivittää projektin ohjausjärjestelmään viikoittain tiedot siitä 1. Kuinka paljon kullekin aktiviteetille on tehty työtunteja? 2. Kuinka paljon kunkin aktiviteetin osalta on vielä jäljellä tekemättömiä työtunteja? 3. Paljonko kukin käynnissä oleva tehtävä vielä kestää nykyisillä resursseilla (tai projektipäällikön lisättyä tehtävälle resursseja)? Ensimmäiseen kysymykseen saadaan vastaus projektin tuntiseurantajärjestelmästä, olettaen, että tuntiseurantajärjestelmässä on täsmälleen sama tehtävälista kuin se, jota käytetään Gantt-kaavion pohjana. Mikäli tuntiseurantajärjestelmää ei ole integroitu projektin Gantt-ohjausjärjestelmään, tästä seuraa kaksi hankaluutta: Projektipäällikön täytyy päivittää erikseen tuntiseurantajärjestelmässä olevaa tehtävälistaa ja erikseen projektin ohjausjärjestelmässä olevaa tehtävälistaa esimerkiksi tilanteessa, jossa syntyy tarve perustaa uusia tehtäviä tai päättää olemassaolevia. Toinen haitta on se, että projektipäällikkö joutuu aina 1-4 kertaa kuukaudessa ottamaan tuntiseurantajärjestelmästä raportin siitä, paljonko kullekin tehtävälle on tehty töitä ja sen jälkeen tämän raportin tulokset on kohta kohdalta syötettävä projektin Gantt-ohjausjärjestelmään. Kun tehdyistä työtunneista on saatu päivitetty tieto 1-4 kertaa kuukaudessa, projektin Gantt-ohjausjärjestelmään on saatava tieto siitä, kuinka paljon kullakin projektiryhmän jäsenellä on tekemättä töitä keskeneräisinä oleville tehtäville. Tämä selvitys on mahdollista tehdä joka viikko projektin viikkopalaverissa, mutta siihen kuluu varsin paljon aikaa, elleivät projektiryhmän jäsenet opettele raportoimaan jäljellä olevia työmääriä todella ripeästi. Hitautta työmääräarvioinnille aiheuttaa se, että projektiryhmän jäsenet kokevat tarvetta selitellä sitä, miksi jokin tehtävä vaatii vielä niin paljon työtunteja. Myös se hidastaa raportointia, jos tiimin jäsenet alkavat miettiä jäljellä olevia työmääriä vasta palaverissa. Tehokkaaksi havaittu keino jäljellä olevien työmäärien raportoimiseen erityisesti monelle eri paikkakunnalle hajautettujen projektien viikkopalavereissa on se, että raportointi tehdään yhtaikaa suullisesti sekä Lynciä tms. chat-ohjelmaa käyttäen: Kukin projektiryhmän jäsen valmistelee nopeasti jo ennen palaveria listan keskeneräisistä tehtävistään ja niiden vaatimista työajoista. Kun hänen vuoronsa kokouksessa tulee, hän lähettää listan ja jäljellä olevat työmäärät chat-viestinä koko muun projektiryhmän nähtäville sekä 72

74 kommentoi lyhyesti tilannetta. Kokouksen lopussa projektipäällikkö tallentaa projektipalaverin chat-historian tiedostoksi sekä kopioi sieltä jäljellä olevia työmääriä koskevat tiedot projektin ohjausjärjestelmään. Kun kullekin tehtävälle tehdyt työtunnit sekä jäljellä olevat työtunnit on syötetty IGO:oon, se laskee automaattisesti uuden Gantt-kaavion ja uuden kriittisen polun projektille. Mikäli uusi Gantt-kaavio näyttää aikataulun näkökulmasta pahalta, projektipäällikön on lisättävä resursseja kriittisen polun varrella oleville tehtäville sekä laskettava sen jälkeen Gantt-kaavio uudestaan. 6.4 Gantt-ohjauksen ruma totuus suomalaisissa projekteissa Vain harvoilla suomalaisilla organisaatioilla on käytössään kunnollinen IGO, joka perustaa organisaation tuntiseurantajärjestelmään uusia tehtäviä tarpeen mukaan ja joka saa tuntiseurannasta viikoittain päivitetyt tiedot toteutuneista työtunneista. Tämä johtuu siitä, että Clarityn ja PlanViewin kaltaiset IGO-ohjelmat ovat varsin kalliita, minkä lisäksi niiden integrointi tuntiseurantaan on monesti huomattavan kallista tai teknisesti täysin mahdotonta siksi, että tuntiseuranta toteutetaan organisaation antiikinaikaisessa ERPjärjestelmässä. Paljon yleisempää on tilanne, jossa projektipäällikkö käyttää kerran kuukaudessa 5 tuntia projektin tuntiraportin ottamiseeen sekä toteutuneiden tuntien syöttämiseen projektin ohjausjärjestelmänä toimivaan Excel-taulukkoon. Projektin tehtävien jäljellä olevia työmääräarvioita ei yleensä seurata, koska se tuntuu projektiryhmän jäsenistä jotenkin hankalalta eikä siihen ole käytössä systemaattisia menettelyjä. Seurauksena on se, että projektin alemman tason tehtävien ja aktiviteettien valmiusasteita ei lasketa systemaattisesti valmiusastelaskennalla vaan valmiusasteet merkitään aktiviteeteille projektipäällikön näppituntumalta. Näihin arvioihin liittyy osuvasti sanonta siitä, että projektin tehtävät saavuttavat nopeasti 80% valmiusasteen, jonka jälkeen viimeistelyyn kuluu vielä vähintään saman verran lisää. Koska tehtävätason valmiusasteet on vedetty hihasta, projektipäälliköt eivät yleensä vaivaudu laskemaan projektin kokonaisvalmiusastetta, eivätkä siksi pysty tekemään valmiusasteeseen tai etenemisvauhtiin perustuvia ennusteita projektin valmistumispäivämäärästä tai kokonaiskustannuksista. Projektin valmistumispäivää ja kokonaiskustannuksia ei siis systemaattisesti ennusteta, vaan ennusteet pohjautuvat siihen alkuperäiseen Gantt-kaavioon ja kustannusennusteisiin, jotka projektipäällikkö teki aivan projektin alkuvaiheessa ja jotka sen jälkeen jätettiin päivittämättä, koska päivittäminen olisi liian vaivalloista. Nämä ongelmat johtavat tyypillisesti tilanteeseen, jossa projektipäälliköt tarjoavat ohjausryhmille PowerPoint-kalvoja, subjektiivisilla värikoodeilla esitettyjä liikennevaloraportteja sekä paljon sanallista selitystä projektin edistymisestä mutta kuitenkin vain hyvin epätarkkoja ennusteita projektin todellisista työmääristä, kustannuksista ja aikatauluista. Lopputuloksena on se, että ohjausryhmä lähinnä vain kuvittelee ohjaavansa projektia, mutta todellisuudessa se ei saa kunnollisia ennusteita ja siksi se näkee projektin vakavat kustannus- ja aikatauluongelmat vasta liian myöhään. 73

75 Ratkaisu näihin ongelmiin on löydettävissä CPM-menetelmän kuvaamista ketterien kehityshankkeiden johtamismenetelmistä, PlanViewin tai Clarityyn perustuvista kaalliinpuoleisista IGO-järjestelmistä tai edullisista ja innovatiivisista Gantt-ohjauksen ratkaisuista. 6.5 Edulliset Gantt-ohjauksen ratkaisut Kaikkein edullisin Gantt-suunnittelun apuvälinen on Project Libre, joka vastaa varsin pitkälti käyttöliittymältään ja toiminnoiltaan Microsft Projectia. Se ei kuitenkaan ole toimiva ratkaisu, jos tavoitteena on kehittää ingegroitu gantt-ohjauksen järjestelmä IGO. Edullisin tarjolla oleva IGO-järjestelmä muodostuu MS Projectista sekä MS Service Managerista, joka on Microsoftin kehittämä palvelupyyntöjen eli tikettien hallintajärjestelmä. Näiden väliseen integraatioon tarvitaan lisäksi vielä Kuwaitilaisen Expitin kehittämää Connector. Ratkaisun ideana on se, että Service Manageria käytetään organisaation vastuulla olevien atomististen tehtävien ja tikettien hallintaan, mutta toisaalta myös MS Projectilla käynnistettyjen tehtävien ja aktiviteettien seurantaan. Seuranta tarkoittaa sitä, että tehtävistä vastuussa olevat palvelupäälliköt saavat Service Managerista tiedon oman tiiminsä vastuulla olevien tikettien tilanteesta ja vastaavasti projektipäälliköt saavat tiedon siitä, mitkä projektien tehtävistä ovat valmistuneet ja paljonko niihin on kulunut työaikaa. MS Projectilla tai Project 2010 Serverillä ohjatut projektit Expit connector Tehtävien toimeksiannot Valmistuneet tehtävät ja toteutuneet tunnit MS Service Manager Resurs sivarauk Organisaation resurssipooli ja projektisalkku (MS Projectissa) set Kooste projekteis ta Heti, kun Expit connector on kerännyt tiedot valmistuneiden tikettien ja aktiviteettien valmistumisajankohdasta ja käytetyistä työtunneista MS Projectin MPP-tiedostoon, MS Project pystyy laskemaan projektille uudet kokonaistyömääräarviot sekä uudet aikataulut. Laskenta tapahtuu automaattisesti, kun MPP tiedosto uudelleenladataan avoimena olevaan MS Projectiin. Edellä kuvattu projektin työkustannusten ja aikataulujen seurantajärjestelmä voidaan laajentaa koko organisaation resurssipoolin ja projektisalkun hallintajärjestelmäksi. Tämä 74

76 tapahtuu siten, että yksittäisten projektien yläpuolelle perustetaan koko organisaatiota kuvaava projektisalkku tai hanke, jonne samalla merkitään myös kaikki organisaation resurssit ja jonne täsmennetään organisaation yhteinen työkalenteri (työpäivän pituus, kansalliset pyhäpäivät, kesälomakausi, joululomat yms.). Tämän jälkeen projektisalkkuun perustetaan yksi rivi per käynnissä oleva projekti ja tämä rivi asetetaan hakemaan kyseisen projektin aloitus- ja päätöspäivää sekä kokonaistyömäärää ja kokonaiskustannuksia kuvastavat tiedot kyseisen projektin MPP-tiedostosta. 75

77 7 Yhteenveto CPM :n suosittelemista tehtävien ja projektien hallintajärjestelmistä Tehtävät, hankkeet ja projektit voidaan luokitella seuraavassa esitetyllä monimutkaisuusluokituksella, jossa ylemmän monimutkaisuustason tehtävät (eli hankkeet ja projektit) muodostuvat alemman tason tehtävistä. Iso ja monimutkainen hanke sekä sen jakautuminen erilaisiin ja eri tavoilla ohjattuihin osiin Ketterä kehittämishanke (tai useampia) Gantt- Sprint1 Julkistus 1 Sprint2 Sprint 3-N Julkistukset 2-N Tehtäväsalkku projekti(t) ja niiden päätason tehtävät Yksittäiset isot tehtävät Paljon atomistisia tehtäviä Paljon tikettejä Isojen ja monimutkaisten hankkeiden aikatauluttamisen paras ratkaisu on automaattisesti laskettava hankekaavio, joka on parannettu versio Gantt-kaaviosta (ks. luku 6.2). Koska hyviä hankekaavion laskentaohjelmia ei ole toistaiseksi olemassa, tähän tarkoitukseen on käytettävä MS Projectia tai Project Libreä, joilla lasketut osaprojektien ja tehtävien sekä koko hankkeen alkamis- ja päätöspäivät on manuaalisesti siirrettävä hankekaavioon. Isojen ja monimutkaisten hankkeiden työmääräkustannusten seuranta on syytä toteuttaa Excel-taulukolla, johon kerätään jokaisen osaprojektin tai tehtäväkokonaisuuden uusimmat päivitetyt työmääräennusteet sekä kokonaiskustannusennusteet, joissa on laskettu yhteen työkustannukset sekä muut kustannukset. Ketterien kehittämishankkeiden ohjauksen apuna voidaan käyttää hankekaavion tyyppistä Gantt-kaaviota, mutta keskeisin ohjauksen apuvälinen on kuitenkin Exceltaulukko, johon lasketaan kehittämishankkeen kokonaistyömäärä, kokonaisaikataulu ja kokonaiskustannukset käyttäen luvussa 3.3 esitettyjä varsin yksinkertaisia ja suoraviivaisia laskentakaavoja. Ketterien julkistusprojektien ylätason aikataulujen, kustannusten ja scopen hallintaan soveltuu melko hyvin pelkkä Excel-taulukko, johon projektitoteutusta kuvastavat vaatimukset ja työmääräarviot kirjataan. Toisena vaihtoehtona ketterien julkistusprojektien ohjaukseen on Scrumworks, jonka integraatio sprinttien ohjaukseen voidaan tulkita joko hyödyksi tai haitaksi. 76

78 Sprinttien ohjaukseen tarvitaan melko samankaltainen työkalu kuin muidenkin tehtävälistojen hallintaan. Tämä työkalu voi olla esimerkiksi Jira, johon on mahdollista lisätä ketteriä menetelmiä tukevia piirteitä Greenhopper-lisämoduulin avulla. Toisena vaihtoehtona on Scrumworks ja kolmantena MS Service Manager. Gantt-projektien ohjauksen paras ratkaisu on IGO eli tuntiseurantaan tiiviisti integroitu Gantt-ohjauksen ja resurssienhallinnan ohjausjärjestelmä. Kuuluisimpia IGO:n rakennuspalikoita ovat kalliiseen hintaluokkaan sijoittuvat Clarity ja PlanView. Halvempi vaihtoehto muodostuu MS Projectista ja MS Service Managerista. Mikäli tehtäväsalkku sisältää atomististen tehtävien lisäksi myös vaiheittain eteneviä tikettejä, tehtäväsalkun lähes ainoita hallintaratkaisuja ovat Jira sekä Service Manager. Isojen yksittäisten tehtävien seurantaan riittää Excel, jossa tehtävän valmiusaste, etenemisvauhti ja odotettavissa oleva valmistumispäivämäärä voidaan laskea luvussa 3.3 kuvatuilla kaavoilla. Kun kaikki edellä kuvatut projektinhallinnan tarpeet lasketaan yhteen, voidaan todeta, että Excelillä, MS Projectilla ja MS Service Managerilla on periaatteessa mahdollista täyttää suurin osa kaikista organisaation projektinhallinnan, resurssienhallinnan ja tehtävienhallinnan tarpeet, laadukkaiden ja automaattisesti päivittyvien hankekaavioiden toteutusta lukuun ottamatta. Ennen liiallista innostumista tästä johtopäätöksestä on kuitenkin todettava, että MS Projectin ja MS Service Managerin välisestä integraatiosta on toistaiseksi varsin käytännön kokemuksia. Ratkaisu siis toimii teknisesti, mutta tyytyväisten käyttäjäorganisaatioiden menestystarinat puuttuvat vielä. Lisäksi on huomattava se, että nykyisin suurin osa monimutkaisista hankkeista toteutetaan monitoimittajaympäristössä. Tämä johtaa siihen, että on jossain määrin epärealistista odottaa, että hankkeen kaikki osapuolet, toimittajat ja alihankkijat tallentaisivat toteutuneita työtunteja koskevat tiedot samaan seurantajärjestelmään. Tämä johtaa siihen, että projektipäälliköiden on jatkossakin tultava toimeen useiden eri projektien ja tehtävien hallintajärjestelmien kanssa. Tärkeintä ei itse asiassa olekaan se, millä järjestelmällä yksittäisiä tehtäviä tai projekteja ohjataan vaan se, että kaikki nämä eri järjestelmät tuottavat osaprojektien projektipäälliköille tiedot käynnissä olevan tehtävän - Odotettavissa olevasta kokonaistyömäärästä - Odotettavissa olevista kustannuksista - Odotettavissa olevasta päättymispäivästä Mikäli projektipäällikkö päivittää 2-4 kertaa kuukaudessa hankekaavion näiden tietojen pohjalta, hän säilyttää koko ajan kontrollin monimutkaisiinkin hankkeisiin. 77

79 CPM Creative Project Management Tämä kirja on tarkoitettu projektipäälliköille, projektitoiminnan kehittäjille ja esimiehille, jotka ovat kiinostuneet projektien onnistumisesta. CPM Creative Project Management eli luova projektinhallinta tarjoaa projektipäälliköille ja projektien vetäjille uusia keinoja projektien onnistumiseen, silloin kun ne kasvavat yli ketterien menetelmien tai ovat pienempiä kuin tavanomaiset gantt pohjaiset projektit. Luovalla projektinhallinnalla on pyritty keventämään suuria projekteja ja antamaan välineet kun ketterän tyyppiset projektit kasvavat suuremmiksi. Projektiammattilaiset HTT Pasi Malmi ja KM Karel Åkerlund ovat käytännön projekteissaan havainneet monia ongelmia, joita on aiemmin pyritty ratkomaan erilaiscin keinoin. Nämä vaikeat tilanteet ovat olleet pontimena kehitettäessä uutta CPM projektinhallintaa. Toivomme, että CPM auttaa projektihenkilöstöä onnistumaan vielä paremmin. Pasi Malmi ja Karel Åkerlund PLUS Akatemia, Helsinki Akatemia on projekti- ja palvelujohtamisen kouluttaja, kehittäjä ja konsultti. Tuttuja termejä meille ovat mm. IPMA/NCB, PMI/PMBOK, ITIL ja CPM. Kysy palveluistamme tai soita ISBN