Muutoksenhallinta ohitetaan ICT-projekteissa. Tästä aiheesta on kirjoitettu valtavasti. Clegg & Walsh (2004) ehdottavat, että useissa tapauksissa muutoksen sosiaaliseen puoleen ei ole kiinnitetty tarpeeksi huomiota. Clegg & Walsh keskittyvät vahvasti ns. työkalumuutokseen.
He myös listaavat muutamia syitä sille, miksi ihmiset takertuvat nykytilanteeseen.
- Muutokselle ei ole selvää syytä
- Muutoksen kohteena olevat eivät luota niihin ihmisiin, jotka kertovat että sinun tulee muuttua
- Uusien työkalujen hyötyjä ei ole osoitettu tai huonoimmassa tapauksessa – hyötyjä ei ole
- Käytössä olevien työkalujen hävittäminen näyttää ja tuntuu epäonnistumiselta – teimme jotain väärin
- Työkalut ovat osa tiimin ammatillista identiteettiä (”meidän työkalut”)
Luettuani listan pystyin välittömästi linkittämään nuo kohdat omiin kokemuksiini sekä muutoksen kohteena että muutoksen tekijänä.
Muutokselle ei ole selvää syytä
Tämä voidaan ohittaa. Jos kukaan ei pysty kiteyttämään muutoksen syytä ei sitä myöskään tule lähteä tekemään. Tällainen tapaus on toivottavasti harvinaisuus, mutta jos kyse on siitä, että ihmiset eivät näe muutokselle selvää syytä niin tuo haaste liittyy sitten muihin listan kohtiin.
En luota noihin projektin tyyppeihin enkä johtoon!
Tämä on luonnollinen asia, johon olen törmännyt itsekin. Kyse ei välttämättä ole luottamuksesta ihmiseen vaan enemminkin tietämykseen eli ”noilla ei ole hajuakaan, miten tätä oikeasti tehdään”. Ulkopuolinen konsultti tai ”IT-osaston tyyppi” tulee kertomaan, että nyt pitää tehdä näin. Miten suhtaudut siihen, kun puhelinmyyjä alkaa kauppaamaan kanavapakettia kysymättä yhtään mitään katselutottumuksistasi? Ei tainnut
tulla kauppoja.
On siis luonnollista, että luottamusta ei alussa ole ja se pitää ansaita. Projektien osana tulee olla muutosjohtaminen ja muutosjohtamisen työkalusetin avulla tuota luottamusta rakennetaan. Perusmallin mukaisesti pyri tunnistamaan oikeat sidosryhmät organisaation sisällä ja saa heidät puhumaan puolestasi. ”Matias sanoi, että tämä on ihan hyvä juttu”. Näitä puolestapuhujia tulee olla tilanteen mukaan eri tasoilta.
Johdon näkyvä tuki on aina tarpeen, mutta se ei välttämättä ole ratkaisu, kun puhutaan luottamuksesta. Siksi tarvitaan mielipidejohtajia muutoksen kohteena olevasta joukosta.
Tässä kohdassa tunnistan jo useamman projektin, jossa asia on ylenkatsottu. Näiden sidosryhmien henkilöiden tunnistaminen on jo sinällään iso työ. Lisäksi pitää miettiä, mikä on se tekijä, jolla yksittäinen tunnistettu sidosryhmän edustaja saadaan ensin sitoutumaan asiaan ja sen jälkeen vielä puhumaan sen puolesta. Parhaimmillaan olen ollut mukana miettimässä, miten tuota henkilövaikuttamista tehdään toisen henkilön kautta eli kaverilta kaverille. Muutosjohtaminen on itseäni lähellä oleva aihe, mutta en lähde käsittelemään sitä laajemmin tässä yhteydessä.
Tärkein oppimani asia tässä on, että luottamuksen rakentaminen on loppujen lopuksi aika käytännönläheistä ja arkielämän lainalaisuuksien ohjaamaa toimintaa.
Työkalusta ei ole meille mitään hyötyä!
Projektinhallinnan ammattilaisena sinun täytyy miettiä, millainen tapaus sinulla on käsissäsi. Jos järjestelmän täyttä toiminnallisuutta ja hyötyjä ei ole vielä pystytty todentamaan aiheuttaa se projektille riskin. Tätä riskiä pitää hallita. Muutosjohtamisen näkökulmasta tämä riski aiheuttaa dilemman – voit ottaa riskin ja alkaa myymään muutosta kertomatta suoraan järjestelmän mahdollisista puutteista tai siitä, että hyödyt ovat kiistanalaisia. Jos kaikki menee hyvin selvisit kuivin jaloin, mutta kuinka usein kaikki menee hyvin? Tämä on on/off-
tyyppinen riski. Kun se laukeaa niin onnea matkaa, kun yrität edelleen kertoa viestiä hyödyistä ja puutteiden korjaamisesta.
Luottamuksen rakentaminen on todella haastavaa. Toinen mahdollinen lähestyminen on lähteä avoimesta viestistä eli ”nämä keskeiset integraatiot puuttuvat vielä, mikä tarkoittaa että joudutte siirtämään tuotetiedot käsin seuraavien 4 kuukauden ajan”. Miinuksena on, että kerroit juuri tämän aiheuttavan kaiken käyttöönottoon liittyvä sähläyksen lisäksi vielä manuaalista lisätyötä entisen automaation sijaan. Positiivista on, että
avoimuudella saat aidot reaktiot näkyviin ja pystyt reagoimaan niihin. Tämä onnistuessaan antaa vahvan selkänojan jatkolle. Kyse on siis riskinhallinnasta ja sen pohjalta tehtävistä päätöksistä ja toimenpiteistä.
Listan eri kohdista tämä on mielestäni tapaus, jossa pitää katsoa peiliin ennen työn aloittamista. Uskonko itse tähän? Jos vastaus on Ei, niin voi olla parasta sanoa esimiehelle, että en ole oikea ihminen johtamaan tätä muutosta.
Käytössä olevien työkalujen hävittäminen näyttää ja tuntuu epäonnistumiselta – teimme jotain väärin?
Yllätävää kyllä ICT-järjestelmiin liittyvän muutoksen esteenä voi olla IT itse. Organisaatiossa on ihmisiä, jotka olivat tekemässä nykyisen työkalun evaluointia – he valitsivat parhaan mahdollisen vaihtoehdon. He kehittivät sitä ja parhaassa tapauksessa pyrkivät aktiivisesti parantamaan järjestelmään koko sen elinkaaren ajan. Nyt uudet tekijät tulevat sanomaan, että järjestelmä pitää korvata uudella. Alkaa vertailu vanhan ja uuden välillä. Puheeseen tulevat lauseet, kuten ”mietimme tätä”, ”tämä oli määritelty, mutta jäi toteuttamatta, koska…”.
Muutoksen tukena oleva voima ei siis itsekään usko uuden järjestelmän muuttavan mitään tai ainakaan parantavan tilannetta. Sen lisäksi takaraivoon hiipii ajatus ”mitä teimme väärin, kun tämä ajetaan alas”? Muutoksen johtajana sinun on muistettava, että myös muutosta tukeva organisaation osa on osa muutosta. Lisäksi sinun on saatava nämä muutoksen osatekijät ei vain myönteiseksi muutokselle vaan heidät pitää saada muutoksen puolestapuhujiksi ja edelläkävijöiksi.
Järjestelmä on osa ammatillista identiteettiä
Olen työstänyt tapauksia, joissa organisaation osa on ollut aktiivisesti kehittämässä järjestelmää tarpeidensa mukaan, he ovat käyttäneet sitä 10 vuotta ja tukiporukka istuu samassa kerroksessa. Järjestelmällä on lempinimi ja maskottikarhu notkuu kahvihuoneen sohvalla. Järjestelmä on kasvanut osaksi tiimiä. Muutosjohtamisen periaatteita kai tässäkin tulisi hyödyntää, mutta tässä liikutaan niin vahvasti tunnetasolla, että tilannetta täytyy miettiä monelta eri kanteilta sekä keppiä että porkkanaa hyödyntäen.
Mitä tästä nyt jäi käteen? Muutoksen alussa on hyvä tunnistaa tekijät, jotka saavat ihmiset pitämään kiinni nykytilanteesta. Itselleni oppina on ollut, että ICT-projekteissa pitää huomioida ”oman väen” kyky ja tahto muuttua. Huolehdi, että tekijäpuoli on valmis muutokseen ja muutoksen tukena silloinkin, kun muutos kohtaa muita haasteita.
ajatuskatkoja 
Vastaa