Valtio perustaa IT-yksikön, jolle annetaan kaikki julkiset urakat ilman kilpailutusta: Ne tuplaavat tuon 1.8 miljardia kustannukset, koska kukaan ei edes voi tarjota parempaa diiliä ja virkamiehille kyllä paisutettu budjetti maistuu. Valtion elimet ovat monopoliaseman huipentuma, koska niillä ei usein ole laillista kilpailua laisinkaan.
Tämän potilastieto-katastrofin ongelma ei ollut se, että asian selvittäminen hoidettiin yksityisin voimin, vaan se ettei selvitystä osattu/viitsitty/haluttu kilpailuttaa asianmukaisesti.
Jokaisessa skenaariossa on omat toki omat painajaislopputulemamahdollisuutensa. Hyvässä skenaariossa valtion IT-yksikköä johtamaan palkattaisiin hyvällä liksalla tiimi rehellisiä teknologian huippuosaajia, teknisessä mielessä kunnianhimoisia arkkitehtejä, jotka ottaisivat tietojärjestelmätarpeet haltuun ja tuottaisivat järjestelmiä jotka juoksevat kuin porsliiniunelmien junan vessa. Tuntemani softa-arkkitehdit ovat juuri tälläisiä ihmisiä; raha on heille hyvä bonus, mutta todellinen motivaatio heille tulee siitä on mahdollisuus tehdä jotain hienoa ja mullistavaa urallaan. Tässä skenaariossa siis näillä arkkitehdeillä olisi ylin päätäntävalta tässä yksikössä, heidän yllään olisi sitten kumileimasinta heilutteleva valtion taho, jolla ei olisi sanomista projektin sisältöön, paitsi jos budjetti mene järjettömyyksiin. Heidän apunaan olisi määrittelytiimi, joka olisi täydellisen perehtynyt esim. juuri Suomen sairaalamaailman prosesseihin.
Usein se, mihin järjestelmäprojektit kaatuvat, tai siis miksi softasta tulee raskasta ja huonosti käytettävää, on asiakkaan aikaansaamattomuus ja tietämättömyys ynnättynä IT-firmojen rahanahneuteen, ja siihen, että oikeastaan monimutkaisen ja huonosti toimivan järjestelmän kehittäminen tulee paljon kannattavammaksi IT-firmoille. Kun aikataulut venyvät ja lisää ongelmia tulee, yleensä asiakas maksaa. Näiden firmojen "tehtävänä" on siis venyttää projektia. Valtion IT-konsultti taasen voisi saada bonuksia sitä myötä miten hyvin järjestelmäprojekti itsessään etenee.
Sovelluskehittäjän tasolla projektien ongelmat näkyvät niin, että syy huonoihin ratkaisuihin on se mieletön bullshitti mikä seuraa sopimusasioihin liittyvästä väännöstä ja kieroilusta. Siitä kun on pakko nostaa kädet pystyyn asiakkaan aikaansaamattomuuden ja osaamattomuuden edessä. Ja sitten tehdään hölmöjä ratkaisuja kun kun tietämätön asiakas tai sopimusväännöstä kimpaantunut pomo niin sanoo. Pomo taasen ei yksinkertaisesti vain ymmärrä että mitä sillä sovellustasolla oikeasti tarvitsee tehdä jotta homma pelittäisi paremmin, tai häntä ei kiinnosta. Sitten homma kustaan sovellustasolla sillä asenteella että: "Olkoon tuo spagetti nyt siellä, saivat mitä halusivat". Tai sitten: "Noh, ei nyt paranneltu komponenttia X kun ei saatu siihen yhtään aikaa". Sitten asiakas on epätyytyväinen ja valittaa kun järjestelmä ei toimi niin nopeasti ja virheitä on, ja sovelluskehittäjien tekisi mieli laittaa hanskat naulaan.
Hyvässä skenaariossa siis järjestelmän kehittäjä olisi myös asiakas, päätäntävaltainen siitä mitä tehdään ja miten, ja tavoitteena myös tuottaa säästöjä yksikölleen ja pitää budjetti kurissa, eli ei ostaa niitä Oraclen komponentteja mitä ei oikeasti tarvita. Mutta, ollen tietoinen siitä mitä siellä pitää OIKEASTI tehdä, eli komponentti X pitää tehdä hyvin eikä sitä saa ryssiä, ja siihen voi kuluttaa nyt hieman enemmän aikaa, siksi kehittäjällä on oikeasti täysi päätäntävalta ja järjestelmä hallussa. Eli siis siten, ettei joku asioista tietämätön ole siellä panikoimassa, huohottamassa niskaan ja tekemässä huonoja päätöksiä johtuen omasta ymmärtämättömyydestään ja kyvyttömyydestään.
