Tämä on tositarina ei niin kovin kaukaa menneisyydestä. Minun oli tarkoitus rakentaa tietovarasto käyttäen itselleni uutta teknologiaa ja entuudestaan tuntemattomia datalähteitä. Pilkoin projektin sopivan kokoisiin tehtäviin, arvioin tehtävien kestot ja ilmoitin arvioiden summan asiakkaalle. Kelataan pikana eteenpäin kaksi kuukautta ja oli selvää, että antamani työmääräarvio oli täysin paska.

Inhoan virheiden tekemistä ja jäin pohtimaan, että missä meni pieleen…

Tekemäni virheet

Yhden, jos toisenkin unettoman yön jälkeen päädyin näihin virheisiin:

1. En jakanut projektia määrittely ja toteutusvaiheeseen
2. Annoin tarkkoja arvioita aikahaarukoiden sijaan ilman selkeitä rajauksia
3. En antanut todennäköisyyttä arvioiden paikkansa pitävyydelle
4. Annoin asiakkaan vaikuttaa arvioihini

Jatkossa teen asiat toisin.

Erota projektin määrittely ja toteutus

Etenkin tutun asiakkaan kanssa työskennellessä on helppo turvautua pieniin oikoreitteihin, kuten projektin aloittamisen kiirehtimiseen ja määrittelyvaiheen skippaamiseen. Aina ei ole helppo tehdä eroa jatkuvan kehityksen ja uuden projektin välillä, jos kyse on yhdestä ja samasta asiakkaasta.

Käytännössä aina, kun kyse on useiden päivien työstä, kannattaa työ tehdä projektina.

Ensiksi kannattaa ottaa käyttöön projektin mallirakenne ja prosessi parempaan määrittelyyn. On mahdotonta tehdä tarkkaa arviota ilman tarkkoja vaatimusmäärityksiä.

Kun annoin surkean arvion, minulla oli vain pintapuolinen käsitys asiakkaan tarpeista. Lisäksi minun olisi oikeasti pitänyt sukeltaa tarkemmin konepellin alle ja huomata, että kuinka monimutkaisesta datasta on kyse.

Jokaisessa data projektissa on kaksi suurta kysymysmerkkiä ja ne vaikuttavat merkittävästi projektin kestoon.

1. Datan rakenne ja monimutkaisuus
2. Datan saatavuus

Simppelin datan saa mallinnettua päivässä, monimutkaisen käsittelyyn voi mennä kymmeniä päiviä. Sama pätee tiedon saatavuuteen rajapinnoista. Joskus ne ovat hyvin dokumentoituja helppoja käyttää, joskus vaaditaan merkittävä määrä salapoliisin työtä.

Ainoa tapa olla varma, on oikeasti laittaa kädet saveen (lähdedataan).

Hyvä ymmärrys johtaa parempiin arvioihin, mutta vaatii enemmän panostusta etukäteen.

2. Tarkat arviot vs. arviovälit

Hyvä tapa olisi, että antaa ensin arvio ja sitten lisää arvioon 20–30 % työaikaa alkuperäisen päälle, jolloin absoluuttisen arvon sijaan voidaan esittää arvioväli. Näin huomioidaan se, että yleensä arviot ovat aina alakanttiin.

Jos ihan tarkkoja ollaan, niin hyvin harvoin olen nähnyt liian suuria työmääräarvioita enkä ole tainnut koskaan sellaista antaa.

Arviovälistä on helpompi hahmottaa, että kyse on arvauksesta eikä tarkasta lukemasta.

Tiedän, että moni ei ole kanssani samaa mieltä arviovälin käyttämisestä. Vaihtoehtoinen tapa on ilmoittaa asiakkaalle maksimi ja sitten yllättää positiivisesti, jos työmäärä jää alle arvioidun.

Minä pidän realismista ja yllätyksettömyydestä, sinä saatat olla eri mieltä.

3. Varmuusprosentti

Jokainen ennuste kaipaa kaverikseen varmuusprosentin.

Esimerkiksi säätä ennustettaessa pelkkä sateen määrän arviointi ei kerro lähellekään koko totuutta. On täysin eri asia ennustaa 100 millin rankkasadetta 5 % tai 80 % todennäköisyydellä. Liian usein projektityössä tyydytään pelkän työmäärän arviointiin.

Kuinka usein sinä olet nähnyt arvioitavan työmääriä ilman todennäköisyyttä niiden paikkansapitävyydelle?

Jos tehdään ennuste tai arvio, realistisen kokonaiskuvan antamiseksi myös todennäköisyys on pakollinen. Luonnollisesti todennäköisyys on myös arvaus, mutta se voi auttaa paikallistamaan mahdollisia sudenkuoppia.

Edit: Sain jutun julkaisun jälkeen palautetta varmuusprosentista. Itseasiassa paljon parempi tapa olisi listata epävarmuustekijät sekä rajata arvion ehdot niin tarkasti, että pystyy tekemään arvion ilman todennäköisyyksiä. Jos arvio ei sitten pidäkään paikkansa, on paljon helpompi vedota ehtoon X, kuin hatusta vedettyyn varmuusprosenttiin.

4. Älä anna asiakkaan vaikuttaa arvioihin

Suurin osa Power BI tai tietoalusta projekteista myydään tuntityönä.

Muutaman kerran olen törmännyt asiakkaisiin, jotka alkavat neuvottelemaan annetuista työmääräarvioista. Joskus olen jopa erehtynyt laskemaan omaa arviotani tämän takia. Molemmissa toimenpiteissä kyse on puhtaasta idiotismista, koska työmääräarvioilla ei ole vaikutusta laskutukseen.

Tuntilaskutus perusteisissa projekteissa laskutus tapahtuu toteutuneiden tuntien mukaan, joten kaikkein paras, jos arviot ovat mahdollisimman realistiset.

• Jos asiakas yrittää neuvotella työmääräarvioista, älä annan hänen vaikuttaa arvioihin
• Jos olet asiakas, joka yrittää neuvotella arvioista, lopeta. Keskitä neuvotteluenergiasi tuntihintaan.

Kukaan ei tykkää yllätyksistä projekteissa. Mitä lähempänä työmääräarviot ovat todellisuutta, sitä tyytyväisempiä kaikki ovat.

Lopuksi

Ilman kristallipalloa ennusteet ovat vaikeita. Erityisesti silloin, jos tekee jotain ensimmäistä kertaa, mutta aina voi parantaa ennustetarkkuutta tai vähintään antaa realistisemman tilannekuvan.

Jos etukäteen ei voi saada tarpeeksi tarkkoja tietoja kunnollisen arvion tekemiseen, on hyvä muistaa todeta, että arviot tulevat tarkentumaan määrittelyvaiheessa.