Miten valitsen osaavan IT-projektipäällikön, ja vältän huithapelit, jyrääjät ja tuuliviirit?

Mies meni eläinkauppaan. Häkissä oli kolme apinaa. ”Miten tuo apina voi maksaa 10.000 euroa?”, mies kysyi myyjältä. ”Se osaa koodata”, vastasi myyjä. ”Entä tuo toinen apina?”, kysyi mies. ”Se maksaa 15.000 euroa. Se osaa IT-arkkitehtuuria”, vastasi myyjä. ”Entä tuo kolmas sitten?”, kysyi mies. ”Se maksaa 20.000 euroa.”, vastasi myyjä. ”Mitä se oikein osaa?!?”, kysyi mies. Myyjä vastasi: ”En tiedä, mutta nuo kaksi muuta sanoo sitä projektipäälliköksi.”

Apina tietokoneella

Projektipäällikön valinta on yksi IT-projektin ohjausryhmän tärkeimmistä päätöksistä. Osaava projektipäällikkö on IT-projektin keskeinen menestystekijä. IT-projektipäälliköiden osaamisen arviointi ja vertailu on haastavaa, joten ohjausryhmät eivät useimmiten kiinnitä projektipäällikön valintaan riittävästi huomiota. IT-projekteihin liittyy useita epävarmuuksia, eikä edes osaava projektipäällikkö voi estää kaikkia ongelmia, minkä takia projektipäällikön merkitystä projektin onnistumiselle aliarvioidaan liian usein. Osaava projektipäällikkö osaa kuitenkin ennakolta estää monia ongelmia ja lieventää ennakoimattomien ongelmien vaikutusta, mikä näkyy pienempinä kustannus- ja aikatauluylityksinä.

Käytännön IT-arjessa kamppaillaan taivaita hipovien tavoitteiden, rajallisten resurssien ja tiukkojen aikataulujen ristipaineessa. Seuraavan kerran kun olet nimittämässä IT-projektiisi projektipäällikköä, pysähdy hetkeksi ja varmista, ettet ole tietämättäsi syyllistymässä johonkin seuraavista virhearvioista IT-projektipäällikön valinnassa:

  • valitset huithapelin, jolla on kirkas visio, mutta jolle työn suunnittelu on utopiaa ja prioriteetit turhuuksia
  • valitset ahertajan, joka ratkaisee ongelmat nopeasti, mutta ei estä niiden syntymistä ennakoimalla
  • valitset hurmaajan, joka uskoo ilmapiirin, fiiliksen, ja yhteishengen vievän vaikka läpi palomuurin
  • valitset kauppiaan, joka pitää ohjausryhmän ja sidosryhmät tyytyväisenä syöttämällä niille paskaa
  • valitset kylmäkallen, joka tehokkuuteen pyrkiessään kohtelee tiimiä mekaanisina suorittajina ja korvattavissa olevina resursseina
  • valitset ohjeistamispäällikön, jolle projektissa tärkeintä on hallinnollinen tarkkuus ja metodologinen kuri
  • valitset törmäysnuken, joka tietää kestävänsä palautetta, joten projektin onnistumisesta ei ole tarvetta stressata
  • valitset norsunluutornilaisen, jolle liiketoiminnan tavoitteet ovat selkeitä, mutta tekniikka-, arkkitehtuuri- ja vaatimusasiat on epämiellyttävää nippeliä
  • valitset propellipään, joka pyrkii edistykselliseen tekniseen ratkaisuun, mutta ei ymmärrä liiketoiminnan tarpeita
  • valitset höpöttäjän, joka osallistaa kaikki projektityöhön, mutta mittaa projektin etenemistä palaverien ja niiden osallistujien määrällä
  • valitset jyrääjän, joka toimittaa ala-arvoisen ratkaisun sovitussa aikataulussa ja budjetissa
  • valitset jokapaikanhöylän, joka on aina tekemisessä mukana ja ilmestyy mikromanageeraamaan myös silloin, kun ei tarvita
  • valitset tuuliviirin, joka etsii kompromisseja, mutta ei tee päätöksiä, koska ei halua sanoa kenellekään vastaan
  • valitset konkarin, jolla on pitkä kokemus teknisenä asiantuntijana, mutta jolle ei löydy enää muitakaan hommia
  • valitset juniorin, joka vakuuttaa olevansa motivoitunut IT-projektipäälliköksi, mutta ei ole aiemmin ollut IT-projektissa mukana

Vaikka IT-projektipäällikköjen osaamisen arviointi on haastavaa, kannattaa muistaa se tosiasia, että toiset projektipäälliköistä todella ovat osaavampia. Lisäksi erilaiset IT-projektit vaativat projektipäälliköltä erilaista osaamista riippuen esim. projektin liiketoimintakeskeisyydestä, ratkaisun teknisyydestä, projektin riskiprofiilista, projektiorganisaation muodosta tai ratkaisun loppukäyttäjistä. Nimenomaan vaativissa olosuhteissa projektipäällikön osaamisella on suurin vaikutus projektin onnistumiseen tai epäonnistumiseen.

Mount Everestin valloitus

Vaatii huomattavasti vähemmän osaamista retkenjohtajalta johtaa patikointia vehreälle kukkulalle kauniina kesäpäivänä kuin kiipeämistä Mount Everestille lumimyrskyn uhatessa. Kesäpäivänä kukkulalla voi olla vaikeaa nähdä eroja retkenjohtajien osaamisessa tai huonojen päätösten seurausten merkitystä. Sen sijaan Mount Everestilla jokainen retkenjohtajan päätös voi tehdä eron koko retkikunnan elämän ja kuoleman välillä. Valitsisitko itsellesi Mount Everestille retkenjohtajaksi joviaalin jutustelijan, joka patikoi ruohikolla kerran vuodessa aurinkoisessa säässä vai sherpan, joka on aiemmin vetänyt retken huipulle parikymmentä kertaa?

Kaikissa IT-projekteissa projektipäälliköltä vaaditaan monipuolista osaamista tasapainoisessa suhteessa. Projektinhallinnollisten menetelmien lisäksi mm. liiketoiminnan tavoitteiden syvällinen ymmärtäminen, organisaatiorajat ylittävät viestintätaidot, kokonaisuuden tilannekuvan säilyttäminen ja konkreettisten priorisoitujen toimintasuunnitelmien valmisteleminen ovat arvokkaita taitoja.

Älä ainakaan valitse seuraavan IT-projektiisi projektipäällikköä, jolta löytyy kovin monia edellä listatuista piirteistä. Muuten saatat pian löytää itsesi ja projektisi perinteisen sananlaskun kuvaamasta tilanteesta, jossa kyvyttömät yrittävät saada haluttomat tekemään mahdottomia.

”Oho”, sanoi IT-asiantuntija

IT-asiantuntijan tehtävä: Pankin suurtietokoneen (mainframe) CA-7 eräajo-ohjelmiston rutiinipäivitys. Asiantuntijatyön lopputulos: Inhimillinen virhe ja arviolta 100 miljoonan euron suorat kustannukset ja korvausvaatimukset pankille, jonka 17 miljoonaa asiakasta ei pystynyt käyttämään pankkitilejään viiteen päivään. Tällaisia IT-haasteita koki juhannusviikolla Iso-Britanniassa The Royal Bank of Scotland (RBS) pankki.

RBS:n pääjohtaja Stephen Hester on liiketoimintajohdolle tyypillisesti päässyt valittelemaan tapahtunutta: ”Asiat menevät joskus pieleen. Asiat menevät pieleen IT:n kanssa.” On luontevaa selitellä jälkikäteen ikään kuin mitään ei olisi ollut tehtävissä ja vedota IT-asioissa ”force majeure”-ajatteluun. Todellisuudessa kuitenkin oikein suoritetuilla laadun (quality management) ja riskien hallinta (risk management) toimenpiteillä sekä selkeällä IT-hallinnointimallilla (IT governance model) voidaan kustannustehokkaasti ehkäistä sellaisten riskien realisoituminen, joilla on potentiaaliset 100 miljoonan euron kustannukset.

Ohjelmistopäivityksen onnettomaan lopputulokseen ovat todennäköisesti vaikuttaneet ainakin tehtävän tyyppi (rutiinitehtävä), tehtävän määrittely (epäselvät toimintatavat), tehtävä suorittajan osaaminen (puutteellinen), tehtävän suorittamisen olosuhteet (kiire), tehtävän hallinnointi (epäselvät vastuut), tehtävän riskikategoria (väärin arvioitu) sekä tehtävän laatukriteerit (puutteellisesti hallittu).

Käytännössä tapahtumassa oli kyse siitä, että eräajo-ohjelmiston päivitys ei syystä tai toisesta onnistunut. Julkinen tarina ei kerro oliko päivityksen toimivuus ennen tuotantoympäristöä varmistettu testiympäristöissä. Oli tai ei, niin joskus IT:n kanssa tulee yllättäviä ongelmia ja niihin vain pitää varautua. Päivityksen epäonnistumisen jälkeen palautusohjeistusta (roll-back procedure) ei noudatettu, vaan jostain syystä asiantuntija poisti järjestelmästä 100 miljoonaa jonossa odottavaa transaktiota (tilisiirtoa) ja ilmeisesti myös eräajo-ohjelmiston koko konfiguraation.

Julkinen tarina ei myöskään kerro oliko palautusohjeistusta ylipäätään laadittu, oliko se ymmärrettävä ja tunsiko asiantuntija kyseisen ohjeistuksen. Ongelman laajuuden selviämisen jälkeen ympäristöön piti asentaa toimiva versio CA-7 ohjelmistosta, ohjelmiston konfiguraatio piti tehdä uudelleen ja tuhotut transaktiot piti palauttaa jonoon. Samalla jonossa olevien transaktioiden määrä kasvoi noin 100 miljoonalla päivässä. Lisähaasteen selvitykseen toi se, että transaktiot piti ajaa tileille alkuperäisessä järjestyksessä (tuhotut tiistain transaktiot ennen keskiviikon transaktioita jne.). Kolmen päivän päästä eräajojen tekniset ongelmat oli korjattu, mutta transaktioiden järjestyksessä oli edelleen korjattavaa.

Iso-Britanniassa RBS:n IT-ongelmat ovat herättäneet keskustelua paitsi pankin asiakkaille aiheutuneista käytännön haitoista, myös RBS:n vuonna 2010 tekemästä päätöksestä siirtää IT-toimintojaan Intiaan. RBS:lta aiemmin irtisanotut isobritannialaiset IT-asiantuntijat ovatkin kärkkäästi kommentoineet julkisuudessa, että nyt kohdatut ongelmat ovat väistämätöntä seurausta RBS:n johdon aiemmista päätöksistä luopua paikallisesta edistyneestä IT-osaamisesta, jolla oli kymmenien vuosien kokemus kyseisistä tietojärjestelmistä. RBS on jyrkästi kiistänyt, että intialaisilla olisi mitään tekemistä ongelmien kanssa. Eihän IT-asioissakaan ole kyse olekaan siitä kuka tekee vaan siitä mitä ja miten tehdään.

Tietoviikko

IT tulee töpselistä, eikun pilvestä

Muutamia vuosia sitten alkanut pilvilaskenta-trendi ei ota laantuakseen. Trendin huipulla suurten IT-talojen johtajat parhaimmillaan (tai pahimmillaan) yksinkertaistivat pilvilaskennan siten, että pilvet tekevät IT:sta yhtä helppokäyttöistä kuin sähkö. Vertaus on ihailtavan visionäärinen, mutta pilvilaskentaan liittyy vielä runsaasti sekä hallinnollisia että teknisiä käytännön haasteita.

Mitä pilvilaskenta sitten oikein on? Pilvilaskenta tarkoittaa tietoteknisen palvelun suorittamista palvelun käyttäjälle läpinäkymättömässä virtuaalisessa ympäristössä. Pilvipalvelun käyttäjä ottaa yhteyden palveluun tietoverkon yli. Pilvipalvelut jaetaan hierarkkisesti kolmeen luokkaan (edeltävä taso sisältää jälkimmäiset tasot): 1) Software as a Service (SaaS), 2) Platform as a Service (PaaS), 3) Infrastructure as a Service (IaaS).

Pilvilaskenta ei ole sama asia kuin palvelinten virtualisointi, jossa yksittäinen fyysinen palvelin abstrahoidaan käyttöjärjestelmän kannalta näkymättömäksi. Jo alimmalla IaaS-tasolla pilvipalvelu abstrahoi koko fyysisen infrastruktuurin sisältäen tallennusratkaisut ja verkon konfiguraatioineen. Ylimmällä SaaS-tasolla abstraktio ulottuu aina sovellustasolle asti.

Käytännön esimerkki SaaS-pilvipalvelusta on internet-sähköposti, joka ei vaadi mitään asennuksia käyttäjän koneelle internet-selainta lukuunottamatta. PaaS-pilvipalvelu puolestaan voi olla esimerkiksi webhotelli, jonne käyttäjä voi luoda internet-sivut (HTML), ohjelmoida dynaamista sisältöä (esim. PHP) ja rajoitetusti asentaa ohjelmistoja (kuten tietokanta tai blogi). IaaS-pilvipalvelu sen sijaan tarjoaa vain teknisen virtuaalisen ympäristön, mutta kaikki ohjelmistot ovat käyttäjän vastuulla.

Pilvipalveluilla voidaan korvata perinteisiä konesaleja ja liiketoimintasovelluksia sekä tehostaa palvelutuotantoa. Kapasiteetinhallinnan näkökulmasta pilvipalveluiden arvolauselma on ilmeinen: 1) fyysisen infrastruktuurin ja alustojen hankinta- ja ylläpitokustannus on toimittajan volyymiedun ansiosta matalampi, 2) toimittajan kapasiteettijouston ansiosta muutoksia on mahdollisuus tehdä nopeasti tilannekohtaisen tarpeen mukaan, 3) toteutunut kustannus perustuu todelliseen käyttöön ja kiinteä kustannuskomponentti on ennakoitavissa.

Haasteita pilvipalveluiden käyttöönotolle asettavat kuitenkin siihen liittyvät migraatiokustannukset sekä yritysten riskienhallinnalliset vaatimukset. Peruskysymys on, miten ulkoisia pilvipalveluja tulisi ylläpitää ja hallinnoida, jotta laadulliset vaatimukset täyttyvät hyväksytyllä riskitasolla, mutta kuitenkin kustannusedut saavutetaan. Kaikkia liiketoimintasovelluksia ei voida teknisistä, integraatio- tai suorituskykysyistä siirtää ulkoiseen pilvipalveluun.

Yhtenä ratkaisuna pidetään esim. nk. hybridimallia, jossa osa pilvipalveluista tuotetaan yrityksen sisäisestä pilvestä ja osa ulkoisesta pilvestä palvelukohtaisista kustannussäästömahdollisuuksista ja vaatimuksista riippuen. Aina sovelluksia jää myös kokonaan pilvien ulkopuolelle. Erityisesti ulkoisten pilvipalveluiden hallinnoinnissa tulee kiinnittää erityistä huomiota tietoarkkitehtuuriin, selkeisiin tietoturvalinjauksiin, oikean palvelutason valintaan.

Pilvilaskennan kehitys tulee jatkumaan ja se tulee varmasti jäämään osaksi yritysten IT-arkkitehtuureita ja palvelutuotantomalleja. Viimeksi tällä viikolla Forrester hämmensi keskustelua väittämällä, että pilvilaskenta ei olekaan IT:n tulevaisuus – ainakaan kokonaisuudessaan. Aika näyttää.

Lisätietoa: cio.com

Tervetuloa Cheetah-blogiin!

Tervetuloa! Tämä blogi käsittelee tietojärjestelmien ihmeellistä maailmaa. Useimmiten tuon blogeissa tekniseen, projektinjohtamiseen ja liiketoiminnalliseen kokemukseeni perustuvan näkökulman johonkin tapahtumaan, josta olen lukenut tai teemaan, johon olen tutustunut.

Blogin kirjoittajalla Teemu Leppäsellä on vahva kokemus vaativista liiketoiminnan tietojärjestelmistä ja kymmenistä suurille organisaatioille toteutetuista IT-projekteista. Koulutukseltaan Teemu on tekniikan tohtori (TKK). Teemun perustama Cheetah Consulting Oy on erikoistunut liiketoiminnan tietojärjestelmiin liittyvään neuvonantoon ja IT-toimittajayhteistyön kehittämiseen. Yritys tarjoaa kokonaisvaltaista, toimittajista riippumatonta palvelua pohjautuen kattavaan teknologia-, projekti- ja liiketoimintaosaamiseen.