19. syyskuuta 2016

Osaatko tehdä projektille hyvän lähdön? 5 hyödyllistä ohjetta tietojärjestelmäprojektia suunnittelevalle tilaajalle!

Kokemukseni mukaan projektin kohtaloa maalataan isolla siveltimellä sen alkumetreillä ja tai jo silloin kun varsinainen projekti ei ole vielä alkanutkaan. Ratkaisevia projektin onnistumiseen vaikuttavia asioita linjataan jo hankinnan suunnittelun aikana ja hankintaprosessissa.


1. Pilko ja paloittele! Vältä liian monimutkaisia kokonaisuuksia!

Monesti tilaajaorganisaatiossa ajatellaan, että järjestelmäprojektin sisällöksi on väistämättä otettava valtavan suuri kokonaisuus. Monesti uskotaan, ettei kokonaisuutta vain voi pilkkoa pienemmiksi osa-kokonaisuuksiksi. Mieli voi kuitenkin muuttua viimeistään silloin kun projekti on ajautunut monimutkaisuuden vuoksi karikolle. Silloin huomataan pakon edessä, että kokonaisuutta voi sittenkin paloitella pienempiin ja paremmin hallittaviin osiin.

Usein asiantuntijat ovat tottuneet ajattelemaan kokonaisuuksia tietyllä tavalla eivätkä hahmota, että muitakin lähestymistapoja voi olla. Joskus voidaan ajatella, ettei paloittelua voida tehdä asiakaskokemuksen heikentymisen vuoksi. Joskus taas koko toimituksen sisällön mietintä tai hankintaa edeltävä vaatimusmäärittely on jäänyt kokonaan tai osittain tekemättä.

Mitä monimutkaisempi projektin kohteena oleva alue on, sitä tärkeämpää kokonaisuuden osittaminen onnistumisen kannalta on. Monimutkaista suurta kokonaisuutta on vaikea hallita jo yksinkertaisesti sen vuoksi, että sisällöllisiä riippuvuuksia on vain liikaa ja korttitalo romahtaa pienestäkin iskusta. Siksi projektitoimituksen hankintavaiheessa sisältöä suunniteltaessa kannattaa kiinnittää paljon huomiota siihen, miten kokonaisuuksia voi pilkkoa pienempiin osiin.  Kunnollinen vaatimusmäärittely ja arkkitehtuurisuunnittelu kannattaa ja maksaa itsensä takaisin. Jos oma osaamien organisaatiossa ei riitä tällaiseen suunnitteluun, tähän on ehdottomasti rahanarvoista hankkia ulkoista apua.

2. Hyvää ja käsittämättömän halpaa tietojärjestelmäprojektia ei ole olemassa!

Olen nähnyt useat kerrat, kun asiakas on valinnut halvimman tarjouksen, mutta päätynyt maksamaan siitä lopulta huomattavasti enemmän kuin kalleimman tarjouksen hinta olisi ollut. Pelkästään hinta toimittajan ja toimituksen valinnassa on erittäin huono valintakriteeri. 

Tarjouspyyntöjen analysointi on vaihe, joka kannattaa ottaa asiaankuuluvalla vakavuudella. Kun mietit toimituksen hintaa, yritä ymmärtää varsinaisen sisällön ja sen kattavuuden lisäksi hinnoittelun perusteet, toimittajan motiivit ja syyt siihen, miksi toimitus on halpa. Älä sumeilematta usko, että toimittaja on tehnyt emämunauksen ja tarjoaa nyt niin halvalla, että tilaisuuteen on pakko tarttua. Toimittaja ei ehkä ole tehnytkään emämunausta. Ehkä toimittaja laskee, että raha tulee myöhemmin muutospyynnöistä tai vaikka ylläpidosta. Tilaajan kustannukset tulevat nousemaan jotain kautta joka tapauksessa.  Jos taas toimittaja on tehnyt emämunauksen, ja hinnoittelee toimituksen liian paljon kilpailijoita halvemmaksi, voi kyse olla vakavasta toimittajan osaamattomuudesta. Osaamattomuus taas on vaarallista eikä osaamattomuuden vaikutuksia kannata milloinkaan aliarvioida. Osaamattomissa käsissä projektitoimitus venyy ja sitä kautta koko projektin hinta nousee usein vielä hallitsemattomasti.  Hinta on asia, johon kannattaa suhtautua suurella kriittisyydellä.

3. Älä säästä väärästä kohdasta!

Kun tuntuu, että kaikki tietojärjestelmäprojektissa ja hankinnassa on niin kovin kallista, ryhdytään yleensä säästämään jo hankintavaiheessa.  Pienistä säästämisen puroista syntyy suuri virta, näin uskotaan. Yleensä säästetään projektinhallinnasta, ehkä määrittelystä, ehkä testauksesta tai käyttöönotosta. Näistä on kohtalaisen helppo karsia osuuksia vielä hankintavaiheessa. Mutta valitettavasti näistä säästämisen puroista syntyvä virta keikuttaa kaarnaveneen vaarallisille vesille. Näillä säästöillä karsitut työt on tavalla tai toisella kuitenkin tehtävä. On illuusio, että voidaan säästää välttämättömistä asioista kuten testauksesta. Heikosta testauksesta syntyy huonoa laatua, joka voi johtaa viiveeseen käyttöönottovaiheessa. Vielä pahempaa ja kalliimpaa on, jos puutteellisen testauksen seuraukset näkyvät vasta tuotannon häiriöinä. Fakta kuitenkin on, että tekemätön työ näkyy aina jossain ja valitettavasti huonosta laadusta kärsii viime kädessä aina tilaaja.

Suosittelen harkitsemaan tarkkaan, mistä asiasta kannattaa säästää. Kustannusten ollessa ohjaava tekijä, on mielestäni parempi rajata kokonaisuus laajuudeltaan mahdollisimman pieneksi ja tehdä se kunnolla. 

4. Sopimus ei ole vakuutus!

Moni varmasti haluaisi ostaa vakuutuksen, joka turvaisi tietojärjestelmäprojektin onnistumisen. Joskus tuntuu, että projektin toimitussopimuksien toivotaan olevan se vakuutuskatalogista puuttuva tietojärjestelmäprojektivakuutus. Sopimuksia väännetään osapuolten taitavien juristien kesken joskus kuukausia ja sopimusneuvotteluissa osapuolet pyrkivät usein aggressiivisesti puolustamaan omia etujaan.  Silti en ole koskaan nähnyt tilannetta, jossa sopimus olisi suojannut projektin epäonnistumiselta tai epäonnistumisesta johtuvilta kustannuksilta. Sopimus ei ole vakuutus.

Usein sopimusta laatiessa ei ole riittävää ymmärrystä siitä, mikä projektin tarkka sisältö tulee olemaan. Kuitenkin sopimuksessa pyritään suojaamaan osapuolten oikeuksia tyypillisesti hyvin tarkalla tasolla.  Varsinkin ketterät toimitusprojektit tuovat sopimuksiin aivan uuden haasteen. Lopputulokset ja tuotokset kun eivät ketterässä toimintatavassa ole suunnitteluvaiheessa edes tiedossa. Sopimuksiinkin tarvitaan ketterässä maailmassa joustavuutta. 

Yleisesti ottaen menetelmästä riippumatta sopimus olisi hyvä nähdä toimituksen win-win asetelman varmistavana dokumenttina eikä oman edun tavoitteluna tai vakuutuksena. Se luo terveen pohjan toimitukselle ja luo todellisia onnistumisen edellytyksiä.  Jo sopimusvaiheessa syntyvä voittaja häviäjä asetelma tuo riskejä toimitukselle. Onnistuminen syntyy parhaiten yhteispelillä, läpinäkyvyydellä, avoimuudella ja sillä, että kaikilla osapuolilla on mahdollisuus onnistua.

5. Älä yliarvioi oman organisaatiosi resursseja ja kyvykkyyttä!

Kun suunnittelet tietojärjestelmähanketta tai projektia, arvioi realistisesti oman organisaation voimavarat. Vaikka projektin toimitus ostetaan muualta, ei toimittaja milloinkaan tee kaikkea työtä. Tilaajaorganisaation edustajilta vaaditaan osallistumista ja osaamista sekä yhä useammin vahvaa muutosjohtamiskykyä.

Osaaminen tietojärjestelmäprojektissa on tyypillisesti erilaista kuin linjatöissä.  Tarvitaan ihmisiä, jotka toisaalta ymmärtävät oman liiketoiminnan ja järjestelmät, mutta toisaalta ymmärtävät miten tietojärjestelmäprojektissa toimitaan. Tarvitaan esimerkiksi määrittelijöitä ja testaajia, useiden toimittajien työn koordinoijia sekä ohjausryhmän jäseniä.  Tyypillisesti tarvitaan ihmisiä, joilla on kyvykkyyttä irtautua vanhasta ja ajatella uudella tavalla. Tarvitaan myös johtajia, jotka kykenevät muutosjohtamiseen ja nopeaan päätöksentekoon. On hyvä arvioida jo hyvissä ajoin, mitkä ovat oman organisaation taidolliset valmiudet tietojärjestelmäprojektiin osallistumiseen. 

Projektin osallistumiseen suhtaudutaan joskus yliolkaisesti. Ajatellaan, että tilaajaorganisaation asiantuntijat pystyvät hoitelemaan projektitoimituksen vaatimat tehtävät ”vasemmalla kädellä” omien töiden ohessa. Todellisuudessa panostus tietojärjestelmäprojektiin voi olla yllätys. Panostusta ja osaavia tekijöitä tarvitaankin paljon enemmän kuin oli kuviteltu. On hyvä olla realisti ja budjetoida jo suunnitteluvaiheessa riittävästi myös sisäiseen työhön projektitoimitukseen liittyen. Joskus viisas valinta on jo etukäteen kasvattaa omaa organisaatiota tulevan projektin tarpeisiin sopivaksi tai varautua konsulttiavun hankkimiseen.

15. syyskuuta 2016

Älä vaikuta tyhmältä - opettele digisanasto!


Digitalisaatio on tuonut mukanaan paitsi työtä helpottavia työkaluja ja menetelmiä, myös ison kasan uusia lyhenteitä ja kirjainyhdistelmiä. Lyhenteiden ja kirjainyhdistelmien lisäksi mukaan tunkee kaiken maailman vieraskieliset sanat, jotka tarkoittavat, no, jotain. 

Ei kirjoittajan kuva, kuva kuvapankista

Yritän tässä parhaani mukaan selittää erilaisia eniten hämmennystä herättäviä tai muuten vain tärkeitä sanoja ja lyhenteitä selityksineen. Sanat eivät ole missään tietyssä järjestyksessä, joten joudut lukemaan ne kaikki. En myöskään googlettanut mitään. Mitä hauskaa siinä olisi? Osaat sitä paitsi ihan itse. 

Iot - Internet of Things. Kaikki on nykyään yhdistetty Internettiin. Televisiot, kellot, ruokapöydät, jääkaapit, pesukoneet ja miksei vaikka peilitkin, saadaan yhdistettyä Internettiin. Miksi niin? Koska haluamme helpottaa arkeamme. Pyykkikoneen saa päälle mistä tahansa ja jääkaappisi tekee sinulle ostoslistan sen mukaan mitä haluat syödä. Pärjäätkö ilman nettiin yhdistettyä suihkua? Kyllä pärjäät. Haittaako, että saat kaikesta tietoa? Ei, kunhan opit hyödyntämään saamaasi tietoa. 

Big Data - läjä tietoa. Tätä tietoa pitää käsitellä ja suodattaa. Oikein luettu ja suodatettu data antaa valtavasti mahdollisuuksia kehityksessä. Kehitys taas on nykyään elinehto globaalissa maailmassa.

LeanIT - IT-organisaatio asiakaslähtöiseksi ja tehokkaaksi. Kuten muutkin Leanit putsataan ylimääräinen häsläys ja tehdään asioita, jotka tuovat arvoa asiakkaille. Kuusi peukkua. 

IT - Information Technology. Informaatio teknologia, tietotekniikka. Sisältää kaiken ja kaikki, jossa on tietoa, jota ei ole painettu tai hakattu kiveen.

TOGAF - The Open Group Architecture Framework, yritysarkkitehtuuriviitekehys. Mikä on yritysarkkitehtuuriviitekehys? Pitkä sana. Lisätietoja Tieturin Jari Kasslinilta

UI - User interface, Käyttäjän ja teknologian yhdistävä näkymä. Jotkut ovat hyviä, jotkut vähemmän hyviä.

OS - Operating System eli käyttöjärjestelmä. Esim. Windows, iOs, Android.

CRM - Customer Relationship Management. CRM on elintärkeä osa menestyvän yrityksen työkalupakkia. Vastaukset mm. kysymyksiin kuka, mitä, milloin ja miksi löytyvät CRM:stä (tai pitäisi löytyä).

ERP - Enterprise Resource Planning. Prosessien hallintaohjelma. Automatisoi ja hallitse!

Tieturi - Suomen paras tietoteknologiakouluttaja. Ei epäilystäkään.

Android - Linux pohjainen, Googlen omistama, mobiilikäyttöjärjestelmä.

Mobiilikäyttöjärjestelmä - Mobiililaitteissa käytettävä käyttöjärjestelmä, esimerkiksi Android tai iOS.

Linux - avoimeen lähdekoodiin perustuva, pingviinistäkin tunnettu.

AdWords - Maksa Googlelle, että näyt Google-haussa tai Googlen verkostossa.

Sharepoint - Microsoftin toimistopalvelu, pilvessä.

Amazon - Sademetsä tai yhdysvaltalainen tietoteknologiajätti. Ei ole tehnyt voittoa yrityksenä kuin korkeintaan vuoden.  Verkkokaupan lisäksi tarjoaa pilvipalveluita ja paljon muuta. Entisten Top Gear -pappojen nykyinen työnantaja.

CPC - Cost Per Click. Tarkoittaa verkkomainonnassa yleisesti käytettyä hinnoittelumallia, jossa maksat pelkästään mainosten klikkauksesta etkä näyttökerroista.

CPM - Cost per thousand impressions. Liittyy oleellisesti edelliseen, tällä kertaa maksat näyttökertoja. Mistä tuo M tulee lyhenteeseen? Sanasta Mil - tuhat.

IG - Insta, iigee eli Instagram. Tarkoitetaan Facebookin omistamaa kuvanjako- ja rahantekopalvelua. Käyttäjälle kuvajakopalvelu, jossa on hauskoja kuvia, videoita ja hashtageja.

Hashtag - Sosiaalisessa mediassa keskusteluaiheita merkitsevä merkki. Esimerkiksi ulkoilusta puhuttaessa voi käyttää #ulkoilu. Ylen urheilulähetyksistä puhuttaessa usein #hassuttelu riittää.

FB - Facebook on yhdysvaltalainen tietoteknologiajätti. Käytännössä rahasampo. Kaikki on Facebookissa.

Twitter - 140 merkkiä sis. välilyönnit. Siihen pitää mahtua mielellään joku pointti ja hashtag.

HTML - Ei kuulemma koodausta vaan jotain muuta. Käytetään nettisivuilla.

CSS - HTML:n kaveri. Saa nettisivut näyttämään kivalta.

ISTQB - Testausta

Uber - Kyydinjakopalvelu. Kivaa uuberissa on, että tiedät kuljettajan nimen ja tähtiarvion.

Docs - Google tallentaa pilveen, pääset käsiksi dokumentteihin lähes kaikilla laitteilla aina kun olet yhteydessä nettiin. Voit myös muokata samaa dokumenttia työkaverin tai oikean kaverin kanssa. Huippu juttu.

COBIT - Seuraa ohjeita kohdasta TOGAF

Reddit - Buzzfeedin ja muiden suosittujen Internetsivustojen lähdesivusto. reddit.com

Snäppi - Snapchatissa voit jutella kaverin kanssa, lähettää tälle kuvan tai jakaa tarinaasi kameran välityksellä omassa tarinassa. Kertoo, kun joku ottaa kuvastasi, keskustelustasi tai tarinastasi screenshotin eli ruutukaappauksen. Voit toki myös tallentaa kuvasi itse. Jos mitään ei tallenneta, hommat katoavat. (JES)

.NET - www.google.com 

Puffata - Suositussa Pokemon Go -pelissä karkuun lähtevä Pokemon puffaa. Näin käyn varsinkin, jos yrität saada hyvän Pokemonin.

Agile - Ketterä, daa

Mikropalvelu - Netflix on kuulemma rakennettu näin. Pienistä puroista kasvaa iso virta ja nämä pienet purot vielä juttelevat keskenänsä. Mageeta.

Perl - Ohjelmointikieli

TCP/IP - ?

Infrastruktuuri - Yrityksen tietoteknologia makaa infrastruktuurin päällä. Joku saattaa käyttää myös ei teknologia mielessä kuvaamaan teitä, rakennuksia yms.

www. - World Wide Web - Internet.

saitti - sivu World Wide Webissä, kuten Tieturi.fi

VBA-makro - Excel-taiturien juttuja. Tieto kulkee kauhean näppärästi ja selvästi. Tästä kurssille >>

Java - ohjelmointia

data scientist - hyviä käsittelemään Big Dataa, kannattaa jutella tai palkata. Ihannetilanteessa molemmat. 


YouTube - Videoiden katseluun erinomainen paikka. Videot eivät lopu kesken, sen voin luvata. Kuulemma tekevät siitä sosiaalisemman, mutta mitenköhän se muka sitten toimii. (Google+ ei ole jymymenestys) 

Ihan parhaiten löydät nämä kaikki, tietenkin, osoitteesta www.google.com. 

Jos haluat kuitenkin kaverille selittää esim. Big Datan voit vapaasti lainata tätä tekstiä tai lähettää seuraavan linkin http://lmgtfy.com/?q=Big+Data#  . Itse voit tehdä vastaavia linkkejä osoitteessa www.lmgtfy.com

Severi

13. syyskuuta 2016

ITIListä prosessit, DevOpsilla työkulttuuri

Kun minua ja Erno Aapaa haasteteltiin Tivin DevOps-juttuun, mietimme yhdessä, miten saisimme esimerkin avulla selväksi eron ja yhtäläisyydet. Päädyimme ravintola-esimerkkiin.

ITIL tarjoaa prosessit ja menetelmät, joilla saadaan ravintolan tilaus-, valmistus-, laskutus ym prosessit oikealle tasolla. Se ei tarkoita sitä, että pienessä tavernassa tarvitaan samoja prosesseja kuin monen sadan asiakkaan työmaaruokalassa tai fine dining -gourmetravintolassa. Eivätkä prosessit takaa, että asiakkaat pitävät annoksista.


DevOps korostaa työkulttuuria: valmista annosta ei vain heitetä asiakkaan eteen - ota tai jätä, maksat kuitenkin - vaan pyritään koko ajan ymmärtämään, että koko ravintolan olemassaolo perustuu asiakastarpeeseen. Asiakas saa sitä, mitä tarvitsee ja palautekanava on auki keittiöön asti. Se ei tarkoita etteikö prosesseja tarvita.

Ei kai tämä sen vaikeampaa ole. Luulisi. Käytäntö on usein muuta. Siksi tarvitaan tietoa, tietoisuutta, faktaa ja asennetta.


Ben Kalland

Ben on palvelunhallinnan ammattilainen – Tieturin kouluttaja ja konsultti – joka on nähnyt IT-alaa eri suunnista jo 30 vuoden ajan. 

Hänen erikoisosaamistaan ovat ITIL, COBIT ja ISO 20000 sekä muut mallit ja standardit, jotka tuovat lisäarvoa ja laatua palveluihin. 

Benin koulutuksen ja konsultoinnin missio on osaamisen siirtäminen asiakkaalle.

Sertifikaatit: ITIL® Expert, COBIT®, Certified Outsourcing Specialist, ISO 20000, Lean IT, TOGAF® 9

7. syyskuuta 2016

Excelistä apua ikääntyvälle nörtille?

Kaupungilla liikkuessani, oli se sitten kävellen, julkisilla tai omalla autolla, tahtoo nykyisin verenpaine kohota. En tiedä johtuuko se omasta erakkoluonteestani vai muitten töppäilyistä, toki omistanikin, mutta niin se vaan tuppaa kohoamaan. Kohoaa niin, että sitä täytyy aina silloin tällöin seurata ja laittaa tarvittaessa pilleri poskeen.

Kirjoiteltuani aikani tuloksia paperilappusille, jotka aina olivat väärässä paikassa eivätkä koskaan käsillä, kun niitä tarvitsin, päädyin tekemään taulukon Exceliin. Perustaulukon tekeminen ei ollut kovin vaikeata. Sitten keksin tallentaa sen pilvipalveluun, jolloin se oli siellä missä minäkin: kännykällä selattavissa vaikka lääkärin vastaanotolla.

Keskiarvot laitoin taulukon alkuun ja lukitsin ensimmäiset rivit niin, että yhteenveto ei hävinnyt vaikka rivejä itse taulukkoon tuli lisää. Kaaviokuvakin oli ihan kiva ja havainnollinen, kunnes kyllästyin tietojen lisäämiseen kaaviokuvaan aina lisätessäni taulukkoon uutta tietoa.

Tähän taas löytyy oiva ratkaisu Excelin dynaamisista nimistä. Ei muuta kun funktioita selaamaan ja nimiä määrittelemään. Kerrottakoon tässä vaiheessa, että funktio tällaiseen on SIIRTYMÄ (OFFSET).

No, ei tämäkään vielä ihan hyvä ollut, koska tuloksien kertyessä kaaviokuva paisuu ja muuttuu epäselväksi. Ajattelin, että haluan vain seurata viikon tai kuukauden tuloksia valitsemallani aikavälillä koko taulukosta, joten mietintämyssy päähän taas.

Excelistä löytyy tähänkin apu. Excelin ohjausobjektit! Vierityspalkki, jolla valitsen, kuinka monelta viikolta tiedot haluan, ja minun tarvitsee vain kirjata aloituspäivä.

Oheisesta kuvasta näkyy lopputulos.


Kiinnostuitko?

Lisää kikkoja Excelin taltuttamiseksi saat Tieturin Excel-kursseilta. Tule ja koe Excelin ihmeellinen maailma.

Excelin ihmeelliseen maailmaan tästä >>


Boris Isaksson
Senior Consultant
Tieturi

1. syyskuuta 2016

Miksi projekti mättää - projektijohtamisen ongelmia

Kesän aikana on julkisuudessa keskusteltu merkittävien projektien yllättävistä viiveistä ja epäonnistumisista. Tuntuu jonkinlaiselta luonnonlailta, että mitä mutkikkaampi ja isompi projekti on, sitä suurempia ja yllättävämpiä ovat myös ongelmat. Kun näitä ongelmia ja niiden syitä ryhtyy tarkemmin analysoimaan, törmää yleensä kolmeen perussyyhyn.


1. Organisaation kyvykkyys projektitoiminnan tukemisessa

Vaikka projektipäällikön osaaminen olisi huipputasoa, saattaa projektin omistava linjaorganisaatio olla strategisilta kyvyiltään rajoittunut riittävän tehokkaaseen projektitoiminnan tukemiseen. Tämä näkyy usein projektin omistajuuden ja ohjausryhmätyön rajuina laatutason vaihteluina. Tuntuu siltä, ettei vieläkään ymmärretä projektin omistajan ja ohjausryhmien vastuuta projektin onnistumisessa ja businesshyötyjen saavuttamisessa. Ohjausryhmien jäsenten henkilökohtaiset vastuut jäävät usein sopimatta kokonaan.

Toinen, mikä usein ”mättää” on projekteihin liittyvä johtoryhmätyö eli projektisalkunhallinta. Projekteja käynnistetään ilman riittävää tuotto/riskianalyysiä ja projektipäällikön osaamisen & työedellytysten varmistamista. Usein myös resursoinnin onnistumisen varmistaminen jää tekemättä. Myös nopeiden muutostilanteiden yhteydessä strategisen päätöksenteon hitaus ja poukkoileva toimintatapa aiheuttavat usein vakavia viiveitä ja muita ongelmia projektille.

 

2. Vääränlainen ketteryys tai ketteryyden puute

Usein ketterät työmenetelmät ovat projektin toteutuksessa määräävässä roolissa, jopa niin että koko projektikehyksen tarpeellisuus ja projektipäällikön rooli kyseenalaistetaan. Tähän antaa oman mausteensa myös työmenetelmien ”oikeaoppisuuden” yliarvostaminen, joskus projektin riskitason nousun kustannuksella. Kuitenkaan hyvin ja ketterästi johdetussa projektissa ketterät menetelmät eivät muodosta minkäänlaista ristiriitaa tehokkaan projektijohtamisen kanssa. Monessa onnistuneessa projektissa osa toteutuksesta tehdään ketterillä ja osa perinteisillä menetelmillä ilman konflikteja. Ketterät menetelmät ovat haastavampia linjajohdolle (ohjausryhmä, omistaja, salkunhallinta) kuin projektinjohdolle.

Ketterään projektijohtamiseen kuuluu johtamistyyliin liittyviä vaatimuksia, kuten turhan byrokratian poistaminen sekä tehokas projektin ”scopen” ja businesshyötyjen hallinta. Pedanttinen ja ylikontrolloiva, "perinteistä tyyliä käyttävä" projektipäällikkö haluaa joskus vetää projektinsa pienimmätkin yksityiskohdat ”by the book”, jolloin liiallinen ja turha byrokratia ylikuormittaa ja vie energiaa tiimiltä sekä vaikeuttaa asioiden priorisointia.

 

3. Projektijohtamiseen liittyvä osaaminen

On yleisesti tiedossa, että projektien ja hankkeiden johtotehtävissä toimivilta puuttuu usein tarvittava projektipuolen perusosaaminen. Projektipäälliköiksi ja hankejohtajiksi edetään yleensä teknisen osaamisen ja työkokemuksen kehittymisen kautta, mutta varsinaista projektinjohtamisen valmennusta tällainen huippuammattilainen on saanut uransa aikana usein erittäin vähän suhteessa muuhun tekniseen tai substanssiosaamiseen liittyvään koulutukseen (tutkimusten mukaan joskus jopa vain 1 %). Projektipäällikkö toimii usein hänelle itselleen tyypillisellä tavalla - usein sellaisella, joka on joskus aiemminkin toiminut, tosin jossain toisenlaisessa projektissa tai hankkeessa. Tästä johtuen tulee usein tilanteita, joissa joku projektin kannalta kriittinenkin asia saattaa jäädä puutteellisesti johdetuksi tai hallituksi. Näitä kipupisteitä ovat usein projektin scopen hallinta, riskien hallinta, resursoinnin ja osaamisen hallinta sekä hyvin usein sidosryhmien hallinta ja viestintä heille.

Pertti Olamaa


Kirjoittajalla on yli 35 vuoden kokemus vaativista johto- ja projektinhallinnantehtävistä usealta eri toimialalta. Strategisten kyvykkyyksien sekä liiketoiminnan ja prosessien kehitys ovat hänen ydinosaamisalueitaan. Pertillä on ollut aktiivinen rooli projektijohtamisen koulutusohjelmamme Project Championin kehittämisessä. Pertti myös kouluttaa kyseisessä ohjelmassa

Suositut tekstit