Browsing: Perusasiat

Digitalisaation kolme muotoa

Digitalisaatio on päivän sana. Siitä puhutaan jo kaikkialla. Sen tarjoamat välineet mahdollistavat uuden liiketoiminnan luomisen, tekniikan kehittyessä syntyy myös keinoja kyseenalaistaa vanhat prosessit. Iso osa digitalisaatiota on kuitenkin kategoriaa ‘kiva juttu’. Se, että onko kivoista jutuista hyötyä onkin jo toinen asia. On, mutta..

Digitalisointi on liiketoiminnan uudistamista. Sitä voidaan lähestyä kolmella kulmalla. Tehostaminen, ehostaminen ja uuden luominen. Useimmiten lopputulema on sekoitus kahta ensimmäistä ja joskus harvoin näkee uuden luomista.

1. Tehostaminen

Tämä on digitalisoinnin muoto, jossa teknologia tarjoaa uuden tavan tehostaa olemassaolevaa prosessia. Useimmiten kustannukset menevät murto-osaan ja prosessi nopeutuu huikeasti. Esimerkkejä voisi olla ajan varaaminen tai tuotteen ostaminen verkossa. Tämä on riskittömin ja useimmiten nopein tapa toimia. Välistä tuntuu, että kaikki Suomessa tehdyt digitalisointiprojektit keskittyvät tehostamiseen. Mutta jos kerran tehostaminen toimii, niin miksi sitten tehdä muuta? No, siksi. Muista kuitenkin tämä & tämä.

2. Ehostaminen

Tässä tehdään koristeita olemassaolevan toiminnan ympärille. Usein puhutaan visualisoinnista, jonkun prosessin tekemisestä näkyväksi ja usein vain saadaan ruudut vilkkumaan. Joskus nämä ovat järjettömiä, joskus todella hienoja. Näitäkin pitää olla, koska ne tarjoavat uuden tavan lähestyä vanhoja rakenteita. Ja usein näillä on vahva markkinoinnillinen arvo. Lisäksi, organisaatio, jonka uudistuminen junnaa tarvitsee vähintään pari tällaista, jotta syntyy jotain uutta. Riskinhallinnan kannalta ehostus on ongelmallinen. Rahaa palaa ja todennäköisesti sitä ei saa takaisin. Ainakaan heti.

3. Uuden luominen

Digitalisoinnin jaloin muoto ei oikeastaan ole digitalisointia. Se on koko liiketoiminnan uudelleenluominen, käyttäen teknologiaa vahvana vipuvartena. Ei siis digitalisoida vanhaa prosessia. Vaikka useat väittävät toisin, korostuu tässä nörttien rooli (kts. ps2). Nörtit eivät yleensä ymmärrä vanhaa liiketoimintamallia. Varsinkin, jos se perustuu aikansa eläneisiin uskomuksiin.

Ikävä kyllä usein näissä unohtuu se, että kun idea on valmis tarvitsee se myydä ja markkinoida. Keinolla tai toisella. Tätä ei yleensä saa tehtyä yksin. Tiimissä on oltava hyvä sekoitus myynnillistä, markkinoinnin ja teknistä ymmärrystä. Epäonnistuminen on melkein varmaa jos joku näistä puuttuu. Se, että asiakkaat haluavat maksaa palvelusta on lopullinen testi idealle. Jos eivät, on idea susi.

Riskinhallinnan kannalta uuden luominen on kaikista vaikein. Onnistuminen voi olla todella komeaa ja epäonnistuminen vielä komeampaa. Välimuotoja tapaa harvoin. Forbesin mukaan 90% startupeista epäonnistuu. Todennäköisesti enemmän.

Digitalisaatiota pitää uskaltaa johtaa

Oma kokemukseni on, että liiketoiminnan kehittäminen kulkee useimmiten polkua jossa aluksi tehostetaan ja ehostetaan ja sitten (ainakin yritetään) luoda liiketoiminta uudelleen. Klassinen liikkeenjohto ei ole parhaimmillaan uuden luomisessa ja siksi nämä lähdöt tulevat usein perinteisten yrityksien ulkopuolelta. Jo senkin takia, että uuden luominen kannibalisoi vanhan. Tyhjän päälle astuminen pelottaa. Eri muodot eivät kuitenkaan ole ristiriidassa keskenään. Isompi yritys tarvitsee uudistuakseen kaikkia näitä. Ja työtä pitää johtaa. Varsinkin, jos kaikki ei suju kuin elokuvissa.

Digitalisaatio edellyttää uudenlaista johtamista. Innovatiivisuus, riskien järkevä hallitseminen ja erilaisuuden hyväksyminen ovat asioita, jotka ei vaan onnistu kaikilta.

Kaikki palaa erilaisten yksilöiden muodostamaan tiimiin

Lopuksi vielä tärkeä juttu. Tarvitset tiimin, jossa on erilaisia ihmisiä. Sinulla pitää olla pedantteja tehostajia, introverttejä nörttejä, innostavia viestijöitä ja lopuksi muutama puolihullu, jotka kiistävät kaiken olemassaolevan ja, jos onni on myötä keksivät sen uudelleen.

Jos ympäröit itsesi muoviklooneilla saat aikaiseksi korkeintaan keskinkertaista, jos sitäkään. Onnistuminen edellyttää erilaisten ideoiden hyvää synteesiä. Ja tehokasta toteutusta. Onnistumista ei ole ilman intohimoa uudistua.

Villakoira?

  1. Älä jää odottamaan ideaa joka ‘muuttaa kaiken’, pienikin askel vie eteenpäin
  2. Muista mitata onnistumista. Mittaamalla saat välineen johtaa. Muista eurot.
  3. Jos homma ei rokkaa reagoi nopeasti. Hyvän kuuloinen idea voi olla oikeasti susi, eikä sudet yleensä parane vanhetessaan.
  4. Onnistuvassa tiimissä on erilaisia ihmisiä. Älä potki päähän tarkkoja tuunaajia. Arvosta nörttiä. Älä järkyty kun liehuva liekinvarsi kertoo sinulle että kaikki aikaisempi on roskaa ja hänellä on aivan uusi idea.

Lopuksi : Eurot on todella hyvä keino mitata liiketoiminnan onnistumista. Monetisaatio on kuningas. Aina. No money, no honey.

Näihin kuviin ja tunnelmiin, iloista ja uudistavaa kesää.

ps1 : kaiken digitalisoinnin voi sössiä komeasti, jos sinulla ei ole riittävän vankkaa teknistä pohjaa.

ps2 : Nörttien roolista asiassa voi kiistellä pitkään, jätän se johonkin toiseen kertaan, mutta sitä odottaessa voit googlata vaikka seuraavia nimiä : Mark Zuckerberg, Sergey Brin, Bill Gates, Sir Tim Berners-Lee, Ralph H. Baer, Bram Cohen, Shawn Fanning, Linus Torvalds ja satoja muita. Tuo joukko on tuhonnut enemmän vanhoja yritysrakenteita kuin useimmat sodat. Vaikkapa Shawn Fanning, joka loi Napsterin, hänen aloittamansa kehitys murskasi lopulta fyysisiin levyihin ja kasetteihin perustuvan musiikkiteollisuuden ja pakotti toimialan uudistumaan. Kaveri ei tehnyt itse kaikkea, mutta potkaisi ensimmäisen pallon kentälle. Muut pelasivat eteenpäin. Btw – uuden luomisen yleensä tunnistaa siitä, että lopputuloksena on iso liuta käräjäkäyntejä, kun vanhojen liiketoimintamallien omistajat hirttäytyvät historiaansa. Oikeasti me nörtit johdetaan salaa maailmaa. Te ette vain tiedä sitä.

{ Add a Comment }

ProjektiNatsi kuolee yksin

Edellinen kirjoitus käsitteli Velttoa projektipäällikköä (VPP). Tämän oman elämänsä sankarin vastakohta on ProjektiNatsi (PN). Jos VPP:n ongelma oli epämääräinen ja löysä toiminta on PN toista puuta. Ihan oikeasti. Yllättävää kyllä kumpikin on saman ongelman äärellä…

Olen hyvin tietoinen siitä, että tämä kirjoitus on vähän turhankin synkkä. Mielestäni se on kuitenkin tarpeen siksi, että olen urani aikana nähnyt useita loppuunpalamisia. Toimin kauan sitten projektiauditoijana. Joka yleensä kutsuttiin paikalle kun onnettomuus on sattunut, rauniot savuavat ja ihmisiä kärrätään pois paikalta. Ennen näitä projektikolareita oli aika paljon, nykyään vähemmän. Ne ehkä saavat enemmän julkisuutta. Erikoista on se, että aiheesta ei ole pahemmin kirjoitettu.

Kaikki ei mene kuin elokuvissa

On tärkeää tunnustaa avoimesti se, että IT-projektitoiminta on vaativaa ja joskus raskasta. Jos kaikki projektit menisivät kuin Strömsössä ei tätäkään kirjoitusta tarvittaisi.

ProjektiNatseja näkee aika usein nuorissa projektipäälliköissä. Ikä tuo tässä asiassa viisautta ja Siperia opettaa.  PN:n tunnistaminen on helppoa. Hän aiheuttaa ahdistusta. Projektipäällikön pitää tehtävässään saada tuloksia ja niitä ei synny jos projektiin osalliset eivät voi hyvin. Ahdistuksen aiheuttamiseen riittää ihan seuraavat temput:

  • Täydellinen piittaamattomuus ihmisen yksityiselämästä
  • Ihmisen esineellistäminen malliin ‘resurssini sairastui, mitä teen?’
  • Kiusaaminen järjettömillä raportointipyynnöillä
  • Absurdit venymisvaatimukset
  • Raportoinnin kaunistelu

Edelleenkin, asiakkaan kannalta projekti on onnistunut jos se toteuttaa tehtävänsä aikataulussaan ja sille varatuin resurssein. Olivat ne sitten rahaa tai tekijöitä. Mutta projektipäällikön (ja yrityksen) kannalta on vielä toinenkin ulottuvuus. Projektin pitää onnistua niin, että sen tekijät puhuvat toisillensa projektin jälkeenkin. Ja tätä PN:t eivät yleensä ymmärrä. He ajattelevat projektia yksittäisenä tapahtumana. Kun oikeasti sitä pitäisi ajatella jatkumona. Eli … projektipäällikön pitää menestyäkseen vetää projekti niin, että hän voi vetää sen jälkeen seuraavan projektin. Ja niiden asiantuntijoiden pitää pystyä työskentelemään vielä raskaan projektin jälkeen.

Ja tämän takia PN:t kuolevat yksin. He eivät nimittäin ymmärrä ihmisiä. He eivät ole kivoja kavereita.

Rohkeus ja ymmärrys

Projektipäällikön työ vaatii rohkeutta. PN:n ongelma on siinä, että hänellä on haaste edessään, joka vaatii ymmärrystä. Ja hän hyökkää haastetta kohti ajatellen että ongelmana ovat ne resurssit. Jolloin ratkaisu on ruoskia kaikki irti niistä. Ja esineellistämällä ihmisen resurssiksi saat voideltua omantunnon.

Ratkaisuja yleensä löytyy. Ja joskus yksi keinoista on jaksamisen venyttäminen. Mutta vain joskus, ja silloinkin oikein säännösteltynä.

Ja joskus pitää vaan kohdata haaste ja rehellisesti kertoa projektin ohjausryhmälle että meillä on ongelma, jota ei ratkaista ylittämällä inhimilliset rajat. Tässä kohden PN kohtaa VPP:n. ProjektiNatsi välttää ongelman rehellistä tunnustamista ja Veltto ei osaa sitä nähdä. Ongelma on sama. Pätevän tilannekuva ja sen ylläpitäminen auttaa huomaamaan ongelmat ajoissa. Ennenkuin kaikki on päreinä.

Ammattitaitoinen projektinjohto on nimenomaan työtä, jossa hyvän tilannekuvan avulla, tuntien projektin tavoitteet edetään systemaattisesti kohti maalia. Se on intohimoa onnistumisesta, rakkautta tavoitteisiin ja asiallista, kannustavaa johtamista. Ihan niinkuin kaikki muukin johtaminen.

Muutama pallo arkeesi

  • MUISTA että ne ‘resurssit’ ovat yleensä IHMISIÄ. HEILLÄ ON TUNTEET JA OMA ELÄMÄ. Prkl.
  • Projektipäällikön työ on esimiesrooli. Olet vastuussa projektin ihmisistä.
  • Ensimmäinen askel ongelman ratkaisuun on sen tunnustaminen
  • Rehellisyys, rehellisyys ja rehellisyys
  • Tarkka ja täsmällinen tilannekuva auttaa ymmärtämään

ps1 : Kuten lähes kaikki tuttuni tietävät minulla on fiksaatio ‘resurssi’-sanaan. En voi sietää sitä, että ihmistä kutsutaan resurssiksi. Sanakirjan mukaan resurssi voi olla muutakin. Vaikka työstökone. Älä kutsu ihmistä työstökoneeksi. You have been warned.

ps2 : jep. Näitäkin on ohjattu ulos projekteista. Tee vain sellaista työtä, josta olet ylpeä. Jos tilanne vaatii, suojele ihmisiä.

{ 4 Comments }

Tietohallintoa vessaviisaudella

Katrin-2-wMuutama vuosi sitten silmään osui wc-paperiteline, jossa luki Katrin “Less is More”. Nopeasti ajatellen tuo tuntuu samanlaiselta heitolta kuin tyypillinen postaus Linkedinissä. Eli otetaan jonkun ajatuksen tiivistys, teipataan se valokuvan päälle ja julkaistaan. Sitten se pyörii ruudussa muutaman kuukauden ja iso joukko ihmisiä peukuttaa sitä. Minäkin olisin voinut julkaista kuvan vessasta.

Todistus

Tässä on enemmän. Tässä on kyseessä oikeasti suuri viisaus, nimenomaan tietotekniikan ja digitalisoinnin johtamisessa. Viimeisimässä McKinsey on Business Technology-lehdessä (36-2014) oli artikkeli ’How winning banks refocus their IT budgets for digital’. Siinä vertailtiin pankkeja käyttäen IT-budjetteja, panostuksia eri alueisiin ja näistä syntyneitä tuloksia.  Näitä oli verrattu toisiinsa ja rakennettu malli, jossa palveluissaan onnistuneet pankit oli peilattu siihen miten ne käyttävät IT:tä. Sekä haettu näiden välisiä selittäviä tekijöitä.

Tulokset olivat täsmälleen vessaviisauden mukaisia. Digitalisoinnissaan tehokkaat, onnistuneet pankit käyttivät tietotekniikkapalvelujen tuottamiseen vähemmän resursseja. Ja vastaavasti huonommin onnistuneet pankit käyttivät enemmän resursseja. ‘IT-tehokkaat’ pankit saivat myös aikaisemmaksi korkeamman kate%:n. Ero oli 53% verrattuna tehottomien 26% katteeseen. Huonosti menestyvät pankit kuluttivat IT-operaatioihin (day-to-day) 17% kokonaiskustannuksista. Ja hyvin menestyvät kuluttivat 10%. Pankeista puhuttaessa tämä on aika paljon rahaa.

Ja se varsinainen pihvi oli siinä, että selittäväksi tekijöiksi oli löydetty seuraavat toiminnalliset panostukset:

  • Tiukka kustannuskuri
  • Hankinnan kyvykkyys
  • Standardointi

Ei siis perinteinen ‘meillä on enemmän leluja kuin teillä’-kilpailu. Itseasiassa artikkeli täysin vastoin yleistä digiviisautta toteaa, että esimerkiksi panostukset monikanavaiseen integraatioon ja asiakasdialogin kehittämiseen eivät juurikaan tuota. Aivan hulvattomaksi artikkelin tekee se, että siinä todettiin vähemmän vaikuttaviksi tekijöiksi seuraavat kyvykkyydet:

  • Testauksen automatisointi
  • Formalisoitu prosessi liiketoiminnan kanssa työskentelyyn
  • Liiketoiminnan tarpeiden dokumentointi

Näihin tehdyt panostukset eivät korreloi varsinkaan sovelluskehityksen kustannuksiin. Ymmärrän, että osalle IT-teollisuuden väkeä tämä saattaa synnyttää ristiriitaisia tunteita. Jos haluat kinata asiasta kannattaa se tehdä McKinseyn tutkimustiimin kanssa, minäkin ihmettelin muutamaa artikkelin havaintoa.

Reaalimaailma

Kaikkea tätä voisi selittää monella tavalla, mutta ehkä yksinkertaisin selitys voisi olla, että normaali maalaisjärki auttaa monessa asiassa. Formaalit prosessit ovat välttämättömiä toiminnan sujuvoittamiseksi. Monimuotoiset palvelut ovat tärkeitä. Mutta mikään näistä ei tee kesää. Formaalien prosessien iso ongelma on se, että niiden ympärille pesiytyy uskovaisia, jotka saarnaavat niiden ratkaisevan kaikki ongelmat. Jep, mutta se ongelma vaan on jossain muualla.

Viisaus

Lopultakin kaikki palaa siihen, että tekemällä ne tärkeät asiat hyvin ja jättämällä vähemmän tärkeät tekemättä saat enemmän aikaan. Se tärkein taito on valita ne merkitykselliset asiat. Sitä kutsutaan joskus priorisoinniksi.  Senkin voi sössiä helposti jos kuluttaa aikaa priorisointiin enemmän kun tekemiseen. Yksi suurimmista viisauksista on myös sekin, että tekemätön päätös on myös päätös. Se on päätös hyväksyä nykytila, olla etenemättä. Aika on ainoa täydellisen rajallinen luonnonvara. Ajan varastoa ei ole.

Asiakas on aina kingi. Ne tärkeät palvelut ovat sellaisia, että niillä on merkitystä asiakkaalle. Ja silloin niillä on merkitystä liiketoiminnalle. Ja se on ainoa millä on merkitystä. Ihan oikeasti. CIO ei saa harrastaa IT:tä, hänen pitää rakastaa liiketoimintaa.

Artikkeli loppuu lakonisesti ’To meet IT budget pressures, CIOs have many opportunities to fund investments by cutting the costs of day-to-day operations and application development’. Aika hyvin sanottu.

Muutama pallo päiväsi parantamiseksi

  • Keskity liiketoiminnan kannalta olennaiseen
  • Tee tärkeät asiat valmiiksi
  • Älä hajota keskittymistä merkityksettömillä asioilla
  • Less is more. Really.

Ja käy vessasssa. Se on opettavaista ja terveellistä.

Ps1: Artikkeli listaa ison joukon tuottoisia investointikohteita, niitä voit lukea varsinaisesta jutusta.

{ 1 Comment }

Rakkaus ja CIO

Kevät on aikaa rakkauden. On siis hyvä hetki kirjoittaa muutama sana rakkaudesta. Ja nimenomaan CIO:n rakkaudesta. Tuntuuko ristiriitaiselta? Eikös se ollut niin, että CIO on se ’IT-hemmo jonka rakastaa tietotekniikkaa’. Tämä on aika jännä ajatus. Miksi CIO:n pitäisi rakastaa tietotekniikkaa? Kokeile joskus työssäsi sanoa ääneen, että et rakasta tietotekniikkaa…

Olen käynyt tästä aika monta keskustelua ja yleensä juttu menee niin, että ’kun sä teet IT-juttuja niin kai sun pitää rakastaa IT-juttuja’. Tämä analogia on suunnilleen samaa tasoa kuin ’CFO tekee numeroita joten CFO varmaan rakastaa exceliä’. Tai ’Sihteeri tekee kalenterivarauksen joten hän varmaan rakastaa kalenteriansa’. On ihan oikeasti omituista ajatella, että lankkumaalari rakastaa lankkujen maalaamista niin, että tekee sitä varmasti vapaa-ajallaankin.

Väitän, että CIO:n kuuluu vihata tietotekniikkaa. Tai vähintään suhde pitää olla platoninen. CIO:n keskeisimmät tehtävät ovat:

  1. pitää huoli, että tietotekniikkaan nojaavat prosessit toimivat riittävän hyvin.
  2. pitää huoli, että tietotekniikan kustannukset ovat mahdollisimman alhaiset.
  3. pitää huoli, että erilaisten käyttäjien tarpeet tulevat toteutettua niin että edelliset toteutuvat.
  4. pitää huoli, että tietotekniikka on renki. Ei isäntä.

Avainsanat tässä ovat riittävän & mahdollisimman. Kaikki turha on tarpeetonta. Asiat, jotka eivät toteuta yrityksen strategisia tavoitteita ovat tarpeettomia. Niitä ei saa olla, eikä niitä saa tehdä. Ja ne eivät saa maksaa senttiäkään.

Tämä ei ole kuitenkaan niin yksioikoista kuin edellä lukee. CIO:n kuuluu myös olla intohimoisen kiinnostunut asioista, jotka mahdollistavat uusia asioita. Ja olla palavan innostunut siitä, miten näitä voitaisiin hyödyntää. Mutta CIO ei saa ikinä, milloinkaan, koskaan ryhtyä jonkun tekniikan / menetelmän / toimittajan / välineen matkasaarnaajaksi. Ja tästä tulee se, ettei CIO saa koskaan rakastua tietotekniikkaan.

  • CIO:n kuuluu rakastua tyytyväisiin palvelujen käyttäjiin.
  • CIO:n pitää innostua ratkaisusta, joka toteuttaa yrityksen strategiset tavoitteet entistä paremmin.
  • CIO:n pitää saada hurjia viboja siitä, että liiketoiminta ylittää tavoitteensa.
  • CIO:n kuuluu haltioitua siitä, että toiminta uusiutuu ja kehittyy

Ja kaikki tämä korostuu jos liiketoiminta on tietointensiivistä. Jolloin tietotekniikka voi mahdollistaa sellaisia asioita, jotka muuten eivät olisi mahdollisia.

Muutama teesi CIO:lle vuoden aluksi:

  1. Tietotekniikka pitää olla renki, ei isäntä
  2. Teknologia mahdollistaa (joskus) muutoksen
  3. Muutos syntyy johtamalla toimintaa, hyödyntäen (joskus) tietotekniikkaa
  4. Pyri aktiivisesti hävittämään kaikki turha, kallis ja tarpeeton tietotekninen puuhastelu.
  5. Rakasta työtäsi, vihaa (turhaa) tietotekniikkaa

{ Add a Comment }

Ja mikä olikaan projektisi rasvaprosentti?

Näin vapun kunniaksi voisi paneutua työn jakautumiseen järkevästi. Tarkemmin projektin johtamiseen ja siihen liittyvään tekemisen & johtamisen jakautumiseen. Oletko koskaan ihmetellyt, mitä kaikki projektin johtoryhmässä olevat ihmiset tekevät? Tai miksi?

Kävelet tavallisen projektin tavalliseen johtoryhmään. Tavallisesti tupa on täynnä. On toimittajan projektipäällikkö, hänen esimiehensä, salkkuvastaava, laatuvastaava, myyjä ja hyvällä tuurilla vielä erillinen account manager ja hänen kaverinaan joku soveltuva Suuri Johtaja. Asiakkaan puolelta on myös väkeä. Yleensä vähemmän.

Sitten mennään projektin sisällön läpikäyntiin. Yleensä yksi puhuu ja loput haaveilevat. Jostain. Projektipäällikkö kertoo, että miten se onneton ihminen Krakovassa on sairastunut. Ja että projektin tilanne on epäselvä koska tekijä saikuttaa.

Jos vaikka tässä kohdassa pysähdyttäisiin ja kysyttäisiin, että ’mitä te täällä teette?’. Useimmat eivät osaa vastata. Osa sanoo jotain siihen malliin, että ’haluan seurata projektia jotta voin arvioida… jotain’. Tai sitten selittää jotain epäselvää tyyliin ’mä tässä manageroin’. Osa rehellisesti sanoo, että ei ole hajuakaan.

Useimmiten tilanne on juuri näin. Projektit ovat nykyään aika pieniä, siis tekijämielessä. Ja projektien johtaminen on aika isoa. Koska ’niin vaan kuuluu toimia’. Tai sitten ’menetelmämme edellyttää’. Tai ’raportoimme johdolle’.

Tämä on ongelma

Asian havainnollistamiseksi voisi soveltaa jo pahasti kulunutta käsitettä organisaatioläski ja laskea projektille sen rasvaprosentti. Se on hulvattoman helppoa ja tapahtuu seuraavasti. Laske ne nupit jotka osallistuvat projektin johtamiseen. Käytännössä vaikkapa johtoryhmän jäsenet. Ja sitten laske ne nupit jotka tekevät sen oikean työn. Näiden suhteesta syntyy projektin rasvaprosentti. Jossa läskiä ovat ne ihmiset jotka ’johtavat’ projektia ja lihasta on he jotka tekevät projektin varsinaisen sisällön. Kuten ihmisilläkin rasvaprosentti ei saa olla liian suuri. Hyvä on jossain 15-20% tienoilla. Projektille se pitäisi olla vielä pienempi.

Miksi?

Minä en asiakkaana ole kiinnostunut siitä, miten projektia ’manageroidaan’. Kunhan lopputulos ja keinot ovat odotusten mukaiset. Onnellisuuteni ei kasva jos projektia johtaa yhden sijasta viisi ihmistä. Jos projektin rasvaprosentti on korkea kertoo se siitä, että ketju tavoitteen ja tekijän välillä on pitkä. Ja että projekti on yliorganisoitu. Ja että se maksaa liikaa.

Kaikki ylimitoitettu johtaminen kuluttaa voimavaroja. Tarkoittaen sitä, että yksikin tarpeeton raportointia vaativa ihminen ylikuormittaa työtä tekeviä ihmisiä. Ja jos näitä parasiitteja on riittävästi tarvitaan lisäksi ihminen tekemään pelkästään niitä raportteja. Koneisto ruokkii siis itseään. Johtamisen määrällä ja tuloksilla on tietyn rajan jälkeen käänteinen korrelaatio.

Korkea rasvaprosentti kääntää perinteisen organisaatiopyramidin väärin päin. ’Manageeraajia’ on enemmän kuin tekijöitä. Tähän ei kannata sotkea sitä, että projektia ihan oikeasti pitää johtaa. Kyseessä on tilanne jossa sitä ylijohdetaan ja roolit & vastuut ovat menneet sekaisin.

Ihmiset sen työn tekevät, eivät organisaatiot tai prosessit

Olen nähnyt tilanteita joissa puolikkaan ihmisen työpanosta on pohtimassa kahdeksan johtajaa. Tässä ei todellakaan ole mitään järkeä. Lisäksi yliohjaaminen loukkaa, ihan sananmukaisesti, tekijöitä. Jokainen tekijä tietää, että se työ, jonka he tekevät maksaa myös näiden kuhnureiden palkan. Kannattaa avoimesti tunnustaa, että usein kehittäjät ovat organisaatiosi fiksuimpia ihmisiä. He kyllä näkevät ‘resurssit ovat organisaatiomme tärkein voimavara’-huuhaan läpi vaikka itse siihen uskoisit.

Juttelin erään konsulttiyhtiön maajohtajan kanssa. Hän kertoi, että he olivat laskeneet, että heidän menetelmillään ei kannata käynnistää projekteja ellei niissä ole vähintään 10 tekijää. Muuten rasvaprosentti kasvaa liian suureksi. Jo siksikin pienemmissä projekteissa kannattaa käyttää pienempiä taloja jotka eivät vielä ole kangistuneet -60-luvun projektimalleihin. Itseasiassa kaikkien projektitalojen kannattaisi laskea, että mikä on heidän minimiprojektin koko ja kustannus. Tarkoittaen siis sitä, että jos menetelmät ja organistointi edellyttää tiettyä prosessia saa siitä helposti laskettua mikä on pienin mahdollinen projektikustannus. Erittäin opettavainen harjoitus…

Projekti on väliaikainen organisaatio jolla on määritelty tavoite ja keinot päästä niihin. Projektista ei saa tehdä byrokratiamyllyä ja unohtaa miksi se on olemassa.

Bottomline

Asiakasta kiinnostavat tulokset. Ei se, kuinka monta ihmistä kuluttaa aikaansa kokouksissa. Johtamisen määrä ei yleensä korreloi laatuun. Saatikka tehokkuuteen. Mennessäsi seuraavaan projektin johtoryhmään laske sille rasvaprosentti ja ohjaa tarpeettomat ihmiset ulos huoneesta. Nyt on hyvä hetki saada projektisi rantakuntoon, onhan kesäkin tulossa. Rasvaa voi polttaa kuntoilemalla.

Ja käytä sitä maalaisjärkeä.

jk. Tämä on ensimmäinen kirjoitus projektitoiminnasta. Jatkoa on tulossa, kannattaa painaa oikealla olevaa subscribe-nappulaa jos haluat kuulla seuraavista episodeista. Seuraavaksi voisi paneutua vaikkapa velton projektipäällikön toimintaan .. vai olisiko kiinnostavampaa keinot tunnistaa valennörtit? Entäpä …

{ Add a Comment }

Tietotekniikka muuttaa liiketoimintasi?

Miksi fiksutkin ihmiset vaikuttavat joskus … ei niin fiksuilta? Pohdin tätä eräänä päivänä kuunnellessani esityksiä eräässä seminaarissa. Tarina meni sitä tavallista rataa, ’Meille tulee tämä CRM-järjestelmä ja sen myötä myyntimme räjähtää’ ja ’meille tulee OLAP-raportointityökalu joka antaa meille ymmärryksen liiketoiminnasta’. Aivan kuin järjestelmällä olisi näissä mitään tekemistä.  Esittäjät kertoivat, että ’odottelemme sitä ja tätä ja sitten aurinko nousee ja kesä tulee’. Ei muuten tule. Jos odotat, että IT muuttaa liiketoimintasi sataa räntää vielä juhannuksena.

Otetaan pari faktaa vasaroista

  1. vasara on työkalu
  2. kun sen laittaa maahan ei se rakenna taloa
  3. vaikka vetäisit ripaskaa vieressä

Laudoista

Otetaanpa laajempi versio noista edellisistä faktoista:

  1. jep, se vasara tarvitaan
  2. mutta tarvitset myös piirustukset siitä, mihin ajattelit sitä käyttää
  3. ja lautoja & nauloja
  4. sen lisäksi sinun pitää osata käyttää sitä vasaraa sekä myös lukea niitä piirustuksia
  5. sitten tarvitaan naulaamista, mielellään osuvaa, muuten sattuu ja kovasti
  6. ja sitten katsoa sitä mihin tuli iskettyä ne naula

Tietotekniikasta

Sovelletaanpa tätä yrityksen sisäisin tietojärjestelmäprojekteihin:

  1. Kaiken aloittaa tarve muutokseen ja sen tavoitteet
  2. Sitten tarvitaan jonkinasteinen prosessi jonka mukaan toimitaan
  3. jep, se järjestelmä saatetaan tarvita
  4. Perustiedot ja lähtöaineistot pitää olla kohdallaan
  5. Ja sitten olisi aika hyvä jos käyttäjät osaisivat käyttää järjestelmää
  6. sitten kovaa pauketta
  7. tuloksien mittaamista ja reagointia niiden perusteella

Kaikkea tätä ohjaa johtaminen. Se on kaikista tärkeintä muutoksen tavoittelemisessa. Enkä tarkoita tässä naivia ajatusta siitä, että johdon pitää sitoutua järjestelmään. Järjestelmiä ei saa rakentaa jos niillä ei ole käyttötarkoitusta. Kukaan ei ole niin hullu että sitoutuisi tarpeettomaan järjestelmään.

Muutos?

Halutessasi muutoksen on järjestelmä vain työkalu. Se varsinainen muutos lähtee johtamisesta. Toimintaa pitää johtaa tuloksellisesti kohti niitä tavoitteita joita organisaatiolla on. Työkalut ovat työkaluja, organisaation voima on ihmiset.

Siis haluat muutosta? Ihan simppelisti, vaikkapa haluat automatisoida jonkun prosessin, tai vaikkapa tehostaa varastonhallintaa. Koko homma lähtee siitä, että sinun pitää tietää mitä haluat. Ihan ensimmäisenä aseta ne tavoitteet.  Ja jos et osaa asettaa liiketoiminnallisia tavoitteita niin sitten unohda koko juttu.

Tavoitteiden jälkeen olisi hyvä keksiä ne keinot miten niihin päästään. Tarkoitan siis tavoitetilan prosessia ja niitä askelia joilla siihen tavoitetilaan päästään. Samalla määritetään ne tahot jotka prosessissa toimivat. Ja ne joukot jotka sitä prosessia johtavat sekä tukevat.

Vasta nyt aloitetaan sen järjestelmän pohtiminen. Ja tässä vaiheessa alkaa se IT-projekti ja homma menee normisti eteenpäin. Olettaen, että et aja projektia seinään ’tarpeellisilla’ muutoksilla. Kannattaa yleensä tavoitella yhtä juttua kerrallaan. Lisäksi järjestelmän pitää toimia riittävän hyvin jotteivat käyttäjät voisi pahoin sitä käyttäessään.

Sitten alkaa se vaikea osuus. Se uusi prosessi otetaan käyttöön ja parempi olisi että se toimisi. Myös se järjestelmä. Tästä eteenpäin ainoa mikä merkitsee on toiminnan johtaminen.  Ja mittaaminen. Ja johtaminen. Ja mittaaminen.  Ja vasta nyt ollaan siinä muutoksessa. Kaikki ennen tätä on ollut jotain muuta.

Bottomline

On perverssiä sanoa että tietotekniikka itsessään tekisi muutoksen. Tietotekniikka mahdollistaa asioita, mutta johtaminen tekee sen muutoksen. Sinun pitää tietää mitä haluat, ihan konkreettisesti. Turha luulla että löydät perille jos et tiedä minne olet menossa.

Vielä yksi juttu : paras muutos on sellainen jonka saa aikaiseksi ilman tietojärjestelmää.

ps : IT-alalla toimivat ihmiset eivät yleensä tunne talojen rakentamista ja vasaroita. Mäpäs olen rakentanut 2+ taloa, tunnen vasarat 🙂

{ 3 Comments }