Aloitan tämän tarinan
kertomuksella elävästä elämästä. Amerikkalainen IBM- yhtiö
kehitti 1960- luvulla markkinoille suurtietokoneiden perheen nimeltä
S/360. Koneen ainutlaatuinen piirre olisi sen käyttöjärjestelmä.
Se on ohjelmisto, joka helpottaa huomattavasti koneen käyttöä.
Hyvin määriteltyjä käyttöjärjestelmiä ei oikeastaan siihen
aikaan vielä ollut olemassa.
Kehityshanke
oli kuitenkin
vakavissa
vaikeuksissa. Budjetti oli jo
ylittynyt
moneen
kertaan, ja aikataulujen venyminen uhkasi tietokoneen kaupallista
tulevaisuutta. Frederick Brooks huomasi silloin
merkillisen
ilmiön. Projektin
miehitystä lisättiin, mutta seuraus
oli odottamaton. Projekti
ei siitä nopeutunut, vaan kävi suorastaan päinvastoin. Jos
joku
tehtävä
oli myöhässä esimerkiksi kolme kuukautta ja siihen lisättiin
uusia henkilöitä, tehtävä myöhästyi entistä enemmän, ehkä
viisi kuukautta.
Ilmiön
on havaittu pätevän projektitoiminnassa myös yleisesti. Sille
löytyy myös luonnollinen selitys. Projektissa eri henkilöiden ja
ryhmien välinen tietojen vaihto vaatii paljon työtä. Kun tietoa
vaihtavien osapuolten määrä kasvaa, tarvittavan kommunikaation
määrä kasvaa myös, mutta vielä paljon nopeammin. Lisäksi
projektissa toimivien henkilöiden kuormitus on jo ennen työvoiman
lisäystä venytetty äärimmilleen. Nyt heidän tulisi vielä
käyttää osa ajastaan uusien henkilöiden opastamiseen.
Niinpä Brooks saattoi
muotoilla kauniin ja kompaktin säännön: ”Resurssien lisäys
myöhässä olevaan projektiin tai tehtävään saa sen myöhästymään
lisää.”
Tällaisten
hankkeiden vaikeuksiin vaikuttaa tietenkin myös hankkeen sisältö,
tai pikemminkin sisällön haastavuus, sillä kyse ei todellakaan ole
ojankaivuusta tai heinänteosta. Tavoitteena
oli kehittää IBM-
tietokoneen käyttöjärjestelmä OS
360.
Tehtävän määrittely oli sumea, sillä tuohon aikaan,
1960-luvulla, tietokoneen käyttöjärjestelmä oli aivan uusi idea.
Ei ollut yleistä mielikuvaa siitä, miten helposti sellainen voidaan
saada aikaan. Siksi työpaketit ja
koko hanke osoittautuivat
alusta
alkaen väärin
mitoitetuiksi.
Valitettavasti
projektin tulos osattiin kuitenkin hahmottaa. Ymmärrettiin hyvin,
miten tietokoneen käyttöjärjestelmän piti palvella konetta ja
käyttäjiä. Siksi projektia ei voitu lopettaa, ennen kuin tuo tulos
oli saatu. Seurauksena oli massiivinen, tuhansien prosenttien
eskalaatio. Kaikkiaan projektiin upposi 2000 henkilötyövuotta. Se
on valtava määrä työtä. Jälkiviisautena voisi vielä sanoa,
että ohjelmakoodin koko oli vaivaiset
kaksi megatavua. Nykyaikana se on naurettavan pieni ohjelma!
Frederick
Brooks on kuvannut tilannetta klassikoksi muodostuneessa kirjassaan
Myyttinen
henkilötyövuosi
(the
Mythical Man-Month).
Brooks
oli huomannut, että tällaisessa hankkeessa henkilötyövuodesta
tulee
myyttinen käsite. On
vaikea tietää etukäteen, mitä
sillä saa aikaan. Lisäksi se ei tottele normaalia matematiikkaa.
Työpaketteja ei voi summata, kertoa tai jakaa osiin normaalilla
tavalla, tulokset ovat arvaamattomia.
Brooksin
kirja ilmestyi vuonna 1975, ja siitä tuli nopeasti
teknologiakirjallisuuden
klassikko. Kirjasta
otetaan säännöllisesti uusia painoksia, se on ns. steady-seller.
Sitä
myydään maailmanlaajuisesti vuosittain ehkä
noin
10 000 kappaletta. Brooksin
projektista on kulunut jo
vuosikymmeniä,
mutta edelleenkin hänen kuvaamansa ongelma on ja pysyy. Kirjasta
on sanottu, että sen neuvot ovat eniten siteerattuja ja vähiten
noudatettuja.
Siirrytään nyt
nykyaikaan. Luin hiljattain lehtiuutisen. Terveydenhuollon
tietojärjestelmä Apotti tulee maksamaan 200 miljoonaa euroa
enemmän kuin on suunniteltu. Rivien välistä luin, että
kustannusylitystä pidettiin aika suurena. Déjà-vu! Se on
ranskaa, ja tarkoittaa tunnetta: tämähän on aiemmin nähty. Aivan
oikein, siinähän on taas Brooksin myyttiset henkilötyövuodet –
tai oikeastaan vielä myyttisemmät eurot!
Joten
mikä on Apotin kustannusarvio, paljonko se nyt tulee lopulta
maksamaan. Hankkeella on runsaat ja havainnolliset kotisivut, joilla
hanketta ja sen tilaa selostettiin tarkasti tiedon välittämistä
vältellen. Piti turvautua pieneen googlaukseen: uusin kustannusarvio
on
nyt
570 miljoonaa euroa. Kustannusten ylitys on siis mojova, ja tulee
ilmi vaiheessa, jossa kaikki on suunniteltu ja toteutuskin on ”75%
valmis”. Rupesin pohtimaan tarkemmin. Apotti on
tietokantajärjestelmä, siis jotain aika suoraviivaista ja tuttua.
Se on laaja, mutta tällaiset järjestelmät skaalautuvat hyvin.
Siinä on tosin varmaan
aika paljon toimintologiikkaa ja rajapintoja. Homma
on pääosin työtä, joten karkeasti arvioiden hanke voisi olla
kooltaan 3000 – 5000 henkilötyövuotta. Brooksin OS 360- hanke jää
kirkkaasti toiseksi.
Miten
tällaiseen loukkuun taas jouduttiin? Osa vastauksesta löytyy tämän
kirjoituksen alkuosasta. Olen itsekin pohtinut, miksi niin monet
projektit epäonnistuvat ja suistuvat raiteeltaan. Tämän pohtiminen
on ollut työtäni, ja olen koonnut myös omat kokemukseni kirjaksi:
Projektitoiminnan musta kirja.
(Readme.fi
2011). Kirjasta löytyy paljonkin syitä siihen, miten tällaiset
hankkeet joutuvat vaikeuksiin. En selosta niitä tässä sen
tarkemmin, mutta tottahan siinä myös Brooksin myyttiset
henkilötyövuodet käsitellään.
Kuten
Brooksin kirja, myös oma kirjani on steady seller. Kustantajan
kirjanpidon mukaan sitä myydään edelleen muutama kappale vuodessa.
 |
| Brooksin kirjan ikoninen kansikuva -ja Apotti- hankkeen tilanne? |
