Ohjelmistohankkeet taas otsikoissa

Kun tämä blogi aloitettiin oli Suomessa paljon julkista keskustelua ohjelmistoprojektien onnistumisesta. Sitten keskustelu kuitenkin loppui – olivatko IT-hankkeet alkaneet onnistua? Nähtävästi eivät olleet, koska nyt saamme taas lukea IT-hankkeiden turmiollisuudesta, kun VR ei saa myytyä lippuja kaikilla halukkaille.

Ensimmäinen reaktio oli tietysti syyllisten etsiminen. Lopulta joku lipsautti, että järjestelmän ovat tehneet Accenture ja Tieto. Sitten VR:n sisältä otettiinkin ongelmista vastuuta. Tänään Aamulehdessä oli mielenkiintoinen artikkeli, jossa oli haastateltu Börje Uimosta ja Reino Myllymäkeä, jotka ovat kirjoittaneet kirjan IT hankkeiden epäonnistumisesta. Artikkelissa he tuovat esille suurten IT hankkeiden epäonnistuvan vielä paljon pieniä useammin.

Kuka on syyllinen?

Tähän on minun mielestäni olemassa aivan selvä ja oikea vastaus: kaikki projektin osapuolet ovat syyllisiä. Ihan kaikki. Ei mikään merkittävä hanke voi onnistua jos projektin osapuolet kantavat vastuuta vain oman osuutensa onnistumisesta. Kaikkien osapuolten on kannettava vastuuta koko projektin onnistumisesta. Niin se vaan on.

Ja hienoa onkin, etteivät lipunmyyntihankkeen osapuolet ole kauheasti toisiaan julkisuudessa haukkuneet. On aika vaikeaa uskoa, ettei kuka tahansa osapuolista olisi voinut toimia paremmin ja siten ehkäistä ongelman syntyä.

Miksi kuormitusta ei osattu arvioida oikein?

Teknisenä ihmisenä minulle mielenkiintoisinta on, miksi järjestelmä ylikuormittui, vaikka asiakkaiden määrä on varmasti hyvin tiedossa. Tästäkin aiheesta on jo kirjoitettu ja vastaus ainakin tuntuu uskottavalta: uusi järjestelmä kannustaa hintavertailuun ja siten yksi asiakas käyttää järjestelmää paljon enemmän kuin ennen.

Mikä meni pieleen?

Mikael Aro toteaa YLElle, että viiden kuukauden testijakso ei ollut riittävä. On tietenkin helppoa todeta, että Aro on oikeassa, mutta toivottavasti hän ei tarkoita, että seuraavaan projektiin järjestetään 12 kuukauden testijakso. Järjestelmä on pakko olla mahdollista testata viidessä kuukaudessa ja, kun testauksessa löytyy vakavia ongelmia, ei järjestelmää tietenkään oteta käyttöön. Jos järjestelmää ei ole mahdollista testata viidessä kuukaudessa, sellaista järjestelmää ei pitäisi ollenkaan tehdä – se on yksinkertaisesti liian suuri.

Suuria järjestelmiä voidaan kyllä rakentaa, mutta ne pitää rakentaa osissa. Jokainen osa voidaan sitten rakentaa erillisenä ja testata alle viiden kuukauden aikana.

Tämä on asia, jossa meillä ohjelmistosuunnittelijoilla muilla olisi opittavaa. Ihan liian helposti ratkaisu kaikkeen on järjestelmän uudelleenkirjoittaminen. Mutta toisaalta myös johtoporras rakastaa suuria hankkeita, joissa voidaan pitää paljon palavereja. On todella upeaa laittaa “kaikki järjestelmät kerralla kuntoon!” Olemassa olevaan järjestelmään tehtäville jatkokehityshankkeille on myös vaikeaa saada avoimen kilpailutuksen kautta kiinteää hintaa.

Yksi askel kerrallaan

Valtavan järjestelmän uusimisessa on usein mahdotonta onnistua: kukaan ei enää tiedä, miksi käytössä oleva järjestelmä toimii niin kuin se toimii, joten kukaan ei osaa määritellä uuteen järjestelmään kaikkia tarvittavia toimintoja. Kun uusi järjestelmä kuitenkin yritetään määritellä,

1. tulee määrittelyyn mukaan paljon turhia ominaisuuksia, jotka entisestään kasvattavat järjestelmän kokoa ja
2. siitä puuttuu paljon ominaisuuksia, joita nykyisessä järjestelmässä ei edes tiedetty olevan.

Paras perustelu järjestelmien jatkokehittämiseen on jatkuva muutos. Vaikka järjestelmien uusiminen veisi vain viisi vuotta ja vaikka se onnistuisi, mikä organisaatio voi pitää toimintatapansa samoina viiden vuoden ajan? Nykyään toiminta muuttuu koko ajan esimerkiksi lainsäädännön muuttuessa. Tämä tekee uudelleenkirjoittamisen mahdottomaksi, koska järjestelmän määrittely elää sen rakentamisaikana niin paljon, ettei se koskaan tule valmiiksi.

Näin ollen suuret järjestelmät on pakko pilkkoa osiin jolloin niitä voidaan uusia osa kerrallaan. Jokaiseen osaan on myös säilytettävä mahdollisuus jatkokehitykseen. Tämä ei ole helppoa tai kivaa tai edes tehokasta, mutta se on ainoa keino saada valtavat tietojärjestelmät pysymään käyttökelpoisina.

Mikä ei mennyt pieleen?

Reino Myllymäki tuo Aamulehden artikkelissa esille, että VR:llä on aikaisemmin ollut erittäin tiukka seuranta IT hankkeissa ja miettii olisiko tämä seuranta nyt löystynyt. Tiukalla seurannalla olisi ehkä voitu varmistaa, että kuormitustestausta tehdään tarpeeksi, ennen järjestelmän käyttöönottoa.

Tiukka seuranta kuitenkin myös ajaa kohti selkeältä tuntuvia, suuria uudelleenkirjoitushankkeita, joilla Myllymäen mukaan on taas suurempi mahdollisuus epäonnistua. Lisäksi tiukka seuranta on usein taloudellista ja pintapuolista: kukaan ei osaa seurata sitä, miten ohjelmistosuunnittelijoiden työ oikeasti etenee. Omassa kokemuksessani olen havainnut, että projektit joiden aloituskokouksessa verrataan projektin organisaatiota armeijaan, epäonnistuvat 100% todennäköisyydellä.

Motivaation löytäminen

Katsoin herättävän (ja hienosti tehdyn) videon Dan Pinkin luennosta RSA:lla. Luennolla Dan kertoo, mikä ihmisiä motivoi ja miten heidät saadaan tekemään työnsä hyvin. Olen tehnyt paria aika isoa projektia viime vuodet ja miettinyt samalla, miksi ne eivät motivoi. Teen kyllä kovasti töitä, mutta enemmän velvollisuuden tunteesta kuin palavan intohimon johdattamana.

Jotenkin muistelen, että tietokoneohjelmien tekeminen oli ennen jännittävää ja tuntui hyödylliseltä. Nyt projektit tuntuvat turhauttavilta, koska ne ajautuvat samoihin ongelmiin riippumatta siitä, miten toimin. En tarkoita, että projektit varsinaisesti epäonnistuvat – voi olla, että projektin lopussa asiakas on lopputulokseen tyytyväinen. Voi olla, että projektin lopussa omat esimiehet on tyytyväisiä tehtyyn työhön ja kannustavat seuraavaan hankkeeseen. Silti hankkeet tuntuvat turhauttavilta ja motivaation kerääminen niihin on joka kerta vaikeampaa. On varmaankin tullut aika tehdä jotain muuta kuin julkishallinnon ohjelmistoprojekteja.

Videossa Dan esittelee yhden asian, joka ei motivoi: raha. Sitten siinä esitellään kolme asiaa, jotka motivoivat: itsenäisyys, kehittyminen ja tekemisen merkitys. Äkkiä ajatellen voisi kuvitella, että juuri julkisella sektorilla olisi ainakin merkitykseen hyvät mahdollisuudet: olisi hienoa tehdä valtiolle hienoja järjestelmiä, jotka auttavat meitä kaikkia jonkin viraston parempana toimintana. Itsenäinen työ ja kehittymismahdollisuudet – kyllä niihinkin pitäisi olla mahdollisuudet.

Itsenäisyys. Julkishallinnon ohjelmistohankkeet tehdään tiimeillä – niin kuin varmaankin melkein kaikki ohjelmistot nykyään. Mutta yhteistyö tiimissä voi olla itsenäistä. Asioista pitää neuvotella tiimin sisällä, mutta hyvin toimivassa tiimissä omakin kanta tulee huomioitua. Tiimi voi myös jakaa töitä jäsenilleen siten, että nämä saavat tehdä osia itsenäisesti. Enemmän minua häiritsee, ettei tiimi, joka järjestelmän tekee, saa toimia itsenäisesti tiiminä. Tiimi ei pääse mukaan järjestelmän määrittelyyn, jolloin heille ei kehity syvällistä ymmärrystä järjestelmän toiminnasta. Tämän jälkeen he voivat joko kahlata huonoa dokumentaatiota tai keskustella asiakkaan ihmisten kanssa dokumentaation aukkojen täyttämiseksi. Päämääränä on tehdä sopimuksen mukainen järjestelmä, ei esimerkiksi asiakkaalle parasta järjestelmää.

Kehittyminen. Hiukan yllättäen oman kokemukseni mukaan projekteissa on mahdollista oppia paljon uusia asioita ja tehdä alan uusinta aaltoa edustavia ratkaisuja. Tämän kääntöpuolena kuitenkin on, että aikataulut ovat erittäin tiukkoja ja yhtään ylimääräistä työtuntia ei sopimuksessa oppimista varten ole. Lopputulos on, että uusia asioita kyllä oppii, mutta jatkuvassa kiireessä se ei tunnu palkitsevalta.

Merkitys. Mitä enemmän olen lukenut erilaisten järjestelmien vaatimusmäärittelyitä ja nähnyt uusia toimivia järjestelmiä, sitä enemmän tuntuu, ettei niiden tekeminen välttämättä ole palvelus kenellekään. Järjestelmät on yleensä määritelty todella kankeiksi ja työläiksi käyttää. Kun tämän päälle laitetaan jo mainitun todella kovan kiireen tuomat laatuongelmat, ei voi  kuin ihmetellä, että ne ollenkaan toimivat. Ei kai kukaan koe elämäänsä merkitykselliseksi tehdessään jotain, mitä itse pitää keskinkertaisena tai huonona?

No, kaikki tämä on toki ollut minun tiedossani jo jonkin aikaa – miksi siis purkautua tänne nyt? Mitä hyötyä tästä negatiivisuudesta on? Olen käsittääkseni viimeinen ja ainoa tämän blogin kirjoittajista, joilla on jotain tekemistä julkishallinnon ohjelmistojen kanssa. Kaikki muut ovat olleet viisaampia ja keksineet jotain parempaa tekemistä jo ajat sitten. Viimeinen vuosi on saanut minut varmaksi siitä, että minunkin on aika paeta myös jonnekin muualle. Valitettavasti minun asemassani, järjestelmää toteuttavan tiimin teknisenä arkkitehtinä, en keksi mitään keinoa parantaa yllä olevia asioita. Tulemme mukaan kuvioon liian myöhässä ja olemme tekemisissä täysin ohjelmistohankintoja tuntemattomien ihmisten kanssa. Toiset asiakasorganisaatiot ovat parempia ja toiset eivä vielä parempia, mutta minun vaikutusmahdollisuuteni tuntuvat olemattomilta. Ja silloin on aika pitää taukoa.

Toimiva, kestävä ohjelmisto

Markku Niemi Suomen Akatemiasta kirjoitti hyvän kommenttin aiempaan postaukseeni. Markun esille nostamat ongelmat ohjelmistotyössä ovat niin yleisiä, että päätin kirjoittaa vastaukseni tämän uuden artikkelin muotoon.

Markku mainitsee viestissään kaksi ohjelmistoprojektien ongelmaa:

• Liiallinen “ketteryys” alkuvaiheessa kostautuu myöhemmin, jos järjestelmä ei ole organisaation yritysarkkitehtuurin mukainen.
• Ohjelmiston sisäinen laatu heikkenee jatkuvasti kun sitä kehitetään. Tämän seurauksena sen korjaaminen, parantaminen ja muokkaaminen muuttuu hankalammaksi ajan kuluessa. Lopulta toimintaympäristön muutoksiin ei voida enää vastata ohjelmiston muutoksilla ja joudutaan kirjoittamaan uusi ohjelmisto alusta lähtien.

Olen Markun kanssa samaa mieltä näiden ongelmien merkittävyydestä. En kuitenkaan pidä niitä voittamattomina ongelmina. Itse asiassa, pidän juuri ketteryyttä näiden ongelmien ratkaisukeinona.

Aloitetaan liiallisesta “ketteryydestä” projektin alkuvaiheessa: olen Markun kanssa samaa mieltä tämän vaarallisuudesta, niin kauan kuin sana “ketteryys” pidetään lainausmerkkien välissä. On siis ketteryyttä ja “ketteryyttä”. Moni firma nimittää tekotapaansa “ketteräksi” ymmärtämättä mistä ketteryyden hyödyt lopulta tulevat.

Ketterässä kehityksessä suunnitteluvaihe, joka perinteisesti on projektin alussa, muutetaan koko projektin jatkuvaksi. Todellisessa ketteryydessä tämä ei kuitenkaan tarkoita, etteikö asioita suunniteltaisi huolella. Projektin toteutus aloitetaan mahdollisimman nopeasti projektin alussa, jotta suunnitelmien realistisuudesta saadaan varhain oikeaa palautetta. Esimerkiksi teknisen riskin minimoimiseksi voidaan käyttää walking skeleton -mallia, jossa projekti aloitetaan arkkitehtuurin oikeaksi osoittavalla minimaalisella ominaisuuskokonaisuudella. Tai sen kumoavalla! Tarkoitus on nimenomaan löytää mahdolliset ongelmat heti projektin alussa, ei sitten kun niitä on liian myöhäistä korjata.

Todellisuudessa myös perinteisissä ohjelmistoprojekteissa suunnittelutyö jatkuu loppuun asti – joka projektissa tulee yllätyksiä, ja niiden tultua esiin joudutaan asiat suunnittelemaan uudestaan. Tätä on jostain syystä ollut monissa projektisuunnitelmissa vaikea myöntää.

Oikeastaan jako “suunnittelun” ja “toteutuksen” välillä on siis keinotekoinen: ohjelmistotyö on luovaa suunnittelutyötä alusta loppuun. Välineet vain vaihtelevat; joskus asioita on helpointa suunnitella tussitaululla, joskus ohjelmointikielellä.

Palatakseni itse asiaan, eli yritysarkkitehtuurin huomioimiseen projektissa: Jatkuvan suunnittelun ohella ketteryyden vastaus tähän on, että olennaisten toimintojen kuuluu olla edustettuna joko järjestemää rakentavassa tiimissä tai sen asiakastiimissä (tätä kuvaavalle englanninkielen termille cross-functional team ei taida olla vakiintunutta suomennosta). Jos yritysarkkitehtuuri on olennaisessa osassa, tulee tiimiin kuulua joku joka hallitsee organisaation yleisarkkitehtuurin. Se, kumpaan tiimiin tämä kuuluu, riippuu yritysarkkitehtuurin merkityksestä tässä organisaatiossa ja tässä projektissa.

Käytännössä monissa organisaatioissa ei haluta irrottaa projekteihin niihin parhaiten sopivia ihmisiä. Sekin voi toimia, kunhan projektin alkuvaiheessa aikaa varataan tarpeeksi kommunikaatiolle tiimin ja näiden sidosryhmien välillä. Olennaista on, että nämä asiakaspään edustajat ovat aktiivisesti mukana projektissa. Tältä kannalta esimerkiksi se, miten Maa- ja metsätalousministeriön Tietopalvelukeskus oli järjestänyt teknisen arkkitehtuurin hallinnan, kuulosti minun korviini hyvältä.

Myös toinen Markun mainitsema ongelma, eli ohjelmistojen rapautuminen elinkaaren loppua kohden, on hyvin yleinen. Sekään ei ole kuitenkaan mikään luonnonlaki; sitä vastaan on mahdollista taistella. Tässä on pari tärkeää keinoa:

1. Laaditaan kattavat automaattiset hyväksymistestit ja ajetaan ne joka päivä. Kunnolla tehtynä nämä ovat järjestelmän todellinen tarkka määrittely. Uudet tulokkaat ymmärtävät järjestelmän halutun toiminnan näiden kautta tarkemmin kuin paperidokumentista. Lisäksi järjestelmän arkkitehtuuria voidaan muuttaa tarvittavaan suuntaan, kun automattisesti voidaan varmistaa, ettei olemassaoleva toiminnallisuus sen takia muutu.Itse alan olla monien kollegoideni tavoin sitä mieltä, että vähänkään pitkäkestoisempaa ohjelmistoprojektia ei voi tehdä ilman automaattisia hyväksymistestejä. Muuten seurauksena on juuri kuvaamasi ohjelmiston rapautuminen.
2. Panostetaan heti ohjelmiston alkuvaiheesta asti koodin ja dokumentaation laatuun – ei määrään. Pahin laadun este on keinotekoinen kiire. Usein ohjelmistoprojekteissa kuvitellaan, että hyvä suunnittelu on joitain, joka voidaan siirtää syrjään, kun on pidettävä kiirettä. Näin ei tietenkään ole. Hyvä suunnittelu auttaa projektia pitämään vauhtia yllä. Ohittamalla suunnittelun voi saada vain lyhytaikaisen nopeutuksen. Kun se on käytetty loppuun, on työ entistä hitaampaa.Toinenkin laadun este liittyy aikaan; se on tehtävien tarkka aikataulutus etukäteen pitkälle ajalle. Koska koko ohjelmistoprosessi on uuden suunnittelua, on ennalta vaikea arvata, mihin asiaan aika lopulta kuluu. Jos tehtävien aikataulut on lyöty lukkoon etukäteen, tulee jäljestä väistämättä vaihtelevaa. Asiat, jotka eivät menneetkään niin kuin alunperin oli suunniteltu, joudutaan paikkaamaan pikaisesti purukumilla. Lopulta suurin osa järjestelmästä on purukumia ja sen toiminnan selvittäminen käytännössä mahdotonta.

Deadlineja saa olla, ja esim. Scrumin voi sanoa jopa toimivan juuri niiden varassa. Aikataulut ja tavoitteet pitää kuitenkin määritellä oikealla tarkkuudella ja oikealla tavalla. Seuraavan päivän toimille voidaan asettaa tarkat tehtäväkohtaiset tavoitteet, mutta mitä pidemmälle tulevaisuuteen mennään, sitä epämääräisempi pitää suunnitelmankin olla. Ei ole järkevää asettaa tarkkaa määrittelyä vuoden päästä valmistuvalle järjestelmälle – sen sijaan voidaan arvioida esim. sitä kuinka paljon arvoa järjestelmä asiakkaalle vuodessa tuottaa ja seurata sitä. Näin tiimi ei ole sidottu yhteen suunnitelmaan vaan se voi tuottaa asiakkaalle arvoa parhaalla mahdollisella tavalla, kun se oppii järjestelmästä ja sen toimintaympäristöstä uutta.

Toki lopulta kaikkein tärkein laatuun vaikuttava tekijä on ohjelmistotiimin osaaminen. Hyvä tiimi tekee hyvää laatua ja on lopulta moninkertaisesti kustannustehokkaampi kuin keskinkertainen tiimi.

Tässä käsitellyt ongelmat liittyvät olennaisesti yhteen. Hyvää suunnittelua tarvitaan alusta loppuun asti. Muuten ongelmat kasautuvat, ja lopulta maksumieheksi joutuu tilaaja.

Nörtit syyllisiä?

Luin tuoreeltaan Kauppalehden artikkelin “Eduskunta pui it-pulmia: nörtit hihittävät ja käärivät rahat” ja jonkinasteisen tunteenpurkauksen myötä koin tarvetta kommentoida.

Kyllä nörtit ovat tähän tilanteeseen täysin syyttömiä. Tai jos oikeastaan tarkkoja ollaan, ilman nörttejä homma olisi kategorisesti pahemmin levällään, sillä vain nörttien ansiosta olla edes tässä tilanteessa.

Kauppalehden artikkelissa siis pohditaan, että kumpi, nörtti vai systeemi, on syyllinen tilanteeseen, jossa järjestelmät eivät ole yhteensopivia ja “nörtit käärivät rahat”. Eivät nörtit ole rahoja käärineet, hehän ovat vain nostaneet kuukausipalkkaa, joka on todennäköisesti mennyt lähinnä asuntolainan maksamiseen ja paikalliseen ruokakauppaan. He ovat usein jopa siviilielämänsä kustannuksella ahertaneet ylitöitä, jotta järjestelmät olisi saatu edes yhteensopimattomina toimimaan (ei siis keskenään, vaan ylipäänsä). Kyllä rahat ovat menneet muiden taskuun.

Kuka on siis syyllinen? Onko se systeemi vai joku muu? Kenen on vika, jos tilataan tietoisesti yhteensopimattomia järjestelmiä? Onko taustalla joku “systeemi”, joka tuollaista edellyttää? Vai onko taustalla epämääräistä lainsäädöntöä ja tietotekniikasta tietämättömiä päättäjiä? Vai liiketoiminnan konsultteja (siis ei nörttejä), jotka ovat neuvoneet tietämättömiä päättäjiä aiheesta? Vai onko kaikilla osansa sopassa?

Mikä on “systeemi” tässä tilanteessa? Keskustan Pekka Vilkuna totesi artikkelissa, että “syy on tässä systeemissä, jossa ei valvota riittävästi”. Hänen mielestään siis ilmeisesti valvonnan lisääminen olisi ratkaisu. Henkilökohtaisen kokemuksen valossa “valvontaa” on ihan riittävästi (ja usein liikaakin). Se, mitä puuttuu, on “vastuu”. Ohjelmistoprojekteja ostetaan vahvasti ulkoistettuina eikä ostaja ota todellista vastuuta hankittavan järjestelmän todellisesta soveltuvuudesta organisaation toimintaan ja tavoitteisiin. Tässä kohtaa kyllä voidaan “systeemiä” syyttää osasyylliseksi, sillä perinteinen vaiheistettu projektirakenne ei anna juurikaan mahdollisuutta todelliseen vastuunottoon projektin aikana.

Vaikka tiedän, että jokaiseen omenapuuhun mahtuu mätiä omenia, uskon kuitenkin vahvasti, että suurin osa “omenista” on varsin terveitä ja pyrkivät varsin vilpittömästi hyvään lopputulokseen. Mutta jos nuo hyvään pyrkivät ihmiset opetetaan tilaamaan tietojärjestelmiä tavalla, joka perimmäisiltä lähtökohdiltaan estää projektin aikaisen oppimisen ja reagoimisen ympäristön muutoksiin, eikä heille opeteta parempia tapoja hankkia ohjelmistoja (mikä ei edes ole heidän ammatillista perusosaamistaan), niin mielestäni heitä ei oikein voi syyttää tilanteesta. Se, että heitä on opetettu tietyllä tavalla, on “systeemin” vika, mutta ei niin, että “systeemi” olisi joku henkilö tai taho, vaan “systeemi” on IT-alaan juurtunut projektikulttuuri.

Tätä projektikulttuuria ruokittiin 20-30 vuotta ja taustalla on illuusio siitä, että tietojärjestelmäkehitys olisi samankaltaista perinteisen insinöörityön kanssa. Perinteisen insinöörityön perusta on huolellinen suunnittelu ja toteutettavan rakenteen huolellinen pikkutarkka suunnittelu, joka sitten jalkautetaan vähemmän osaaville tehtäväksi tarkkojen ohjeiden mukaan. Lähestymistapa on soveltuva vain tilanteisiin, joissa tehtävä työ ei edellytä tekijöiltään hartioiden yläpuolella olevien elinten aktiivista käyttöä (ja siis vain työtä ohjaavilta tahoilta vaaditaan pään käyttöä) JA voidaan perustellusti olettaa, että rakennelman suunnittelun ja toteutuksen aikana ei ole oletettavissa olennaisia muutoksia rakennelman käyttötarpeisiin ja ympäristöön.

Tietojärjestelmähankkeissa kumpikaan edellisistä ehdoista ei toteudu. Vähänkään pidempiaikaisen projektin (ml. hankintaprosessi) aikana yrityksen tai julkisen organisaation toimintaympäristö ja -tarpeet muuttuvat väistämättä niin paljon, että toteutuksessa olevaa järjestelmää pitäisi muuttaa olennaisesti, jotta se vastaisi valmistumishetkellään organisaation sen hetkisiin tarpeisiin. Lisäksi tietojärjestelmien suunnittelu ja toteutus vaatii mitä enemmissä määrin nimenomaan harmaan massan rasittamista. Kun tähän vielä lisätään se, että toteutetut tietojärjestelmät ovat enemmän tai vähemmän uniikkeja, joudutaan käytännössä jokaisen projektin yhteydessä ratkaisemaan ongelmia, joita ei sellaisenaan ole missään aikaisemmin ratkaistu (tai ainakaan tieto muualla tehdyistä ratkaisuista ei ole tekijöiden käytettävissä).

Systeemin muuttamisen perimmäinen edellytys siis on, että hylkäämme perinteisen projektihankinnan, -suunnittelun ja -johtamisen mallin, ja korvaamme sen todellisen toimintaympäristön vaatimusten mukaisella toimintatavalla. Tämän toimintatavan ydinelementtejä on projektinaikaisen muutoksen haltuunotto, jatkuvan muutoksen mahdollistava systeemityötapa sekä kaikki osapuolet koko projektin ajan aktiivisesti osallistuttava johtamistapa. Ohjelmistotuotannon puolella tuolla työtavalla on nimikin – ketterät ohjelmistotuotannon menetelmät. Nuo menetelmät on kuitenkin ymmärrettävä laajemmassa mittakaavassa kuin missä ne ottavat kantaa itse ohjelmiston tuotantotapaan tai ohjelmistoprojektin johtamiseen. Ne vaikuttavat myös ostavan organisaation ostotapaan, ostavaan yksikköön sekä ylempään liiketoimintajohtoon ja tukifunktioihin. Jos vaikutus ei ulotu sinne asti, ei organisaatio voi myöskään todellisesti hyötyä projektitason ketteryydestä.

Jottei lukijoille jää virheellistä mielikuvaa, todettakoon vielä, ketterät menetelmät eivät ole mikään hopealuoti, joka muuttaisi ohjelmistotuotannon helpoksi. Ei tehokkaiden, käytettävien, organisaation tavoitteita täyttävien tietojärjestelmien rakentaminen ole helppoa niilläkään. Tarvitaan riittävää osaamista ja ymmärrystä kaikilta projektitoiminnan osapuolilta, jotta järjestelmä syntyy tehokkaasti ja että se oikeasti vastaa tilaavan organisaation ja sen asiakkaiden tarpeisiin. Tällä hetkellä meillä on käyttävissä perusmalli – kattava osaaminen ja kokemus meiltä vielä liiketoiminta-alana puuttuu.

Julkishallinnon ketterä tarjouspyyntö: Paikkatietoikkuna.fi

Maanmittauslaitos käynnisti maaliskuussa 2008 pilottihankkeen, jolla tuetaan Euroopan yhteisön paikkatietoinfrastruktuurin eli nk. INSPIRE-direktiivin kansallista toimeenpanoa.

Projektissa kehitetty paikkatietoikkuna.fi julkaistiin 7.7.2009 ja sen toimitti Logica Oy. Sinänsä hyvin onnistuneessa pilotissa havaittiin, ettei ohjelmistokehityksen perinteinen malli täysin vastannut nykyaikaisen verkkopalvelun kehittämisen haasteisiin. Lisähaastetta toivat kehityksessä hyödynnettävät avoimen lähdekoodin tiuhaan kehittyvät komponentit.

Kokemusten valossa Paikkatietoikkunan vuonna 2010 julkaistava tuotantoversio päätettiin kehittää ketterillä menetelmillä oman projektihallinnon alaisuudessa. Tavoitteen toteuttamiseksi Resiina / Idealist Digital Oy pyydettiin avustamaan tarjouspyynnön toteutuksessa sekä Maanmittauslaitoksen henkilökunnan Scrum-koulutuksessa.

Tarjouspyynnön toteutusvaihtoehtoja selvittäessäni päädyin tähän mainioon blogiin, josta bongasin TIKE:n osastopäällikön Kalle Ollaksen.

Kallella on hyviä kokemuksia ohjelmistojen resurssipohjaisesta alihankinnasta julkishallinnolle. Sain Kallelta arvokkaita vinkkejä julkishallinnon “ketterän tarjouspyynnön” laatimiseksi siten, että se noudattaa hankintalakia:

• Tarvittavan ohjelmiston sijaan tarjouspyyntö kohdistetaan tarvittaviin henkilöresursseihin.
• Valitut yritykset/henkilöt sitoutetaan työskentelemään tilaajan ketterän projektijohdon alaisuudessa sekä tyypillisesti tilaajan omissa toimitiloissa, jolla saavutetaan kommunikointi- ja synergiaetu.
• Tarjouspyyntö kannattaa toteuttaa puitetyyppisenä, jolloin sopivia resursseja voidaan hankkia projektin aikana tarvittaessa useammalta toimittajalta. Tämä pitää vaihtoehdot laajempina ja toimittajat herkempinä, kun asiantuntijat voidaan tarvittaessa korvata helpommin.
• Asiantuntijoiden työympäristön, työkalujen (ellei käytössä ole omat työkalut) ja projektijohdon tulee olla asianmukaiset, jotta toimittajat uskaltavat tarjota projektiin parhaita asiantuntijoitaan.

Resurssipohjaisessa tarjouspyynnössä ei siis tarvitse kuvata ohjelmiston sisältöä. Näin hankintalain kirjain täyttyy vähemmällä paperimäärällä ja kehitysprojektin sisältö saa tarkentua ennen toteutuksen aloittamista.

Julkishallinnon näkökulmasta on tärkeää, ettei projekti karahda käräjille heti tarjouspyyntövaiheessa juridisen muotoseikan vuoksi, josta on Suomessa muutamia esimerkkejä. Oikeussalin pelko on aiheuttanut sen, että harva on uskaltanut rikkoa brezneviläistä perinnettä, jossa julkishallinto tilaa ohjelmistoprojekteja kuin sementtiä. Lopputulosta kuvaa ikävän usein sanonta “leikkaus onnistui, mutta potilas kuoli.”

Olisikohan jo aika ja keinot potilaan (suomalaisen tietoyhteiskunnan) pelastamiseen?

Paikkatietoikkunan julkinen tarjouspyyntö löytyy toistaiseksi HILMA-järjestelmästä sekä tämän artikkelin lopusta. Dokumentit on kirjoittanut Maanmittauslaitoksen Kehityskeskuksen Antti Rainio, Panu Muhli sekä ulkopuolisena avustajana toiminut Lare Lekman.

Resurssipohjainen tarjouspyyntö mahdollistaa ketterän kehityksen julkishallinnon ohjelmistohankkeissa. Mikäli organisaationne osaaminen ei vielä riitä ohjelmistokehityksen itsenäiseen johtamiseen, voitte hyödyntää joustavampaa resurssipohjaista mallia palkkaamalla “projektikonsultin vahtimaan kehityskonsultteja”. Samalla organisaationne projektiosaaminen päivittyy kertaheitolla ja saatte todennäköisesti edullisemman ohjelmiston, johon käyttäjät ovat tyytyväisempiä.

Paikkatietoikkunan tuotantoversion julkinen tarjouspyyntö:

• PaikkatietoportaaliTarjouspyynto091119
• Liite1VaatimustenTayttaminen091119
• Liite2Liikesalaisuudet091119
• Liite3Hintataulu091119
• Liite4Kompetenssitaulu091119
• Liite5Arviointitaulukko091119

Kuka on syyllinen?

Ennen joulua Kauppalehti julkaisi artikkelin otsikolla “Eduskunta pui it-pulmia: nörtit hihittävät ja käärivät rahat.” Artikkelissa löydetään kaksi syyllistä asioiden huonoon tilaan: nörtit ja puutteellinen valvonta. Suurin ongelma artikkelin mukaan on järjestelmien yhteensopimattomuus ja ratkaisu ilmeisesti velvoite yhteensopivien järjestelmien tekemiseen.

Jouluaattona taas Helsingin Sanomat toi asiaa esille haastattelemalla Valtiontalouden tarkastusviraston Tomi Voutilaista otsikolla “Valtion rahavahdin mielestä Suomen it-rahat valuvat konsulteille.” Helsingin sanomien artikkelissa syyllisiä ovat heikko asiakkaan johtaminen ja kovapalkkaiset, ahneet konsultit. Voutilainen ei varsinaisesti ehdota mitään korjauksia vaan luettelee pahimmat ongelmakohdat.

Kumpaankin artikkeliin saa jättää kommentteja ja niitä onkin jätetty ahkerasti, tällä hetkellä  yhteensä 189 kappaletta. Luin molempien kirjoitusten kommentit ja sieltä löytyi seuraavia syyllisiä (sulkeissa esiintymien määrä):

• Osaamattomat ja ahneet toimittajan konsultit. (18)
• Julkishallinnon asiakkaiden osaamattomuus (määrittelyt, vaatimukset). (15)
• Sisäänostajat (hankintailmoitukset, sopimukset, sanktiot, suurten toimittajien suosiminen). (15)
• Isot toimittajat lupaa yhtä ja tekee toista, lisäksi heillä on kartelli. (13)
• Hallitsematon yksityistäminen ja ulkoistaminen. (10)
• Poliitikot ovat pihalla tai lahjottuja. (9)
• Tietojärjestelmähankkeiden monimutkaisuuden aliarvioiminen (8)
• Suljetut rajapinnat ja lähdekoodin puute rajoittaa kilpailua. (7)
• Julkishallinnon sovellusten raskaan ei-toiminnalliset vaatimukset. (4)
• Toimittajan myyntiorganisaatio petkuttaa. (3)
• Virkamiehet välttelevät vastuuta. (3)
• Julkishallinnon huonot palkat pakottavat ostamaan konsultteja. (3)
• Liian vähän säätelyä (vrt. rakennusala). (2)
• Ostajan ja toimittajan yhteistyö määrittelyvaiheessa. (2)
• Vaatimusten muuttuminen sovelluksen käyttöaikana. (Sovellus oli hyvä, kun se otettiin käyttöön.) (1)
• Toimittajien välinen riitely. (1)
• Kun on sijoitettu jo niin paljon, on vain pakko antaa lisää rahaa. (1)
• VTV, jolla ei ole yhtään parannusehdotusta. (1)
• Tekniikan ehdoilla ostaminen. (1)

Tuli kyllä aika kattava lista erilaisia syyllisiä nykyisiin ongelmiin. Osaa ongelmista en osannut muuttaa syyllisen muotoon. Ehkä syyllisyyttä riittääkin jaettavaksi kaikille.

Luin kaikkia kommentteja ainakin sen verran, että tajusin, mikä niissä koettiin suurimmaksi ongelmaksi. Artikkelit luin kokonaan. Monet kommentit olivat todella hyvin kirjoitettuja ja jäsensivät ongelmia hyvin. Sen sijaan korjausehdotuksia oli kommenteissakin todella vähän. Olen myös itse huomannut, että mitä enemmän tätä asiaa selvittelee ja siitä lukee, sitä vähemmän uskon tietäväni varman ratkaisun kaikkeen.

Ainoa kommenteista löytämäni konkreettinen parannusehdotus, jonka itse ajattelisin nykytilannetta parantavan, on virkamiesten palkkojen nostaminen. Palkkoja pitäisi nostaa paljon, että itsekin miettisin julkiselle sektorille siirtymistä. Se voisi tuoda korjausta ainakin määrittelyyn, konsulttien käyttöön ja toimittajien valvontaan. Ehkä myös vastuunotto ja ulkoistaminen muuttuisivat toimivammiksi.

TIEKE:n seminaarin muistiinpanoja

TIEKE järjesti eilen eduskunnassa seminaarin Julkisesti avoin ja ketterä hankinta (video). Unohdin valitettavasti muistiinpanoni paikan päälle, mutta tässä ne seminaarin asiat, jotka jäivät päällimmäisinä mieleeni.

ValtIT:n johtaja Yrjö Benson puhui viranomaisten tietoarkkitehtuurin tehostamisesta. Nykyään jokaisen kansalaisen tiedot on tallennettu moneen rinnakkaiseen ja päällekkäiseen järjestelmään. Tämän seurauksena uusien järjestelmien kehittäminen ja vanhojen käyttö on hidasta ja kallista. Benson kertoi kolmesta lakialoitteesta, joilla tätä aiotaan korjata:

1. Viranomaisten pitää jakaa tietonsa maksutta toisten viranomaisten käyttöön. Tarkoitus on, että jokaisen viranomaisen on kannattavampaa käyttää jo olemassaolevaa tietoa kuin itse valmistaa rinnakkainen järjestelmä vastaavan tiedon tallentamiseen.
2. Viranomaisten pitää tarjota julkinen data maksutta yksityissektorin käyttöön. Julkinen data tarkoittaa sellaisia asioita kuin vesistö- ja maanmittaustietoja ja taloudellisia tilastoja. Toivon mukaan innovatiiviset yritykset sitten rakentaisivat koko kansantaloutta hyödyttäviä ratkaisuja näiden tietojen pohjalta.
3. Viranomaiset eivät saa pitää päällekkäisiä rekistereitä. Esimerkiksi eri viranomaiset eivät saisi tämän jälkeen kerätä erikseen henkilön yhteystietoja, vaan jokainen tallettaisi henkilötunnuksen (tai muun tunnisteen) ja tämän avulla viitattaisiin yhteiseen tietokantaan. Tämä olisi viimeinen askel yhteiseen tietoarkkitehtuuriin siirtymisessä.

Ohjelmistoarkkitehti sisälläni pitää tätä tietojen päällekkäisyyden poistamista järkevänä tavoitteena. Toisaalta hankkeen riskit ovat hyvin suuret. Mitä tapahtuu, jos koko Suomen henkilötietoja ylläpitävä tietokanta lakkaa toimimasta? Tämä on poikkeuksellsen iso projekti, ja koska projektien koko korreloi niiden epäonnistumistodennäköisyyden kanssa, mahdollisuus epäonnistumiseen on todellinen.

Nämä asiat ovat toki sellaisia, jotka on mahdollista ratkaista. Joka tapauksessa kaikkien on syytä tiedostaa, että tällaisessa projektissa riskien minimointi on ykkösasia. Siihen parhaat keinot ovat rakennettavan järjestelmän vaatimusten minimiointi, asteittainen käyttöönotto ja plan B siltä varalta, että hanke menee pieleen.

Jyrki Kasvi vastasi puheenvuorossaan kysymykseen “Millä lailla [onnistuneet julkiset ohjelmistohankinnat on] estetty?” Vastaus oli, että hankintalaki ei suoranaisesti estä järkeviä ohjelmistohankkeita. Kasvi esitti lisäksi neuvoja ja näkemyksiä siitä, miten julkiset ohjelmistohankinnat saadaan toimimaan:

• Kannattaa tietää tarkkaan, mitä tilaa. (Tulkitsin aluksi tämän tarkoittavan täsmällistä vaatimusmäärittelyä. Kun Kasvin puheenvuoron jälkeen esitin eriävän mielipiteeni, Jyrki vakuutti, ettei siitä ollut kyse, ja että näkemyksemme olivat melko samanlaiset. Oman kokemukseni mukaan siis täsmällisen määrittelyn sijaan tärkeintä on seurata projektin aikana, miten projekti etenee ja ohjata projekti vastaamaan todellisiin tarpeisiin, riippumatta siitä, mitä projektin alussa suunniteltiin.)
• Erityisesti on syytä selvittää, halutaanko tilata tietojärjestelmä, halutaanko kehittää toimintatapoja vai halutaanko jotain muuta. Jos halutaan tietojärjestelmä, mikä on siitä koituva lopullinen hyöty?
• Tarvittavaa ohjelmistoasiakkaana toimimisen asiantuntemusta ei usein löydy itse julkisesta organisaatiosta. Silloin kannattaa tilata “konsultti vahtimaan konsulttia”.
• Jos uusi tietojärjestelmä ei muuta toimintatapoja, sen edut ovat usein kyseenalaiset. Tietojärjestelmä sinällään harvoin nopeuttaa asioita, jos prosessointiin tarvitaan samat henkilöt samassa järjestyksessä kuin aiemminkin.

Kolmantena vuorossa oli Espoon kaupungin Timo Martelius teemalla “Muodollisesti välttävä”. Hän kertoi esimerkkejä Espoon hankinnoista (ei välttämättä ohjelmistohankinnoista), jotka oli tehty perinteisen hankintamenettelyn rajoja rikkoen.

• Ranskalainen huutokauppa: kiinteä hinta, kilpaillaan laadulla (tai toteutettujen vaatimusten määrällä). Tätä mallia mukaeltiin niin, että tarjoaja sai esittää lisävaatimuksille hinnan, joka toimi yhtenä (vai peräti ainoana?) arviointiperusteena. Lopulta kolme kilpailijaa tarjosi lisätoiveet ilmaiseksi ja voittaja jouduttiin ratkomaan näiden välillä arvalla. Ilmeisesti kaupunki yliarvioi projektin perustyön kustannukset, mistä syystä päädyttiin tähän tilanteeseen. Valintaan oltiin kuitenkin tyytyväisiä.
• Projekti, jossa ei kiinnitetty tuotetun palvelun tavoitetasoa. Kilpailulutuksessa kuvattiin asiakkaan tilanne ja tarve. Yksi tarjouskilpailun hävinnyt osapuoli valitti päätöksestä sillä perusteeella, etteivät tarjoukset olleet suoraan vertailukelpoisia. Valitus hylättiin.
• Puitesopimus, jossa puitejärjestelyyn päässeiden firmojen palveluista valitaan sopivat aina sähköisellä huutokauppamenettelyllä.

Kommenteissa tuotiin vahvasti esiin ohjelmistoprojektien erot “sementtisäkkien kauppaan” ja se etteivät Marteliuksen esimerkit välttämättä sovellu sinällään ohjelmistoprojekteihin.

Viimeisenä puhui tämän blogin Pentti Virtanen. Pentti esitti perustelut ja ohjeet ketterälle ohjelmistohankinnalle. Asia oli pitkälti samaa kuin mitä tässä blogissa on muutenkin esitetty ja tullaan esittämään, joten en pura sitä tähän. Toivottavasti Pentillä itsellään on aikaa kirjoittaa yhteenveto esityksestään tähän blogiin.

Kaiken kaikkiaan seminaari onnistui hienosti; puhujat olivat hyviä ja keskustelua käytiin oikeista asioista. Kiitos TIEKE:lle sen järjestämisestä!

Ominaisuuksia / euro

Scan-agile -konferenssin keskusteluissa kuulin ketteriä kehitysmenetelmiä julkishallinnossa kokeilleilta, että ne tuntuvat hyviltä projektin aikana, mutta projektin lopussa järjestelmässä on yllättävän vähän toiminnallisuutta. Vertailukohtana oli projekti, joka on alun perin kilpailutettu valmiilla määrittelyllä ja kiinteällä hinnalla. Näin ollen ketterä projekti tuottaisi vähemmän toimivaa tietojärjestelmää euroa kohti. Mitään objektiivista näyttöä ominaisuuksien toteutusnopeudesta erilaisissa projekteissa minulla ei ole, mutta uskon konferenssissa kuulemani havainnon pätevän monissa projekteissa. Ohjelmistoprojektien kilpailuttamisessa on useita tekijöitä, jotka edesauttavat tätä.

Kun monta tarjoajaa arvio projektin työmäärän, olisi yllättävää, jos joku ei arvioisi alakanttiin. Kaikissa avoimissa tarjouspyynnöissä on tietenkin sama vaara arvioida työmäärä väärin, mutta ohjelmistoprojektit ovat niin suuria suunnittelutehtäviä, että niiden työmääräriskit ovat suurempia kuin useimpien kilpailutettavien hankintojen. Koska hinta on usein tärkeäa valintakriteeri tulee työmäärän liian pieneksi arvoinut toimittaja helposti valituksi. Aina välillä näkee myös tarjouskilpailuja, joissa joku on tarjonnut projektia sisäänheittohintaan – ja hintaa on nimenomaan pienennetty työmäärää vähentämällä.

Asiakkaan ohjatessa projektia iteraatio kerrallaan on vaarana, että takerrutaan johonkin yksityiskohtiin liian pitkäksi aikaa. Asiakas saattaa myös teettää parempaa laatua vaikkapa käytettävyyden suhteen kuin hän saisi avoimessa tarjouskilpailussa. Kiinteähintaisissa projekteissa ei ominaisuuksia yleensä ole kuvattu kauhean tarkasti ennen projektia ja toimittaja ei tietenkään tee mitään ylimääräistä.

Kun projekti kilpailutetaan valmiiksi määriteltynä se on jo määritelty ja määrittely on maksanut rahaa. Vastaavan ketterän projektin pitäisi olla kevyemmin määritelty ja tämän kevyemmän määrittelyn pitäisi säästää rahaa itse projektiin. Kalenteriaikaa järjestelmän ostajat käyttävät valmisteluihin ennen projektia varmasti enemmän kuin projektin varsinainen kesto. Työtunteja tulee tietenkin vähemmän, mutta merkittävä määrä.

Mitä on projektin onnistuminen? Mahdollisimman paljon ominaisuuksia käytettyä rahaa kohti? Olisi todella kiinnostavaa päästä näkemään, ovatko ketterien projektien tuottamat ominaisuudet asiakkaan tarpeiden mukaisia. Uskallan väittää, että useimmissa kiinteällä hinnalla kilpailutetuissa projekteissa toteutetaan ominaisuuksia, joita ei koskaan käytetä.

TIEKE:n seminaari eduskunnassa 1.12.2009

TIEKE järjestää seminaarin Julkisesti avoin ja ketterä hankinta eduskuntatalossa 1.12.2009. Tämän blogin kirjoittajan Pentti Virtasen lisäksi tapahtumassa puhuvat kansanedustaja Jyrki Kasvi, valtion it-johtaja Yrjö Benson ja Espoon strategisen hankintatoiminnan johtaja Timo Martelius.

Seminaari tuli heti täyteen, mutta nyt tila on vaihdettu isompaan, joten vapaita paikkoja on muutama jäljellä. Ilmoittaudu tästä.

Open Spacen muistiinpanot

Pidimme tänään tunnin pituisen Open Space -session Scan-Agile-konferenssissa aiheesta “How should we encourage Agile in the Finnish public sector?”. Kaikki noin 20 osallistujaa olivat suomenkielisiä, joten englanninkielisestä otsikosta huolimatta puhuimme suomea. Kaikki osallistujat olivat käsittääkseni tuottajapuolen ihmisiä: ohjelmistosuunnittelijoita, myyjiä, projektipäälliköitä, jne.

Haasteita ketterien menetelmien käyttöönotolle julkisella sektorilla:

• Nykyinen sopimuskäytäntö lyö lukkoon järjestelmältä vaaditut ominaisuudet jo ennen projektin alkua.
• Pelko markkinaoikeudesta estää kilpailuttajia kokeilemasta joustavampia hankintatapoja.
• Todisteita ketterien menetelmien eduista julkisella sektorilla on vähän.
• Julkisissa organisaatioissa on jopa liikemaailmaa byrokraattisempi budjetointikäytäntö.
• Yhtenä syynä edelliseen: Media puuttuu helposti epäonnistumisiin, joissa on käytetty rahaa avokätisesti. Niinpä huonon julkisuuden välttämiseksi julkisella sektorilla on paineita pitää rahahanat niin tiukalla kuin mahdollista – eli kontrolloida ennakkoon sitä, mihin mikäkin euro käytetään.
• Julkiselta sektorilta puuttuu tuotehallintaosaamista. Tilataan mitä sattuu ja projektin aikana ei osata ohjata projektia kunnolla. Tuotteeseen liittyvää päätöksentekoa ei ole keskitetty tai projektin aikainen ohjaus puuttuu kokonaan.
• Julkisella sektorilla on yleinen illuusio siitä, että tuotekehityksen ongelmat pystytään välttämään riittävän tarkalla määrittelyllä projektin alkuvaiheessa. Päinvastoin pitäisi myöntää, ettei projektin alkuvaiheessa tiedetä tarkkaan, mitä halutaan, ja keskittyä tarkan määrittelyn sijaan huolelliseen projektin ohjaukseen.
• Projektit “eivät saa epäonnistua”, joten epäonnistuvia projekteja ei osata tappaa ajoissa.
• Myöskään toimittajat eivät välttämättä halua luopua vesiputousmallista. Tiukka vaatimusmäärittely takaa jonkinlaisen suojan tilaajan tekemiä määrittelyvirheitä vastaan. Toimittajat käyttävät tätä myös hyväkseen tarjoamalla halvalla (huonon) määrittelyn mukaista projektia ja laskuttamalla suurta hintaa muutoksista.

Ratkaisuja ongelmiin:

• Kerätään esimerkkejä parhaista käytännöistä ja levitetään niitä. Miten projektia kannattaa johtaa? Miten kilpailutetaan ja laaditaan sopimukset tehokkaasti mutta vailla pelkoa markkinaoikeudesta?
• Yritetään saada tilaajapuolen ihmiset keskustelemaan keskenään ja levittämään itse hyviä hankintakäytäntöjä keskuudessaan.
• Kannustetaan tilaajaa säilyttämään tilaamansa ohjelmistoprojektin tekijänoikeudet itsellään.

Lisäksi pyritään levittämään tietoamme ohjelmistoalan todellisuudesta:

• Projektin alussa ei tiedetä tarkkaan mitä halutaan. Kannattaa vaatia se, mikä tiedetään ehdottaman varmasti, mutta ei mitään muuta. Liian yksityiskohtainen vaatimusmäärittely vaikeuttaa projektin onnistumista merkittävästi.
• Kannattaa tilata kiinteällä hinnalla vain minimaalinen järjestelmä, joka täyttää vaaditun tarpeen. Lisäksi kannattaa varmistaa, että lisätyö (jota melkein joka tapauksessa tulee, riippumatta siitä, kuinka suuren järjestelmän on aluksi tilannut) on yhtä edullista kuin kiinteän hinnan työ.
• Kannattaa vaatia järjestelmän asteittaista toteuttamista ja käyttöönottoa. Mitä pidempään projektia tehdään ilman konkreettista tulosta, sitä nopeammin projektin riskit kasvavat.

Itselleni innostavinta sessiossa oli osanottajien suuri määrä ja innokas asiasta keskustelu. Konkreettisiin askeliin asian ratkaisemiseksi ei päästy, mutta ainakin meille tämän blogin kirjoittajille tämä antoi paremmat suuntaviivat jatkoa varten. Kaikki apu näiden asioiden toteuttamiseksi otetaan ilomielin vastaan!