Aikataulutus ja toimintaverkot
Projektin aikataulun hallinnan tarkoitus on varmistaa, että projekti toteutuu ja valmistuu suunnitellussa ajassa. Yksi projektinhallinnan vaikeimmista päätöksistä on tehtävien töiden keston määrittely. Ei ole epätavallista, että IT-hankkeiden asiantuntijoiden tarkkaan laskemat budjetit ja aikataulut eivät toteudukaan ilman ylityksiä ja viivytyksiä. Jos työmäärä aliarvoidaan, niin sen seurauksena projekti on tuomittu epäonnistumaan. Yhtälössä on aina kaksi muuttujaa: työmääräarvoiden oikeellisuus ja toteutustyön tehokkuus. Työmäärien ylittymisen syynä voi olla väärä työmäärien arviointi tai tiimin tehottomuus. Tehottomuuden yleisin syy on huono osaaminen eikä niinkään laiskottelu. Sen takia arvoissa pitää ottaa huomioon myös toteutustiimin kyvyt [Leh06].
Tehtävien keston määrittämiseen ei usein ole "Stetson-menetelmää" parempaa keinoa. "Stetson" ei ole välttämättä huono menetelmä, jos se perustuu kokemukseen. Tehtävien työmääräarvioiden tekemiseen tarvitaan asiantuntijoita, ja he voivat pelata vaikkapa Scrumin suunnittelupokeria. Lisäksi hyödynnetään aikaisemmista projekteista tallennettua historiatietoa, minkä perusteella päätellään uudessa projektissa aikaisempia tehtäviä muistuttavien tehtävien kesto. Tähän voidaan käyttää malli-tehtävälistoja, joita voi olla useammanlaisia käytettävän elinkaarimallin ja järjestelmän tyypin mukaan. Aina kun uuden projektin työmäärien arviointi aloitetaan, niin otetaan jokin näistä organisaation malleista pohjaksi. Siihen tehdään muutoksia eli uusia asioita voidaan lisätä kommentoiden. Mallipohjasta ei poisteta mitään. Epärelevantit tehtävät laitetaan nolla-työmäärälle tai harmaannutetaan. Listassa ei ole työmääräarvoita, vaan runko tehtävälistaksi. Tehtävien keston määrittelyä tarkentaa useamman henkilön mielipide, jolloin arvion teko projekti- tai tehtäväkohtaisessa asiantuntijaryhmässä voi johtaa parhaaseen lopputulokseen [Leh06].
Koska kyse on loppujen lopuksi todennäköisyyksistä, niin projektin kokonaiskestosta voidaan laskea myös todennäköisyysjakauma tehtävien minimi-, maksimi- ja todennäköisen keston avulla (kolmen pisteen menetelmä). Kullekin tehtävälle annetaan kolme eri työmääräarviota: paras tapaus, todennäköisin ja pahin tapaus. Paras tapaus toteutuu, jos kaikki onnistuu ja huonoin silloin, kun projekti kohtaa paljon vaikeuksia ja kompleksisuutta. Arvoissa voidaan käyttää myös suoraan todennäköisintä arvoa, jollon työmäärät lasketaan kaavalla (paras tapaus + 4* todennäköisin + pahin tapaus) /6. Tätä kaavaa käytetään PERT-mallissa (Program Evaluation and Review Technique) [AMK06, Leh06].
Suunnitelmien eri vaiheiden työmäärien suhdetta kannattaa verrata viitteellisin ohjearvoihin, esimerkiksi määrittely ja suunnittelu 30 %, toteutus 40 % ja testaus 30 % [Ruu08]. Projektinhallinnan työmäärän voi hyvin arvioida lopuksi lisäämällä tietyn prosenttiosuuden muun työmäärän päälle. Sopivimmat arvot ovat välillä 10-15 % [Leh06].
Toimintaverkkotekniikka
Toimintaverkko on graafinen kuvausmenetelmä, jolla esitetään tehtävät, tapahtumat ja tehtävien väliset riippuvuudet. Toimintaverkosta saadaan selville projektin kriittinen tehtäväketju sekä kaikkien tehtävien pelivarat. Kokonaispelivara (KPV) on yhden ketjun pelivara eli aikaväli, jonka tehtävä voi viivästyä ilman, että projektin valmistuminen siirtyy. Vapaa pelivara (VPV) on aikaväli, jonka tehtävä voi viivästyä ilman, että minkään toisen tehtävän aloittaminen viivästyy. Pelivaroja hyödynnetään resurssitasauksessa [Pel11]. Suuria toimintaverkkoja piirrellään käytännössä harvoin enää käsin, sillä projektihallintaohjelmat laskevat pelivarat automaattisesti. Toimintaverkko auttaa kuitenkin ymmärtämään, miksi tehtävien riippuvuudet on tärkeä laittaa oikein projektinhallintaohjelmaan. Yksinkertaistettu toimintaverkko on myös Gantt-kaaviota selkeämpi tapa kuvata projektin eri vaiheet.
Toimintaverkossa projekti kuvataan sarjana toisistaan riippuvaisia tehtäviä, jotka kuvataan tehtävien ajallisen järjestyksen mukaan vasemmalta oikealle. Yhden toimintaverkon sisällä ei tehtävien kestoissa saa olla kymmenkertaisia eroja. Jos verkossa on kuukausien pituisia tehtäviä, niin siinä ei saa olla päivän pituisia tehtäviä. Mitä hienojakoisemmin tehtäväerittelyn tekee, niin sitä työläämpää toimintaverkon laadinta on. Sen takia on valittava sopiva tarkkuusaste. Yhden työntekijän osaamia työvaiheita ei tarvitse erikseen eritellä [Pel11].
Toimintaverkon määrittely etenee seuraavasti [AMK06]:
1. Ensin määritetään tehtäväverkon tehtävät, tehtävien kestot ja riippuvuudet.
2. Lasketaan tehtävien aikaisin alkamishetki (AAH) ja aikaisin päättymishetki (APH) eli edetään toimintaverkkoa alusta loppuun. Aikaisin päättymishetki saadaan lisäämällä aikaisimpaan alkamishetkeen tehtävän kesto. Jos tehtävien alkamiselle on määritetty negatiivisia tai positiivisia viiveitä, niin ne otetaan huomioon alkamishetken määrittelyssä. Solmukohdissa seuraavan tehtävän aikaisimman alkamishetken ratkaisee edellisten tehtävien aikaisimmista päättymishetkistä se, joka on suurin. Esimerkiksi kehitys voi alkaa vasta, kun arkkitehtuurisuunnittelu on valmis.
3. Lasketaan tehtävien myöhäisin päättymishetki (MPH) ja myöhäisin alkamishetki (MAH).
Nyt laskenta aloitetaankin toimintaverkon lopusta. Viimeiselle tehtävälle asetetaan myöhäisimmäksi päättämiseksi sen aikaisin päättäminen eli esimerkiksi tehtävän "Käyttöönotto" myöhäisin päättymishetki on sama kuin sen aikaisin päättymishetki (74). Myöhäisin alkamishetki saadaan vähentämällä myöhäisimmästä päättymishetkestä tehtävän kesto eli MPH - tehtävän kesto. Jos varsinaista yksinäistä viimeistä tehtävää ei ole, vaan niitä on useita, niin kannattaa lisätä yksi kokoava tehtävä, jonka kesto asetetaan nollaksi. Edeltävien tehtävien myöhäisimmäksi päättymishetkeksi laitetaan seuraajan myöhäisin alkamishetki. Solmukohdissa edeltäjän myöhäisimmän päättymishetken ratkaisee seuraajista se, jonka myöhäisin alkamishetki on pienin. Esimerkiksi testiympäristön rakentamisen myöhäisimmäksi päättymishetkeksi valitaan pienin sen seuraajien (katselmoinnit, koulutus, integrointitesti, dokumentointi) myöhäisistä alkamishetkistä.
4. Lasketaan tehtävien kokonaispelivara myöhäisimmän aloituksen ja aikaisimman aloituksen ( tai myöhäisimmän päättämishetken ja myöhäisimmän alkamishetken erotuksena). Näin saadaan selville projektin kriittinen polku, jonka kokonaispelivara on nolla.
5. Pelivarat voi laskea myös taulukkoon. Vapaa pelivara on aikaisimman seuraavan tehtävän AAH - ko. tehtävän APH.
Tehtävä | Kesto | AAH | MAH | APH | MPH | KPV | VPV |
Vaatimukset | 10 | 0 | 0 | 10 | 10 | 0 | 0 |
Testausohjelmisto | 10 | 10 | 10 | 20 | 20 | 0 | 0 |
Käyttöliittymät | 5 | 10 | 20 | 15 | 25 | 10 | 3 |
Arkkitehtuurit | 8 | 10 | 17 | 18 | 25 | 7 | 0 |
Testitapaukset | 7 | 20 | 20 | 27 | 27 | 0 | 0 |
Testiympäristö | 7 | 27 | 27 | 34 | 34 | 0 | 0 |
Kehitys | 9 | 18 | 25 | 27 | 34 | 7 | 7 |
Integrointitesti | 18 | 34 | 34 | 52 | 52 | 0 | 0 |
Koulutus | 11 | 34 | 58 | 45 | 69 | 24 | 24 |
Systeemitesti | 17 | 52 | 52 | 69 | 69 | 0 | 0 |
Katselmoinnit | 6 | 34 | 67 | 40 | 73 | 33 | 33 |
Hyväksymistesti | 4 | 69 | 69 | 73 | 73 | 0 | 0 |
Dokumentointi | 20 | 34 | 53 | 54 | 73 | 19 | 19 |
Käyttöönotto | 1 | 73 | 73 | 74 | 74 | 0 | 0 |
Tehtävien riippuvuudet
Tehtävillä on erilaisia riippuvuuksia, jotka voidaan luokitella seuraavasti [Män16]:
- Looginen riippuvuus - tehtäviä ei ole mahdollista suorittaa kuin tietyssä järjestyksessä.
- Limitysriippuvuus - edellisen tehtävän on edettävä tiettyyn vaiheeseen, ennen kuin seuraava tehtävä voidaan aloittaa.
- Viiveriippuvuus - on odotettava tietty aika edellisen tehtävän päättymisestä, ennen kuin seuraava tehtävä voidaan aloittaa.
- Resurssiriippuvuus - samat resurssit kohdentuvat eri tehtäviin.
- Kalenteririippuvuus - tehtävä voidaan aloittaa tai lopettaa vain tiettynä kalenteriaikana.
- Ei suoranaista riippuvuutta tehtävien välillä - tehtävät ajoitetaan muiden tehtävien ehdoilla.