CPM_Creative_Project_Management_ISBN_9789526790114_pdf

Transcription

CPM_Creative_Project_Management_ISBN_9789526790114_pdf
CPM® Creative Project Management
eli projektien ja hankkeiden luova johtaminen
ketteryyttä, gantteja ja tikettejä yhdistellen
Pasi Malmi – Karel Åkerlund
CPM® Creative Project Management
CPM® Creative Project Management
eli projektien ja hankkeiden luova johtaminen
ketteryyttä, gantteja ja tikettejä yhdistellen
1
CPM® Creative Project Management
Copyright © 2013 Pasi Malmi, HTT
Toimittaja ja konseptin tarkistus: Karel Åkerlund, KM
CPM® konsepti: PLUS Akatemia Oy
ISBN 978-952-67901-0-7 (rengaskirja)
ISBN 978-952-67901-1-4 (PDF)
Kustantaja:
PLUS Akatemia Oy
Pihkatie 3 A
00410 HELSINKI
Sähköposti: [email protected]
Rekisteröitymällä PLUS Akatemian kotisivuilla CPM® hyödyntäjäksi, saat uusimman
sähköisen pdf version omaan käyttöösi.
www.plusakatemia.com
2
CPM® Creative Project Management
Sisällys
0
1 JOHDANTO ............................................................................................................................................5
1.1 CPM® Creative Project Management –menetelmän hyödyt eri kohderyhmille ........................5
1.2 Kirjan rakenne ja etenemisjärjestys ..........................................................................................6
1.3 Mitä luovuus on ja miten CPM® hyödyntää luovuutta? ............................................................6
2 PROJEKTINHALLINNAN PERUSKÄSITTEET .....................................................................................8
2.1 Peruskäsitteet sekä projektien kytkeytyminen strategiseen johtamiseen .................................8
2.2 Projektin organisoinnin peruskäsitteitä ......................................................................................9
2.3 Projektin vaiheet ja projektinhallinnan osa-alueet .................................................................. 11
2.4 Projektinhallintamenetelmät sekä niiden jaottelua ja vertailua............................................... 12
2.4.1 Ganttin menetelmä .................................................................................................. 12
2.4.2 Vesiputousmalli ....................................................................................................... 13
2.4.3 PMBOK ................................................................................................................... 14
2.4.4 Prince2 .................................................................................................................... 15
2.4.5 Protoileminen ja iteratiiviset kehitysmallit ............................................................... 16
2.4.6 Inkrementaalinen projektitoteutus sekä paranneltu vesiputous .............................. 18
2.4.7 Scrum ...................................................................................................................... 19
2.4.8 Lean ja IPMA........................................................................................................... 20
3 CREATIVE PROJECT MANAGEMENT – MENETELMÄN YLEISKUVAUS ..................................... 22
3.1 Projektien monimutkaisuusluokitus sekä vaihtoehtoiset ohjausratkaisut ............................... 22
3.2 Gantt-ohjaus CPM® -mallissa ................................................................................................ 24
3.3 Aikataulu- ja kustannusennusteiden laskenta valmiusasteen ja etenemisvauhdin
pohjalta ............................................................................................................................. 25
3.3.1 Valmiusasteen laskenta .......................................................................................... 25
3.3.2 Valmiusasteeseen perustuvat työmäärä-, aikataulu- ja
kustannusennusteet ............................................................................................ 27
3.4 Ketterän julkistusprojektin scope-ennusteet........................................................................... 30
3.5 Erilaisten tehtävien ja projektien jakautuminen päävaiheisiin ................................................ 32
4 KETTERIEN KEHITTÄMISHANKKEIDEN JOHTAMINEN CPM:SSÄ ............................................... 34
4.1 Ketterän kehittämishankkeen tavoitteet ja osatehtävät .......................................................... 34
4.2 Hankkeen organisaatio sekä ohjaus säännöllisillä kokouksilla .............................................. 34
4.2.1 Organisaatiokaavio ................................................................................................. 34
4.2.2 Organisaation toimielinten ja roolien täsmennykset CPM:ssä ................................ 35
4.2.3 Ketterien kehittämishankkeiden ohjaus säännöllisillä kokouksilla .......................... 39
4.3 Ketterän kehittämishankkeen aloitus, toteutus, ohjaus ja päätös .......................................... 40
4.3.1 Yleiskuvaus ja peruskäsitteet.................................................................................. 40
4.3.2 Hankkeen aloitus askel askeleelta .......................................................................... 41
4.3.3 Ketterän kehittämishankkeen toteutus ja päätös .................................................... 46
4.3.4 Ketterän kehittämishankkeen ohjaus ...................................................................... 46
4.4 Ketterän julkistusprojektin aloitus, toteutus, ohjaus ja päätös................................................ 48
3
CPM® Creative Project Management
4.4.1 Ketterien julkistusprojektin tyypit ohjauksen näkökulmasta .................................... 48
4.4.2 Ketterän julkistusprojektin aloitus............................................................................ 49
4.4.3 Ketterän julkistusprojektin toteutus, ohjaus ja päätös ............................................. 52
4.5 Sprinttien aloitus, toteutus, ohjaus ja päätös.......................................................................... 53
4.5.1 Yhteenvetokaavio ................................................................................................... 53
4.5.2 Sprintin aloitus......................................................................................................... 53
4.5.3 Sprintin toteutus sekä päivittäisjohtaminen ............................................................. 54
4.5.4 Edistymiskatselmukset, valmiusaste ja tekninen velka .......................................... 55
4.5.5 Sprintin päätös eli luovutuskatselmus ja toimintatapojen
kehittämistyöpaja ................................................................................................ 56
4.5.6 Miksi sprintit kestävät 4 viikkoa ja miksi ne jakautuvat
neljännessprintteihin? ......................................................................................... 58
4.5.7 Sprinttien luova käyttö ilman kytkentää tuotejulkistuksiin ....................................... 58
5 TEHTÄVIEN, TIKETTIEN JA TEHTÄVÄSALKKUJEN JOHTAMINEN ............................................. 59
5.1 Aihepiirin yleiskuva ................................................................................................................. 59
5.2 Yksittäisen ison tehtävän johtaminen ..................................................................................... 59
5.3 Atomististen tehtävien johtaminen ......................................................................................... 60
5.3.1 Miten atomistiset tehtävät syntyvät erilaisille tehtävälistoille? ................................ 60
5.3.2 Atomististen tehtävien ohjauksen tavoitteita ja suosituksia .................................... 62
5.4 Vesiputoustehtävien ohjaus tiketeillä ja ITIL:illä ..................................................................... 63
5.4.1 Määrämuotoiset vesiputoukset, ITIL ja Lean .......................................................... 63
5.4.2 Vapaamuotoisten pienoisvesiputousten johtaminen .............................................. 65
5.5 Tehtäväsalkun johtaminen ..................................................................................................... 65
6 GANTT-KAAVIOIDEN HYÖDYNTÄMINEN CPM:SSÄ ...................................................................... 67
6.1 Mille osa-alueille Gantt-kaaviot soveltuvat? ........................................................................... 67
6.2 Ison ja monimutkaisen hankkeen johtaminen Gantt-kaavioilla .............................................. 68
6.3 Projektien ohjaus integroidulla Gantt-ohjausjärjestelmällä eli IGO:lla ................................... 70
6.3.1 Integroitu Gantt-ohjausjärjestelmä .......................................................................... 70
6.3.2 Projektin Gantt-kaavion sekä aikatauluennusteen laadinta IGO:lla........................ 71
6.3.3 Viikottaiset aikataulu-, työmäärä- ja kustannusennusteet IGO:lla .......................... 72
6.4 Gantt-ohjauksen ruma totuus suomalaisissa projekteissa ..................................................... 73
6.5 Edulliset Gantt-ohjauksen ratkaisut ........................................................................................ 74
7 YHTEENVETO CPM®:N SUOSITTELEMISTA TEHTÄVIEN JA PROJEKTIEN
HALLINTAJÄRJESTELMISTÄ ................................................................................................. 76
4
CPM® Creative Project Management
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
CPM® Creative Project Management
-
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
CPM® Creative Project Management
-
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
CPM® Creative Project Management
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
CPM® Creative Project Management
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
Projekti 1
Projekti 2
Projektisalkku
tai ohjelma 2
Projekti 3
Projektisalkku
tai ohjelma N
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
CPM® Creative Project Management
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 4.2.
10
CPM® Creative Project Management
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,
Toteutus,
Päätös,
Initiation
Execution
Closing
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.
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
Aloitusvaiheen
johtaminen:
Kustannus-hyötyvertailun, vaatimus-
Toteutuksenjohtaminen
Projektin
päättäminen
luettelon sekä projektisuunnitelman asteittain
tarkentuva laadinta.
raportointi
tehtävät
Systemaattinen
ohjaus ohjausjärjestelmien avulla
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
CPM® Creative Project Management
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
2.4.1 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
12
Tammi
Helmi
CPM® Creative Project Management
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.
2.4.2 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
Testaus
Käyttöönotto
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 loppu13
CPM® Creative Project Management
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.
2.4.3 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
Toteutuksenjohtaminen
Projektin
päättäminen
saanti ja projektin
suunnittelu
raportointi
ohjaustoimenpiteet
Systemaattinen
ohjaus
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
CPM® Creative Project Management
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
Toteutuksenjohtaminen vaihe
vaiheelta
Initiating a project
Systemaattinen
ohjaus
15
Projektin
päättäminen
CPM® Creative Project Management
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.
2.4.5 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
CPM® Creative Project Management
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
Toiminnallisen
osa-alueen 1 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
17
CPM® Creative Project Management
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
CPM® Creative Project Management
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
Toteutuksen johtaminen
daily sprinteillä ja
itseohjauksella
vaatimusluettelon
Projektin
päättäminen
kun deadline
koittaa
ja työmääräarvioiden laadinta
Systemaattinen ohjaus sprint
review- ja sprint retrospective kokousten sekä Velocitylaskelmien avulla
Scrum-projektin systemaattinen ohjaus tapahtuu projektin omistajan eli product ownerin
toimesta. Ohjauksen keinoja ovat kunkin sprintin lopussa pidettävät Sprint review ja
19
CPM® Creative Project Management
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.
2.4.8 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
CPM® Creative Project Management
-
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
CPM® Creative Project Management
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ä.
Atomistiset
Toteutuksen
jäsennys
Organisointi
kesken/valmis
yksi toteuttaja
pikkutehtävät
Ohjaus ja suositeltava
maksimikesto
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
kesken/valmis
Sama kuin yllä
Valmiusaste ja siitä lasketut
(tasainen vauhti)
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ää
Gantt-projekti
5-25 päätason
Sama kuin yllä +
Sama kuin yllä + aikataulu-
tehtävää
mahdollisesti
seuranta tuntiseuranta-
projektitoimisto
järjestelmään kytketyllä
(maksimikesto 3 vuotta)
Gantt-kaaviolla (1 vuosi)
Iso Gantt-projekti
5-15 osaprojektia
(tai hanke)
Sama kuin yllä +
Sama kuin yllä
toteutuksen ohry
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
CPM® Creative Project Management
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)
GanttJulkistus 1
Sprint1
Sprint2
projekti(t)
Julkistukset 2-N
Sprint 3-N
Paljon atomistisia tehtäviä
ja niiden
Tehtäväsalkku
päätason
Yksittäiset
isot tehtävät
tehtävät
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
CPM® Creative Project Management
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-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
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
CPM® Creative Project Management
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
3.3.1 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
CPM® Creative Project Management
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
CPM® Creative Project Management
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.
3.3.2 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
CPM® Creative Project Management
Tavoitellut kokonaishyötypisteet
Hyötypisteiden summa nyt
Aika
Nykyhetki
Valmistumisajankohta
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
Valmistumisajankohta
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
CPM® Creative Project Management
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ä
tehtävän (esim. sprintin, julkistuksen, tehtävälistan tai ison tehtävän)
pistemääräksi. Kun kokonaishyötypistemäärä on kertaalleen laskettu,
laskea enää uudestaan, ellei tämän ylemmän tason tehtävän alle synny
alemman tason tehtäviä.
ylemmän tason
kokonaishyötysitä ei tarvitse
kokonaan uusia
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
CPM® Creative Project Management
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
CPM® Creative Project Management
Vaatimus
Prioriteetin
järjestysluku
Työmääräarvio (h)
Kumulatiivinen
työmääräarvio (h)
Tärkeimmän
vaatimuksen kuvaus
1
150
150
Toiseksi tärkeimmän
vaatimuksen kuvaus
2
15
165
Kolmanneksi
tärkeimmän
vaatimuksen kuvaus
3
30
195
…
…
…
…
Vaatimuksen N
kuvaus
N
50
920 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
CPM® Creative Project Management
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
Toteutusvaihe:
- tehtävän toteutus joko yhtenä
2. Työmäärä- tai hyöty-
vaiheena (atomistiset tehtävät) tai
pistearvion laadinta
3. Vastuuhenkilön
Tehtävän
päättäminen
usean peräkkäisen askeleen
kautta (tiketit sekä isot tehtävät)
nimeä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
CPM® Creative Project Management
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
Toteutusvaihe:
1-5 toimituserää,
Projektin päättäminen
1. Viimeisen toimituserän
jotka jakautuvat kukin
julkistus tai käyttöönotto
2-10:een neljän viikon
mittaiseen sprinttiin
2. Kehityshankkeen
purkaminen ja lopetus.
4. Proof of concept
testi- ja katselmustulokset
sprinttien ja toimitusten hyväksymiset sekä
sekä riskit ja ongelmat
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
CPM® Creative Project Management
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)
GanttJulkistus 1 (tai toimituserä 1)
Sprint1
Sprint2
Sprint 3-N
Paljon atomistisia tehtäviä
projekti(t)
Julkistukset 2-N
ja niiden
Tehtäväsalkku
päätason
Yksittäiset
isot tehtävät
tehtävät
Paljon tikettejä
4.2 Hankkeen organisaatio sekä ohjaus säännöllisillä kokouksilla
4.2.1 Organisaatiokaavio
Ulkomaisessa projektinhallintakirjallisuudessa ei useinkaan erotella toisistaan hankkeita
ja monimutkaisia projekteja, vaan niille molemmille sovelletaan samanlaista
34
CPM® Creative Project Management
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 jäsenet
Tiimin 2 vetäjä
Tiimin 3 vetäjä
Tiimin jäsenet
Tiimin N vetäjä
Tiimin jäsenet
Tiimin jäsenet
4.2.2 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
CPM® Creative Project Management
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
CPM® Creative Project Management
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
CPM® Creative Project Management
Tällöin on tärkeää täsmentää projektisuunnitelmaan, miten projektipäällikkövastuut
jakautuvat asiakkaan ja toimittajan kesken.
38
CPM® Creative Project Management
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
CPM® Creative Project Management
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
4.3.1 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
Toteutusvaihe:
2-5 peräkkäin toteutettavaa
Kehittämishankkeen
ketterää projektia, jotka
päättäminen
1. Viimeisen toimituserän
2. Määrittelyvaihe
kukin tuottavat joko
julkistus tai käyttöönotto
3. Kilpailutusvaihe
julkistuksen tai
2. Kehittämishankkeen
4. Proof of concept
toimituserän
purkaminen ja lopetus.
testi- ja katselmustulokset
sprinttien ja toimitusten hyväksymiset sekä
sekä riskit ja ongelmat
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
CPM® Creative Project Management
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
päivää
1-5
Kustannus (€)
100 –
5000
5000 –
30000
Portti
1-30
0 – 5000
3
0-30
0–
30000 €
4
5-30
1
2
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 70.000 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 70.000 € 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
CPM® Creative Project Management
4.3.2.1 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.
4.3.2.2 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
CPM® Creative Project Management
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
CPM® Creative Project Management
4.3.2.3 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
CPM® Creative Project Management
4.3.2.4 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.
4.3.2.5 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ää.
4.3.2.6 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
CPM® Creative Project Management
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.
4.3.4 Ketterän kehittämishankkeen ohjaus
Ketterän kehittämishankkeen ohjaus perustuu erittäin keskeiseltä osin aikataulu-,
kustannus- ja scope-ennusteiden laskentaan (luvuu 3.3 – 3.4) 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
CPM® Creative Project Management
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
CPM® Creative Project Management
4.4 Ketterän julkistusprojektin aloitus, toteutus, ohjaus ja päätös
4.4.1 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
Toteutusvaihe:
Jakautuu
johtaminen:
1. Määrittelyvaihe
2. Kustannusennuste
3. Sopimusneuvottelut
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
sprinttien hyväksymiset ja uudet
sekä demot ja ongelmat
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 4.3.2.3) 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
CPM® Creative Project Management
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 3.3 – 3.4 esitettyjä aikataulun, kustannusten ja scopen ennustamismenetelmiä.
4.4.2 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
CPM® Creative Project Management
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
1h
1h
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 4.3.2.4).
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 3.3 –
3.4), 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
CPM® Creative Project Management
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
CPM® Creative Project Management
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.
4.4.3 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 4.2.3 .
Julkistusprojektin ylätason ohjaus perustuu varsin pitkälti projektin aikataulu-, kustannusja scope-ennusteisiin, joiden laadintaa on kuvattu luvuissa 3.3 – 3.4. 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
CPM® Creative Project Management
4.5 Sprinttien aloitus, toteutus, ohjaus ja päätös
4.5.1 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
Toteutusvaihe:
- ihmisten päivittäisjohtaminen ja
daily scrumit
- tiiminvetäjien kokoukset pari
kertaa viikossa
Sprintin
päättäminen
1. Final sprint
review
2. Sprint
teko ja tehtävien työ-
retrospective
määräarvioiden laadinta
3. ToteuttamattoPäivitetty tehtävälista
Vaatimuksia koskevien
toteutusten hyväksymiset
Systemaattinen ohjaus viikkopalavereissa
- sprintin valmiusasteen laskenta
mien vaatimusten
sekä teknisen velan
tarkennettu työmääräarvio
- vaatimusten (back-log itemien) hyväksyminen
- riskinhallintatehtävien perustaminen
- ongelmanhallintatehtävien perustaminen
4.5.2 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
CPM® Creative Project Management
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.
4.5.3 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 10-30 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 10-20
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
CPM® Creative Project Management
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.
4.5.4 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
CPM® Creative Project Management
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.
4.5.5 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
CPM® Creative Project Management
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
CPM® Creative Project Management
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 11.000 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ä.
4.5.7 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
CPM® Creative Project Management
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)
GanttJulkistus 1
Sprint1
Sprint2
projekti(t)
Julkistukset 2-N
Sprint 3-N
ja niiden
Tehtäväsalkku
Paljon atomistisia tehtäviä
päätason
Yksittäiset
isot tehtävät
tehtävät
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
CPM® Creative Project Management
5.3 Atomististen tehtävien johtaminen
5.3.1 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 10-20 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
CPM® Creative Project Management
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 90-100%
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
CPM® Creative Project Management
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
CPM® Creative Project Management
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ä
5.4.1 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
CPM® Creative Project Management
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
CPM® Creative Project Management
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.
5.4.2 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
CPM® Creative Project Management
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 20-30 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
CPM® Creative Project Management
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)
GanttJulkistus 1
Sprint1
Sprint2
projekti(t)
Julkistukset 2-N
Sprint 3-N
Paljon atomistisia tehtäviä
ja niiden
Tehtäväsalkku
päätason
Yksittäiset
isot tehtävät
tehtävät
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
CPM® Creative Project Management
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 10-20
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.
2012 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
CPM® Creative Project Management
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.
2012 alku
2012 loppu
2013 alku
2013 loppu
2014 alku
2013 loppu
Aloitus
Päätös
AN-laitejulkistus 1
julkistus
AN-laitteen sarjatuotanto (vähintään 3000 kpl)
AN-ohjelman 1. julkistus
AN-ohjelman 2. julkistus
Laitteiston ja AN-ohjelman asennus 3000 ajoneuvoon
Infosysteemin 1. julkistus
Back-endin julkistus 1
Infosysteemin 2. julkistus
Infosysteemin 2. julkistus
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
CPM® Creative Project Management
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
6.3.1 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
CPM® Creative Project Management
-
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.
6.3.2 Projektin Gantt-kaavion sekä aikatauluennusteen laadinta IGO:lla
Myös Gantt-kaavioilla ohjatut tehtäväkokonaisuudet tulisi aloittaa aiemmin kuvattuja
aloitusmenettelyjä noudattaen (ks. luvut 4.3.2 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
CPM® Creative Project Management
aikataulusuunnitelma. Tämän lisäksi IGO laskee myös projektin kokonaistyökustannukset
sekä siirtää ne projektin budjettiin.
6.3.3 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
CPM® Creative Project Management
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
CPM® Creative Project Management
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.
Expit connector
MS Projectilla
tai Project 2010 Serverillä
ohjatut projektit
Tehtävien toimeksiannot
MS
Service
Manager
Valmistuneet tehtävät ja
toteutuneet tunnit
Resurs
sivarauk
Kooste
projekteis
ta
Organisaation
resurssipooli ja projektisalkku (MS Projectissa)
set
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
CPM® Creative Project Management
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
CPM® Creative Project Management
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)
GanttJulkistus 1
Sprint1
Sprint2
projekti(t)
Julkistukset 2-N
Sprint 3-N
Paljon atomistisia tehtäviä
ja niiden
Tehtäväsalkku
päätason
Yksittäiset
isot tehtävät
tehtävät
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
CPM® Creative Project Management
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
CPM® Creative Project Management
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 [email protected] tai soita
0504340979
www.plusakatemia.com
ISBN 978-95267901-1-4
78