Tuottavuusaktivisti Reino Myllymäen blogi

Ennen oli paremmin?

Perjantai 24.5.2019 - Tuottavuusaktivisti Reino Myllymäki

Ennen oli kaikki paremmin, sanotaan. EVAn tuoreen arvo- ja asennetutkimuksen mukaan 45 % suomalaisista on sitä mieltä, että ennen oltiin onnellisempia kuin nyt (25 % on vastakkaista mieltä) ja 27 % on sitä mieltä, että viiden vuoden kuluttua asiat ovat huonommin kuin nyt (23 % on vastakkaista mieltä). Edellisessä kysymyksessä ei osaa sanoa -mieltä oli 30 % ja jälkimmäisessä peräti 50 %.

Mutta oliko ennen asiat paremmin?

Testi 1.

Lähde heinäkuussa henkilöautolla kiertämään viikoksi Suomea. Kokeile laittaa autostasi ilmastointi pois päältä. Tunnin kuluttua kysy itseltäsi, oliko asiat ennen paremmin. Ilmastointilaitteet yleistyivät autoissa vuoden 1999 tienoilla, muuten.

Testi 2.

Lähde kiertomatkalle Eurooppaan. Laske maiden lukumäärä, jossa vierailet. Sen jälkeen arvioi, monessako maassa oli ennen oma valuutta. Mieti, valuutanvaihtoprosessia ja sitä, oliko asiat ennen paremmin. Euroon siirryttiin käteisvaluuttana monessa Euroopan valtiossa - Suomessa muiden mukana - vuoden 2002 alussa.

Testi 3.

Lainaa kirjastosta 30 kirjaa ja käy uusimassa ne kirjaston tiskillä 4 viikon välein. Miten teet sen nyt? Mieti oliko ennen asiat paremmin?

Testi 4.

Mieti, montako kertaa olet tänä kesänä kuullut radiosta tiedotuksen "perhe se-ja-se matkalla jossainpäin Suomea, ottakaa heti yhteys kotiin..." Mieti, useinko kuulit sen radiosta 20 vuotta sitten. Dekkarikirjailija Sue Grafton, jonka aakkoskirjat sijoittuvat 1980-luvulle, kertoo joutuneensa oikein pinnistelemään muistaakseen, että silloin ei voinut soittaa matkapuhelimeen vaan oli tavoitettava ihmiset lankapuhelimesta silloin, kun he sattuivat olemaan sen liepeillä. Oliko asiat ennen paremmin?

Testi 5.

Mieti millaiset lainanhoitokulut sinulla olisi asunnostasi 1990-luvun alun 10 vuoden maksuajalla ja 15 % korolla. Oliko asiat paremmin?

Testi 6.

Mieti montako isoisäsi sukupolven sukulaistasi kaatui sodissa. Mieti sitten, montako oman sukupolvesi sukulaistasi on kaatunut sodassa. Euroopan Unionin paras saavutus on, että emme ole joutuneet enää sotiin.

Testi 7.

Kuvittele itsesi 1700-luvun ruotusotilaan vaimoksi. Kuulet, että miehesi on kaatunut sodassa tai kuollut tauteihin jossain kaukana. Toivo, että ruodun uudella sotamiehellä ei ole vielä vaimoa ja että kelpaat hänelle vaimoksi, ennenkuin sinut heitetään lapsinesi tielle ruotutorpasta. Sillä siinä on sinun sosiaalinen turvaverkkosi. Oliko ennen asiat paremmin?

Elämme tällä hetkellä monessa suhteessa ihmisen historian parasta aikaa. Kaikki asiat eivät ole tietenkään kunnossa, käytämme pallomme resursseja kohtuuttomasti ja jotkin asiat huononevat sen sijaan, että paranisivat. Kokonaisuutena kuitenkin asiat ovat paremmin kuin koskaan.

Tulevaisuutta ei koskaan tiedä. Mutta pidetään huolta itsestämme, toisistamme ja maapallostamme niin huomennakin asiat ovat paremmin kuin tänään!

Kirjoitus on julkaistu aiemmin CxO Mentor Oy:n blogissa 10.7.2013.


Kommentoi kirjoitusta. Avainsanat: uskomukset, ajatusvirheet, tulevaisuudenusko, tulevaisuudenpelko

Kohti parempaa IT:n ja liiketoiminnan yhteistyötä. Osa 4/4: Kohti syvempää asiakasyhteistyötä

Torstai 28.3.2019 - Tuottavuusaktivisti Reino Myllymäki

Tehokkuus_ensin_2_720x405_px.jpg

Palveluyksikön kehittämisessä voi riittää vähempikin kuin syvälliseen asiakasyhteistyöhön pääseminen. Voi olla, että asiakkaidesi kannalta on aivan riittävää, että palveluyksikkö toimii tehokkaasti. Siksi syvälliseen asiakasyhteistyöhön pääseminen ei voi olla mikään itseisarvo; mutta jos palvelusi ovat asiakkaallesi tärkeitä - esimerkiksi IT-palvelut alkavat olla jokseenkin joka liiketoiminnalle nykyään tärkeitä - hyvät palvelusi kannustavat asiakastakin syvällisempään yhteistyöhön.

Eli jos syvällinen asiakasyhteistyö on molempien osapuolten tavoitteissa, kannattaa edetä luomalla yhteinen johtamismalli yhteisille asioille. Business Relationship Managementia kannattaa luonnollisesti kehittää eteenpäin. Ja kannattaa luoda strategioita ja mielellään vieläpä asiakkaan kanssa yhteisiä.

Korkealentoisten ja pitkälle tähtäävien strategioiden yhteydessä kannattaa pitää jokapäiväinen tekeminen kunnossa - siinä riittää esimerkillä johtajalle töitä! Nimittäin kaiken huipulla on asiakkaan luottamuksen ansaitseminen - joka päivä, jokaisen palvelun yhteydessä ja jokaisen palvelutyöntekijän kohdalla!

Kirjoittaja on tuottavuusaktivisti ja tietokirjailija Reino Myllymäki, joka toimii myös IT Forumin puheenjohtajana ja Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsenenä. Hänen vuonna 2017 julkistettu kirjansa Tehokuus ensin! on saatavissa mm. Ketterät Kirjat Oy:n verkkokaupasta.

Kommentoi kirjoitusta. Avainsanat: tietohallinto, it-palvelut, tehokkuus, asiakasyhteistyö, yhteenlinjaaminen

Kohti parempaa IT:n ja liiketoiminnan yhteistyötä. Osa 3/4: Katse asiakkaaseen päin!

Maanantai 25.3.2019 - Tuottavuusaktivisti Reino Myllymäki

Tehokkuus_ensin_2_720x405_px.jpg

Tykkäämme tehokkaista palvelutoimittajista, eikö totta? Pahoitamme kovasti mielemme, jos sähköposti ei kulje, tietoliikenne pätkii, tulostimet eivät tulosta ja niin edelleen. Mutta jos edellämainittu ja muutkin perusasiat toimivat, voidaan keskustella palvelutoimittajan kanssa jo muistakin asioista kuin häiriöistä ja toimimattomuuksista.

Tässä yhteydessä on pakko todeta, että ei se asiakaskaan aina palveluntoimittajan näkökulmasta reilu ole. Kokemukset esimerkiksi huonoista IT-palveluista kannetaan mukana firmasta toiseen, jolloin ne eivät edes liity nykyiseen palvelutoimittajaan. Toisaalta pitkään samassa talossa työskennelleet eivät välttämättä osaa vertailla asioita oikein, eivätkä aina tiedä ylimmän johdon asettamista kustannuspaineistakaan. Vertailu nirvanaan voi olla aika epäreilua.

Lisäksi on muistettava propagandan myöhäisvaikutus. Vaikka kuinka mittaustulokset osoittaisivat myönteisestä kehityksestä ja hyvistä tuloksista, organisaation yleinen mielipide asioista jatkaa vanhalla uralla. Hyvin hitaasti mielipiteet alkavat muuttua. Muuttumista ei kannata jäädä odottamaan, vaan kehitystä on jatkettava.

Seuraava kehityskohde on palveluorganisaatiosi rajapinnat - rajapinta omistajiin tai konsernin johtoon, rajapinta omiin toimittajiin sekä mikä tärkeintä, rajapinnat käyttäjäasiakkaisiin ja liiketoimintayksiköihin.

Käyttäjäasiakasrajapinnan paras käytäntö on Help Desk, jota myös Contact Centeriksi tai Service Deskiksi kutsutaan. Toiminto on palveluyksikön hermokeskus, johon yhteyttä ottamalla oma ongelma lähtee ratkeamaan. Hermokeskukseksi kutsun sitä siksi, että se tietää, millaisia ongelmia organisaatiolla kulloinkin on ja siksi sillä on hyvät mahdollisuudet reagoida niihin.

Toinen ja yhtä tärkeä toiminto on tuo liiketoimintarajapinta, jonka paras käytäntö on Business Relationship Management. Laitetaan avainhenkilöitä hoitamaan suhteita palveluyksikön ja eri liiketoiminta-asiakkaiden kanssa.

Palveluyksikön sisäinen organisointi on toki tämän jälkeen tehtävä tukemaan näitä rajapintoja palvelevia prosesseja. Ja samaan syssyyn on alettava kehittämään organisaation osaamista ja todennäköisesti myös rekrytoitava uusia voimia muuttuneisiin haasteisiin. Sekin on osattava tehdä oikein.

Jo aikaisemmin tehtäväluettelossa oli palveluluettelon (Sevice Catalog) laadinta. Nyt hommaa on jatkettava sen suhteen kahdesta suunnasta: on tehtävä - ensin vaikka sisäinen - palvelulupaus jokaiselle palvelulle. Ja on saatava kustannusvastaavuus palveluille eli käytännössä jokaiselle palvelulle hinta. Ja koko homman orkesteroinnin suhteen tärkeät linjaukset, periaatteet ja valinnat ovat koottava yhteen. Siihen tarvitaan kokonaisarkkitehtuurityötä. Helposta asiasta tässäkään yhteydessä ei ole kysymys, sillä tehokäyttöön kokonaisarkkitehtuuri saadaan vasta, kun siitä on tehty koko yrityksen tai konsernin kehittämisen selkäranka. Ja silloin se ei enää kuulu yhden palveluyksikön vastuulle.

IT-palveluyksiköiden kannattaa vielä tiedostaa hallussaan olevan tiedon hyväksikäyttö koko organisaation kilpailutekijänä. Jos nämä kaikki rastit hoitaa hyvin, palveluyksiköstä on alkanut tulla jo merkittävä tuottavuus- ja kasvukumppani koko organisaatiolle. Ja sitten voi mennä vielä pidemmälle asiakasyhteistyössä.

Kirjoittaja on tuottavuusaktivisti ja tietokirjailija Reino Myllymäki, joka toimii myös IT Forumin puheenjohtajana ja Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsenenä. Hänen vuonna 2017 julkistettu kirjansa Tehokuus ensin! on saatavissa mm. Ketterät Kirjat Oy:n verkkokaupasta.

Kommentoi kirjoitusta. Avainsanat: tietohallinto, it-palvelut, tehokkuus, asiakasyhteistyö, yhteenlinjaaminen

Kohti parempaa IT:n ja liiketoiminnan yhteistyötä. Osa 2/4: Tehokkuus ensin!

Tiistai 12.3.2019 - Tuottavuusaktivisti Reino Myllymäki

Tehokkuus_ensin_720x405.jpg

Kun palveluyksikön perusasiat ovat kunnossa eli palveluyksikkö toimii ja tuottaa niitä peruspalveluja, joita asiakkaat kipeästi tarvitsevat, on saatu hetki aikaa, jonka voi käyttää joko laakereilla lepäämiseen tai yksikön tehokkuuden parantamiseen. Suosittelen lämpimästi jälkimmäistä.

Tärkeää on myös pitää aloite koko ajan omissa käsissä. Joskus seuraava askel on selkeä mutta usein etenemisvaihtoehtoja on useita. Silloin olennaista on tehdä laskelmia eri vaihtoehtojen kannattavuudesta. Näissä laskelmissa nykytila on aina yksi vaihtoehto. Laskelmat ovat osoitus siitä, että vaihtoehtoja on mietitty, vaikka pidättäydyttäisiinkin nykyisessä toimintatavassa. Laskelmat ovat suoja mielivaltaisia kehitystoimia vastaan.

Kehittämisen lähtökohta on hyvä ottaa selville. Kuinka tehokkaita olemme nyt ja jos mahdollista, miten vertaudumme muihin samantyyppisiin palveluyksikköihin? Koko organisaation IT-kustannusprosentti on yksi varsin yksinkertainen, joskin vain suuntaa-antava luku. IT-palvelujen TCO eli Total Cost of Ownership on toinen. Molempien lukujen huono puoli on siinä, että ne käsittelevät vain kustannuksia ja laatupuoli jää pimentoon. Sitä voi muuttaa rahaksi IT-ympäristön häiriöitä käsittelevällä käyttäjäkyselyllä.

Kolmas asia, jonka tässä vaiheessa haluan nostaa esiin, ovat tyytyväisyyskyselyt. Niistä pitäisi muodostua kattava kuva palveluyksikön kokonaistyytyväisyydestä: kuinka tyytyväisiä ovat käyttäjäasiakkaat, entä omistajat ja johto. Entä oma porukka? Mitkä ovat tyytymättömyyden aiheet, voiko mielipiteensä antaneiden kenttää segmentoida tarkemmin toimenpiteiden kohdistamiseksi tarkemmin.

Tyytyväisyystutkimusten ja TCO-tyyppisten kustannusrakennetutkimusten tulokset ovat mittaustuloksia ja mittaamisen ottaminen yhdeksi palveluyksikön johtamisen välineeksi on tiedolla johtamisen lähtökohta. Mittauksilla voidaan myös varmistaa, että toimenpiteet tuottavat haluttuja tuloksia eli kehitystyössä mennään eteenpäin.

Tässä vaiheessa on hyvä katsoa myös palveluyksikön tuotantokoneistoa. Onko organisaatiossa vapaamatkustajia, alisuoriutujia, työilmapiirin myrkyttäjiä tai muita sellaisia, joista on päästävä eroon, jotta koko yksikkö kehittyisi? Miten prosesseja voidaan parantaa, eikä ainoastaan tuotannon ja palvelujen, vaan myös johtamisen osalta? Mikä on tehokasta ja hyvää, mikä tehotonta ja huonoa?

Lopuksi vielä kaksi asiaa: palveluluettelon (service catalog) tekeminen kuuluu niihin perusasioihin, joihin myöhemmät kehitystoimet nojaavat. Mitä palveluja tuotamme ja kenelle? Mitä palvelut sisältävät ja maksavat? Onko palveluluettelon erittelytarkkuus sopiva, joudutaanko paljon tekemään sellaista erikoistyötä, joka ei sisälly millekään palvelulle?

Ja sitten vielä viestintä! Millaisia sidosryhmiä palveluorganisaatiolla on ja miten niille viestitään? Tässä yhteydessä kannattaa ottaa huomioon Osmo A. Wiion (1928-2013) lait inhimillisestä viestinnästä.

Tässä luetteloidut kehitystoimenpiteet ovat sellaisia, joita palveluyksikkö voi ja sen myös oletetaan tekevän itse. Jotkut niistä osoittautuvat helpoiksi, jotkut kipeitä ratkaisuja vaativiksi. Muista, että jos kaikki olisi helppoa, hommat olisi tehty jo. Sinua tarvitaan juuri siksi, että palveluyksikkö vaatii muutoksia ja niiden aikaansaamiseksi on tehtävä päätöksiä ja varmistettava, että oikeansuuntaisia muutoksia todella syntyy.

Kirjoittaja on tuottavuusaktivisti ja tietokirjailija Reino Myllymäki, joka toimii myös IT Forumin puheenjohtajana ja Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsenenä. Hänen vuonna 2017 julkistettu kirjansa Tehokuus ensin! on saatavissa mm. Ketterät Kirjat Oy:n verkkokaupasta.

Kommentoi kirjoitusta. Avainsanat: tietohallinto, it-palvelut, tehokkuus, asiakasyhteistyö, yhteenlinjaaminen

Kohti parempaa IT:n ja liiketoiminnan yhteistyötä. Osa 1/4: Perusasiat kuntoon!

Perjantai 8.3.2019 - Tuottavuusaktivisti Reino Myllymäki

Tehokkuus_ensin_720x405.jpg

Yksi itsenäni pitkäaikaisesti elähdyttäneistä tutkimuksista on Bain & Co:n 2000-luvulla tekemä IT Alignment Trap -tutkimus, joka osoitti, että tietohallinnon ja liiketoiminnan välinen läheinen yhteispeli saattaa tuottaa yritykselle hallaa, jos tietohallinto on tehoton. Siis mitä? Eikö yhteenlinjaaminen ja läheinen yhteistyö olekaan aina positiivisia asioita?

Eivät näytä olevan. Hirmu hyviä tuloksia saadaan, kun tietohallinto ja IT-palvelut ovat tehokkaita ja tekevät läheistä yhteistyötä liiketoiminnan kanssa. Hyviä tuloksia saadaan ilmankin tuota yhteistyötä, kunhan tietohallinto ja IT-palvelut ovat tehokkaita. Mutta tehottoman tietohallinnon läheinen yhteistyö liiketoiminnan kanssa on yhtä hyvä ystävä kuin sudenkuoppa tai musta surma.

Yritimme taannoin tutkia suomalaista tilannetta samoin perustein kuin amerikkalaiset aikananaan. Saimme tulokseksi, että jopa kolmannes yrityksistä saattaa olla tuossa sudenkuopassa, jossa tehoton tietohallinto tekee yhteistyötä liiketoiminnan kanssa. Tutkimuksen sanallisissa arvioissa moni epäili organisaatiotaan tuohon ansaan pudonneeksi.

Vuonna 2017 IT Forumin jäsenet valitsivat vuoden toiseksi teemaksi CIO Survival Kitin. Tämän teeman ympärillä käytyjen keskustelujen ja kyselyiden - sekä toki myös omien kokemuksieni pohjalta - kirjoitin kirjan Tehokkuus ensin! Palveluyksiköstä tuottavuus- ja kasvukumppaniksi. Kirja julkistettiin syyskuussa 2017 ja on yhtä ajankohtainen tänään kuin silloinkin.

Kirja kuvaa prosessin, jota kautta on mahdollista tehdä tietohallinnosta ja IT-palveluista organisaatiota aidosti hyödyttävä osa. Kirja jakaantuu kolmeen osaan sen mukaan, kuinka paljon tietohallinto ja IT-palvelut voivat tehdä toimintansa kehittämistä omin päin. Eli aloitetaan siitä, mikä kuuluu organisaatiossa kuin organisaatiossa sille itselleen: oman tekemisen kehittäminen. Ja päätetään siihen, missä ilman asiakkaan myötävaikutusta todellista kehitystä on vaikea saada aikaan.

Ihan ensimmäiseksi on kuitenkin saatava perusasiat kuntoon! Maitokaupassa on oltava maitoa tarjolla, huoltoasemalla bensaa ja dieseliä, kirjastossa kirjoja. Muuten asiakas menee muualle, eikä koskaan palaa. Sama koskee tietohallintoa ja IT-palveluja: asiakkaiden perustarpeet on ratkaistava ja ratkaisujen on toimittava tyydyttävästi, silloin kun niin on luvattu. Muu on vielä ekstraa tässä vaiheessa. Ja perustarpeet ovat niitä, joita ilman asiakas ei tule toimeen.

Palvelujen tekninen toimivuus on siis etusijalla, kakkostilalla tulee sitten palvelujen hinta. Usein kysymys on palveluista, joita ei hankita muualta, jolloin korkeaa hintaa siedetään - mutta ei loputtomiin. Perusasioiden kuntoonlaitto on kuitenkin hyvä alku. Siitä päästään eteenpäin.

Kirjoittaja on tuottavuusaktivisti ja tietokirjailija Reino Myllymäki, joka toimii myös IT Forumin puheenjohtajana ja Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsenenä. Hänen vuonna 2017 julkistettu kirjansa Tehokuus ensin! on saatavissa mm. Ketterät Kirjat Oy:n verkkokaupasta.

Kommentoi kirjoitusta. Avainsanat: tietohallinto, it-palvelut, tehokkuus, asiakasyhteistyö, yhteenlinjaaminen

Kohti onnistunutta kehitysprojektia, osa 18: Tee se, mitä olet tekemässä

Maanantai 11.2.2019 - Tuottavuusaktivisti Reino Myllymäki

Avokonttori_720x405.jpg

31.8.1999 myöhään illalla Buenos Airesista Caracasiin suunnannut Boeing 737 -kone ei koskaan päässyt ilmaan. Se päätyi kiitoradan jatkeelle ja tuhoutui lähes täysin. Niin kuin lento-onnettomuuksissa yleensäkin, syitä oli monia. Lentoemäntä kävi juttelemassa ohjaamomiehistön kanssa juuri lentoonlähdön tarkistuslistaa läpikäytäessä ja niin yksi kriittinen asia jäi tarkistamatta: laskusiivekkeet, jotka on otettava ulos myös nousussa, jäivät sisään.

Joskus käy niin, että luulet lähettäneesi viestin, jota vastaanottaja ei ole saanut. Kun viestiä ei löydy lähetettyjen kansiosta, mutta tiedät kirjoittaneesi viestin, saattaa olla, että jokin häiritsi keskittymistäsi ja niin lähetä-nappi jäi painamatta. Viesti löytyy luonnoksista tai ei mistään.

Tavaroita löytyy kummallisista paikoista, jonne olet laskenut ne väliaikaisesti. Dokumentteihin jää kesken jääneitä virkkeitä, joista ei saa kiinni, mitä niitä kirjoittaessaan on ajatellut. Kesken jäänyt blogikirjoitus on mennyt mustaan aukkoon, kun unohdit tallentaa ennen istunnon aikakatkaisua. Alkavaa dementiaa? Ehkä. Mutta usein kysymys on siitä, että tekeminen keskeytyy.

Sille voi vain vähän, että joku toinen keskeyttää sinut ollessasi tekemässä jotain tarkkuutta vaativaa. Avokonttorissa kuulokkeiden päässä pitämisen pitäisi olla tällaisesta merkki, vaan ei kuulemma tehoa ainakaan aina. Joillakin on otsaa tulla jopa keskeyttämään puhelu. Vaan keskeytyksiä syntyy myös omaehtoisesti. Kiinnitämme huomiomme muuhun, kun tulee saapuneesta viestistä ilmoittava merkkiääni, posti kolahtaa postiluukusta tai vauva alkaa itkeä - tai radiosta tulevaan musiikkiin on sotkeutunut ääniä, jotka aivot reagoivat hälytysääneksi.

Eri ihmiset pystyvät keskittymään eri tavoin. Yksilölliseen keskittymiskykyyn vaikuttaa myös kulloinenkin energiataso. Itselläni vaihtelu on suurta. Joskus minua häiritsee pienetkin asiat, joskus ei mikään.

Keskeytyksen riskiä voi pienentää lyhentämällä tehtäviä. Esimerkiksi tämän blogikirjoituksen kykenen kirjoittamaan (yleensä) kerralla, kirjaa en - en edes yhtä kirjan lukua. Keskeytyksen riskiä voi vähentää myös yhteisön pelisääntöjä kehittämällä. Annetaan toisen nyt ainakin kirjoittaa virke loppuun ennen keskeytystä!

Keskeytyksen seurauksia voimme puolestamme vähentää tallentamalla työmme aina lopuksi. Kirjaa kirjoittaessani tai taittaessani aloitan päivän tekemällä dokumentista aina uuden, sille päivälle päivätyn version.

Säälin niitä, jotka eivät ole luotuja avokonttorielämään, mutta joutuvat siellä tekemään töitä.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, projektityö

Kohti onnistunutta kehitysprojektia, osa 17: Pari hyödyllistä kirjaa

Maanantai 4.2.2019 - Tuottavuusaktivisti Reino Myllymäki

Joululomat on vietetty ja siinä meni seuraavaa blogikirjoitusta miettiessä koko tammikuukin! Mutta aloillaan ei ole oltu, nimittän on julkistettu kaksi projektien onnistumiseen liittyvää teosta.

Yksi projektien epäonnistumistekijä on se, että tekijät eivät tunne asiakkaan toimintaympäristöä. Mitään mittaustietoa siitä, kuinka usein tämä on johtanut projektin epäonnistumisen polulle, ei ole. Mutta viitteitä on siitä, että erilaiset väärinymmärrykset - suoranaisen ylimielisyyden lisäksi - ovat aiheuttaneet ylimääräistä resurssien kulutusta ja sitä kautta altistaneet projektin epäonnistumiselle. Jos puuttuu yhteinen ymmärrys toimintaympäristöstä ja terminologiasta, aikaa ja rahaa palaa hukkaan.

9789527044421.jpgTämä on ratkaistu Timo Jokelan uraa uurtavassa teoksessa Kohdemaailma-analyysi - Syvälliseen asiakasymmärrykseen heti kehityshankkeen alussa. Kirjassa kuvataan miellekarttoihin (Mind Map) perustuva menetelmä, jolla asiakkaan toimintaympäristö kuvataan yleensä noin kolmen päivän ponnistuksella niin, että syntyy yhteinen ymmärrys sekä asiakkaalle että kehittäjille.

Kyse ei ole uudesta speksausmenetelmästä. Kohdemaailma-analyysillä ei selvitetä kehitystarpeita tai uuden tietojärjestelmän vaatimuksia, vaan se, millaisessa maailmassa asiakas elää. Millainen hänen toimintaympäristönsä on. Kun tästä syntyy ymmärrys, kehitystarpeiden ja tietojärjestelmien ominaisuuksien speksaaminen on askeleen pari helpompaa.

Lue lisää Kohdemaailma-analyysi-kirjasta

9789527044391.jpgToinen kirja - tai oikeammin kirjanen - jolla uskon olevan merkitystä projektien onnistumisen kanssa, on kirjoittamani teos Business Case - perustele projektisi hyvin. Latasin kirjaan kaiken relevantin kustannuslaskentakokemukseni ja investointiehdotusten teko-osaamiseni ja kirjoitin kirjan siitä, mitä hyvä business case eli projektin perustelu sisältää ja mitkä ovat parhaat tuntemani käytännöt.

Business Case -kirja nousi Ketterät Kirjat Oy:n vuoden 2019 myydyimmäksi teokseksi jo ennen julkistuspäivää 18.1.2019 ja on pysynyt asemassaan toistaiseksi. Lue lisää Business Case -kirjasta.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, projektityö

Kohti onnistunutta kehitysprojektia, osa 16: Se kaikkein vaikein taitolentoliike

Maanantai 17.12.2018 - Tuottavuusaktivisti Reino Myllymäki

9789527044322.jpgSuomen kokeneimpiin lentäjiin kuuluva Lento-onnettomuudet lentoturvallisuuden kehittäjinä -kirjan kirjoittaja Jari Rinne on on leikkisästi arvuutellut, mikä on lentäjälle kaikkein vaikein taitolentoliike.

Se on kuulemma U-käännös. Lentoonlähdön jälkeen paluu lähtöpaikkaan. Lennon keskeyttäminen.

Sama pätee projektitoimintaan. Keskeytetty projekti on The Standish Groupinkin mukaan epäonnistunut projekti ja epäonnistuminen on se mitä projektihenkilöstö eniten pelkää.

En tiedä mistä johtuu - geeneistä, kotikasvatuksesta vai muista ympäristötekijöistä - mutta pelkäämme epäonnistumista välillä niin paljon, että onnistumiselle ei jää paljoa tilaa.

Joillakin on sellainen käsitys, että ongelmat poistuvat kunhan projekti saadaan käyntiin tai lentokone ilmaan. Ja kun projekti on saatu käyntiin, sitä ei parane keskeyttää, koska hankkeeseen on laitettu niin ja niin paljon rahaa. Vaikka projekti menisi kohti täydellistä tuhoa, yritetään hukattuja rahoja pelastaa heittämällä hyvää rahaa huonon perään.

Itse olen purkanut tuota problematiikkaa jo loppuunmyydyssä Miksi tietojärjestelmäprojekti epäonnistuu? -kirjassa Business Caseen kuuluvan hyöty-kustannusanalyysin kautta, tässä se tiivistettynä:

  • Tutkitaan, ylittävätkö hyödyt projektin kokonaiskustannukset siinä tapauksessa, että projektia jatketaan. Jos ei,
  • tutkitaan, ylittävätkö hyödyt projektin jäljellä olevat kustannukset siinä tapauksessa, että projektia jatketaan.

Jos ensimmäinen ehto täyttyy, hyvä. Jos jälkimmäinen täyttyy, projektia kannattaa jatkaa, jos lopputulos on organisaatiolle kriittisen tärkeä. Jos jälkimmäinen ei täyty, projekti on keskeytettävä heti. Sen lisäksi, että menneet rahat katsotaan kokonaan hukkaan joutuneiksi, tappiot ovat kasvamassa uudenkin rahoituksen myötä. Parasta on silloin lopettaa koko juttu ja alkaa miettiä paremmin tuottavia projekteja rahoille.

Tämän kirjoituksen myötä kirjoittaja toivottaa kaikille Hyvää Joulua ja Vieläkin Parempaa Uutta Vuotta 2019! Kirjoitussarja jatkuu vuoden 2019 puolella.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, projektityö, cockpit resource management, CRM

Kohti onnistunutta kehitysprojektia, osa 15: Tarkistuslistat

Maanantai 10.12.2018 - Tuottavuusaktivisti Reino Myllymäki

Kävin kolmisen vuotta sitten kaksikin kertaa polvileikkauksessa. Operaatiossa leikattiin tähystyksellä vasemman polven nivelkierukkaa. Operaation mennessä minulta varmistettiin moneen kertaan, että kysymyksessä oli nimenomaan vasen polvi. Siihen piirrettiin tussilla jopa nuoli. Kysyinkin sitten henkilöltä, joka saattoi minut leikkaussaliin, että kuinka monesti he olivat leikanneet väärän polven. Kuulemma sellaista ei ollut hänen 25-vuotisella urallaan tapahtunut kertaakaan.

Itse leikkaussalissa käytiin läpi tarkistuslista. Se ei ollut kovin pitkä ja kysymyksiin vastattiin nopeasti. Mutta tarkistuslista ainakin käytiin läpi.

9789527044322.jpgLentokonetyyppikohtaiset tarkistuslistat ovat lentämisen nykypäivää, oli kyseessä sitten pienkoneet, matkustajakoneet tai sotilaskoneet. Jokainen lentäjä tietää, että lentoturvallisuuden toteutuminen on kiinni siitä, että yhdessä sen vaarallisimmista vaiheista, lentoonlähdössä, kaikki on kunnossa.

Eräässä lento-onnettomuudessa kauan sitten kävi niin, että lentokone ei yksinkertaisesti noussut ilmaan. Jostain syystä lähtökiitoa ei keskeytetty ajoissa, jolloin kone ajoi kentän päädystä läpi ja osui kaasunjakeluasemaan (!) pahoin seurauksin. Ihme kyllä, muutamat matkustajat selvisivät hengissä.

Koneen jäänteitä tutkittaessa selvisi, että laskusiivekkeet olivat olleet sisällä, vaikka niiden pitäisi olla ulkona riittävän nostovoiman saamiseksi lentoonlähdössä. Ohjaamon äänitallentimesta selvisi, että tarkistuslistan läpikäynnin aikana ohjaamossa kävi lentoemäntä juttelemassa illan ohjelmasta. Kun häiriön jälkeen tarkistuslistan läpikäynti jatkui, yksi kohta jäi välistä. Laskusiivekkeet.

Ohjaamossa oli myös järjestelmä, joka varoitti siitä, että laskusiivekkeet olivat sisällä. Äänimerkkiä ihmeteltiin, mutta sen merkitystä ei tajuttu, jolloin korjaavat toimenpiteet jäivät tekemättä. Oli niin kiire ilmaan, että jäi varmistamatta, että ilmaannousu onnistuu.

Olen itse kehitellyt kehityshankkeita varten tarkistuslistoja. Yksi niistä on jopa otettu Projecttop-ohjelmistoon mukaan. Mutta kehityshankkeita on kovin erilaisia - niinkuin lentokoneitakin - joten yleistä "patenttiratkaisua" on vaikea tehdä. Jokaisen projektin kannattaisi tehdä itselleen tarkistuslista, jossa varmistettaisiin projektien menestystekijöiden olemassaolo vaikka joka viikko.

Jos omaa tarkistuslistaa ei ole, kannattaa turvautua ulkopuolisiin konsultteihin ja heidän tarkistuslistoihinsa, kokemuksiinsa ja ulkopuoliseen näkemykseensä.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, projektityö, cockpit resource management, CRM

Kohti onnistunutta kehitysprojektia, osa 14: Terminologia

Maanantai 3.12.2018 - Tuottavuusaktivisti Reino Myllymäki

9789527044322.jpgViikko sitten julkaistussa blogikirjoituksessa kerroin tuhoisan, Teneriffalla 27.3.1977 tapahtuneen lento-onnettomuuden opiksi otettavista asioista ja tänään jatkan saman onnettomuuden tiimoilta.

Tuota 583 ihmishenkeä vaatinutta lento-onnettomuutta tutkittaessa huomattiin ongelmia viestinnässä. Käytettiin epävirallisia ilmaisuja, jolloin syntyi väärinkäsityksiä. Lentoliikenteessä, joka on kansainvälistä toimintaa, yksikäsitteisten fraasien käyttäminen on tärkeää varsinkin, kun kaikkien englanninkielen taito ei ole korkealla tasolla.

Edellisessä kirjoituksessa kerroin tapauksesta, jossa huomasin keskustelijoiden päässeen kuviteltuun yhteisymmärrykseen, koska he puhuivat eri asioista. Se on täysin mahdollista, koska samalla termillä voidaan useinkin tarkoittaa useita asioita, ellei terminologiaa ole määritelty.

Esimerkkejä tulee vastaan joka päivä. Mieleeni on jäänyt, kuinka oikoradan suunnitteluvaiheessa käytettiin sanontaa "tontti, jolla sijaitsee kiinteistö", jolla tarkoitettiin "kiinteistöä, jolla sijaitsee rakennus". Kiinteistöihmisillä on kiinteistö-sanalle eri merkitys kuin maankäyttöihmisillä.

Terveyskeskuksessa oli eräässä ovessa lappu, jossa kirjoitettiin "vaippatilauksien vastaanottamisesta". Kontekstistä päättelin, että kysymys oli terminologiavirheestä ja tekstillä tarkoitettiin tilattujen vaippaerien toimitusten vastaanottamisesta. Tilaus ja toimitus samoinkuin tarjous ja tarjouspyyntö menevät usein sekaisin. Esimerkiksi tietojärjestelmää rakennettaessa tällaisten termien sisällön tulee kuitenkin olla yksiselitteinen.

Yhteinen terminologia parantaa projektien onnistumisen todennäköisyyttä sekä substanssi- että projektiterminologian osalta. Projektitoiminnan osalta yhteinen terminologia on helpompi saavuttaa, substanssin (vaikkapa tietyn toimialan liiketoiminta) osalta tilanne vaihtelee.

Pidän terminologiaa tärkeänä. Se on osa organisaation kokonaisarkkitehtuuria. Yhteistä terminologiaa on hyvä määritellä, testata ja jalkauttaa projektien yhteydessä ja muutenkin. Mutta erillisten sanasto- eli terminologiaprojektien ennuste on huono. Ne hyvin helposti keskeytetään turhaan resursseja vievänä "hömpötyksenä".

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, projektityö, cockpit resource management, CRM

Kohti onnistunutta kehitysprojektia, osa 13: Epätasa-arvo on riskitekijä

Maanantai 26.11.2018 - Tuottavuusaktivisti Reino Myllymäki

9789527044322.jpgKun olen nyt ottanut esille lento-onnettomuuksiin liittyviä oppeja, joita hyödyntämällä lentoturvallisuus on saatu nostettua nykyiselle korkealle tasolle, otan tässä ja ehkäpä myös seuraavassa blogikirjoituksessa vielä pari asiaa, joissa projektitoiminta voisi ottaa oppia lentämisestä ja CRM:stä (Cockpit Resource Management).

Asiat tulivat vastaan kustantaessani Jari Rinteen kirjan Lento-onnettomuudet lentoturvallisuuden kehittäjinä.

Kun KLM:n Boeing 747 -koneen kapteeni Jacob Veldhuyzen van Zanten päätti aloittaa lähtökiidon sumuiselta Los Rodeosin lentokentältä Teneriffan saarelta lyhyelle lennolle Las Palmasin lentokentälle 27.3.1977, hän toimi itsevaltiaan tavoin. Hetken kuluttua vastaan tuli kiitoradalla rullaava Pan-Amin samantyyppinen matkustajakone, eikä KLM:n kapteenin viime hetken yritys nostaa kone ilmaan onnistunut. Lopputuloksena koneet törmäsivät ja syntyi historian pahin lento-onnettomuus, jossa 583 ihmistä menehtyi.

Syitä onnettomuuteen on monia. Yksi niistä on ohjaamotyöskentely. Tuon aikaista auktoriteettijärjestystä voi kuvata sanomalla, että kapteeni oli kuin "jumalasta seuraava" ja perämies kuin "välttämätön paha". Lisäksi juuri tuon koneen ohjaamossa arvoero oli suurin mahdollinen, sillä kapteeni oli tarkastuslentäjänä hyväksynyt perämiehen perämieskelpuutuksen vain kaksi kuukautta aikaisemmin. Lisäksi kapteeni Jacob Veldhuyzen van Zanten oli KLM:n mainoksissa esiintyvä "kiiltokuvapoika". Firman ykköskuski.

Jari Rinne kirjoittaa: "Esimiehen toimiin puuttuminen on aina riski. Pahimmillaan puuttuja saa kovin huonon maineen yhteistoimintaan kyvyttömänä henkilönä, eikä ole vaikea päätellä, kenellä tällöin on huonot mahdollisuudet edetä urallaan ja toisaalta, kuka lähtee työttömäksi kaikkein helpoiten. Tämä problematiikka säilyy niin kauan kuin ihmisetkin, eikä helppoa ratkaisua ole. Lentämisen osalta ratkaisu on kuitenkin aivan välttämätön ja pakollinen. Muutoin kuolee ihmisiä – jo saman syyn vuoksi kuolleiden lisäksi – edelleen aivan turhan vuoksi."

Ohjaamon äänitallentimen mukaan sekä perämies että lentomekaanikko yrittivät kyseenalaistaa epäselvässä tilanteessa kiitotien vapaanolemisen. Kapteeni kuului kuitenkin sen ajan "erehtymättömiin" ja aloitti lähtökiidon tulkittuaan saaneensa lennonjohdolta lähtöluvan. Häneltä jäi kahden samalla VHF-radiotaajuudella yhtä aikaa tehdyn viestin vuoksi kuulematta, millaisia ohjeita lennonjohto antoi. Lennonjohtaja sanoi ensin "OK" ja pienen tauon jälkeen: "Odota lentoonlähtöä varten, kutsun uudelleen". OK-kuittaus kuultiin, loppuosaa ei. Asiat tulkittiin väärinpäin.

Useamman kerran minulle on tapahtunut projektitoiminnassa niin, että hälytyskellot alkavat (kuvannollisesti) soida päässäni. Joko niin, että huomaan kahden tai useamman ihmisen pääsevän kuvitteelliseen yksimielisyyteen jostakin asiasta, vaikka ulkopuolisena tajuan heidän puhuneen eri asioista. Tai yksinkertaisesti minulle syntyy tunne, että kaikki asiat eivät ole kunnossa. Syy tunteeseen selviää ennemmin tai myöhemmin. Joskus se on väärä hälytys, useimmiten kuitenkin olen alitajuisesti tajunnut jonkin asian olevan pielessä, mutta en vain ymmärrä, mistä on kysymys.

Jos nykyään liikennelentokoneen miehistöstä kuka tahansa - kapteeni, perämies, lentoemäntä, stuertti tai ihan kuka tahansa - kertoo, että hänen mielestään asiat eivät ole koneessa kunnossa lentoonlähdössä, se keskeytetään ja palataan takaisin seisontapaikalle selvittämään, mikä on vialla.

Tarvitsemme projektitoimintaan samanlaista tasa-arvoisuuden tuomaa avoimuutta. Jotta jokainen uskaltaisi kertoa havaintonsa tai epäilyksensä, ennenkuin tehdään toimenpiteitä, joissa asiat voivat mennä pieleen. Tähän päästään rakentamalla yrityksiin keskustelevaa johtamiskulttuuria.

Rakensimme omakotitaloa 1990-luvun lopulla. Kerran lähdimme keskeneräiseltä taloltamme asuntoomme nukkumaan. Oli myöhäinen ilta ja näimme eräässä rakenteilla olevassa rivitalossa tulipalon klassiset tunnusmerkit. En jäänyt tutkimaan asiaa, vaan soitin palokunnan paikalle. Paljastui, että olivat höyryttämässä alapohjan jäätynyttä maata ja se minkä olin pimeydessä tulkinnut räystään alta tunkevaksi savuksi olikin höyryä. Sainko moitteet väärästä hälytyksestä? En! Palopäällikkö löi minua olkapäälle ja sanoi, että "oikein toimittu!"

Hyvän johtamiskulttuurin rakentaminen ei onnistu helpolla eikä nopeasti. Sitä nopeammin se kuitenkin valmistuu, mitä aikaisemmin sen aloittaa. Mieluummin tänään.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, projektityö, cockpit resource management, CRM

Kohti onnistunutta kehitysprojektia, osa 12: Älä unohda tehdä sitä, mitä olet tekemässä

Keskiviikko 21.11.2018 - Tuottavuusaktivisti Reino Myllymäki

9789527044322.jpgKahdestoista blogi myöhästyi kahdella päivällä, mutta parempi myöhään kuin ei milloinkaan.

Tuolle edelliselle blogikirjoitukselle jatkoksi toinenkin Lento-onnettomuudet lentoturvallisuuden kehittäjinä -kirjan kustannusprosessissa tietoisuuteen tullut kultahippunen.

Eräällä lennolla (Easter Air Lines 401, 29.12.1972) oltiin laskeutumassa Floridaan. Perämies lensi, kapteeni oli vapaana. Lisäksi ohjaamossa oli lentomekaanikko. Laskuteline laskettiin alas, mutta nokkapyörän merkkivalo ei syttynyt. Pääteltiin, että merkkivalo oli rikki. Perämies alkoi vaihtamaan polttimoa ja kun ei voinut sitä tehdessään lentää, kytkettiin autopilotti päälle. Oltiin 600 metrin korkeudessa.

Koko ohjaamomiehistön huomio kiinnittyi ongelmaan. Jossain vaiheessa kapteeni tönäisi tai hipaisi ohjaimia, jolloin autopilotti meni pois päältä, kone lähti loivaan laskuun ja laskeuduttuaan 76 metriä alkoi varoitusignaali. Sitä ei kukaan huomannut, vaan kone törmäsi maahan. Kyydissä olleista 175 ihmisestä 101 menetti henkensä.

Samanlaisia tilanteita tapahtuu maaliikenteessä. Matkapuhelimeen puhuttaessa auton kuljettajan huomio kiinnittyy muualle ja onnettomuusriski kasvaa. Mutta sama voi tapahtua myös vaikka kehitysprojektissa: jonkin ongelman tai häiriötekijän käsittely vie niin paljon aikaa, että varsinainen asia - projektin vieminen eteenpäin hallitusti - häiriintyy tai jopa unohtuu.

Joskus projektin voi keskeyttää, jos ongelma on niin suuri, että vaarantaa projektin onnistumisen. Myös lennon voi keskeyttää. Sitä kutsutaan pakkolaskuksi. Mutta usein projektia ei keskeytetä, vaan sitä jatketaan samalla ongelmia selvitellen ja häiriötekijöitä selvitellen. Häiriötekijä voi olla yhtä hyvin projektin yli-innokas ja vaikutusvaltainen asiakas tai sponsori kuin jokin teknologiafriikki "primadonnakin".

Cockpit Resource Management (CRM) -oppia mukaillen on sovittava, kuka jatkaa projektin johtamista ja ohjaamista, jos vaikka projektinjohtaja keskittyy ongelman selvittelyyn.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, projektityö, cockpit resource management, CRM

Kohti onnistunutta kehitysprojektia, osa 11: Viisas lentäjä etsii aina pakkolaskupaikkaa.

Maanantai 12.11.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto.jpgPuoli vuotta sitten erään kokouksen päätteeksi kysyin vierustoveriltani eräästä projektista. Että kuinka todennäköisenä hän piti sen toteutumista. "Se on 100 %, muuta ei kannata ajatellakkaan!" sanoi hän. Sanoin, että omasta mielestäni todennäköisyys oli alle 50 %.

Jotkut pitävät vaihtoehdottomuutta keinona saavuttaa päämäärä. Kun ei ole "plan B:tä", ei voi turvautua vaihtoehtoisiin suunnitelmiin, vaan on mentävä silmälaput silmillä sen ainoan suunnitelman mukaisesti.

Tämän tyyppistä ajattelua edustaa suuri strategi Sun Tzukin: "Heitä joukot tilanteeseen, josta ei ole ulospääsyä, niin ne ennemmin kuolevat kuin pakenevat. Jos kuolema on väistämätön, upseerit ja sotilaat antavat kaikkensa". Kyse on kuitenkin taistelun voittamisesta, taktiikasta, ei sodan voittamisesta ja strategiasta. Suurella strategilla oli aina varasuunnitelmia, joita ei upseereille ja sotilaille välttämättä kerrottu.

Kustantaessani Jari Rinteen kirjaa Lento-onnettomuudet lentoturvallisuuden kehittäjinä mieleeni jäi lause "viisas lentäjä etsii aina pakkolaskupaikkaa", jota kirjailija kutsuu yksinkertaisesti vanhaksi toteamukseksi. Se merkitsee sitä, että on koko ajan mielessä paikka, jonne kone lasketaan mahdollisimman turvallisesti, jos lentäminen käy mahdottomaksi.

Kirjailija kutsuu alituista "pakkolaskupaikan etsimistä" turvallisen lentämisen henkiseksi perustaksi. Tehdään kaikki mahdollisimman hyvin, jotta tavoite saavutetaan, samalla kuitenkin koko ajan realistisesti varasuunnitelmaa. Jos kaikki ei menekään niin kuin pitäisi.

Tämä viisaus on vain yksi niistä opeista, jotka kuuluvat kokonaisuuteen, joka lentämisessä tunnetaan kirjainyhdistelmällä CRM, joko Cockpit Resource Management tai Crew Resource Management. Sitä noudattamalla lentoturvallisuus on saatu sille huipputasolle, jossa se nykyään on.

Epäonnistumiset eivät poistu sillä, että ne kielletään. Ei, ne ovat osa elämää, joita ei pidä pelätä. Mutta varautua niihin kannattaa.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, projektityö, cockpit resource management, CRM

Kohti onnistunutta kehitysprojektia, osa 10: Onko projektien aika ohi?

Maanantai 5.11.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgKun projekti epäonnistuu, saattaa mieleen juolahtaa, että epäonnistumisista päästäisiin, jos ei olisi projekteja. Että projekti on se, joka aiheuttaa epäonnistumisen.

Projektitoimintaan liittyy toki paljon ongelmia. Esimerkiksi projektitoiminnan ja muun toiminnan yhteensovittaminen on ongelma, joka esiintyy kaikissa projektoimintaa harjoittavissa yrityksissä ja yhteisöissä. Mitä tehdään sitten, kun projekti päättyy?

Projektitoiminnan ongelmista huolimatta Kari Leppälä huomautti kirjassaan Projektitoiminnan musta kirja jotenkin siihen tapaan, että projekti on edelleen ylivoimainen tapa valjastaa resurssit tietyn tavoitteen saavuttamiseen. Eli Winston Churchillia mukaillen:

 Kukaan ei väitä, että projekti olisi täydellinen tai kaikkitietävä. Itse asiassa, on sanottu, että projekti on huonoin organisointitapa, ellei mukaan lasketa kaikkia muita organisointitapoja, joita aika ajoin on kokeiltu.

Oman projektitoimistourani aikana tuli vastaan tilanteita, että jotain järjestelmää pyydettiin muuttamaan saatesanoilla "se on pikku juttu, hoitakaa se pois. Älkää nyt siihen mitään projektia perustako..." Se on jo oma juttunsa, että muutoksia systeemeihin halutaan tehtävän jotenkin epävirallisesti "tiskin alta", mutta huolestuttavampaa oli, ettei pyytäjä ymmärtänyt systeemisuunnittelun perusasioita. Muutoksia voi toki tehdä tuosta noin vain, jos ei välitä vaikutuksista kokonaisuuteen.

Ei, kyllä projekti on edelleen voimissaan. Tarvitsemme eri järeyden toimintatapoja pieniin ja suuriin hankkeisiin, ja tarvitsemme vesiputousmalleja tietyntyyppisiin ja ketteriä menetelmiä toisentyyppisiin hankkeisiin. Tarvitsemme pilotointia, pöristimiä, himmeleitä ja systeemejä.

Tarvitsemme myös projektien käynnistämisen tarkistuslistoja ja ulkopuolista auditointia - terveystarkastuksia - hankkeille. Jotta ne saavuttaisivat tavoitteensa aikaa, rahaa ja muita resursseja tuhlaamatta tai tapettaisiin heti, kun huomataan onnistumisten edellytysten menneen.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, projektityö

Kohti onnistunutta kehitysprojektia, osa 9: Rikkinäinen puhelin ei toimi

Maanantai 29.10.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgKehityshankkeelle perustetaan johto- ja ohjausryhmät yleensä vasta siinä vaiheessa, kun nimet IT-palvelutalon tai -talojen kanssa ovat pahvissa. IT-palvelutaloilla on taipumus ajatella, että ylin päättävä elin miehitetään tasapuolisesti asiakkaan ja toimittajan edustajilla sekä mahdollisesti vielä kolmannen osapuolen, asiakkaan konsulttitoimiston, edustajalla. Todellisuudessa tällainen ryhmä on ohjausryhmä ja sen yli menee vielä pelkästään asiakkaan edustajista koottu johtoryhmä.

Jos projektia on valmisteltu pitkään, valmistelu tuskin on tehty yhden ihmisen voimin. Yleensä sitä on ollut tekemässä ryhmä, joka vastaa hyvinkin toteutusvaiheen ohjaus- tai johtoryhmää. Ikävä kyllä, usein henkilöt vaihtuvat ja se on sääli. Kari Leppälä toteaa kirjassaan Projektitoiminnan musta kirja, että kysymyksessä on yksi projektitoiminnan käsittämättömyyksistä.

Kun ihmiset vaihtuvat, tietojen siirto jää vähäiseksi. Kapulanvaihto jää tekemättä, eikä viesti mene perille. Valmistelun tehneet tietävät projektin tavoitteista ja taustoista paljon sellaista, joka olisi toteuttavalle porukalle hyödyllistä.

Projektiryhmäkin kasvaa, kun toteutus alkaa. Niinpä projektiin tulee paljon sellaista väkeä, jolla on kapea ja jopa vääristynyt käsitys projektin tavoitteista ja taustoista. Näiden asioiden tietoisuuteen viemiseen kannattaa kuitenkin käyttää aikaa ja vaivaa. Muuten jossain vaiheessa pidetään intohimoisesti kiinni ei-tärkeistä tavoitteista ja päästetään irti tärkeistä.

Pidä siis huoli, että linkki strategiaan ymmärretään vielä toteutus- ja käyttöönottovaiheissakin, samoinkuin vastaus kysymykseen: "Mikä ongelma tällä yritetään ratkaista?"

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, johtoryhmä, ohjausryhmä, viestintä

Kohti onnistunutta kehitysprojektia, osa 8: Ota huomioon sopimusneuvotteluissa

Maanantai 22.10.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgVain harva kehityshanke voidaan toteuttaa ilman sopimuksia. Usein sopimus IT-palvelutalon kanssa on keskeisessä osassa kehityshankkeen toteutusta.

Sopimusneuvotteluissa kaksi osapuolta on eripuolilla pöytää. Asiakas ostaa palveluja ja tuotteita sekä toimittaja myy palveluja ja tuotteita. Kolmantena osapuolena voi olla asiakkaan valintakonsultti tai projektinomistajan/johtajan mentori. Mitä pienemmästä asiakasyrityksestä on kysymys, sitä harvemmin tällaiset sopimusneuvottelut tulevat vastaan ja sitä fiksumpaa on käyttää apuna ulkopuolista auttajaa. Itse olen toiminut tällaisena apuna useita kertoja.

Sopimusneuvottelutilanteessa - niin kuin koko kehitysprojektissa - IT-toimittaja pitää perustellusti asiakasta oman liiketoimintansa ja toimintaympäristönsä asiantuntijana. Näin tietysti onkin, joskaan läheskään aina asiakkaan edustajat eivät tunne edustamaansa yritystä läpikotaisin, eikä sitä, miten yritystä aiotaan tai voisi tulevaisuudessa kehittää.

Vastaavasti asiakas pitää IT-toimittajaa tarjoamiensa tuotteiden ja palvelujen asiantuntijoina. Näinkään ei aina ole. Asiantuntemusta on monen tasoista ja totuus tasosta voi joskus olla aika karu. Joka tapauksessa nämä ovat lähtöasetelmat ja niissä esiintyvät epävarmuudet luovat pohjaa sopimusneuvottelujen ja sopimuksen täytäntöönpanon ongelmille.

Sopimusehdotus, josta neuvotteluissa keskustellaan, on useimmiten toimittajan laatima. Se on tehty toimittajan näkökulmasta. Asiakas ja asiakkaan tilanne on sopimuksessa kuvattu staattisena ikään kuin asiakas ei kehittyisi tai muuttuisi mitenkään sopimuksen soveltamisperiodin aikana. Kun ottaa huomioon, että sopimusnivaskaan kuuluu varsin pitkällä tähtäimellä sovellettavia osia, kuten tuki- ja ylläpitosopimuksia, kysymyksessä on puute.

Se, mitä sopimus aina sisältää, on saman tien hankittavien tuotteiden ja palvelujen hinnat ja ylläpitomaksut. Joskus ylläpitomaksuja ja lisähankintojen hintoja on sidottu tai jäädytetty joitakin vuosia eteenpäin. Harvemmin on otettu huomioon, että asiakas voi joutua supistamaan toimintaansa tai myymään osiaan pois. Kuitenkin nämä ovat aivan normaalia yritystoimintaa.

Yrityksen osan, etenkin tytäryhtiön, myyminen on tietojärjestelmien käyttöoikeuslisenssien ja sopimusten näkökulmasta vaarallista puuhaa, ellei asioita ole otettu huomioon jo sopimuksia neuvoteltaessa. Nimittäin, kun tytäryhtiö myydään, on se saman tien käyttöoikeuslisenssien osalta sopimuksettomassa tilassa. Tietojärjestelmiä ei saa käyttää ja usein yrityskauppa on sovittu ostajan kanssa siten, että liiketoiminta jatkuu saumattomasti omistajanvaihdoksesta huolimatta.

Ongelma on ratkaistavissa kahdella tapaa. Toisessa asiakas sopii IT-palvelutalon (ja sen päämiesten) kanssa ennen yrityskauppaa väliaikaisesta käytöstä. Tämä edellyttää IT-palvelutalon edustajien sisällyttämistä sisäpiiriin ja pahimmillaan kymmeniä neuvotteluja lyhyessä ajassa ja lähtöasetelma asiakkaan puolelta on huono. Tämäkin kuuluu valitettavasti koettujen asioiden piiriin.

Toinen tapa on sopia jo alkuperäisiä sopimuksia tehtäessä väliaikaisen käytön periaatteista ja hinnoista. Tällä vältetään vähintään sopimuksettomaan tilaan joutuminen, kiireiset neuvottelut ennen yrityskauppaa ja parhaassa tapauksessa mahdollistetaan ilman lisäneuvotteluja ja -sopimuksia yrityskaupan toimeenpano. Tällaisia erikoisehtoja olen päässyt neuvottelemaan muutaman asiakkaan sopimuksiin ja ainakin yksi raportoi, että tuleva yritysjärjestely helpottui olennaisesti, kun se oli alunperinkin otettu huomioon sopimuksia laadittaessa.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, sopimusneuvottelu

Kohti onnistunutta kehitysprojektia, osa 7: Yhteensopivuusongelmat ovat yleisiä

Maanantai 15.10.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto.jpgYritysten ja yhteisöjen tietojärjestelmäkokonaisuudet ovat yhä monimutkaisempia, mikä vaikeuttaa uusien kehityshankkeiden läpivientiä.

Kirjassa Miksi tietojärjestelmäprojekti epäonnistuu? jaoin yhteensopivuusongelmat kahteen luokkaan: käyttöönotettavan tietojärjestelmän yhteensopivuus yrityksen tai yhteisön kokonaisarkkitehtuuriin ja käyttöönotettavan tietojärjestelmäkokonaisuuden sisäiset yhteensopivuusongelmat. Kolmantena on tietysti vielä käyttöönotettavan tietojärjestelmän yhteensopivuus käyttäjiin, mutta käsitellään sitä erikseen muutosjohtamisen yhteydessä.

Kokonaisarkkitehtuurityö on sitä, että luetellaan organisaation periaatteet ja valinnat sekä niiden suhteet toisiinsa. Tehokkaassa ympäristössä periaatteet ja valinnat tukevat toisiaan niin, että niiden määrä on pienin mahdollinen. Usein tarvitaan kuitenkin vaihtoehtoisia, rinnakkaisia valintoja, jotta kaikki haluttu mahdollistuu.

Kokonaisarkkitehtuurityöhön kuuluu myös olemassa olevan kokonaisarkkitehtuurin kelpoisuuden tarkistaminen aika ajoin. Minkä ohitse aika on ajanut, mikä ei vastaa enään tarkoitustaan, mihin kohdistuu muutospaineita? Kokonaisarkkitehtuuria ei pidä hakata kiveen.

Toinen olennainen asia on kokonaisarkkitehtuurin poikkeusten käsittely. Onko kokonaisarkkitehtuurilla vain ohjaava vaikutus? Silloin kaikki saattavat tehdä miten huvittaa, jolloin poikkeuksiakaan ei tarvitse käsitellä. Lopputulos on sekamelska. Tai onko sillä määräävä vaikutus? Jos näin, poikkeuksia pitää olla mahdollista tehdä, mutta ne vaativat käsittelyn. Silloin kehityshankkeiden tarvitsevat poikkeukset kokonaisarkkitehtuuriin vaativat ja saavat arvoisensa käsittelyn.

Myyjät lupaavat helposti semmoistakin, mikä ei onnistu. He eivät välttämättä ole lunastamassa aikanaan lupauksiaan, vaan sen tekee toimittamista tekevä lunastusosasto. Niinpä kannattaa kuunnella omia ja toimittajan asiantuntijoita herkällä korvalla. Jos asiantuntija sanoo: "Kyllä se periaatteessa onnistuu", se ei tarkoita, että "kyllä se onnistuu", vaan, että "ei se käytännössä onnistu".

Yhteensopivuuskysymyksiin kannattaa suhtautua vakavasti.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, kokonaisarkkitehtuuri

Kohti onnistunutta kehitysprojektia, osa 6: Vältä räätälöintejä!

Maanantai 8.10.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgKirjan Miksi tietojärjestelmäprojekti epäonnistuu? haastattelujen tekemisen yhteydessä ja yrityksiä tietojärjestelmäprojektien valmistelussa auttaessani sain kuulla kauhutarinoita loppuun asti räätälöidyistä valmisohjelmistoista. Siis siitä, että valmisohjelmiston käyttöönottoprojektissa järjestelmää puukotettiin niin paljon, että edes projektinaikainen - saati käytönaikainen - versionvaihto ei enää onnistunut.

Olenkin sanonut, että on hetteisellä tietojärjestelmien käyttöönoton suolla on kaksi reittiä, jotka ovat suhteellisen turvallisia: (koeteltujen) valmisohjelmistojen käyttöönotto ilman räätälöintejä ja ohjelmointiprojekti. Näiden välissä on upottava räätälöintirämeikkö, jolle ei kannata mennä.

Valmisohjelmiston soveltuvuuden vertailussa usein mieleen hiipii ajatus, että "tämä olisi meille sopiva, jos tuo ja tuo asia muutettaisiin". Seis! Nyt on nirvana-virhepäätelmä lähellä! Nirvanahan houkuttelee meidät etsimään täydellistä ratkaisua ja hylkäämään kaikki tilannetta parantavat mutta epätäydelliset ratkaisut.

Parempi tapa on miettiä, onko tarjolla oleva valmisratkaisu käyttöönotettavissa sellaisenaan. Tuhoaako jokin puute kilpailukykymme? Jos tuhoaa, ratkaisu ei ole oikea meille. Mutta muussa tapauksessa valmisjärjestelmä on mahdollinen ilman räätälöintejä.

Jos omat vaatimukset ovat "ihan aikuisen oikeasti" niin erikoisia, että mikään valmisohjelmisto ei niihin vastaa, voi olla ohjelmointiprojektin eli kokonaan uuden tietojärjestelmän kehitysprojektin paikka. Sen lainalaisuudet ovat osin toiset kuin valmisjärjestelmän käyttöönotossa. Yhteistä on nirvana. Pitää välttää ajatusta, että "kaiken luvatun on oltava valmista heti kerralla" ja varauduttava vaiheittaiseen käyttöönottoon. Sekin on muutosjohtamisen paikka.

Ohjelmointiprojektissa on omat vaikeutensa ja riskinsä. Valmista ei siinäkään välttämättä tule, vaikka rahaa kuluu. Lisäksi kaava, jolla 80 % ominaisuuksista saadaan 20 %:lla kuluista ja 95 % 50 %:lla, panee miettimään product backlogin vihoviimeisten tekemisten takaisinmaksuaikaa.

Joka tapauksessa on varauduttava vaikeuksiin ja muutosjohtamiseen. Varautuminen on viisautta, ei vaikeuksien esiin manaamista.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja. Tämä blogikirjoitus julkaistaan myös hänen verkkosivuillaan www.tuottavaksi.fi/blogi.html.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, räätälöinti, sovittaminen, mukauttaminen

Kohti onnistunutta kehitysprojektia, osa 5: Onko ratkaisu etukäteen valittu?

Perjantai 5.10.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgTarjolla oleviin ratkaisuihin - niin tietoteknisiin kuin muihinkin - on helppo ihastua ja jopa rakastua. Ihastuminen ja rakastuminen ovat monissa yhteyksissä hyvä asia, mutta kehitysprojektissa näin ei välttämättä ole. Uskomme helposti, että ihastumisen tai rakastumisen kohde on ainoa vaihtoehto, joka tekee meidät onnellisiksi. Se estää meitä tutkimasta vaihtoehtoja. edessä on vaihtoehdottomuus.

Ystävän tai tuttavan hyvät kokemukset omassa ympäristössään nyt meillekin tarjolla olevasta ratkaisusta saattavat harhauttamaan meidät uskomaan, että juuri tuo sama on meillekin saatava. Peliin voi astua myös kilpailuhenki, jonka mukaan kyllä meilläkin tuo juttu otetaan käyttöön. Myös myyjät ovat hyviä saamaan meidät uskomaan, että heidän tarjoamansa tuote on paras ratkaisu.

Jos ratkaisu valitaan etukäteen, kaikki vaihtoehtojen tutkimiset ovat turhia. Konseptointi voi olla turhaa, ja helposti projektin valmisteluun osallistuva henkilökunta turhautuu. Selviytyminen edellyttää asennemuutosta, jossa unohdetaan vaihtoehdot ja aletaan miettiä, mitä valitulla ratkaisulla voidaan tehdä ja miten.

Jos on onnea, lopputuloksena voi olla onnistunut lopputulos. Osin tämä riippuu siitä, kuinka projektiorganisaatio ja liiketoimintajohto sitoutuu ennalta valittuun ratkaisuun. Jos sitoutumista ei ole, projekti kannattaa lopettaa heti. Asiaan vaikuttaa myös projektin koko. Jos projekti on laajuudeltaan pieni ja nopea, onnistumisen mahdollisuudet tässäkin tapauksessa ovat paremmat, varsinkin jos ratkaisu osoittautuu käyttöönottovaiheen jälkeen hyväksi.

Parempi vaihtoehto on, että projektin valmistelu viedään läpi vaihtoehtoja tutkien. Mietitään, missä on yrityksen kilpailuetu nyt ja tulevaisuudessa, ja varmistetaan, että näitä ei projektin lopputulosten käyttöönoton myötä menetetä. Ratkaisun tarvitsee muilta osin olla vain riittävä, joskin silloin on varauduttava isoon muutosjohtamiseen.

Ratkaisun kiinnittäminen aikaisessa vaiheessa on kuin oikopolku. Monet suunnistajat tietävät, että harvoin oikopolku säästää aikaa. Usein se on harhapolku.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio,

Kohti onnistunutta kehitysprojektia, osa 4: Älä pelkää epäonnistumisia?

Maanantai 24.9.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgMiten asia sanottiinkaan eräässä televisiossa juuri nyt pyörivässä mainoksessa? Oliko se, että: "hyvät päätökset perustuvat kokemukseen, kokemus kertyy huonoista päätöksistä." Joku toinen on sanonut, että "epäonnistuminen luonnollinen välivaihe pyrittäessä onnistumiseen".

Tavoittelemme onnistumisia, pelkäämme epäonnistumisia. Välillä pelkäämme epäonnistumisia niin, ettei se anna tilaa onnistumisille. Hiljattain julkaistu Mika Sutisen ja Mikko Kuitusen kirja Mahtava moka muistuttaa, että epäonnistunut projekti, jonka juurisyyt tunnetaan ja joita voidaan organisaatiossa käyttää hyväksi, on arvokkaampi kuin sattumalta onnistunut projekti, josta ei ymmärretä, miksi onnistuttiin.

Tietoyhteiskunnan kaksi puolta -kirjassa määrittelin epäonnistumiset kolmeen eri lajiin:

Ratkaisun epäonnistuminen syntyy, kun emme onnistu luomaan sellaista tietoteknistä ratkaisua, joka täyttäisi käyttäjäorganisaation tarpeet. Voi olla, että projektissa yritetään käyttää ei-toimivia teknologioita, teknologiat eivät toimi yhteen tai projektissa ei vain yksinkertaisesti ole riittävästi osaamista. Joskus lopputulos saadaan kyllä toimimaan, mutta sen ylläpito on hankalaa ja kallista.

Projektitekninen epäonnistuminen syntyy, kun kustannukset ylittyvät, aikataulu menee pitkäksi tai suunniteltua toiminnallisuutta jää toimittamatta. Projektin budjetti voi olla täysin väärin arvioitu, projektinhallinnassa voi olla puutteita tai ratkaisun epäonnistuminen nostaa kustannuksia ja vie aikaa.

Liiketoiminnallinen epäonnistuminen syntyy, kun toimitettu tietotekninen kokonaisuus ei täytä tarpeita, on vaikea käyttää, toimitetaan liian myöhään, on vaikea ylläpitää tai yksinkertaisesti kustannukset ylittävät hyödyt. Usein liiketoiminnallisen epäonnistumisen takaa löytyy joko ratkaisun epäonnistuminen tai projektitekninen epäonnistuminen tai molemmat, mutta liiketoiminnallinen epäonnistuminen voi syntyä ilmankin niitä. Esimerkiksi muutosjohtamisen epäonnistuminen voi systätä kehitysprojektin epäonnistuneiden kastiin, vaikka muuten se olisi onnistunut.

Yhä edelleen pitää paikkaansa se näkökohta, että pieni projekti onnistuu todennäköisemmin kuin suuri. Pienessä projektissa suunnitelma ja suunnitelman visualisointi ovat lähempänä toisiaan, jolloin vääriä raiteita on ehditty kulkea vähemmän matkaa kuin suuressa.

Paikkaansa pitää edelleen sekin, että vahingot ovat sitä pienemmät, mitä aikaisemmin ongelmaan puututaan. Epäkohtien sivuuttaminen sillä perusteella, että aika korjaa ongelmat, on väärä tie.

Onnistumiset ovat hieno asia. Melkein yhtä hieno asia on epäonnistuminen, jonka juurisyyt ymmärretään ja opitaan niin, että korjaavat liikkeet on ollut mahdollista tehdä. Onnistumiseksi naamioitu epäonnistuminen ei tuota ymmärrystä ja oppimista synnytä, vaan aiheuttaa epäonnistumisten kierteen.

Siispä: lopetetaan epäonnistumisten piilottelu. Tunnustetaan epäonnistumiset, analysoidaan juurisyyt, opitaan ja parannutaan. Se on ainoa tie jatkuviin onnistumisiin.

Kirjoittaja, tietokirjailija ja tuottavuusaktivisti Reino Myllymäki, on tutkinut tietojärjestelmäprojektien onnistumista vuodesta 2009 ja julkaissut aiheesta kaksi kirjaa. Hän on myös Tieto- ja viestintätekniikan ammattilaiset TIVIA ry:n hallituksen jäsen ja tietoyhteiskuntatoimikunnan puheenjohtaja.

Kommentoi kirjoitusta. Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, epäonnistuminen

Vanhemmat kirjoitukset »