Näin VR sotki lippujärjestelmänsä - Miksi it-projektit epäonnistuvat?

Julkaistu yli kolme vuotta sitten

VR:n uusi lipunmyyntijärjestelmä maksoi 15 miljoonaa euroa. Sen rakentaminen kesti kolme vuotta. Järjestelmä kesti käytössä noin kolme tuntia.

Syyskuun 14. päivän aamu ei ollut vielä valjennut, Helsingin päärautatieaseman kello näytti neljää. VR:n tietohallintojohtaja Jukka-Pekka Suonikko oli ollut työpaikallaan pian vuorokauden, edellisestä aamusta asti.

Suunnitelma oli kirjattu Exceliin minuutin tarkkuudella, sillä aikaa oli vähän: vain yksi yö. Vanha järjestelmä suljettiin, kun VR:n lipunmyynti hiljeni syyskuun 13. päivän iltana. Seuraavana aamuna uuden lipunmyynnin piti olla jo käytössä.

Kaikki näytti hyvältä. Uusi verkkokauppa oli juuri avattu, ja valvontamonitorit kertoivat, että ensimmäiset uteliaat surffaajat olivat jo löytäneet sivustolle. Päivästä tulisi vilkas.

Myös media seuraisi tarkasti, kuinka VR:n lipunmyyntiuudistus sujuu.

Kyseessä oli VR:n historian laajin it-projekti. Miljoonien eurojen myyntijärjestelmän uudistusta oli tehty jo vuodesta 2008. Lippuautomaatit ja konduktöörien laitteet oli vaihdettu ja vanhahtava verkkopalvelu oli päivitetty nykyaikaisemmaksi.

Oikeastaan uudistuksen piti olla valmis talvella, mutta aikataulu oli venynyt kaksi kertaa, koska ohjelmistot ja laitteistot olivat olleet keskeneräisiä. Julkaisua oli siirretty ensin maaliskuusta kesäkuuhun ja sitten syyskuun 14. päivään.

Junamatkustajille uusi lipunmyyntijärjestelmä oli sivuasia, isompi uutinen oli junalippujen hinnoittelun uudistuminen. Junalipusta saisi alennusta, jos sen ostaisi etukäteen.

Yleisöryntäys oli odotettavissa, joten VR oli pelannut varman päälle. Asiantuntijat olivat suunnitelleet järjestelmän, joka kestäisi pahimmatkin kävijäpiikit. Kapasiteettia oli lisätty vielä puolella asiantuntijoiden suosituksen päälle.

Rautatieaseman neljännen kerroksen projektitiloissa kävi kuhina läpi yön, kun 40 hengen asiantuntijajoukko ohjasi ja valvoi käyttöönottoa. Vanhoja järjestelmiä suljettiin, liikennettä ohjattiin uusiin.

Aamuviideltä avattiin Turun Kupittaan lipunmyynti, ensimmäinen asiakaspalvelupiste. Kaikki sujui hyvin.

Suonikko seurasi monitorilta verkkopalvelun kävijämääriä. Aamuseitsemältä ihmisten herääminen alkoi näkyä kasvavana liikennevirtana. Kahdeksalta tietoliikenne oli jo vilkasta.
Kahdeksan ja yhdeksän välillä kävijämäärä rikkoi kaikki aiemmat ennätykset – myös turvarajat, joiden mukaan järjestelmä oli suunniteltu.

Pian osa asiakkaista ei päässyt enää palveluun, ja nekin jotka pääsivät, joutuivat odottamaan sivujen latautumista pahimmillaan kymmeniä sekunteja. Tilanne paheni keskipäivän lähestyessä.

VR:n pääkonttorin naapurissa, päärautatieaseman lipunmyynnissä, asiakkaat alkoivat hermostua. Asiakaspalvelun laitteet muuttuivat yhä hitaammiksi, ja uudet pirteänvihreät lipunmyyntiautomaatit jumiutuivat ympäri Suomen.

Kaikki junaliput myydään saman varausjärjestelmän kautta, minkä vuoksi verkkopalvelun tuoma asiakastulva haittasi myös paperilippujen ostamista. Lopulta lippuja sai vain konduktööreiltä.

Pelkkä kävijämäärä ei kuitenkaan selittänyt kaikkia ongelmia, järjestelmässä oli jotain muutakin mätää. Suonikon työpäivä venyi 38 tunnin mittaiseksi.

Ohjelmoinnista tuli helppoa

Mikä it-alaa vaivaa? Hankkeet tuntuvat epäonnistuvan, vaikka niiden tavoitteet vaikuttaisivat yksinkertaisilta, kuten helppokäyttöisen lippukaupan tekeminen.

Sähköinen resepti viivästyi vuosikausia. Sampo Pankin asiakkaat saivat kärsiä, kun sen tietojärjestelmät yhdistettiin Danske Bankin kanssa. Kuntavaalit jouduttiin uusimaan Karkkilassa, Kauniaisissa ja Vihdissä, kun sähköinen äänestysjärjestelmä hukkasi 232 ääntä.

Lisäksi hankkeiden budjetit pyörivät mittaluokassa, jota on vaikea ymmärtää, ellei ole ollut niissä osallisena.

Huomiota on herättänyt muun muassa eduskunnan uusi tietojärjestelmä, jonka avulla asiakirjoja voi käsitellä sähköisesti yhden yhteisen järjestelmän kautta. Se tilattiin 4,7 miljoonalla eurolla.

On perusteltua ihmetellä, kuinka esimerkiksi julkishallinnon projektit maksavat yhä miljoonia, vaikka ohjelmointityö muuttuu vuosi vuodelta helpommaksi. Erilaiset lippupalvelut, lomakkeet ja viestintäjärjestelmät on tehty jo useaan otteeseen, ja niiden suunnittelua opetetaan yliopistojen peruskursseilla.

Samaan aikaan muutaman hengen start-up-yritykset ympäri maailman tekevät teknisesti edistyksellisiä tuotteitaan murto-osan budjetilla.

“Tuntuu, että julkishallinnon hankkeissa on jämähdetty 20 vuoden takaiseen aikaan, jolloin tietoprojektit olivat jättihankkeita”, sanoo tekniikan tohtori Risto Sarvas ohjelmistoyritys Futuricesta.

“Tärkein huomio on, että it-järjestelmät eivät ole enää suuria ja kalliita eivätkä ne vaadi vuosien kehittämistä.”

Tekniikka on kehittynyt merkittävästi 1990-luvulta. “Ohjelmakoodin tuotantokustannukset lähenevät nollaa”, Sarvas sanoo.

Toimiviksi havaittuja, valmiita ratkaisuja on olemassa niin paljon, että ohjelmoija saa aikaan näkyviä tuloksia yhä nopeammin.

Alan harrastajakin pystyy valmiita osia ja palveluita hyödyntämällä rakentamaan verkkosivuston, joka palvelee joustavasti ja katkotta koko Suomen käyttäjiä. Eikä sen tekemiseen tarvitse käyttää vuosikausia tai edes kuukausia, saati satojatuhansia euroja.

Tilauksissa paljon turhaa

Ongelmat alkavat usein jo ostamisesta – ennen kuin riviäkään ohjelmakoodia on kirjoitettu.

Laki vaatii kilpailuttamaan yli 30 000 euron arvoiset julkiset ohjelmistohankinnat. Silloin tilaaja laatii tarjouspyynnön, jossa kuvataan järjestelmältä vaaditut ominaisuudet sekä kerrotaan ne kriteerit, joilla toimittajavalinta tehdään.

Lain mukaan toimittaja täytyy valita joko hinnan tai kokonaistaloudellisuuden perusteella. Se voi viitata esimerkiksi käyttökustannuksiin tai muihin tarjouspyynnössä mainittuihin kriteereihin.

Nykyistä hankintamallia kritisoidaan usein epäsopivaksi ohjelmistojen, eli asiantuntijatyön ostamiseen. Yksi ongelma on hankintojen paisuminen, kun työtä ostetaan projektiluontoisesti.

Hankintamenettelyssä ohjelman ominaisuudet pyritään määrittämään huolellisesti etukäteen. On kuitenkin äärimmäisen vaikea ennustaa, mitkä ominaisuudet ovat oleellisia ja mitkä eivät.

Mukaan otetaan varmuuden vuoksi vähän liikaakin. Usein siteeratun tutkimusyritys Standish Groupin arvion mukaan tilattujen ohjelmistojen ominaisuuksista 45 prosenttia on turhia.
Se tarkoittaa montaa haaskattua euroa ja työtuntia.

“Nykyään yritetään priorisoida niitä ominaisuuksia, jotka ovat ehdottoman tärkeitä, mutta se on helpommin sanottu kuin tehty”, sanoo ohjelmistotekniikan professori Pekka Abrahamsson Helsingin yliopistosta.

Jättimäiseksi kasvaville hankkeille on Suomessa vähän tekijöitä. Toimittaja joutuu puntaroimaan suurten hankkeiden riskiä tarkkaan, sillä tarkan työmääräarvion tekeminen on aina jossain määrin arvailua. Toisaalta tilaaja haluaa vakavaraisen ja luotettavan – eli suuren – toimittajan.

Jäljelle ei jää Suomessa montaa ehdokasta. Uutisissa pyörivät samat nimet, kuten Accenture, Tieto, Logica ja Fujitsu.

Toimittajavalinnassa hinnan merkitys on suuri. Tarjouskilpailuista tippuneet yritykset esittävät usein toivomuksen siitä, että laatua arvioitaisiin nykyistä tarkemmin ja sen merkitystä korostettaisiin.

Heikkolaatuisen ohjelmiston korjailu ja ylläpito voivat osoittautua monin kerroin luultua vaikeammiksi tai kalliimmiksi.

VR:llä yllättäviä vikoja

“Työtä todella tehtiin yötä päivää”, VR:n Suonikko sanoo. Alihankkijat pyysivät paikalle asiantuntijoita ulkomailtakin. Oli kiire, koska koko järjestelmä oli jumissa, myös lipunmyyntiautomaatit.

Uusi palvelu oli suunniteltu kestämään helposti suurin koskaan koettu kävijämäärä, tuhkapilven aikana syntynyt 420 000 latauksen ennätys. Ensimmäisenä päivänä latauksia oli 1,2 miljoonaa.

Jonottamista ei tietokonemaailmassa tunneta, vaan kaikki verkkokaupan kävijät pyrkivät virtuaaliselle lippuluukulle samanaikaisesti. Kaikki verkkopalvelun asiakkaat saavat huonoa palvelua, jos laitteiden teho loppuu kesken.

Hitausongelmaa alettiin ratkoa monella eri suunnalla, sillä varausjärjestelmä oli rakennettu alihankkijoiden yhteistyönä.

Accenture oli vastannut järjestelmän tekemisestä, mutta sen alihankkija Enfo oli toimittanut lipunmyyntiautomaatit ja konduktöörien laitteet. Tieto vastasi konesaleista ja palvelimista, joilla järjestelmä pyöri. Lisäksi yksi osa, paikkavarausjärjestelmä, oli peruja vanhasta lippukaupasta, ja oli alun perin Logican tekemä.

VR pyysi Tietoa kolminkertaistamaan palvelinkapasiteetin heti ensimmäisenä päivänä. Se ei kuitenkaan ratkaissut tilannetta. Paljastui, että palvelimet toimivat epävakaasti, koska niiden ohjelmistoissa oli tunnettu, mutta korjaamatta jäänyt vika.

Ongelma ei ollut paljastunut kuormitustesteissä. Lippuja myydään automaateissa, tiskeillä, verkossa ja junassa, eikä joka suunnasta tulevaa kuormitusta ollut osattu simuloida etukäteen tarpeeksi realistisesti.

Paljastui myös, että lippuautomaateissa oli vika, joka kuormitti muuta varausjärjestelmää tarpeettomasti. Automaatit päätettiin sulkea korjaustöiden ajaksi. Ne venyivät lopulta lähes kahteen viikkoon.

Tärkein hyytymisen syy oli kuitenkin yllättävän suuri kävijämäärä, Suonikko sanoo.

“Heti alkupäivien aikana huomattiin, että kuormitus jää hyvin korkealle tasolle eikä tule palaamaan lähellekään sitä, mitä se oli aiemmin.” Alun huippulukujen jälkeen sivulatausten määrä jäi yli 500 000:een, yli kaksinkertaiseen aiemmasta.

Verkkokaupassa otettiin käyttöön ominaisuus, joka rajoittaa kävijämäärää silloin, kun samanaikaisia käyttäjiä alkaa olla liikaa. Pikaisesta muutoksesta seurasi ongelmia: osa asiakkaista ei enää saanut lippua, vaikka rahat katosivat tililtä.

Virheellisesti toiminut rajoitin saattoi potkia maksaneen asiakkaan ulos palvelusta ennen kuin tämä ehti saada lippuaan. Tämäkin ongelma oli jäänyt testeissä löytämättä. Rajoitinominaisuutta ei ollut alun perin tarkoitus edes käyttää.

Kun käyttöönotosta oli kulunut viikko, korjaustyöt olivat edelleen kesken.

Iso hanke onnistuu harvoin

It-projektia ei voi johtaa tehdastyön periaattein. Jo vuonna 1975 IBM:n insinööri Fred Brooks huomasi tärkeän piirteen: myöhässä olevaan ohjelmointiprojektiin ei kannata lisätä työvoimaa, sillä se saa projektin myöhästymään entistä enemmän.

Ohjelmistosuunnittelu on asiantuntijatyötä, joka vaatii omat johtamistapansa. Mutta parhaiden käytäntöjen keksiminen on osoittautunut vaikeaksi, eikä onnistumisia ole ollut helppo toistaa.

Ihmiset tekevät virheitä, ja niitä tulee sitä todennäköisemmin, mitä monimutkaisemmista töistä on kyse. Nasa hukkasi 120 miljoonan dollarin Mars-luotaimen, kun osa insinööreistä käytti metrijärjestelmää, osa brittiläistä.

Standish Groupin tutkimuksen mukaan vuonna 2009 vain 32 prosenttia uusista it-projekteista valmistui aikataulussa ja budjetissa, ilman merkittäviä virheitä.

Sen aiemmassa tutkimuksessa kävi ilmi, että yli kymmenen miljoonan dollarin hankkeista onnistui vain joka viideskymmenes. Alle 750 000 dollarin hankkeista onnistui 46 prosenttia.
Standish Group arvioi it-hankkeita tutuin projektimittarein: pysyivätkö ne aikataulussa, tuliko yllätyksiä, ylittyikö budjetti.

Tapaa on moitittu huonoksi, sillä käyttäjät arvioivat onnistumista eri tavoin. Lääkärille sähköinen potilastietolomake on hyödyllinen vain, jos sen käyttö on paperilomaketta nopeampaa tai jos se parantaa potilasturvallisuutta.

Mitä hyötyä on arviosta, josta ei käy ilmi, onko “onnistunut” järjestelmä helppokäyttöinen vai lähes käyttökelvoton?

Kankeus käy kalliiksi

It-epäonnistumisten taustalla on usein sama syy: liian etupainotteinen suunnittelu.

It-hankkeissa olisi tärkeää pystyä pitämään uutta tietoa ja uusia ideoita positiivisina asioina, ei uhkina alkuperäiselle suunnitelmalle. Jos esimerkiksi koekäyttäjä tai ohjelmoija keksii tärkeän parannusidean, olisi hyvä, että muutos pystyttäisiin tekemään lopulliseen tuotteeseen.

Muutosehdotuksia tulee kuitenkin vuosikausia kestävien projektien aikana suunnattoman paljon. Jos työtapa on kankea, hyviäkään ideoita ei voi huomioida tai ne saattavat pysäyttää koko työn edistymisen.

Perinteisessä työtavassa, jossa projektin sisältö ja aikataulutus on saneltu etukäteen, ja kenties jopa vahvistettu tiukoin sopimuksin, törmätään ongelmiin. Tilaaja haluaa saada mahdollisimman paljon, toimittaja haluaa tehdä mahdollisimman vähän.

Lisäksi työskentely muistuttaa usein niin sanottua vesiputousmallia, jota on parjattu alan oppikirjoissa viimeiset neljäkymmentä vuotta.

Vesiputousmalli tarkoittaa työtapaa, jossa edetään suoraviivaisesti vaiheesta toiseen: ensin suunnitellaan, sitten toteutetaan, lopuksi testataan ja julkaistaan.

Sen seurauksena projektin puutteet paljastuvat vasta aivan loppuvaiheessa, jolloin niiden korjaaminen on vaikeaa ja erityisesti kallista.

Kokemus osoittaa, että toimivien ja helppokäyttöisten järjestelmien tekeminen edellyttää jatkuvaa testaamista ja koekäyttäjien osallistumista.

Se, että lääkärit kiroilevat huonosti toimivia ja vaikeasti käytettäviä tietojärjestelmiä, kielii vesiputousmallin käyttämisestä: lääkärit osaisivat antaa korjausehdotuksia, mutta heidän ideoitaan ei voida huomioida, koska ominaisuudet lyötiin lukkoon jo vuosia sitten projektin alkuvaiheessa.

Sama ongelma vaivaa useita suurella budjetilla, yhtenä projektina tehtyjä palveluita: niissä on virheitä ja järjettömyyksiä, jotka on varmasti huomattu. Suunnan vaihtaminen vain on onnistunut yhtä kankeasti kuin Titanicilla.

Palaute korvaa suunnittelun

“On parempi epäonnistua nopeasti ja edullisesti kuin kolmen vuoden päästä jättimäisesti”, sanoo ohjelmistoyritys Reaktorin operatiivinen johtaja Timo Lukumaa.

Reaktor on yksi 2000-luvulla perustetuista suomalaisista ohjelmistoyrityksistä, jotka luottavat niin sanottuihin ketteriin menetelmiin it-hankkeiden toteuttamisessa. Uudet menetelmät pohjautuvat siihen huomioon, että suunnittelutyön ennustaminen pitkälle tulevaisuuteen on vaikeaa. Työ pyritään organisoimaan siten, että virhearvioinneista voidaan ottaa opiksi mahdollisimman pikaisesti.

Kun ohjelmiston tekeminen aloitetaan ketterin menetelmin, ei kirjoiteta monikymmensivuista vaatimusmäärittelyä. Sen sijaan selvitetään tarkasti, mitä käyttäjä haluaa ohjelmalla tehdä.

Sen jälkeen ohjelmistoa yksinkertaisesti aletaan toteuttaa, osa osalta.

Ohjelmiston ensimmäinen toimiva palanen valmistuu pikaisesti, ja sitä voidaan välittömästi arvioida.

Jos tiimi on tehnyt esimerkiksi sähköisen lomakkeen lääkärin käyttöön, lomake voidaan antaa oikean lääkärin arvioitavaksi, vaikka muu järjestelmä olisi vielä kesken. Palautteen pohjalta lomaketta voidaan parannella, ja uusi versio voi olla valmis jo seuraavalla viikolla.

Ajatustapaan kuuluu, että uusi versio ohjelmistosta voidaan julkaista vaikka päivittäin. Testausta tehdään jatkuvasti, jolloin loppuvaiheeseen ei pitäisi jäädä suuria yllätyksiä. Tiheän julkaisutahdin ansiosta asiakas näkee koko ajan, kuinka työ edistyy.

Sen sijaan, että projektille tehtäisiin vuosikausien pituinen tarkka aikataulu, ohjelmiston toiminnallisuuksia aletaan tehdä tärkeysjärjestyksessä. Kehitystyö voi tapahtua prosessina niin pitkään kuin se on järkevää. Useimmiten parannuksia tehdään pitkään julkaisun jälkeenkin, jopa palvelun eliniän ajan.

Mikään yksittäinen menetelmä ei ole kuitenkaan ratkaisu it-alan ongelmiin. Ketteristä menetelmistä on saatu hyviä kokemuksia, mutta nekään eivät pakota esimerkiksi suunnittelemaan käyttäjäystävällisiä järjestelmiä.

Jälkiviisaus on helppoa

Yhteistyön ongelmat vaivaavat jokaista it-hanketta. Tiedonkulku vaikeutuu, kun projektiin osallistuu eri alojen ihmisiä eri yrityksistä. Lisäksi yhteistyöhön osallistuvat alihankkijat ovat usein kilpailijoita keskenään.

VR:n alihankkijoilta meni viisitoista päivää ongelmien korjaamiseen. Mitä projektista voisi oppia?

“Jälkiviisaus on aina helppoa”, Suonikko toteaa. “Teknisen suorituskyvyn kysymykset eivät ole itsestään selviä ja niihin täytyy suhtautua vakavasti.”

Suonikko painottaa myös kokonaisvastuun merkitystä projektissa, jossa on monta alihankkijaa.

“Siinä tilanteessa kun ongelma syntyy, ei voi tehdä muuta kuin korjata se kuntoon”, Suonikko toteaa. Tärkeintä olisi kuitenkin estää ongelmien synty jo etukäteen. “Jälkeenpäin nousee kysymys, oliko yhteistyö sittenkään riittävän toimivaa.”

VR uusi verkkopalvelunsa, jotta sen kehittäminen olisi jatkossa helpompaa. Tulossa on esimerkiksi uusia mobiilipalveluita. “Ollaan tietyllä tavalla kehityspolun alussa”, Suonikko sanoo.

Mutta ihmisen muisti on valikoiva. Kehityspolusta, uusista ominaisuuksista ja uudesta hinnoittelusta huolimatta matkustajat muistavat vain, kuinka vaikeaa junalipun ostaminen oli syksyllä 2011.

Esimerkkinä Sampo Pankki, Sitra ja eResepti

Sampo Pankin 200 miljoonan euron tietojärjestelmäuudistus vuonna 2008 lähti liikkeelle kangerrellen.

Pankin järjestelmät oli määrä yhdistää emoyhtiö Danske Bankin järjestelmiin pääsiäisen aikana, mutta uudistuspäivänä verkkosivuilla näkyi pelkkä vikailmoitus.
Se oli vasta alkusoittoa.

Alihankkija IBM:n laitteet kaatuivat kolme päivää käyttöönoton jälkeen. Lisäksi järjestelmästä löytyi lukuisia ohjelmointivirheitä.

Seuraavina kuukausina maksukortit lakkasivat useita kertoja toimimasta, ja asiakkaat valittivat verkkopankin toimintahäiriöistä.

Danske Bankin toimitusjohtaja Peter Straarup antoi Helsingin Sanomille elokuussa 2008 tutulta kuulostavan selityksen julkaisupäivän ongelmista:

“Verkkopankin käyttömäärä ylitti kolminkertaisesti arvion, jonka saimme Suomesta. Ihmiset olivat uteliaita ja tulivat kokeilemaan uutta pankkia. Ensimmäisenä päivänä verkkopankkiin kirjautuneiden määrä oli aivan eri tasolla kuin koskaan edellisen järjestelmän aikana.”

Sampo Pankki menetti vuonna 2008 yli 27 000 henkilöasiakasta. Lisäksi se maksoi hyvitysmaksuja saman vuoden huhti-kesäkuussa kuuden miljoonan euron edestä.

Hidas eResepti

“Emme anna minkäänlaista aika-arviota, koska koekäyttö on siirtynyt jo viisi kertaa”, ilmoitti Kotkan kaupungin projektipäällikkö Johanna Andersson Mediuutisille helmikuussa 2010.

Sähköisen reseptin käyttöönoton piti alkaa Suomessa jo vuonna 2008, mutta toisin kävi. Kotkassakin ensimmäinen resepti kirjoitettiin vasta huhtikuussa 2011.

Ajatuksena sähköinen resepti kuulostaa simppeliltä. Lääkäri kirjaa lääkemääräyksen reseptijärjestelmään, josta apteekki voi sen tarkistaa. Paperilappuja ei tarvita, vaan potilas voi noutaa lääkkeet pelkällä henkilötodistuksella.

Järjestelmän käyttöönotto on kuitenkin viivästynyt.

Apteekeissa ja terveysasemilla on käytössä useita eri tietojärjestelmiä, jotka täytyy kaikki saada keskustelemaan kansallisen järjestelmän kanssa.

Järjestelmätoimittajia on useita, ja yhteistyön hitaus on yllättänyt. Viimeisimpien arvioiden mukaan sähköinen resepti on joka toisen suomalaisen ulottuvilla vasta tämän vuoden lopussa.

Lain mukaan sähköisen reseptin tulee olla käytössä julkisessa terveydenhuollossa huhtikuussa 2013 ja yksityisessä huhtikuussa 2014.

Ketterä hankinta

Kun Suomen itsenäisyyden juhlarahasto Sitra alkoi uudistaa verkkopalveluaan vuonna 2010, se haki hankkeelle toteuttajaa poikkeuksellisella kilpailutuksella.

Kilpailutuksen ensimmäisessä vaiheessa hakijoiden tuli nimetä työhön tarjoamansa tiimin jäsenet. Sitra arvioi yrityksiä ja niiden ehdottamia tiimejä yksittäisten jäsenten työkokemuksenperusteella ja lähetti lopulta tarjouspyynnön kahdeksaan paikkaan.

Toisessa vaiheessa tarjouksia arvioitiin perinteisemmin: Sitra arvioi muun muassa yritysten tekemiä verkkosivuluonnoksia sekä ehdotettuja teknologioita ja työtapoja.

Kilpailutus päättyi tulikokeeseen, jossa kaksi finalistiyritystä sai viikon aikaa näyttää osaamisensa. Molemmat yritykset saivat 150 tuntia ja 5 000 euroa Sitran verkkopalvelun demoversion toteuttamiseen mahdollisimman pitkälle.

Sitra laati listan toivotuista ominaisuuksia, ja yritykset saivat päättää, mitä ominaisuuksista ne halusivat toteuttaa. Suorituksia arvioitiin työn tehokkuuden, työmenetelmien ja laadun perusteella.

Molemmat tarjoajat rakensivat kiireisen pyrähdyksen aikana toimivan demosivuston, jossa oli suuri osa toivotuista ominaisuuksista.

Juttu on julkaistu ensimmäistä kertaa Suomen Kuvalehdessä 3/2012.

Kuvitus Jorma Marstio, Katja Saarela, Markus Pentikäinen, Lehtikuva.