Futurice Blog

Thoughts from inside Futurice

Julkishallinnon tietotekniikka on päivitettävä 2010-luvulle

(This is a longer version of the letter published in Helsingin Sanomat on October 8th, 2011. In Finnish only, sorry.)

Viime viikkojen julkisen sektorin tietotekniikkauutiset ovat olleet karua luettavaa: VR:n uusi lipunmyyntijärjestelmä ei toiminut ja lisäsi junamatkaajien ahdistusta, ja terveydenhuollon sähköisten reseptien järjestelmä piti ottaa tuoreeltaan pois käytöstä. Miten on mahdollista, että Suomi, joka on monilla mittareilla tietoyhteiskuntien edelläkävijä, tuntuu haaskaavan verorahoja epäonnistuneisiin tietotekniikan jättihankkeisiin?

Kirjoituksessaan (HS Vieraskynä 23.9.2011) Pekka Abrahamsson ja Mikkonen tuovat osuvasti esille keskeisen piirteen tietotekniikasta osana liiketoimintaa: tietotekniikka ei ole enää pelkkä tukitoiminto vaan yhä useammin liiketoiminnan ytimessä. Kirjoittajat ehdottavat, että yritysten ei pidä ulkoistaa ydintoimintojensa tietotekniikan rakentamista, vaan tehdä asiat itse. Tämä on kuitenkin usein helpommin sanottu kuin tehty. Onko esimerkiksi VR:n kaltaisen yrityksen järkevää hankkia itselleen ja pitää itsellään tietoteknistä osaamista? Vai onko VR:n järkevämpää ulkoistaa tämä osaaminen muualta ja tehdä tiivistä yhteistyötä ohjelmistotoimittajien kanssa?

Viime aikaisten tietotekniikan kauhukertomusten taustalla olevat syyt eivät ole siinä, että ulkoistaminen olisi automaattisesti huono asia. Hyvä ulkoistaminen on yhteistyötä ja kumppanuutta, eikä ydinosaamisen siirtämistä alihankkijan ratkaistavaksi. Ulkoistamisen sijaan julkisen sektorin epäonnistumisen syynä on tietotekniikan nopea kehitys sekä julkishallinnon kilpailuttamissäännöt.

Epäonnistumisten taustalla on 1990-luvulle jämähtänyt käsitys tietotekniikasta. VR:n lippujärjestelmän sekä sähköisten reseptien tapauksessa kyse on jättimäisistä projekteista ja kymmenien miljoonien investoinneista, jotka liukuvat jäävirran nopeudella harmittavan usein kohti epäonnistumisia. Tilanne on kuin kaksikymmentä vuotta vanhasta tietotekniikan oppikirjasta, jossa hankkeille on tyypillistä paisuvat budjetit, kankeat toimintatavat, käyttäjien unohtuminen suunnittelussa ja kymmenien insinöörien ryhmät ratkaisemassa oman alueensa ongelmia ilman käsitystä kokonaisuudesta.

Tietotekniikka on muuttunut merkittävästi 1990-luvulta. Ohjelmistojen rakentamisen kynnys on madaltunut valtavasti ja nykyään lähes kuka tahansa voi alkaa ohjelmoida ja laittaa tuloksiaan myyntiin verkon sovelluskauppoihin. Kun nuorten muutaman hengen voimin rakentamista ohjelmista kasvaa maailmanlaajuisia, kuten suomalainen Habbo Hotel, niin on selvää että ohjelmistokehitys ei vaadi suuria alkuinvestointeja. Nopea ja kevyt rakentaminen tekee mahdolliseksi kokeilut ja muutokset, ja siten tietotekniikkaa voi suunnitella entistä enemmän käyttäjien ehdoilla. Lisäksi kun ohjelmoinnin työkalut ovat joko ilmaisia tai erittäin halpoja niin miljoonien budjetit ja vuosien aikataulut ovat historiaa – tai ainakin niiden pitäisi olla.

Tietotekniikan toimittajien maailmassa tämä muutos näkyy sukupolvenvaihdoksena niin sanotun vanhan koulukunnan ja uuden koulukunnan välillä. Vanhan koulukunnan edustajia ovat tyypillisesti suuret konsultti- ja alihankkijayritykset, jotka on perustettu vuosikymmeniä sitten. Uuden koulukunnan edustajat ovat 2000-luvun nuoria, joiden toimintatavat heijastavat nykyajan tietotekniikan ominaisuuksia: kevyttä, nopeaa ja käyttäjälähtöistä rakentamista, joka on edullista toteuttaa.

Uuden koulukunnan sukupolvi ja yrityskulttuuri on samaa kuin innovatiivisten startup-yritysten: työstä nautitaan ja korkea laatu sekä mutkaton toteuttaminen koetaan ammattiylpeytenä. Työstä nauttimisen ja korkean ammattietiikan seurauksena on, että hankkeet onnistuvat lähes aina ja asiakastyytyväisyys on huippuluokkaa.

Julkishallinnon tietotekniikan hankkeiden päivittäminen 2010-luvulle vaatii uuden tavan ajatella: pieniä matalan riskin projekteja, jotka kestävät kuukausia eikä vuosia, jotka maksavat murto-osan siitä mitä ennen, ja jotka valmistuessaan täyttävät oikeasti käyttäjien tarpeet. Tämä ajattelu mahdollistaa aivan uudenlaisen alihankinnan, esimerkiksi kilpailuttamalla useita toimittajia rinnakkain tai kokeilemalla mikä on paras mahdollinen vaihtoehto. Niillä investoinneilla, jotka esimerkiksi VR on laittanut lipunmyyntijärjestelmäänsä olisi voinut rakentaa tusinan uuden koulukunnan järjestelmiä.

Mikä estää julkishallinnon organisaatioita siirtymästä tietotekniikassaan 2010-luvulle? Vastaus on kilpailuttamis- ja hankintasäännöt, jotka suosivat vanhan koulukunnan jättihankkeita. Ja kuten Abrahamsson ja Mikkonen kirjoittavat, kiertääkseen nämä säännöt julkisen sektorin organisaatiot on pakotettu silppuamaan alihankintansa pieniksi paloiksi eri ohjelmistotoimittajille.

Vaikka uutisointi on viime aikoina keskittynyt kauhutarinoihin, ei tämä tarkoita, että kaikki julkisen sektorin toiminta olisi vanhanaikaista. Hyviä vastaesimerkkejä ovat Helsingin seudun julkisen liikenteen mobiilikisa, jossa haettiin innovatiivisia uusia ideoita joukkoliikenteeseen, ja Sitran viimevuotinen uudenlainen rinnakkainen kilpailutus. Toivoa antavat myös valtion entisen IT-johtajan, Yrjö Bensonin puheet, joissa hän on peräänkuuluttanut uusia työtapoja ja työkaluja valtion tietotekniikkahankintoihin.

Mutta jotain on pielessä julkisen sektorin jättijärjestelmissä ja jättihankinnoissa, kun niitä katsoo rinnan muun tietotekniikan kehityksen kanssa. Suomeen on kasvanut Nokian seurauksena suuri määrä nuoria ja innovatiivisia tietotekniikan yrityksiä ja ammattilaisia, ja tätä lahjakkuutta tulisi voida hyödyntää julkisen sektorin hankkeissa. Toisin sanoen, samaan aikaan kun kotimaisen raideliikenteen ja terveydenhuollon tietojärjestelmät epäonnistuvat suomalainen Angry Birds valloittaa maailmaa. Milloin Suomelle tulee ensimmäinen julkishallinnollinen tietojärjestelmähitti kansainvälisille markkinoille? Tai edes kotimaisille?

Risto Sarvas, tekniikan tohtori, Futurice Oy ja Aalto-yliopisto
Kim Weckström, yhteiskuntatieteiden lisensiaatti, Avaus Consulting Oy

Posted by Risto Sarvas 

Strategy, trust, windows, and Lenin

I attended on a yearly Strategy Forum organized by The Finnish Strategic Management Society. Interesting stuff, so wanted to share some thoughts.

Helene Auramo from Zipipop discussed how the social media makes leaders, not just organizations transparent. Antti Koskelin, the CIO of Konecranes, pointed out how the [your favourite letter here] generation spoiled by Google and friends will just not accept the unusable enterprise software and ICT policies (could not agree more!). Minna Elomaa gave a nice presentation about the change management she successfully did at Tapiola Group: repeat, repeat, repeat, that is!

The highlight was absolutely the yearly strategy award. The winner Kimmo Suominen sees strategy as a narration that is consumed!

In my presentation I tried to open up the hopefully successful Futurice strategy and leadership principles. The slides are in Finnish, so here comes a short English summary:

  • for us the business model and other "hard" strategic building blocks are relatively straight-forward. Far most interesting are the people. How we create a community of professionals that is skilled, desired, trusted in a sustainable way.
  •  "Trust is good, control is better", famous quote from Mr. V.I. Lenin. I disagree. Could we instead make trust a core of our strategy? Yes, it is not an easy path, but maybe worth walking!
  • People first, then strategy. Jim Collins: "first right people on the bus ... then figure out where to drive."
  • Futurice decision making principles: 3x2, "The one who promises is the one who delivers", 100% transparency, functions and roles are bad, business thinking for everybody, share everything, agile decision making on the front-line
  • Futurice practices
  • Nassim Nicholas Taleb taught how the world becomes more non-gaussian. The black swans rule. How does it change your business? Most (all?) of the established organizations are poor in utilizing these opportunities. Do you leave it for start-ups only?
    • Or as Lenin put it: "Revolution is impossible without a revolutionary situation, furthermore not every revolutionary situation leads to revolution."
  • Agile software development model is an encouraging example of how a modern, empirical, non-hierarchical approach can change the way one major business operates. 

I also wanted to point out that single case examples like this are not very reliable source of information. Maybe we just have been lucky!

Click here to download:
Startegia_2011-06-13.pdf (746 KB)
(download)

Filed under  //  Strategy   agile   hr  
Posted by Mikko Viikari 

Quality Assurance is dead ... long live Quality Leading

In many projects there is a QA person or persons responsible of ‘assuring’ quality. This is mainly done by testing and writing many reports. I will argue here that this mostly is a waste of time and should not be done anymore.

Lets start off by looking at quality assurance and where it comes from. It initially comes from from manufacturing where the QA would ensure that certain properties of a produced product fall within a predefined range of acceptable values. We in the software development industry took that system and adapted it for our purpose. With requirements and specifications which have to be smart so we can assure the quality. This is in essence a wrong approach as software development is a creative process. Quality is an immensely complex thing and assuring it is a myth the only thing we can do is trying to the best quality for the buck.

It is therefore not a smart thing to just have QA sit in the back waiting till something can be tested. The role of a tester is 3 fold.

First is to find information about the product being developed. This information is mostly bugs, but can also be information developers needs for further development. The method should fit the project, but writing lots of plans and test cases is hardly ever more effective than session based testing.

The second role is to be an advocate of quality improvements. An advocate meaning that the tester should actively participate in product planning, both in the planning in terms of the feature set and planning in terms of possible choices of implementations. The tester should promote implementations with reduce complexity, promote technical stories which are aimed to reduce technical debt. In a sprint planning for example a tester could advocate refactoring some piece of code based on testing results the previous sprint or promote a user story which mitigates a potential unstable application behavior  or discouraging a story which increases the complexity a lot. In short it should be the aim of the tester to maximize the quality and lead efforts to improve the quality.

The third role is to inform stakeholders of the quality so they can make an informed decisions regarding releases etc. How this information is presented has to be agreed, but it should be a holistic picture and not a set of metrics. At the end the tester should present his finding and his opinion of the quality to the product owner. It is up the him or her to say if this is acceptable or not. If the quality in not acceptable, the tester should suggest ways to improve the quality.

-Peter Tennekes

Filed under  //  Quality   Quality Assurance   Session based testing   agile   blog   testing  
Posted by Ville Saarinen