Amos Ahola Kohtuus kaikessa, kohtuudessakin.

kalliiksituli.com

  • Klassikko.
    Klassikko.

Tieto voittaa eli suomalaisten julkisten it-hankkeiden surullinen tarine (Image 29.12.2015) - esimerkkitapaus oli yli 600 000 euron projekti (yli puolet liikaa), joka oli aikataulusta myöhässä (vuosia), ja lopulta kyykkäsi kriittisenä hetkenä.

Leipätyössäni toimin hiljattain vastaavan verkkojulkaisuprojektin omistajana, ja päätin nyt jakaa joitakin (mielestäni) parhaita käytäntöjä, joista julkissektori voi vapaasti ammentaa vastaisuudessa, voitte sitten vaikka laskea jotain veroa vastapalveluksena.

1. Jokaisella ohjelmistoprojektilla pitää olla omistaja, joka vastaa päänahallaan siitä, että projektin tavoitteet toteutuvat, ja että se pysyy budjetissa, aikataulussa, ja toteutetaan määritellyssä laajuudessa (scope).

2. Jokaisella projektilla pitää olla projektipäällikkö, joka huolehtii käytännössä siitä että ylläoleva tapahtuu.

3. Jokaisella projektilla pitää olla tuoteomistaja (product owner), jolla on paras substanssiymmärrys siitä mitä ollaan tekemässä. Tuoteomistajan kannattaa olla se henkilö, joka joutuu käytännössä työskentelemään projektin jälkeen lopputuloksen kanssa.

4.Jokaisella projektilla on ohjausryhmä, joka huolehtii siitä, että projektin tavoitteet ovat sidosryhmien tarpeiden mukaisia, ja katsoo projektin omistajan perään (vrt. osakeyhtiön hallitus ja toimitusjohtaja).

5.Projektinhallinnassa noudatetaan organisaation parhaita käytäntöjä, ja niiden noudattamista seuraa nimitetty taho. Jos projektin omistajan näkemys on ristiriidassa näiden käytäntöjen kanssa, hänen päätöksensä ratkaisee.

6. Projektin määrittelyvaihe/konseptointivaihe on syytä toteuttaa erillisenä harjoituksena, eikä sitä pidä leipoa mukaan toteutusvaiheen tarjouspyyntöihin.

7.Projektin suunnittellun toteutusvaiheen (se vaihe jossa toimittaja koodaa rahaa vastaan) ei pitäisi ylittää kuutta kuukautta, ja yli vuoden mittainen suunniteltu toteutusvaihe tarkoittaa että jotain on suunniteltu väärin (yleensä projektin laajuus on liian suuri).

8.Tarjouspyyntö on syytä lähettää yli viidelle toimittajalle, ja sekä toteutusvaihe että toteutuksen jälkeinen ylläpito kannattaa leipoa samaan tarjouspyyntöön (näin estetään ns. perävalot näkyy - efekti, ja sekä saalistushinnoittelu).

9.Tarjouspyyntöä ei pidä lukita tiettyihin teknologioihin, vaan toimittaja saa ehdottaa sitä mikä heistä parhaiten tilanteeseen soveltuu. Yleensä pitkälle tuotteistetut teknologiat näkyvät tarjouksissa alempina hintoina sekä toteutuksessa että ylläpidossa (vrt. koodataan puhtaalta pöydältä uniikkia).

10. Projektin lopputulos kannattaa kapseloida valitulle toimittajalle niin, että he ovat kokonaisvastuussa palvelusta, sekä toimii single point of contactina kaikissa ongelmatapauksissa (ohjelmisto, palvelimet, verkko, tietokannat...). Toimittaja saa alihankkia nämä miten tahtoo, mutta vastaa niistä sovitun hinnoittelun mukaisesti.

11.Kun tarjouspyyntö lähtee riittävän monelle kyvykkäälle toimittajalle, toimittajien hinnoittelu perustuu pitkälti riskiin - mitä paremmin toimittaja osaa toteuttaa pyydetyn, sen halvempi tarjous yleensä on.

12. Merkittävin tekijä tarjouyspyynnöissä on referenssit - kuinka monelle tyytyväiselle yritykselle toimittaja on aikaisemmin toteuttanut vastaavan projektin.

13. Jos referenssejä ei löydy yhdeltäkään toimittajalta, projektin olemassaolo kannattaa kyseenalaistaa - kaikki on tehty jo aikaisemmin muodossa tai toisessa, mitä ei ole, sitä ei luultavasti kannata tehdä.

---

Lista ei ole kattava, lisää varmasti tulisi jo puristaisin, mutta nyt pitää lähteä kummipojan syntymäpäiväjuhlille. Saatan palata Imagen kirjoitukseen eri kulmasta, eli mitä julkishallinnon himmeleille pitäisi tehdä jotta tilanne paranisi, mutta ensimmäinen askel jo tästä: projektinomistajat, kasvattakaa selkäranka ja sanokaa ei päättömille ohjeille.

---

Jos haluat nähdä uutta verta kunnallisvaaleissa, niin täytä toki Viskipuolueen kannattajakortti: http://viskipuolue.fi/kannattajakortit/

 

Piditkö tästä kirjoituksesta? Näytä se!

8Suosittele

8 käyttäjää suosittelee tätä kirjoitusta. - Näytä suosittelijat

NäytäPiilota kommentit (6 kommenttia)

Käyttäjän kosonenjuhapekka kuva
Juha-Pekka Kosonen

Ei voi kuin naurahtaa, kun katsoo linkittämääsi kuvasarjaa ja miettii, kuinka hyvin tuo kuvasarja referoi valtion käyttämiä tai tilaamia ohjelmistoja.

Useimpien valtionhallinnon ohjelmistojen ainoa notkeus lienee nimenomaisesti laskutuspuolella. Käytettävyys sitä ei todellakaan ole.

Käyttäjän TimoKohvakka kuva
Timo Kohvakka

Pakko suositella. Kerrankin asiantunteva tietopaketti olennaisista asioista aanelosella. Tämä bloggaus kuuluisi pakkolukemistoon etenkin julkisen puolen IT-hankintoja tekevälle.

Käyttäjän magi kuva
Marko Grönroos

Toi ekassa virkkeessä oleva linkki on rikki.

    «9. Yleensä pitkälle tuotteistetut teknologiat näkyvät tarjouksissa alempina hintoina sekä toteutuksessa että ylläpidossa (vrt. koodataan puhtaalta pöydältä uniikkia).»

Näistä julkisista jättihankkeista tulee taas mieleen Apotti, jossa minusta on ongelmana juuri tämän käänteinen ongelma. Valitun toimittajan järjestelmät perustuvat jo 50 vuotta vanhaan teknologiaan. Kilpailut voitetaan, koska järjestelmään on väännetty kallioluolissa kaiken maailman ominaisuuksia jo sen 50 vuotta. Kovin edistykselliset jutut tai edes integrointi sellaisiin voi olla aika kovan työn takana. Vaikka vanha teknologia hidastaa kehitystä jo merkittävästi, kilpailijat eivät pääse markkinoille, koska niillä ei ole varaa investoida 5 vuoden kehitystyöhön, jolla pääsisi samalle tasolle. Myös tärkeimmäksi katsomasi kohdan 12 referenssien osalla tällainen dinosaurus voittaa kaikki.

Puhtaalta pöydältä koodaaminen ei tarkoita uniikin koodaamista – järjestelmä voidaan suunnitella vähintään yhtä geneeriseksi kuin vanha ja vielä laajemmalla kokemuksella, kun siinä vanhassa on ehkä jouduttu hakkaamaan torttua tortun päälle vuosikymmenien ajan. Juuri sen vuoksi, että se ehkä alkujaan oli rakennettu uniikiksi. Mutta tärkeintä lienee, että arkkitehtuuri ja toteutusvälineet voidaan valita tämän vuosituhannen puolelta.

Käyttäjän AmosAhola kuva
Amos Ahola

Thanks, linkki korjattu.

Kyllä Apotin tapauksessa on ongelmana se, että sen sijaan että ostettaisiin valmis tuote niillä toiminallisuksilla mitä siinä on, siinä koodataan customia jonka pitää integroitua kymmeniin olemassaoleviin järjestelmiin ja tehdä asioita joita tuote ei vielä tee.

Apotin tapauksessa kyykkää siis kohta 7 - projekti yritetään toteutetaan liian laajana,jolloin se epäonnistuu.

Aivan hyvin olisimme voineet kopioida Viron vastaavan ratkaisun alle kymmenesosalla Apotin hinnasta vuoden projektilla, ja katsoa kuinka monta kymmentä prosenttia vaatimuksista jäi täyttämättä.

Käyttäjän MarcusWestermark kuva
Marcus Westermark

Hyvä kirjoitus, sopii moneen yhteyteen. Ymmärrän myös argumentin liian laajasta. Joskus se vaan on koko jutun juju. Julkaisujärjestelmä, jonka kautta voidaan sujuvasti hallinnoida ja levittää myös korkean turvaluokituksen aineistoa eri sidosryhmille lienee tässä keississä ollut se ydinongelma - ongelma, jonka takia oma järjestelmä alkujaan tilattiin eikä räätälöity jotain valmista, demokraattista ja vapaata avoimen lähdekoodin alustaa.

Käyttäjän AmosAhola kuva
Amos Ahola

CMS kuin CMS, tekivät Liferaylla, eli ei tässä sen kummoisempaa tarvetta ollut.

Toimituksen poiminnat

Tämän blogin suosituimmat kirjoitukset