Rohkeuden pelko voittaa

Julkaistu alunperin 1.3.2013 Tivi -lehden kolumnina.

Suomalaiset ovat arkaa kansaa. Riskinvälttelymme on viime aikoina ollut esillä monessa yhteydessä. Asia taitaa olla niin syvällä kansanluonteessamme, että ratkaisu vaatii muutaman sukupolven tietoista asennemuokkausta. It-alalla fiksut ihmiset välttelevät riskiä työkseen, ja se vaikuttaa alan lisäksi koko Suomeen.

Arkuus vaikuttaa esimerkiksi kasvuyritystoimintaan siten, että riskisijoittajat varovat alkuvaiheen sijoituksia. Suomalaiset sijoittajat haluavat pelata niin varman päälle, että enää ei voi puhua riskisijoittamisesta. Tuttu yrittäjä lähti hakemaan rahoitusta Ruotsista, jossa valuaatiot olivat järkevämpiä ja rahoituksen saamiseen liittyvät ehdot realistisia. Yrittäjän pitää kuitenkin pystyä myymään tiiminsä kyky toteuttaa liiketoimintamahdollisuus niin hyvin, että sijoittajat uskaltavat mukaan.

Ennen asiat sovittiin kättä päälle, ja sitten tehtiin. Luottamus ei ole enää arvossaan: nykyään halutaan tehdä yli kymmensivuisia sopimuksia.

Onhan se oikein, että sovitaan, kuinka tulevaisuudessa riidellään, jotta ei tarvitse riidellä. Anglosaksinen sopimuskulttuuri ja lakimiehistyminen on löytänyt hyvän kaikupohjan suomalaisesta yrityselämästä: insinööri haluaa asiat valmiiksi paperille varmuuden vuoksi. Onneksi on vielä isojakin yrityksiä, joiden kanssa pääsee kauppoihin ihan parisivuisella sopimuksella, toki yleiset ehdot ovat liitteenä. Meidän pitää päästä irti tarpeesta työllistää lakimiehiä jokaisessa kaupassa. Sekä myyjän että ostajan on aidosti etsittävä win-win-tilannetta, jossa kummallekaan ei tule intressiä rikkoa toimivaa järjestelyä. Lopulta vain molempien osapuolien kokema hyöty tuottaa tasapainon, jota mikään sopimus ei voi taata.

Henkilöstöasioissa suomalaiset ovat erityisen arkoja. Yli 50-vuotiaiden on vaikeaa työllistyä. Mitä ihmettä siinä pelätään? Ajatelkaa nyt, yli viisikymppinen on kokenut eikä hötkyile, tietää, mitä työ on ja on valmis tekemään sitä. Hän on töissä vielä reilusti yli kymmenen vuotta.

Kuinka moni 25-vuotias vasta valmistuva tai viimeisten vuosien opiskelija aikoo olla samassa firmassa yli 10 vuotta? Olen myös huomannut, että teekkari palkkaa teekkarin. Eikö järkevämpää olisi palkata sellainen henkilö, joka ymmärtää asiakasta ja asiakkaan maailmaa? Monesti kaupallishallinnollinen koulutustausta on sopivampi, mutta koska se ei ole teekkarijohtajalle tuttu, taas palkataan yksi sähköinssi ja luullaan, että hän sopii vakuutusyhtiön projektiin.

Arkuus estää vaatimasta hyvää työtä ja antamasta kritiikkiä.

Kritiikin antamista varten esimies piiskaa itsensä raivoon, ja sitten haukkuu alaisensa lyttyyn. Joskus esimies siloittelee asian valjuksi, jottei vain loukkaa alaista, eikä nuhdeltu edes ymmärrä tulleensa nuhdelluksi. Tai sitten palautetta ei anneta lainkaan. Palautteen antaminen on pakollista tai muuten muulle organisaatiolle annetaan viesti: ”meillä on lupa tehdä huonosti”.

Rohkeus edellyttää päättäväisyyttä. Arkuus estää tekemästä päätöksiä. Monet ovat mieluummin ajopuita kuin tekevät vaikeita päätöksiä. Vaikeita asioita pitää edistää aktiivisesti, ei vain tutkia ja miettiä mahdollisuuksia. Jos asiaa pohtii ja miettii tarpeeksi pitkään, aika menee ohi, eikä enää tarvitse päättää. Näin toimii moni suomalainen. Jos päätöstä ei tehdä heti, lopputulos on sama kuin suoraan päättäisi ”ei”. Suoraan päättäminen on suoraselkäistä ja lisäksi se vapauttaa mentaalista kapasiteettia, kun enää ei tarvitse hautoa vaikeaa asiaa. Puuttuu enää jämäkkä toimeenpano.

Projektia pitää ohjata vakavissaan

Julkaistu alunperin 4. ja 28.2.2011 Tivi -lehden kolumnina.

Jyväskylän yliopisto on rakentanut Tietotekniikan liiton kanssa tietohallintojohtamisen suuntautumisvaihtoehdon kauppatieteiden maisterin tutkintoon. Olen juuri konvertoimassa omaa MBA-tutkintoani kauppatieteiden maisterin tutkinnoksi ja siksi osallistuin Tomi Dahlberg in vetämälle informaatioteknologian strategisen johtamisen kurssille. Erityisellä kiinnostuksella tutustuin projektihallintaan liittyviin akateemisiin tutkimuksiin.

Yllätyksekseni projektiosaamista ei katsota ict-toimialan erityis- tai ydinosaamiseksi. Projektiosaamisen nimittäin pitäisi olla kaikilla aloilla yleistä perusosaamista.

Projektihallintoa ja -työtapoja painotetaan tietohallinnon alan ohjeistoissa Cobitissa ja Itilissä. Sitä varten on myös omia ohjeistojaan, esimerkiksi Prince2 (projects in controlled environments) ja oma dokumentoitu tietämysalueensa Pmbok (project management body of knowledge).

Ohjelmistokehityksen asiantuntijoiden yhdistyksellä Sytykkeellä on asiaan erikoistunut osaamisyhteisö ja vieläpä löytyy ihan projektitoimintaan erikoistunut yhdistyksensä. Lisäksi kansainvälinen projektinhallintayhdistys IPMA ja projektinhallinnan instituutti PMI sertifioivat kilvan päteviä projektipäälliköitä.

Yrityksissä on usein olemassa projektitoimisto tietohallinnon ja liiketoiminnan kehittämisen tukena. Ne noudattavat jonkinlaisia hyvä tapoja ja saattavat esimerkiksi käyttää projektien raportoinnissa ja ohjauksessa liikennevaloja. Vaikka värien merkitys tiedetään, saattaa värien itsensä arpominen olla enemmän tai vähemmän hakuammuntaa.

Perusasioiden kuntoon laittaminen kannattaa!

Pahimmillaan värit perustuvat matemaattiseen kaavaan, jonka takana on kuitenkin ihan täyttä huuhaata. Täten luodaan johdolle vaarallinen harhakuva, että asiat olisivat hallinnassa.

Tietohallinnon ja liiketoiminnan yhteistyön tulokset ovat parhaimmillaan ja huonoimmillaan silloin, kun it kehittyy palvelemaan liiketoiminnan tarpeita. Erona on se, kuinka hyvin organisaatio pystyy hoitamaan projektinsa annetuissa puitteissa eli aikataulussa ja sovituilla resursseilla.

Jos tietohallinto seuraa liiketoiminnan tarpeita, mutta arkkitehtuureista ja projektityötavoista ei pidetä huolta, on siitä hyvin pitkä matka hallittuun toimintaan, jossa liiketoiminta saa aidosti hyötyä tietotekniikasta. Tie menestyksekkääseen liiketoimintaa tukevaan tietohallintoon kulkee hallittujen projektien kautta.

Joskus minusta tuntuu, että asiat osataan kyllä, mutta niitä ei viitsitä miettiä. Miettiminen kun on työlästä ja herättää vaikeita kysymyksiä. On mukavampaa lillutella turrassa tyytyväisyyden tilassa, kun projektit kelluvat ja ajelehtivat eteenpäin, kun ei tarvitse heti huolestua. Eivätkä projektitkaan sitten kuitenkaan pysy aikataulussa, mutta eivät ole pysyneet ennenkään.

Asiaa korjatakseni olen luonut projektien onnistumisen arvioinnin menetelmän, jonka avulla voi analysoida organisaation projektityökykyä monilta eri näkökulmilta ja sitä kautta muodostaa kattavan kuvan organisaation projektikyvykkyyden kypsyystasosta.

Tulos on usein yllättävä: perusasioiden laittaminen kuntoon kannattaa! Projektin tavoitteen pitää olla kirkas. Visio lopputuloksesta pitää jakaa kaikkien osallisten kanssa. Työn seurannan on oltava jatkuvaa ja läpinäkyvää. Projektin riskien sekä muutosten on oltava hallittuja ihan samalla lailla kuin minkä tahansa projektin alkuperäisenkin tehtävänkin.

Jos projekti on tärkeä – ja miksipäs se ei olisi, kun se on kerran käynnistetty – pitää sitä ohjata vakavissaan eikä vain olla ohjaavinaan!

Vaadi tosissaan johtamista

Julkaistu alunperin 30.3.2015 Onnistunut projekti -tapahtuman blogina.

Strategia jalkautetaan erilaisin hankkein ja projektein. Niitä käynnistetään hyvässä uskossa ja hyvää tarkoittaen. Liiketoimintajohtajan lempilapsi annetaan nälkäiselle nuorelle päällikölle tai muuten kiltille tytölle, joka ei omista syistään johtuen kieltäydy tehtävästä. Projektin asettaja ei kuitenkaan huolehdi, että projektipäälliköllä on aikaa tai valtuuksia hoitaa annettua tehtävää.

Ylläkuvatun kaltainen tilanne lienee valitettavan tuttu monelle asiantuntijalle ja väliportaan johtajalle. Ihan perustavanlaatuinen onnistumisen edellytysten luonti unohdetaan yllättävän usein. Jokaisen projektipäällikön pitäisi kieltäytyä vastaanottamasta huonoa toimeksiantoa. Projektin toimeksiannon pitää olla kuin työsopimuksen: siinä pitää kertoa mitä tavoitellaan ja odotetaan ja kuinka onnistumista mitataan. Hyvä projektin asettaminen sisältää tiedot siitä, millä resursseilla ja valtuuksilla projektia johdetaan ja kuinka projektin etenemistä seurataan ohjausryhmätasolla.

Sama toimii tietysti myös toisin päin. Projektin asettajan pitää voida luottaa siihen, että muu johtoryhmä tukee asetettua projektia ja antaa resurssit projektille. Johtoryhmän pitää huolehtia siitä, että asetetut projektit joko johdetaan kunnolla tai sitten ne lopetetaan. Jos kaikelle ei ole resursseja tai aikaa, sitten priorisoidaan, ja käynnissä pidetään vain tärkeimmät.

Monessa organisaatiossa koulutetaan projektipäälliköitä. On Prince 2, PM-BOK ja IPMA. On projektiyhdistys ja erilaisia osaamisyhteisöjä. Organisaatiossa on projektitoimistoja ja projektipäällikköpooleja. Projektipäälliköitä on vapaana työmarkkinoilla. Osaamistasolla mitään ei pitäisi puuttua.

Teknisessä kyvyssä on toivomisen varaa. Matriisiorganisaatiossa projektipäällikkö joutuu taistelemaan saadakseen aikaan projektipalaverin. Yhteistä kalenteriaikaa ei vain ole. Johtajien pitää huolehtia siitä, että projektipäälliköllä on käytettävissään kunnollinen projektin ja ryhmätyön infrastruktuuri. Kommunikoinnin ja dokumentoinnin pitää olla helppoa. Virtuaalikokoukset ovat arkipäivää.

Projektiosaaminen ei ole strateginen erottautumiskeino. Se on jokaiselle organisaatiolle välttämätön kyvykkyys. Käytännössä vain hyvin harva organisaatio noudattaa hyviä projektitoiminnan käytäntöjä. Projektijohtaminen on lopulta kiinni vain satunnaisen valveutuneen henkilön halusta. Osaamisesta ei pitäisi olla puutetta, vaan silti asiat ovat vaikeita. Projektipäällikkö joutuu nimittäin kysymään ikäviä kysymyksiä!

Jos projekti on ollut niin tärkeä, että se on aloitettu, eikö sille silloin pidä antaa täysi tuki? Osaaminen ja infrastruktuuri pitää laittaa kuntoon! Asettaminen ja seuranta on otettava osaksi johtamisjärjestelmää. Ja ne hankalat kysymykset, ne ovat johtajille tärkeitä signaaleja oman toiminnan parantamiseksi. Haluammehan toki jokainen kehittyä johtajana?

ICT:n erilaiset ihmiset

Julkaistu alunperin 8.4.2015 CxO mentorit Oy:n blogina.

Tapasin kerran henkilön kulttuurialalta. Minun oli hyvin vaikeaa saada hänet ymmärtämään, mitä tein työkseni. Ongelma johtui siitä, että hänen ajatusmaailmassaan kaikki ICT-alan ihmiset ovat ohjelmoijia. Hän ei ymmärtänyt, että minun työtäni ovat ihmiset eivätkä tietokoneet.

Kuinka hyvin organisaation johto ymmärtää erilaisuutta ICT-ammattilaisten välillä? Uskoakseni huonosti, sillä alan sisälläkin toisenlaisten asiantuntijoiden ymmärtäminen on vaikeaa. Tämä johtuu ihmisten erilaisista ajatusmaailmoista. Se häristä puhuu, joka härillä kyntää!

Kerran isoa konesalihanketta auditoidessani havaitsin, että siihen osallistui toistakymmentä erilaista asiantuntijaa. Näillä ei ollut edes keskenään käsitystä siitä, mitä muut tekivät. Muut näkivät, että siellä olivat ne tietoliikennetyypit. Nämä näkivät toisissaan IP-suunnittelijan, runkoverkkoasiantuntijan, konesaliverkon asiantuntijan, palomuurien asiantuntijan ja vielä sen kaverin, joka veti fyysistä piuhaa seinään ja lattian alle.

Ovatko sitten DBA:t, keskenään samaa porukkaa? Vain sovellusasiantuntijat saattoivat tietää, miten tietokannan scheman rakenne on tehty. Varsinaiset tietokantahoitajat eivät schemasta välittäneet, vaikka näin olisi voinut luulla. Heidän hommiansa olivat tietokannan hallintajärjestelmän asetukset ja tietokannan tiedostot. Tosin levylle asti he eivät tiedostoja hoitaneet, sillä levytallennus oli tietysti tallennusverkkoasiantuntijoiden hommaa.

Ihan yhtä hajanainen tilanne on ohjelmointipuolellakin. Käyttöliittymäihmiset eli UX -suunnittelijat ja -devaajat eivät juuri transaktioiden eheydestä huolehdi. Minäkin olin ennen UX -asiantuntija. Silloin UX oli HP:n oma UNIX-versio. Ohjelmoinnin kohde, käytetty kieli, ohjelmointiympäristö ja jopa kehitysparadigmakin vaikuttavat hyvin paljon maailmankuvaan, sovellusalueesta puhumattakaan. Kavereilla on ihan eli lelut, vaikka muista leikki näyttää samalta.

Otetaan vielä mukaan testaus: eri tasoilla ihmiset tekevät eri asioita. Osa tekee työnsä käsin ja toiset rakentavat laajoja testausalustoja. Kerran asiakkaan testausihmiset ja laatupäällikkö menivät testauksen suunnittelutekniikkakurssille ja hämmästyivät, kun siellä käytiin läpi matemaattisia malleja. Siellä ei kerrottu kuinka käyttötapauksista johdetaan testitapauksia hyväksymistestaajien käyttöön.

Ohjelmoijien ja laitteistoihmisten välissä on usein joukko arkkitehteja. On järjestelmäarkkitehti, sovellusarkkitehti ja yritysarkkitehti (engl. enterprise architect). Ensimmäinen miettii jonkin yleiskäyttöisen palvelun tai järjestelmän asioita, esimerkiksi julkaisujärjestelmää. Toinen miettii jonkin tietyn sovelluksen elämää käyttäjältä koneeseen asti ja kolmas miettii koko organisaation tietojenkäsittelytarpeita. Nämäkin ihmiset puhuvat eri asioista, osittain samoilla termeillä.

Laajassa tietojärjestelmähankkeessa pääsee tapaamaan useita edellä mainituista asiantuntijoista. Hanketta johtaa parhaimmillaan ammattimaiset projektipäälliköt ja hankkeen omistavat liiketoimintajohtajat. Näistä kummankaan ammattiryhmän kulttuuriin ei kuulu tietotekniikkaihmisten ajatusmaailmoiden tunteminen. Kuitenkin heidän pitää ymmärtää, mitä ihmiset heille kertovat ja kuinka tärkeästä asiasta kulloinkin on kyse. Asiantuntijoilla on nimittäin kyky nähdä omien asioidensa merkitys projektiin tärkeimpänä onnistumisen edellytyksenä. Mikähän näistä näkemyksistä on milloinkin se kaikkein kriittisin?

Projektit onnistuvat tai epäonnistuvat oikea-aikaisen ja oikein tulkitun viestinnän ja ohjauksen ansiosta. Siksi isoissa hankkeissa on aina tarvetta tekniselle johtajalle. Tekninen johtaja ymmärtää eri alojen kulttuureja ja ajatusmaailmoja. Hän ymmärtää eri asiantuntijoiden motivaatioiden lähteitä ja osata viestiä kunkin omalla kielellä. Onnistumisen perusedellytyksenä on laaja perehtyneisyys ICT-alaan ja monipuolinen kokemus eri toimialoilta. Tällaista repertuaaria ei hankita parissa vuodessa. Ehkäpä meille keski-ikäisillekin on vielä jotain käyttöä!