Case esimerkki kyvykkyyden kehittämisestä

Törmään usein siihen, että osaamisen kehittäminen on esimiesten agendalla ja muu organisaation kehittäminen on enemmän HR:n vastuulla. Koulutusten tilaamista ja organisointia tehdään molempien roolien taholta. Kuitenkin siinä vaiheessa, kun HR saa koulutustilauspyynnön, yleensä on liian myöhäistä lähteä kyseenalaistamaan, josko kurssi on se oikea tapa kehittää ko. osaamista.

Myönnän, että teknologiayrityksessä osaamisen kehittäminen on HR:lle haasteellista, mutta ei mahdotonta. 1990 -luvun lopulla olin töissä Nokian verkkoyhtiön tuotekehitystä tukevassa koulutustiimissä.  Kuten tapana siihen aikaan oli saimme HR:ään tiedoksi yrityksen ylevät strategiset tavoitteet powerpointilla. Niistä esimieheni arpoi minulle sen vuoden tavoitteeksi SW-osaamisen kehittämisen. Muistan tuijotelleeni tavoitetta pelonsekaisin tuntein. Jaahas, mistäs sitä lähtisi liikkeelle? Rauhoittelin itseäni ajatellen, että – no olisihan tässä vuosi aikaa (Silloin ei vielä eletty kvartaalitaloutta.) ja olin juuri ollut Nokian problem solving -prosessikurssilla. Luotin siis siihen, että systemaattinen eteneminen auttaisi. Tästä tavoitteesta itse asiassa alkoi samalla oma työssäoppimisen jakso osaamisen kehittäjänä.

1. Identify the problem – Mikähän siinä SW-osaamisessa mahtoi olla pielessä?

Jalkauduin ja lähdin haastattelemaan tuotekehityksen väkeä. Tähän mennessä olin jo oppinut, että asiantuntijaorganisaatiossa saa ja pitääkin kysyä, jos ei tunne toisen vastuualuetta. Tietysti loistavassa organisaatiossa on myös loistavia asiantuntijoita, jotka mielellään puhuvat omasta työstään, jos joku haluaa kuunnella. Sujuvasti kuuntelin. Vihdoin tapasin kaksi jaospäällikköä, jotka ymmärsivät, että nyt pitää vääntää ehkä rautalangasta. Lähdin keskustelusta tyytyväisenä ruutupaperi kädessäni, jossa oli viivoja ristiin rastiin ja nuolia sinne tänne = sen hetkisen järjestelmän softarakenne. Riitti minulle.

2. Analyse the Problem – Mistähän se johtuu?

Kävi ilmi, että softasta oli tullut vuosien kuluessa niin monimutkainen systeemi, että sen kehittäminen ja ylläpitäminen oli iso haaste ja kallista puuhaa. Jokaisen uuden koodinpätkän lisäys aiheutti muutoksia lukuisissa muissa osissa softaa ja järjestelmiä. Systeemin arkkitehtuuri ei enää antanut myöten yksinkertaisia ratkaisuja. Käsissä oleva ongelma ei siis ratkennut sillä, että tilattaisiin parit ohjelmointikurssit osaamisen parantamiseksi. (Sekin kyllä tehtiin sitten muutama vuosi myöhemmin, kun lähdettiin rakentamaan uutta tuoteperhettä.)

3. Determine Causes – Mitähän tästä seuraa?

Ymmärrettyäni ongelman ytimen lähestyin Program Manageria, joka vastasi seuraavasta ohjelmistojulkaisusta. Sain samalla oppitunnin numero kaksi – tuotekehitysprosessin ja projektinjohtamisen haasteet.   Nyt sukellettiin tuotekehitysprosessimalliin ja tunnistettiin sieltä SW–projektin kannalta haastavimmat prosessivaiheet. Ja nyt tuli yllätys – suurimmat haasteet eivät liittyneet pelkästään SW-koodiin vaan johtamiseen, kommunikointiin eli tiedonsiirtoon eri prosessivaiheiden välillä. Kommunikointihaaste johtui SW-muutosten suuresta määrästä eri tuotteissa, mikä tarkoitti käytännössä useamman tuotelinjan osallistumista yhteen järjestelmäprojektiin. Siis satoja ihmisiä. Yksi suurimmista haasteista oli osaamisen (tiedon) siirto systeemisuunnittelun ja ohjelmistosuunnittelun välillä. Globaalissa tuotekehitysorganisaatiossa lisähaastetta toivat multisite-projektiorganisaatio, monikulttuurisuus, fyysinen etäisyys ja aikaerot. Sähköposti ei ollut ihan paras kommunikointiväline. (Verkkoryhmätyökalujen käyttöönotto oli alkutaipaleella.)

4. Develop Solutions – Miten tiedonsiirtoa voidaan edistää?

Tuotekehitysprojektien haasteena on aikataulu, jos tiedon siirtämistä (osaamisen kehittämistä) ei ole huomioitu alkuperäisessä projektiaikataulussa. Niin siis oli tässäkin tapauksessa. Projektiorganisaatio tarvitsi siis tehokkaita työpalavereita, jotka olisivat samalla oppimistilaisuuksia.

5. Plan action – Fasilitoidut työpalaverit

Kutsuin apuun parhaan projektitiimikoulutusvalmentajan ja lähdimme tekemään toteutussuunnitelmaa projektin kick-off palavereille, jossa vuorottelisivat; projektitiimien johtamisvalmennus, tiimiyttäminen, kommunikointi ja osaamisen siirto sekä projektityöskentely.

6. Implementation – Intensiivityöpajat poissa toimistolta

Työpajoihin osallistuivat systeemisuunnittelijat ja osaprojektitiimien vetäjät kaikista niistä maista, joissa tuotekehitysprojektia tehtiin eli yhteensä n. 50 henkilöä muutamassa työpajassa. Työpajatyöskentely erilaisine teambuilding -aktiviteetteineen ja  tiedonsiirto ( opetus) tapahtui aidoissa projektitiimeissä.

7. Evaluate outcome – Mitä jäi käteen?

Siis yhtään SW-suunnittelu- tai -ohjelmointimenetelmäkurssia ei sillä kertaa pidetty, koska osaamisvaje oli globaalin projektin yhteistyötaidoissa ja osaamisen siirtotavoissa. Kyseinen tuotekehitysprojekti oli menestys ja program manageri sai vedettäväkseen sittemmin koko projektitoimiston. Koulutustiimille sain rakennettua projektikoulutusmallin, joka sittemmin vietiin osaksi tuotekehitysprojektiohjeistusta. Oma työssäoppimiseni oli huikea.

Aluksi kovin tekniseltä näyttänyt osaamisvaje ei sitten lopulta ollutkaan tekninen vaan ihan HR:n ominta aluetta eli organisaation sosiaalisen- ja psykologisen pääoman kehittämistä.   Varsinaiseen inhimillisen pääoman eli SW-osaamisen uudistamiseen ja muutosprojektiin paneuduttiin seuraavien vuosien aikana, kun oli mahdollisuus lähteä liikkeelle puhtaalta pöydältä rakentamaan uutta tuotearkkitehtuuria, uutta tuotekehitysprosessia ja sitä tukevaa organisaatiomallia.

Tänä päivänä meillä on käytettävissä upeat sosiaalisen median tarjoamat mahdollisuudet jakaa tietoa ja osaamista. Uusia tapoja tehdä työtä. Otetaan niistä riemu irti.

– Päivi

Kirjoittaja on Päivi Ainasoja, intohimoinen uudistaja, organisaatioiden ja kyvykkyyksien kehittäjä