Blogi

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.

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.

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.

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.

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.

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.

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.

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.

Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, johtoryhmä, avainhenkilöt

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.

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_vaihtoehto2.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.

Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, arkkitehtuuri

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.

Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, räätälöinti, standardiohjelmisto

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

Maanantai 1.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.

Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, toimintatapamuutos, muutosjohtaminen

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.

Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, toimintatapamuutos, onnistuminen, epäonnistuminen

Kohti onnistunutta kehitysprojektia, osa 3: Varaudu muutosjohtamiseen!

Maanantai 17.9.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgLähes poikkeuksetta jokainen kehitysprojekti tuo mukanaan muutoksia. Juuri siksihän kehitysprojekteja viedäänkin läpi, että joku asia muuttuisi!

Toisaalta, kehitysprojektin nimenomainen tarkoitus voi olla muuttaa jokin tai jotkin toimintatavat toiminnan tehostamisen tai vaikkapa laadun parantamisen vuoksi. Jopa ns. tekninen uusimisprojekti johtaa lähes poikkeuksetta muutoksiin.

Toisin päin ajatellen; moni projekti epäonnistuu muutosjohtamisen puutteiden vuoksi. Joko muutosta ei ole johdettu ollenkaan, se ei ole kohdistunut oikeisiin ihmisiin tai se ei ole tehonnut. Jos tekeminen jatkuu uusista toimintatavoista ja järjestelmistä huolimatta kuin ennenkin, seuraukset voivat olla vakavia.

Johtajien joukossa on edelleen liikaa niitä, jotka suhtautuvat liian kevyesti tai jopa väheksyvästi muutosjohtamiseen. Vallalla on ajatusta, että organisaation pitää itse vastata sopeutumisestaan uuteen tilanteeseen. Jossain ideaalitilanteessa näin voi käydäkin, mutta se vaatii keskivertoa valveutuneemman henkilökunnan. Ilman muutoksia ei hyötyjä saavuteta. Keskiverto yritys ei taivu muutoksiin ilman johtamista. Ja johtaminen on johtajien tehtävä.

Kehitysprojektin projektipäällikön valtuudet eivät yleensä riitä liiketoiminnallisten muutosten läpiviemiseen. Olenkin pilaillut, että projektipäällikkö huomaa mandaattinsa pienuuden viimeistään kutsuessaan liiketoiminnan väkeä koulutuksiin. Projektipäällikön osaamisen, auktoriteetin ja hurmauskyvyn varaan muutoksen läpiviemistä ei pidä laskea. Liiketoiminnan johtajien on siitä otettava vastuu.

Olen itsekin kirjoittanut muutosjohtamisesta kaksi kirjaa  Muutosjohtamisen oppaan ja Sano se selvästi! -kirjan, joka opastaa muutosviestinnässä. Olennaista muutoksessa on pitää muutostahto muutosvastarintaa (eli oppimisahdistusta) suurempana ja se kannattaa tehdä vähentämällä muutosvastarintaa psykologisen turvallisuudentunteen lisäämisen keinoin. Lisäksi kannattaa panostaa asioihin, jotka yhtä aikaa lisäävät muutostahtoa ja alentavat muutosvastarintaa. Johdon karismaattisesti esittämä uskottava positiivinen tulevaisuuskuva on yksi sellainen.

Muutosjohtamista ei aina mielletä kehitysprojektin osaksi ja siksi se jää usein osin projektin ulkopuolelle ja yksin liiketoiminnan vastuulle. Ja jää usein tekemättä. Projektin käyttöönottovaiheeseen on saatettu sisällyttää uuden järjestelmän ja uusien toimintatapojen luokkamuotoista kouluttamista, mikä on hyvä alku. Mutta kouluttamista ja harjoittelua tarvitaan monenlaista ja siten kullekin oppijalle sovitettuna, että hän tuntee selviytyvänsä muutoksesta ilman pysyvän tai väliaikaisen osaamattomuuden pelkoa.

Hyvin toteutetulla muutosjohtamisella säästytään vuosien tehottomuusmurheilta. Suosittelen!

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.

Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, toimintatapamuutos, muutosjohtaminen

Kohti onnistunutta kehitysprojektia, osa 2: Mitä ongelmaa ollaankaan ratkaisemassa?

Maanantai 10.9.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgYksi kehitysprojektin epäonnistumiseen johtaneita juurisyitä on se, että ratkaistaan olematon tai väärä ongelma. Hieman kliseisesti, tilanteeseen voidaan joutua esimerkiksi sitä kautta, että karismaattinen myyjä saa myytyä asiakkaalle tietojärjestelmätuotteensa tai hankitaan jokin vain sen takia, että johtajan klubikaverillakin on sellainen.

Koska yrityksen kehittämiseen käytettävissä olevista resursseista on lähes aina niukkuutta, kannattaa miettiä, mitä ongelmaa niillä lähdetään ratkaisemaan. Olematon tai epäolennainen ongelma jaksaa odottaa ratkaisuaan. Paneudutaan todellisiin ongelmiin.

Usein ongelma esitetään ratkaisun kautta. Tarvitaan uusi ERP tai CRM tai asianhallintaohjelmisto tai joku muu. Silloin ei vielä olla ongelman ytimessä. Helposti kuvitellaan, että uusi järjestelmä tai ohjelmisto ratkaisee ongelmat, mitä ne nyt sitten ovat. Ei se niin päin mene.

Huomattavasti lähemmäs ydintä päästään, kun mietitään, mitkä ovat ne (liike)toiminnalliset ongelmat, jotka kipeimmin kaipaavat ratkaisua. Jos nykyinen tapa toimia on väärä, kuvataan se haluttu uusi toimintatapa, joka toteutuessaan olisi nykyistä tehokkaampi, tuottavampi ja/tai laadukkaampi. Esimerkki:

Asiakaspalveluumme tulee toistuvasti soittoja, joissa kysytään toimituksen tilannetta ja toimitusaikaa. Näiden pyyntöjen selvittäminen vie valtavasti aikaa ja häiritsee myös tuotantoa, koska minnekkään ei ole merkitty, missä vaiheessa tuote on suunniteltu otettavaksi työn alle tai missä vaiheessa sen tekeminen tai toimittaminen on.

Siinä ongelma. Uusi haluttu toimintatapa voisi olla vaikkapa:

Uudessa toimintatavassa jokainen tilaus kirjataan tietojärjestelmään ja sen tekeminen ja toimittaminen suunnitellaan ottaen huomioon asiakkaan kanssa sovitut päivämäärät, tuotannon kapasiteetit ja muiden asiakkaiden tilaukset. Kun tekeminen aloitetaan, se merkitään ylös samoin kuin eri työvaiheiden valmistumiset. Myös toimittaminen suunnitellaan ja dokumentoidaan samaan tapaan.

Tuotannon lisäksi myynnin ja asiakaspalvelun pitää päästä näkemään tiedot. Järjestelmän tulisi hälyyttää, jos asiakaslupauksissa ei tulla pysymään tai myyjältä tai asiakaspalvelijalta tarvitaan toimenpiteitä. Se voisi myös automaattisesti kertoa asiakkaalle esimerkiksi sähköpostiviestillä, missä vaiheessa asiakkaan tilauksen toimittaminen on.

Esitetyt uudet toimintatavat kannattaa koeponnistaa. Onko uusi toimintatapa tehokas? Kuinka paljon se on tehokkaampi kuin nykyinen? Onko toimialoja, joissa samanlainen ongelma on ratkaistu tehokkaalla tavalla? Jos on, miten?

Olisi hyvä, jos onnistuttaisiin löytämään useampi toisistaan poikkeava tapa ratkaista tuo liiketoiminnallinen tarve. Jos ollaan liikkeellä vain yhdellä konseptilla, jokin sitä parempi tai lupaavampi vaihtoehto on todennäköisesti jäänyt huomaamatta.

Siksi rohkaisenkin kaikkia miettimään, mikä se oikea ratkaistava ongelma tai täytettävä tarve on ja kehittämään siihen useamman kuin yhden potentiaalisen ratkaisun, konseptin.

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.

Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, technology transfer

Kohti onnistunutta kehitysprojektia, osa 1: Strategian toteuttaminen vaatii kehitysponnistuksia

Tiistai 4.9.2018 - Tuottavuusaktivisti Reino Myllymäki

rm_200_vaihtoehto2.jpgUseimmat yritykset ja monet yhdistyksetkin tekevät itselleen strategian. Sen tarkoitus on johdattaa yhteisö nykytilasta uuteen, parempaan tavoitetilaan rajallisen ajanjakson aikana.

Strategian tekeminen koetaan suureksi ponnistukseksi. Joskus se runnotaan läpi pienen joukon voimin viikonlopun aikana lappilaisessa kelomökissä, joskus pitkän ajan kuluessa henkilöstöä laajasti osallistaen. Lopuksi huokaistaan syvään, kun strategia on saatu valmiiksi.

Kun strategia on saatu valmiiksi, ollaan oikeastaan vasta lähtökuopissa. Tiedetään, mitä suunnilleen pitää saada aikaiseksi ja missä ajassa. Mitään ei kuitenkaan ole vielä tehty. Riippuen kuinka suurella porukalla strategia on tehty, strategiaan sitoutettuja voi olla yksi, muutama tai useampia.

Strategia ei jalkaudu itsestään. Joukkueellinen varusmiehiä kyllä jalkautuu traktorin lavalta, mutta strategia ei ole elävä olento eikä tee itsekseen mitään. Paitsi ehkä kerää vaakasuoraan asentoon jätettynä pölyä.

Strategia on siis jalkautettava. Olennainen osa jalkauttamista on, että tunnistetut muutostarpeet muutetaan kehitysponnistuksiksi, jotka voivat olla suuria hankkeita, pienempiä projekteja tai vielä pienempiä toimenpiteitä. Itsekseen muutokset eivät synny. Projektit ovat osa strategian toteuttamista. Olennainen osa sitä, minkä mukaan johtajien onnistumiset mitataan.

Jokainen kehitysprojekti toteuttaa jonkin tai jotkin muutokset. Yleensä kehitysprojekti kykenee tuottamaan uuden toimintatavan mukaisen uuden järjestelmän tai tarvittavan muutoksen olemassaolevaan järjestelmään ja jopa ottamaan sen käyttöön. Silti toimintatapojen käytännön tason muuttaminen ja siihen liittyvä muutosjohtaminen on (liike)toiminnan johtajien ja esimiesten, ei projektiorganisaation tehtävä. Johtajien ja esimiesten on osattava elää tulosten kanssa senkin jälkeen, kun projekti on päättynyt.

Tietotekniikka on tällä hetkellä voimakkaimmin yhteiskuntaa ja yritystoimintaa muuttava tekijä. Monet kehitysprojektit ovat ohjelmistoprojekteja tai tietojärjestelmien käyttöönottoprojekteja. Tiedän, että IT ja digitalisaatio pelottavat monia johtajia. Rohkaisen silti ottamaan vastuuta myös tietotekniikkapitoisista kehityshankkeista ja erityisesti niihin liittyvästä muutosjohtamisesta, sillä niissä on yrityksen tulevaisuus.

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.

Avainsanat: onnistunut projekti, johtaminen, kehitystyö, digitalisaatio, strategia

Digitalisaation hyödyt liiketoiminnan käyttöön projekteilla nopeammin

Maanantai 21.3.2016 - Joonas Iivonen, Project-TOP Solutions Oy

Onnistunut projekti -Helsinki sai yleisarvosanan 4.8/5.0! Palaute oli uskomattoman positiivista ja kaikki, lähes sata osallistujaa kokivat, että tapahtuma oli heille hyödyllinen. Lähes epäuskoisena luen pelkästään positiivista palautetta.

Lue lisää »

Avainsanat: projekti, projektityö, digitalisaatio

Digitalisaatio ja yhteistyö projekteissa

Perjantai 4.3.2016 - Joonas Iivonen, Project-TOP Solutions Oy

Henkilökohtainen kontakti, työkalujen helppokäyttöisyys ja tietoturva ovat tärkeimpiä pointteja projektityön digitalisoitumisessa. Ainakin, jos uskomme Onnistunut Projekti 2016 workshoppien yhteenvetoja.

Lue lisää »

Avainsanat: projekti, projektityö, digitalisaatio

Edellytykset on, missä toimeenpano?

Keskiviikko 11.2.2015 - Reino Myllymäki, CxO Professional Oy

Kansallinen palveluarkkitehtuuri - Digi-Suomen selkäranka? -tapahtumassa se taas kuultiin. Suomen edellytykset digitaalisuuden hyödyntämiseen ovat sekä Digibarometri 2014:n että World Economic Forumin Networked Readiness Index 2014:n mukaan maailman kärjessä. Meillä on parammat mahdollisuudet kuin mitä ymmärrämmekään.

Lue lisää »

Avainsanat: digitalisaatio, sähköinen asiointi, toimintatapamuutokset, tietotekniikan hyödyntäminen