Ensimmäinen projektini, vuosi 1995 Nokia Telecommunications

Sanotaan, ettei projektipäälliköksi synnytä, vaan toimeen ajaudutaan. Ehkä näin on, tai sitten ei. Siivoilin laatikoita, ja mitä löytyikään! Kesä 1995, ensimmäisen projektini projektipäiväkirja printattuna. Tämän jälkeen en olekaan projektipäiväkirjaa pitänyt – vaikka syytä olisi. Voi sitä nostalgiaa, kun lueskelin 11 sivuista viikkotasolla antaumuksella ja rehellisesti kirjoitettua päiväkirjaa.

Seuraavassa otteita NCS/MSG:n koulutuksen palautejärjestelmän kehittäminen -projektista. Pahoittelen lyhenteiden käyttöä, niiltä oli vaikea välttyä (hyvin yleistä ”Nokia kieltä”). Kokosin otteita päiväkirjasta sensuroimatta mutta tiivistäen. Henkilöiden nimiä olen joko poistanut, muuttanut tai käyttänyt luvan kanssa. Huomattavaa, että tämä oli ensimmäinen projektini ja kyseessä oli kesätyö. Hyvät naurut sain tätä lukiessani (huomatkaa mm. ”varovainen” aloitus ja kouluttajien pyydystäminen), niin paatoksella vedin ekan projektini. Aikaa tästä on 26 vuotta 😊

Kesäkuu 1995 vko 22

Työni alkoi 1.6.95 torstaina. Päivä kului valtavaa perehdyttämismappi pinoa lukiessa. Perjantaina ”yritin” jo aloitella työtehtävääni tutustumalla esimieheni jättämään materiaaliin ja valtavaan palautelomakemappiin. Varovaisesti aloitin tekemään nykytilan kuvausta, jotta koulutusosaston toiminta kokonaisuudessaan selkenisi pikkuhiljaa. Aamupäivällä oli klo 10.00 HVT36:ssa VAX1 luento, joten pääsin heti verestämään vanhoja (vuodelta 1991) Vaxin taitojani.

Vko 23

Viikko alkoi aurinkoisessa merkeissä Techran (koulutusosaston henkilöstöä) ryhmän viettäessä päivän Kangasalla koulutusasioiden merkeissä tarjoten hyvän tilaisuuden tutustua Nokian koulutusosaston henkilöstöön.

Keskiviikkona sain tehtäväksi tehdä jälkikäteen suoritettavan arviointikyselyn Ohlo-koulutuksesta, joka oli 3 päivän koulutus suunnittelijoille. Saamieni pohjatietojen perusteella suunnittelin palautelomaketta. Torstai kuluikin lomakkeen parissa ja ohlo-kouluttajia pyydystettäessä, sillä lomake oli saatava pian valmiiksi ja lähetettyä vastaajille.  Aloittelin myös benchmarkkausta eri tahojen kanssa asentamalla Odin-yhtiön tekemän palautteen analysointiin tarkoitetun ohjelman koneelleni tutustumista varten.

Perjantaina pohdimme palaverissa Riitan ja Annukan kanssa eri mahdollisuuksia pyytää palautetta, järjestelmän tavoitteita, lomakesuunnittelua ja jälkikäteen suoritettavaa arviointia. Kävimme läpi myös nykytilaa, jonka olin jo ehtinyt kartoittamaan. Lopuksi sovimme jatkotoimenpiteistä ja määrittelimme tarkemmin tehtäviäni ja tavoitetta.

Vko 24

Soitin Jyväskylään Odin-yhtiöön. Ohjelmasta oli tulossa Windows-versio, jolloin käyttis on huomattavasti parempi verrattuna dos-versioon.  Sain myös listaa tyytyväisistä käyttäjistä, joista yksi oli VHKK (Valtionhallinnon kehittämiskeskus). VHKK:lla oli käyty esittelemässä myös toista Access-tietokantaohjelmistolla tehtyä palautejärjestelmää. Ohjelmisto oli suunniteltu sairaalamaailmaan, jossa potilaat antavat suoraan tietokoneelle palautetta. VHKK:lla on tarkoitus verrata Access-sovellusta ja Odin-ohjelmaa ja katsoa kumpi soveltuu heidän tarkoitukseensa. VHKK:lla oltiin erityisesti kiinnostuneita NTC:n palautejärjestelmän kehittämisestä, sillä heillä oli vastaava suunnitteluprojekti meneillään, joten ehdottivat yhteistyötä.

Tiistaina lomake oli lopulta valmis ja laitoin sen 112 henkilölle jakeluun. Keskiviikkona kokosin jo muutamia kyselyyn tulleita vastauksia. Aloitin samalla ”uhkakirjeiden” lähettämisen, sillä kyseessä oli ensimmäinen jälkikäteen tehtävä kysely, joten vastauksista olisi todella suuri apu. Olen tehnyt ajan salliessa palautelomakkeeseen liittyvää tutkimustyötä. Soitin mm. Jyväskylän yliopiston kasvatustieteiden laitokselle, Riitta H:lle, joka on perehtynyt syvällisemmin palautteen antoon. H painotti palautetta, jota ei kerätä välittömästi koulutuksen jälkeen (koulutettaville on jätettävä aikaa sisäistää opittua).

Olen käynyt läpi Nokian yksiköitä saadakseni kuvaa millaista palautetta missäkin kerätään. Sain koekäyttöön SWP:ssä Accessilla luodun palautelomakkeen. Aloitin tekemään projektin aikataulua Excelillä (voi onnetonta!). Kyllähän se onnistui, mutta ei ole hääppöinen. Sitten kuulin, että olisi kyllä ollut projektien seurantaan ja aikataulujen tekemiseen oma ohjelma, MS-Project. Mika tuli asentamaan minulla Wordin suomenkielisen oikoluvun ja Accessin yms. mukavaa ja työtä helpottavaa. Huom. Olikohan tämä samainen Mika, josta sittemmin tuli aviomieheni 😊 Tuolloin Hatanpäällä IM:ssä oli pari Mika nimistä.

Perjantai kului jälkikyselyn analysointiin, vastauksia oli tullut jo kivasti, kaikkineen 90! Kysely oli 2-sivuinen ja sisälsi vain sanallisia kysymyksiä, joten analysointi oli sen veroista. Ylitöiksi on mennyt (3,5 h).

Vko 25

Maanantaina lähdimme porukalla UPS:iin Tervetuloa NTC:lle tilaisuuteen. Sieltä kiidin vauhdilla Riitan kanssa Munkkiniemeen VHKK:lle palaveriin. Torstaina esittelin OHLO-kouluttajien palaverissa Hotelli Ilveksessä kyselyn tuloksia ja kävimme ne kohta kohdalta läpi korjausehdotuksineen. Edistystä!

Vko 26

Olen jatkanut yhteydenpitoa muihin yksiköihin (CS, MSG, SWP jne.). Perjantaina laitoin kouluttajille kyselyn arvosteluasteikosta. Enemmistö oli 1–5 asteikon kannalla. Joukossa oli poikkeuksiakin; 1–6 (seuraava valinta) ja naamataulut tuntuivat myös varteenotettavilta vaihtoehdoilta. Itse olen painottunut 1–6 asteikon kannalle, sillä en haluaisin ”en tiedä -vaihtoehtoa” mukaan.

Vko 27

Aloitin palautelomakkeiden suunnittelua. Olen saanut kartoitettua kouluttajilta mitä he haluavat palautteelta. Perjantaina olin Mäkkylässä SWP:n vieraana. Sari ja Jari esittelivät Access-sovellusta, jota olivat melkoisesti parannelleet. Samalla piipahdin UPS:ssa, jossa esiteltiin Lotus Notesille tehtyjä koulutussivuja.

Vko 28

Hiljainen viikko ja paljon yksinäistä puurtamista. Tiedän, että Valmetilla on Rautpohjassa jonkinlainen palautejärjestelmä koulutusta varten tehty Lotus Notesilla. Kunhan vain saisi jonkun henkilön kiinni, joka tietäisi asiasta.

Vko 29

Kesäloma-aika, todella hiljaista. Pitää keksiä tekemistä. Aloin suunnitella tietoiskuihin omaa palautelomaketta, sillä huomasin, että ne eroavat ratkaisevasti muista kursseista mm. pituudeltaan (1–2 h). Laitoin kyselyä tietoiskuja pitäville mitä he toivovat palautteelta. Luennoitsijoita on laskujeni mukaan 16. Olen kirjoitellut koko ajan lähdemateriaalista yhteenvetoa. Materiaalia on kertynyt valtava määrä, joten on helpompi saada arvioinnista ja kaikesta siihen liittyvästä kokonaiskuva selvemmin, kun on tehtynä jonkinlainen yhteenveto. Samalla on helpompi perustella tekemiäni palautelomakkeita, sillä jokaiseen kysymykseen löytyy selvät perustelut.

Vko 30

Tiistaina testasin tietoiskun palautelomaketta. Osallistujia paikalla yhdeksän (+ minä). Analysoin välittömästi lomakkeet Excelillä. Mitään yllättävää ei tullut; osallistujat eivät jaksa/viitsi/halua oikein täyttää lomakkeita, kun kyseessä on ”vain” tunnin mittainen tietoisku.

Vko 31

Palaveri Valimossa. Lomakkeet alkavat jo olla melko loppusuoralla, enää tuntuu olevan vain pientä hienosäätöä. Olen oppinut, että koskaan en saa valmiiksi lomaketta, joka tyydyttäisi kaikkia! Topin kanssa selvitettiin onnistuneeko palauteen siirtäminen WWW-sivulle siten, että koulutettavat täyttävät arvioinnin omalta paikaltaan ja tulokset menevät suoraan jonnekin tietokantaan, josta ne on helppo analysoida. VHKK:n yhteistyö palaveri Munkkiniemessä.

Vko 32

Maanantaina käänsin englanniksi tietoiskun palautelomakkeen ja kurssiarviointilomakkeen. Mary tarkisti vielä käännökset. Tiistaina aloitin kirjoitella loppuraporttia.

Perjantaina oli BSSOM-kurssi oululaisille. Mukaan osui yksi englanninkielinen, joten tuli testattua enkunkielinen versio. Lomake tuntuu toimivalta, sillä sanallisia kysymyksiä ei ole montaa. Kurssilaiset olivat vastanneet ihan kivasti, jopa niin kivasti, että keskeytin homman vasta noin 20.00 illalla. Vastauksia oli tullut 11, ja osallistujia oli 12. Valmetilta löytyi vihdoin kontakti. Palautelomake oli vasta kehittelyvaiheessa, toteutus Lotus Notesilla.

Vko 33

Tuukka auttoi alkuun Excelillä tehtävän palautelomakkeen analysointiin tarkoitetun pohjalomakkeen painikenappien tekemisessä. Kävin läpi BSS trainingin palautelomakkeet. Aikaa on mennyt Excel pohjaa tehdessä ja analysoidessa palautteita.

Vko 34

Loppuraportin kirjoittamista. Samoin työni oheistuotoksena tekemä tiivistelmä käyttämästäni oheismateriaalista oli saatava kuntoon. Kävin välillä Wolfissa jumpassa ja tulin takaisin tekemään loppuraportista uuden, korjaillun version ja jätin muiden pöydälle (2 h 34 min). Tiistaina oli loppupalaveri. Jakamani materiaali oli luettu ja kävimme läpi hieman jatkosuunnitelmia ja kertailtiin, miten projekti oli onnistunut. Kaikki, kesälomista huolimatta, oli ilmeisesti onnistunut yli odotusten. Lomakkeet tulee yleiseen käyttöön tarvikevarastoihin.

Seniorin kommentit muistelmiin ”Niin hightekkiä oltiin, että oksat pois😊 Tuo palautelomake oli itseasiassa hyvinkin pitkään käytössä ja niitä kopioitiin aina tarvikevarastoon saataville. ”

Kiitokset kaikille ”projektiin” osallistuneille, seniorilleni Annukka Vaaralle, Riitta Vänskälle, Kirstille, Markulle, Topille, Marylle, Tuukalle, Niinalle, Jarille ja kaikille muille mukaan lukien VHKK:n ja Valmetin edustajat!

Post Project Blues: miten palautua haastavasta projektista?

Fuente de Piedrassa, El Refugio Del Burrito

Olen työskennellyt viimeiset kuusi vuotta useissa eri yrityksissä ulkopuolisena projektipäällikkönä. Projektin päättyessä saattaa edessä olla täysin erilainen ympäristö, tutustuminen uusiin ihmisiin ja uuteen liiketoimintaan perehtyminen joko julkisella tai yksityisellä puolella - ilman organisaation totuttujen tapojen tuomaa painolastia. Projektin päättyessä tulee usein mietittyä, millaiset haasteet on seuraavana tulossa ja millaisessa ympäristössä. Uudet haasteet ja uuden oppiminen pitää motivaation korkealla.

Projektin jälkeistä palautumista en ole sen ihmeemmin aiemmin miettinyt, kunnes työnantaja järjesti FirstBeat mittauksen. Tämä tietenkin osui keskelle projektin kriittisimpiä hetkiä. Mittauksen tulokset eivät olleet kovin silmiä hiveleviä. Tämän projektin päätyttyä jäin miettimään palautumista projektien välillä. Miten palautua haastavasta projektista? Työnantajani tarjosi mahdollisuutta tehdä etätöitä, tai viettää lomaa, Fuengirolassa. Jonkin aikaa mielessäni oli pyörinyt yksi asia: aasit. En tiedä mistä tämä juurtui päähäni. Ratsastan enimmäkseen islannin hevosilla, jotka ovat ”pieniä ja pörröisiä”, joten olisikohan siitä juontunut. Googletin Fuengirolan ympäristöstä aasien ja hevosten rescue paikkoja, koska halusin tehdä vapaa-ajallani jotain hyödyllistä. Läheltä löytyikin paikka Alhaurin el Grandesta (noin 25 km Fuengirolasta), johon otin yhteyttä ja sovimme että talkoilemme siellä ajan minkä vietämme Fuengirolassa. Mikä olisikaan ollut parempi palautumiskeino kuin aasiterapia? Nollata edellinen projekti, käydä vielä mielessä läpi opitut asiat ja ottaa opiksi ja valmistautua seuraavaan aasien ja hevosten seurassa lämpimässä, aurinkoisessa ilmastossa.

Rosie

Viisi päivää kului nopeasti hevosten ja aasien parissa. Aamulla aikaisin herätys ja ruokkimaan hevoset ja aasit. Talkoiluun kuului pääsiäislauantaina järjestettävän festivaalin (lahjoitusten keräystä toiminnalle) valmisteluhommia, kuten aitausten maalausta, tarhojen siivousta, hevosten hoitamista yms. Välillä tehtiin töitäkin ja osallistuttiin palaveriin (kiitos etätyö mahdollisuuden).

Etätöissä, Andalucian Rescue Centressä (A.R.C.H.)

Hevosia on 12 ja aaseja neljä. Kaikki kaltoinkohdeltuja tai heitteille jätettyjä. Järkyttävä katsoa valokuvia huostaanotetuista eläimistä ennen ARCHiin (Andalucian Rescue Centre for Horses & Donkeys) tuloa. Ihminen osaa olla todella julma. ARCHissa hevoset ja aasit hoidetaan kuntoon ja niille etsitään hyvä uusi koti. Hevosia on viety mm. Ruotsiin ja Saksaan (vinkkinä jos jollain tarvetta upealle ratsulle, uutta kotia etsii usea koulutettu, kuntoon hoidettu hevonen). Kuvassa oleva syntymästään sokea aasi, Rosie, todennäköisesti viettänee ARCHissa loppuelämänsä, sillä hänestä pitää huolen toinen ”ei niin sosiaalinen” aasi (Eeyore), joten kahta on haastavampi saada eteenpäin.

Rosie

Jotta sain aaseista ”loman” aikana voimaa seuraavan vuoden ajaksi, kävimme vielä Fuente de Piedrassa, El Refugio Del Burritossa, jossa oli 86 aasia ja 26 muulia. Jostain syystä tätäkin paikkaa pitää britit, ei espanjalaiset, lahjoitusvaroin. Aasien ja hevosten huono kohtelu Espanjassa huolestutti niin paljon, että adoptoin kaksi aasia, Toton ja Alician. Aasit jäivät kuitenkin Espanjaan hyvään hoitoon. Toto (varsinainen veitikka!) jatkaa uraansa lasten parissa terapia aasina ja Alicia nautiskelee elostaan muutoin ja minä maksan kulut. Olisihan nuo mielellään tuonut Suomeenkin…

Fuente de Piedrassa, El Refugio Del Burrito

Palautumisesta en tiedä, sillä uusi ennen reissua alkanut projekti pyöri mielessä. Tosin parhaat ideat ja ajatukset tuleekin usein aivan muuta tehdessä, joten iltaisin tuli kyllä istuttua koneen äärellä.

Palautumisesta vielä sen verran, että työnantaja otti järeämmät menetelmät käyttöön. Meillä on nyt Moverestin FirstBeat Hyvinvointianalyysiin liittyvä verkkokurssi. Muistuttelevat joka viikko olemassa olostaan. Omasta kokemuksesta neuvona (Moverestin puolesta), että pitäkää huoli riittävästä unesta, juokaa vettä riittävästi ja nostakaa takapuoli riittävän usein työtuolista, vaikka kuinka olisitte työn imussa ja syökää säännöllisesti. Sillä pääsee pitkälle!

Tätä postausta kirjoittaessani, toimitusjohtajamme ehti jo ehdottamaan uutta FirstBeat kierrosta, joten palautumisen tärkeys ja ”nollaaminen” projektien välillä pysyy varmasti mielessä.

Julksaistu LinkedInissä 24.4.2019.

Projektin opittujen asioiden (Lessons Learned) koonti, hukkaan heitettyä aikaa?

Mulla päättyi vähän aikaa sitten melko vaativa, kuuden kuukauden mittainen projekti. Projektin ajan kokosin vanhasta tottumuksesta listaa opituista asioista, ja projektin päätyttyä kävin läpi aiempien vuosien mittaan eri projekteissa kokoamiani opittuja asioita. Tämä toki olisi kannattanut tehdä jo tämän edellisen haastavan projektin alkuvaiheessa, mutta parempi myöhään kuin ei milloinkaan.

Käydessäni läpi vanhoja dokuja jäin miettimään, kuka vastaa opittujen asioiden kokoamisesta? Miksi näitä kerätään? Miten? Millä työkalulla? Kenelle? Mitä hyötyä näiden keräämisestä on? Projektipäällikköhän tyypillisesti vastaa siitä, että näitä asioita kootaan mielellään koko projektin ajan, ei vain projektin päätyttyä. Jokaisen projektitiimin jäsenen velvollisuus on myös kirjata löydöksiään. Omissa projekteissani olen huomannut, etteivät projektitiimin jäsenet aina uskalla tuoda kokemuksiaan esiin. Joskus taas on ollut hyvinkin innokkaita tiimin jäseniä ja opittujen asioiden koosteesta on tullut pitkä. Koska toimin ulkopuolisena projektipäällikkönä, pääsen harvoin näkemään, miten koottuja oppeja hyödynnetään. Vain muutamassa tapauksessa olen toimittanut projektin päätyttyä kokoamani opitut asiat organisaation johdolle, sillä olen tiennyt, että asioihin reagoidaan ja niitä hyödynnetään jatkossa. Muutoin hyöty on jäänyt ainoastaan itselleni, uusissa projekteissa hyödynnettäväksi.

Miltei poikkeuksetta aiemmin kokoamani opitut asiat sisälsivät ainoastaan asian ja ehdotuksen, mitä sille voisi tehdä. Esimerkiksi:

1.      Eri sidosryhmien tehtävien tarkempi suunnittelu/aikatauluttaminen

Verkkopuolen henkilöt tulee ottaa jatkossa aiemmin mukaan - tai ainakin tiedottaa missä mennään, jotta he osaavat varautua ja arvioida milloin heidän panostaan tarvitaan.

2.      Projektin Kickoff pidettiin Hesassa kasvokkain. Todella hyvä ratkaisu, sillä osapuolista osa ei ollut tavannut aiemmin. Mukaan olisi kuitenkin voinut kutsua koko projektitiimin, muutama jäi puuttumaan.

Juuri päättyneen projektin puolivälissä tajusin, että ei riittänytkään se, että kirjattiin opittu asia ja mitä sille voitaisiin jatkossa tehdä. Niinpä lisäsin dokuun keskelle sarakkeen ”vaikutus” (opittu asia – vaikutus – miten kehittää). Alla yksi esimerkki projektin opituista asioista.

Nokiassa työskennellessäni projektien retrospectiveissä mulla oli tapana koota opitut asiat postit lapuilla seinälle alla olevan kuvan mukaisen rungon mukaisesti.

Tiimin jäsenet miettivät ensin (jolleivat olleet jo valmistautuneet sprintin aikana) itsekseen rauhassa sprintin aikana opittuja asioita, jonka jälkeen asiat laitettiin seinälle ja keskusteltiin avoimesti havainnoista. Erityisen hyvää retrospectivessä oli se, että asioihin reagoitiin nopeasti. Asioille nimettiin vastuuhenkilö ja sovittiin deadline, jolloin asiat etenivät nopeasti ja kehitystä tapahtui jo projektin aikana.

Useimmiten opittuja asioita kerätään vasta projektin jälkeen erillisessä tilaisuudessa, jolloin opitut asiat ovat hyödynnettävissä tulevissa projekteissa. Vaikka opittuja asioita kerättäisiinkin jo projektin ajan, niin toimenpiteitä ei välttämättä kohdisteta jo projektin aikana (usein kiireeseen vedoten). Hyvä kysymys on, kenelle jatkotoimenpiteet jäävät? Jonkun tulisi varmistaa, että palaute on kaikkien saatavilla ja tulokset jaetaan myös muille projekteille. Tätä tarkoitin kysymyksellä, onko tämä kaikki hukkaan heitettyä aikaa?

Mikäli yrityksessä on PMO, vastuu luonnollisesti kaatuu PMO:lle. Mikäli PMO:ta ei ole, on tilanne haastavampi ja jää projektipäällikön tai projektipäälliköiden vastuulle. Opitut asiat voidaan esimerkiksi jakaa muille esimerkiksi tähän tarkoitukseen luodun hakemiston tai tietokannan avulla, josta muut voivat käydä läpi muiden projektien koosteita. Käydessäni läpi omia vanhoja koosteita, huomasin että muutamat asiat toistuivat useissa projekteissa koska kyseessä oli eri organisaatioiden projekteja. Aina ei kaikkia aiemmin opittuja asioita tule huomioitua organisaation vaihtuessa eikä välttämättä voidakaan soveltaa. Joitain opittuja asioita voin kuitenkin hyödyntää uusissa projekteissa eri organisaatioissa, esimerkiksi em. sidosryhmäanalyysin tekoa ja kickoffin pitämistä kasvokkain.

Saavutettavat hyödyt vs. asioiden kokoamiseen käytetty aika?

Samojen asioiden uudelleen tekemisestä aiheutuu todennäköisemmin organisaatiolle enemmän tai vähemmin kustannuksia, mikäli aikaisemmista projekteista ei ole opittu, vaan samat asiat ja virheet tehdään aina uudelleen. Käymällä läpi aiempien projektien opittuja asioita mahdollisesti vältettäisiin aiemmat epäonnistumiset. Organisaatiossa voidaan hyödyntää opittujen asioiden tietokantaa esimerkiksi projektin aikatauluun, kustannuksiin ja sisältöön liittyvien asioiden keräämisessä, jolloin uusissa projekteissa voidaan välttää projektin sisällön (laajuuden) ja aikataulun muutoksia, sekä resurssien käyttöön liittyviä ongelmia. Lisäksi arvioita työmääristä ja aikatauluista voidaan tehdä entistä tarkemmin hyödyntämällä opittuja asioita aiemmin onnistuneista projekteista tai epäonnistumisista.

Mitä opin edellisestä projektista?

Opittujen asioiden kokoaminen projektitiimin kesken on tarpeellista kiireestä huolimatta projektin alkuvaiheesta lähtien. Aloitin opittujen asioiden kokoamisen itsekseni. Sittemmin mukaan tuli projektin kaksi muuta projektipäällikköä. Asioita käytiin läpi ainoastaan projektipäälliköiden kanssa. Projektin tiukkaan aikatauluun vedoten asioita ei käyty läpi projektipalavereissa. Ei siis näin. Oppeja kerätään koko tiimin voimin, kiire ei saa olla esteenä. Projektin lopussa kävimme kuitenkin kootut opit läpi projektin ohjausryhmän kesken, pariinkin kertaan. Hyöty? Ei sitten mitään, ei tälle projektille, sillä projekti oli jo ohi. Lopuksi sentään kävin PMO:n kanssa nämä läpi, ja pitkä kooste jäi PMO:n hyödynnettäväksi, joten toisaalta täysin turhaa työtä ei varmaankaan tehty.

Olisi mielenkiitoista kuulla, miten muut projektipäälliköt kokoavat opittuja asioita, missä muodossa ja miten, sekä miten näitä hyödynnetään projektin jälkeen. Onko näiden keräämiseen olemassa jotain helppoa työkalua? Miten hyödyntää koottuja asioita ketterästi myös jatkossa?

Kun emäntä päätti vaihtaa nuorempaan: ei vaihtanutkaan!

Järki (ja tunteet) voitti :-) Emäntä ostikin itelleen onnistuneen projektin päätteeksi ihka uuden vastaavan (vaihtoi sentään väriä) ja mä jäin perheen toisen teinin käyttöön, joka saa toukokuussa kortin. Kävi tuuria kerrakseen, jos niin voi katsoa...

Emännällä on valitettavasti uus projekti vapaa-ajallakin (ei saa näemmä niistä tarpeekseen töissä). Nyt se päätti laittaa mut myyntiin. Neljä ja puoli vuotta mä olen sitä luotettavasti kuskannut ja kiitokseksi vaihtaa mut nuorempaan. Aatelkaa nyt! Miltä susta tuntuis, jos sun emäntäs sanois, että vaihtaa sut nuorempaan? 28.7.2014 nähtiin ekan kerran ja emäntä tykästyi muhun heti ekalla silmäyksellä. On niillä aiemminkin ollut audeja, muttei mun kaltaista A3:sta jos saan ite sanoa. Mun onni oli, että silloinen emäntä sai mut myytyä naiselle. Naisen omistukseen toki haluaisin nytkin, mutta kyllä miespuolisetkin kelpaa, kunhan lupaavat pitää musta hyvää huolta.

Emännän ensikosketus uuteen autoon 28.7.2014

Emäntä on pessyt mut aina käsin tai sitten käyttänyt muualla käsin pestävä. Mun maalipinta on upean metallinhohto sininen (S9S9 Scuba sinen, metalliväri), joten sitä pitää vahata säännöllisesti, jotta kiilto säilyy.  Eikä mua saa harjata lumesta kuin hyvin pehmeällä harjalla (tummasta näkyy kuulemma naarmut paremmin kuin valkoisesta). Mä oon tosi tarkka ulkonäöstäni ja emäntä on onnekseni melkoinen perfektionisti😊

Emäntä teetti mulla kerran Ilefixissä täyshoidon. Pesivät moottorinkin, vahasivat kunnolla ja paikkasivat yhden kiven iskin etupellilltä. Vahattu mua onkin paljon. Mulla on ollut ja on yhä talvisin kitkarenkaat. Niistä emäntä ei halua enää luopua. Mä en tykkää yhtään, kun muut viskoo nastojaan toisten päälle rikkoen laseja tai jättäen konepeltiin jälkiä. Mun kitkat on vasta vuoden vanhat ja niillä pärjää hyvin sekä maalla että kaupungissa.

Nyt mut on taas puunattu joka paikasta, sisältä ja ulkoo. Tällä kertaa tosin siksi että aikoo myydä mut. Kyllä nyt on paikat kirkkaana, pääsin lämpöseen autotalliinkin. Yleensä isäntä pitää siellä oman autonsa, pitää sitä muka mua parempana varmaan. Antaa sen nyt luulla niin, vaikka me muut tiedetään, että mä olen paljon kauniimpi. Mulla on katoksessa oma hyvä paikka. 

Mä olen todella hyvä ajettava sekä pitkillä matkoilla, että kaupunkiajossa (vaikken mä kaupungilla kovin paljoa ajele). Hämeenlinnan reissut emäntä tekee isännän autolla. Sanoo, että se on turvallisempi pitkillä matkoilla ja jykevämpi rekkoja ohittaessa. Kiero emäntä vaan on, eikä me kerrota isännälle, että me säästellään mun kilometrejä 😉 Mä on tosi hyvä ohituksissa, mä ampasen todella sutjakkaasti muiden ohi kunhan painetaan kaasu pohjaan, oon todella ketterä ja nopea reagoimaan. Liikennevaloistakin lähtiessä jätän muut taakse miettiin joko ne valot vaihtui. Säästän bensaakin tuolla tavalla.

Koiraa mulla ei oo kuskattu, sitä kuskataan vaan isännän autolla. Hevosen karvoja on saattanut olla, kun emäntä on käynyt tallilla. Mä kyllä pidän puoleni, ettei mitään karvoja tai moskia ole lattioilla tai penkeillä.

Kuvan koira ei kuulu kauppaan (raukka väsähti auton pesusta)

Katsastettukin mut on taas tammikuussa, kun emäntä vihdoin muisti, että pitäs käydä näyttäytymässä katsastuskonttorillakin joskus. Eihän mussa mitään vikaa ollut. Setä vaan muistutti törppöä emäntää, että voisi tulla ajallaan katsastaan.

MINÄ, A3 Sportback Attraction Business 1,4 TFSI 92 kW S tronic

Mulla on hieno taustapeili! Se tummenee automaattisesti pimiällä, kun takana ajaa auto. Ei ota emännän silmiin auton valot. On kuulemma lisävarusteena. Ratti tietenkin on nahalla päällystetty, ei palele kylmällä kädet. Muutama kuva vielä sisältäkin (Nettiautossa on lisää, ne pitäisi vaan uusia nyt kun siivottu kunnolla sisältäkin). 

Kilometrejä on tullut 177424, mutta paljon on vielä ajeluita edessä. Jakopään ketjun emäntä vaihdatti Tammer Dieselissä, vaikkei siinä mitään vikaa lopulta ollutkaan, mutta vaihtoivatpahan varmuuden vuoksi. Kai se vaihto jossain vaiheessa olisi tullut eteen.

Emäntä pyytää musta 10500 euroa, voin sanoa, että halvalla menee. Ei yhtään aattele tunnearvoa, miten mä olen turvallisesti sitä kuskannut talleille, töihin ja vaikka minne. Voihan mun uusi omistaja olla vielä parempi, ja pitää musta vielä parempaa huolta. Eihän sitä koskaan tiedä 😊 

Vähän teknisiä tietojakin.

Kolmella omistajalla ollut erittäin hyvässä kunnossa pidetty suomiauto. Lisävarusteena automaattisesti himmentyvä taustapeili, Xenon plus -ajovalot, Led huomiovalot, vakionopeussäädin ja keskikyynärnoja.

Jakopään ketju vaihdettu tammikuu/2017.

Teho: 92 kW / 125 Hv

Huippunopeus: 203 km/h (ei ole testattu)

Henkilömäärä: 5

Ovien lkm: 5 (yhä 5, kuten kuvista näkyy)

Kulutus:
Kaupunki: 7.4 l/100km
Maantie: 4.8 l/100km
Yhdistetty: 5.8 l/100km

Omamassa: 1 385 kg

Kokonaismassa: 1 870 kg

Ja peruskamaa:

Ajonvakautusjärjestelmä

LED-ajovalot

Luistonestojärjestelmä

Lukkiutumattomat jarrut (ABS)

Mäkilähtöavustin (emäntä tykkää tästä kovasti)

Turvatyynyt

Varashälytin

Xenon-ajovalot

Ajotietokone

Ilmastointi: Automaattinen

Keskuslukitus

Lohkolämmitin / Moottorilämmitin

Ohjaustehostin

Penkinlämmittimet (toimii erinomaisesti)

Sisätilanpistoke

Sähkökäyttöiset ikkunat

Sähköpeilit

Vakionopeudensäädin

Mitä projektipäällikön tulee osata ja mikä on riittävää?

Toimiessani projektipäällikkönä olen usein miettinyt, miten syvällistä osaamista projektipäälliköltä odotetaan käyttöönotettavasta ratkaisusta. Mikä on riittävä ymmärrys käyttöönotettavasta sovelluksesta tai asiakkaan liiketoiminnasta? Entä tarvitaanko sovellusosaamista? Vai riittääkö erinomainen projektinhallinnan osaaminen ja projektityökalujen hallinta? Projektipäälliköitä on monenlaisia, on hallinnollisia ja ketteriä projektipäälliköitä, projektijohtajia ja meitä ”projektipäälliköitä” (on senioreita ja nuorempia, IT-, LVI- jne. projektipäälliköitä, lista on loputon kun katselee avoimia työpaikkoja). Olen kuullut väitteen, että hyvä projektipäällikkö pystyy hyppäämään mihin projektiin tahansa. Pitääkö tämä todellakin paikkansa? Väitän, että ei. Jonkintasoinen tekninen ja/tai liiketoiminnan ymmärrys tulee olla (jollet työskentele täysin hallinnollisena projektipäällikkönä), ainakin se auttaa ohjaamaan projektia oikeaan suuntaan ja vähentää stressiä projektin aikana.

Googletin taannoin projektipäällikön taidoista. Listat osaamisalueista olivat melko yksimielisiä, vain järjestys vaihteli. Kahden tärkeimmän joukossa usein vuorottelivat viestintä ja johtajuus. Tosin oli listoja, joissa viestintä ei päässyt edes viiden tärkeimmän joukkoon. Mielestäni viestintä on yksi tärkeimmistä taidoista mikä kehittyy oppimisen kautta projekti projektilta. Viestintää voi myös opiskella, kuten aikataulun hallintaakin, mikä oli kolmanneksi yleisimpänä osaamisen alueena. Tekniset taidot mainittiin, mutta näillä tarkoitettiin projektissa käytettäviä pätevyyksiä, kuten aikataulun hallintaa, budjetointia ja kustannusarviota yms.

Miten syvällisesti projektipäällikön tulisi ymmärrettävä asiakkaan liiketoimintaa esimerkiksi toiminnanohjausjärjestelmää käyttöönotettaessa? Entä projektinhallintasovelluksen käyttöönotossa ympäristöä, jossa sovellus otetaan käyttöön? Omat haasteensa tuo integraatiot, joita monesti tulee eteen isompien sovellusten käyttöönotoissa. Tuskin yksikään projektipäällikkö hallitsee kaikki mahdolliset integroitavat sovellukset, mutta hänen tulee hallita integraation perusperiaatteet. Lisäksi mielestäni projektipäälliköllä tulee olla ymmärrystä sekä liiketoiminnasta että teknologiasta. Mikäli projektitiimi, projektipäällikkö ja asiakas, eivät puhu yhteistä kieltä ja ymmärrä toisiaan, on projektin johtaminen varmasti haastavaa tai ainakin stressaavaa.

Projektipäälliköllä tulee siis olla kykyä omaksua nopeasti tarvittavat tekniset, liiketoiminnalliset ja tarvittaessa kulttuurilliset tiedot hypätessään projektista toiseen. Projektipäällikön työ on jatkuvaa oppimista. Olen oppinut todella paljon erilaisissa projekteissa projektitiimin jäseniltä. Vaikka toista samanlaista projektia ei ole tullut, niin aiemmista projekteista jää aina jotain mitä voi hyödyntää tulevissa projekteissa. Laskeskelin, miten monta sovellusta olenkaan oppinut toimiessani eri organisaatiossa projektipäällikkönä. Pelkästään projektinhallintasovelluksia on melkoinen määrä, esim. MyParm, Severa, Project-TOP, MS Project 2013, Project Online, ValueFrame, Planner, Jira, Worklist ja Trello.

Tekniset taidot eivät saa olla kriittinen tekijä projektin menestyksen kannalta. Hyvä projektipäällikkö osaa tasapainottaa teknisten taitojensa puutteen resursoimalla projektiin oikeita asiantuntijoita oikeaan aikaan sekä poistaa esteitä projektitiimin jäsenten tieltä. Tekninen osaaminen ei välttämättä ole siis pakollista. Omasta kokemuksestani voin sanoa, että siitä on hyötyä esimerkiksi oikeiden resurssien hankkimisessa, ongelmien ratkomisessa, viestinnässä sidosryhmille sekä projektin riskien määrittämisessä. Erityisen hyödylliseksi koen sen, että ymmärrän mistä asiantuntijat ja asiakas puhuvat. 

Tärkeintä mielestäni on, että projektipäälliköllä on riittävästi tietoa esittää oikeita kysymyksiä oikeaan aikaan ja ohjata projektitiimiä kohti onnistunutta lopputuotosta. Mikäli itseltäni ei löydy tarvittavaa osaamista, se tietää uuden opiskelua. Kuten aiemmin totesin, projektipäällikön työ on jatkuvaa oppimista. Oli kyse IT-, talon- tai sillanrakennusprojektista, lyhenteiltä ja erikoistermeiltä ei voi välttyä. Yksi tärkeimmistä taidoista on osata tasapainotella sopivalla tasolla johtamisen ja asiantuntijuuden (sis. liiketoiminta/sovellus/teknologia) välillä. Tärkeää on ymmärtää riittävästi, jotta voi keskustella tiimin ja sidosryhmien (erityisesti asiakkaan) kanssa.

Projektipäällikön osaamisessa nousi esiin myös neuvottelu- ja organisointitaidot sekä ongelmien ratkaiseminen. Ongelmien ratkaisemiseen liittyy mm. riskienhallinta, sillä esteiden poistaminen on projektipäällikön olennainen taito. Kun riskejä ja mahdollisuuksia tunnistetaan ja niille löydetään ratkaisut ennen niiden syntymistä, on projektin onnistuminen varmempaa. Mikäli riski on päässyt jo realisoitumaan, ja ongelma syntynyt, silloin keskeinen taito on osata kysyä oikeat kysymykset ongelman ratkaisemiseksi.

Neuvottelu- ja organisointitaitoja tarvitaan, kun neuvotellaan resursseista, budjetista, aikataulusta, laajuudesta ja monista muista asioista. Hyvät neuvottelutaidot omaava projektipäällikkö kykenee ratkaisemaan konflikteja löytämällä win-win-lopputuloksen.

Yhteenvetona seitsemän mielestäni tärkeintä osa-aluetta, joissa projektipäälliköltä vaaditaan osaamista:

• Johtajuus (projektin, projektitiimin ja sidosryhmien hallinta, taito tulla toimeen erilaisten ihmisten kanssa, ihmisten johtaminen) 
• Suunnittelu (aikataulun-, laajuuden- ja tehtävienhallinta, organisointi- ja delegointikyky, priorisointi)
• Viestintä (ymmärtää eri sidosryhmien viestintätarpeet)
• Ongelmanratkaisutaidot (taito ennakoida ja puuttua ongelmiin ajoissa, sekä hallita eri ongelmanratkaisu menetelmiä)
• Päätöksentekokyky (kyky punnita eri vaihtoehdot, löytää ratkaisut)
• Riskienhallinta (riskien tunnistaminen ja ennalta ehkäiseminen)
• Tekniset taidot (ymmärrys asiakkaan tarpeesta/projektin lopputuotoksesta, tekninen osaaminen sekä yhteinen kieli. Mitä isompi projekti, tulee projektipäälliköllä olla tietoa ja taitoa, jolla taataan tiimiin tarvittava osaaminen oikeaan aikaan hukkaamatta resurssien aikaa turhaan)

Kukin edellä mainituista seitsemästä kohdasta ansaitsisi oman postauksensa. Listasin kyseiset osa-alueet oman kokemukseni perusteella, joten osa-alueita ja niiden prioriteettijärjestystä saa toki haastaa. Järjestys vaihtelee varmasti projektista riippuen, joten yhtä oikeaa listaa on mahdoton koota. Lisäksi kokoamani lista on lähinnä IT-projektien näkökulmasta. Mikäli kyseessä olisi esim. ison liikekeskuksen rakentaminen, nostaisin tekniset taidot ensimmäiseksi. 

Mitkä omasta mielestäsi ovat seitsemän tärkeintä projektipäällikön osaamisen aluetta? Mikä on haastavin osa-alue osaamisen kannalta?

Hyödyllisiä linkkejä:

Mielenkiintoinen postaus hyvinvoinnista (hyvinvoinnin neljä “kivijalkaa” projektipäällikön näkökulmasta)

How to increase your wellbeing as a project manager

Basic Skills for Project Managers

Pohdintaa vaatimusmäärittelyn työstämisestä ja sen haasteista

Teen paljon vaatimusmäärittelyä osana kilpailutuksia hyvinkin laidasta laitaan erilaisten sovellusten (esimerkiksi ERP) valinnasta IT-palveluiden ulkoistamiseen tai konesalitoimittajan valintaan. Yhteinen haaste näille kaikille on ollut kaivaa esiin asiakkaan todellinen tarve, mikä on monesti asiakkaalta vielä hämärän peitossa. Jokaisen määrittelyn osalta olen joutunut pohtimaan samaa ikuisuusasiaa: mikä on riittävää asiakkaalle (kuten myös toimittajalle vaatimusmäärittelyn osalta) kilpailutusta tehdessä? Kilpailutukset ovat olleet melko suoraviivaisia käyttöönottoja, toimittajan kilpailutusta ja sopivimman toimittajan valintaa. Ei siis niinkään ketteriä sovellusprojekteja, joissa on aivan omat haasteensa.

Aivan ensimmäiseksi, ennen vaatimusmäärittelyn tekoa, tulee selvittää nykytila. Harvemmin on saatavilla kuvauksia nykytilanteesta saatikka prosessinomaisia kuvauksia toiminnasta. Nykyisen menetelmän tai prosessien kuvaaminen visuaalisesti auttaa muodostamaan käsityksen ratkaistavasta ongelmasta. Tämän pohjalta on helpompi määritellä mikä on tavoite tai visio. Esimerkiksi ERP-järjestelmät ovat laajoja kokonaisuuksia, jolloin helposti saattaa iskeä vauhtisokeus ja kaikki tuntuu tärkeältä ja hyödylliseltä.

Nykytilan kuvaus toimii myös vertailukohtana, kun mitataan uuden järjestelmän käyttöönoton tuomia hyötyjä. Monesti uutta työkalua hankittaessa joudutaan miettimään omia prosesseja ja työmenetelmiä uusiksi. Uuden työkalun käyttöönotto tuo aina jotain muutosta totuttuihin toimintatapoihin. Tavoite tai visio tulee pitää kirkkaana mielessä, sillä muutos itsessään on jo suuri. Kaikkea ei kannata haalia kerrallaan. Toiveiden tynnyri on purettava selkokielisiksi vaatimuksiksi ja tehtävä selkeät rajaukset, jotka sekä asiakas että toimittajat ymmärtävät. Jokainen asiakas on uniikki, joten vaatimusmäärittelyä et voi kopioida joltain toiselta. Et vaikka olisit hankkimassa ERP-järjestelmää samoin kuin naapuriyritys.

Kokosin muutamia seikkoja, joihin olen omissa vaatimusmäärittelyissä ja käyttöönottoprojekteissa törmännyt ja joihin mielestäni tulee erityisesti panostaa. Tarjouspyyntövaiheessa ei kannata säästää aikaa ja vaivaa. Selkeä määrittely, tapahtui projekti sitten ketterästi tai vesiputousmallilla, maksaa itsensä varmasti käyttöönottovaiheessa takaisin. Tärkeää on osallistaa määrittelyyn kaikki tarvittavat osapuolet. Mitä isommasta hankkeesta ja organisaatiosta on kyse, sidosryhmien määrä saattaa nousta yllättävän suureksi. Keitä muutos koskee? Ketkä kaikki tulevat käyttämään uutta järjestelmää? Ketkä vaikuttavat välillisesti työkaluun? Tai ketkä käyttävät ulkoistettuja IT-palveluita? Millaisia tarpeita heillä kullakin on? Haastatteluihin eri osapuolten kanssa tulee varata riittävästi aikaa. Tämä takaa varmasti onnistuneemman käyttöönoton ja tyytyväisemmät loppukäyttäjät. Asiakas tietää ja määrittelee omat tarpeensa, vaatimusmäärittelyä ei voi ulkoistaa täysin organisaation ulkopuoliselle. Asiakkaan osallistuminen vaatimusmäärittelyyn riittävin resurssein on onnistumisen kannalta ehdoton edellytys!

Vinkkejä vaatimusmäärittelyn tekemiseen

1. Mieti keitä hanke koskee, keiden tulee osallistua vaatimusmäärittelyyn?  Tee pienimuotoinen sidosryhmäanalyysi keitä uuden järjestelmän hankinta koskettaa. Voit yllättyä, miten moneen tahoon pienikin hankinta saattaa vaikuttaa.

2. Luokittele vaatimukset hierakisesti. Näin pystytään keskittymään jokaiseen kokonaisuuteen mahdollisimman kattavasti. Vaatimusmäärittelyä tehtäessä vaatimukset tulee luokitella toiminnallisiin ryhmiin. Esimerkiksi ERP-järjestelmän määrittelyssä tuotetiedon hallinta, asiakkuuden hallinta, varastonhallinta, ostotilaustenhallinta jne.

3. Identifioi vaatimukset. Vaatimukset, joita ei ole numeroitu, tekee jäljitettävyydestä suorastaan painajaisen. Vaatimuksiin on tällöin helppo viitata jälkeenpäin niitä läpikäytäessä.

4. Määrittele lyhenteet ja termit. Hyvä tapa on kuvata vaatimusmäärittelyn ensimmäisessä luvussa kaikki käytetyt termit ja lyhenteet.

5. Imperatiivien käyttö. Käytä ainoastaan yhtä tapaa johdonmukaisesti. Esimerkiksi ”Asiakkaan yhteyshenkilön tulee saada hälytykset vikatilanteista.”, ei ”Asiakkaan tulisi saada…” tai ” Järjestelmän on hälytettävä tiettyjen asetettujen hälytysrajojen lauetessa”.

6. Varmista, että jokainen vaatimus on testattavissa tai varmennettavissa. Toki palveluita määritettäessä laadullisten vaatimusten mittaaminen saattaa olla haasteellista, muttei mahdotonta. Esimerkiksi ”Palveluntarjoajalla on riittävän teknisen osaamisen omaava lähitukihenkilö, jolla on myös ymmärrystä asiakkaan liiketoiminnasta ja IT-tarpeista.” Mikä on riittävää? Mitä teknistä osaamista tarvitaan? Mitä ymmärrystä ja millä tasolla? Pelkkä ylätason vaatimus ei riitä, toimittajan on todistettava vaatimuksen täyttyminen. Osaamista voidaan arvioida esim. vaatimalla näyttöä osaamisesta, määrittelemällä tekninen osaaminen mahdollisimman tarkoin, kuvaamalla vaadittava liiketoimintaosaaminen tarkemmin, CV:n avulla ja kyselemällä referensseiltä. Itse soitan mielelläni myös sellaisille referensseille, joita toimittaja ei ole tarjouksessaan luetellut. Tällä tavoin olen saanut erittäin arvokasta tietoa ja hyviä vinkkejä asiakkaiden näkökulmasta kilpailutuksia tehdessäni.

7. Vaatimus tulee olla lyhyt, ytimekäs ja yksiselitteinen. Useimmiten vaatimusta joudutaan kuvaamaan tarkemmin. Vaatimukset voidaan otsikoida, jolloin otsikko on ytimekäs ja vaatimusta tarkennetaan kuvauksessa. Esimerkiksi ”Palvelupyyntöjen hallintaprosessi. Toimittajalla tulee olla asiakkaiden palvelupyyntöjen hallintaprosessi, joka kattaa häiriöiden (incident) lisäksi asiakkaiden avainhenkilöiden neuvontapalvelun sekä toimeksiantojen vastaanoton ja käsittelyn (customer request management).”  Ensin siis selkeä, ytimekäs otsikko, mitä vaaditaan (”Palvelupyyntöjen hallintaprosessi”). Vaatimuksessa tarkennetaan mitä hallintaprosessilta odotetaan.

8. Muista, että vaatimus sisältää vain yhden vaatimuksen! Ei näin: ”Palvelun tulee kattaa häiriöhallinnan ja korjaukset sekä muutostenhallinnan ja toimittaja vastaa ko. palveluiden kuvausten ja määrittelyiden tuottamisesta.” vaan häiriöhallinta ja muutostenhallinta omina vaatimuksinaan. Häiriönhallinnan kriittisyydestä riippuen tätä voi tarvittaessa pilkkoa useammaksikin vaatimukseksi jatkuvuuteen ja vikasietoisuuteen liittyvän luokittelun alle.

9. Älä käytä epämääräisiä tai epäselviä sanoja. Näitä on yleensä adverbit, adjektiivit ja verbit, joilla ei ole konkreettista kvantitatiivista merkitystä. Hyvä vaatimus ei sisällä seuraavia sanoja: tehokas, tehostaa, nopea, nopeasti, nopeuttaa, helppo, luotettava, normaali, käyttäjäystävällinen, vähän, jne.

10. Käytä kielteisiä vaatimuksia todella harkiten.  Käytä negatiivista vaatimusta vain korostaaksesi jonkin vaarallisen tai haitallisen toiminnan kieltämiseksi. Älä käytä negatiivista vaatimusta, mikäli se voidaan ilmaista positiivisesti! Esimerkki funktionaalisesta vaatimuksesta: ”Käyttäjiä, joilla on kolme tai useampia käyttäjätunnuksia, ei saa siirtää.” Muunnettuna positiiviseksi vaatimukseksi: ”Järjestelmä siirtää vain ne käyttäjät, joilla on vähemmän kuin kolme käyttäjätunnusta.”

11. Vältä käyttämästä / merkkiä. Merkin tulkinta on epäselvää. Tarkoittaako se, ”ja”, ”tai”, ”yksi jostain” tai niiden yhdistelmää (ja / tai)? Kukin tulkitsee sen omalla tavallaan.

12. Käy vaatimusmäärittely vielä lopuksi kaikkien asianomaisten kanssa läpi. Varmista, että vaatimukset ovat ymmärrettäviä ja kaikki osapuolet ymmärtävät ne samalla tavalla.

13. Mikään vaatimusmäärittely ei ole täydellinen. Valmistaudu ja varaudu muutoksiin ja tarkentuviin vaatimuksiin. Toimittajan asiantuntijat tuntevat työkalut paremmin kuin myyntihenkilöstö ja osaavat ohjata työkalua konfiguroitaessa oikeaan suuntaan.

Pelkän vaatimusmäärittelyn onnistunut koonti ei välttämättä takaa käyttöönottoprojektin onnistumista, mutta takaa hyvän pohjan sopimusneuvotteluille.

Millainen on hyvä projektipäällikkö? Miten voin kehittyä projektipäällikkönä?

Kesäloman aikana pihaprojekteja toteutettaessa tuli mietittyä projektipäällikön osaamista ja miten sitä mitataan monenlaisilla sertifikaateilla ja testeillä. Miten oikeastaan mitataan projektipäällikön onnistumista roolissaan erilaisissa projekteissa? Millainen on ”hyvä projektipäällikkö”? Miten voin kehittyä projektipäällikkönä? Mitä esimerkiksi PRINCE2 tai IPMA C sertifikaatit kertovat siitä, miten projektipäällikkö toimii tai tulee toimeen projektitiimissä olevien erilaisten ihmisten kanssa, saatikka projektin eri sidosryhmien jäsenten? Onko hyvä projektipäällikkö sellainen, joka osaa ulkoa PERT-menetelmän kaavan tai soveltaa FMEA -tekniikkaa?

Projektipäällikön rooli on muuttunut vuosien saatossa huimasti ja yhä muuttuu. Osaaminen ei enää ole ainoastaan aikataulun, kustannusten ja resurssien laskemista kaavojen avulla (moni on varmaan lukenut Pelinin Projektihallinnan käsikirjan). Toimiessani projektipäällikkönä sekä mentoroidessani projektipäälliköitä olen huomannut seuraavien taitojen olevan erittäin kriittisiä: 

1. Ihmisten johtaminen
2. Projektiviestintä
3. Tehtävienhallinta

Seuraavassa muutamia vinkkejä em. kolmeen alueeseen.

Ihmisten johtaminen

Projektien johtamisessa tulee pitää mielessä managementin ja leadershipin ero. Management pyrkii vakauteen ja ennustettavuuteen (tekemään asiat oikein) kun leadership pyrkii kehittämään toimintaa muutoksen kautta (tekemään oikeita asioita). Projektipäällikön rooli koostuu näiden kahden yhdistelmästä.

Projektipäällikön on johtamisellaan osattava motivoida ja sitouttaa tiimin jäsenet yhteisen tavoitteen saavuttamiseksi. Tämä tapahtuu esimerkiksi jakamalla tehtävät tasapuolisesti jäsenten osaaminen ja kokemus huomioiden, kuuntelemalla ja kunnioittamalla muita, ratkaisemalla ongelmia yhdessä (ei syyttämällä muita, tai hakemalla syyllistä), jakamalla ideoita, antamalla palautetta ja tutustumalla tiimin jäseniin yksilöinä. 

Projektipäällikkö on projektitiimissä myös fasilitaattorin ja mentorin roolissa. Fasilitaattorina hän varmistaa, että tiimissä on tarvittava osaaminen ja resurssit projektin eri vaiheissa. Mentorina hän rohkaisee tiimin jäseniä kehittämään osaamistaan ja jakamaan hiljaista tietoa tiimin jäsenten kesken myös yli tiimin rajojen. Ennen kaikkea projektipäällikön tulee luottaa tiimin jäseniin. Projektipäällikön tulee osoittaa luottamusta pitämällä sanansa, olemalla tavoitettavissa, olemalla rehellinen ja aktiivisesti tukemalla tiimin jäseniä tavoitteiden saavuttamisessa. Tiimin jäsenten luottamus ja motivaatio kasvavat yleensä, kun heille annetaan mahdollisuus laittaa taidot käytäntöön ja osoittaa osaamisensa. Projektipäällikön tulee kysyä itseltään, miten hyvin hän tuntee jokaisen tiimin jäsenen vahvuudet ja osaamisen, jotta tehtävien jakaminen onnistuu parhaimmalla mahdollisella tavalla.  Tämä valitettavan usein kaiken muun kiireen ohessa unohtuu.

IPMA Projektijohdon pätevyys määrittelee joukon johtajuuden käytösmalleja, joista seuraavassa muutama mielestäni erittäin tärkeä projektipäällikön taito:

• Delegoi SMART tyylillä (Specific, Measurable, Achievable, Realistic, Time-bound) tehtäviä ryhmän jäsenille, joilla on tarvittava tietotaito ja antaa heille toimintavapauden (luottamus).
• Innostaa, toiset työskentelevät mielellään hänen kanssaan (motivointi).
• Osaa palkita ja ryhtyä korjaaviin toimenpiteisiin ryhmän jäsenten hyväksymillä tavoilla (motivointi).
• Pysyy rauhallisena kriisin aikana, välttää paniikkia.
• Omaksuu johtamistyylin, joka on ominainen tietylle ryhmälle ja työtilanteelle, on avoin palautteelle.

The ”P” in PM

is as much about

“PEOPLE”

MANAGEMENT

as it about

“PROJECT”

MANAGEMENT
(Cornelius Fichtner)

Projektiviestintä

Projektiviestintä on taito, jota ei kovin hyvin opita lukemalla projektinhallinnan kirjoja, vaan kokemuksen kautta. Projektiviestinnän osalta yksi kriittinen tekijä on onnistunut kick-off projektin alkaessa. Kick-off tilaisuuden eteen kannattaa nähdä vaivaa, sillä onnistuessaan se edesauttaa projektin onnistumista ja tukee projektiviestintää. Projektitiimin jäsenten ja vähintään projektin kriittisimpien sidosryhmien tutustuttua kasvokkain toisiinsa, on viestintä projektin edetessä esimerkiksi Skypen välityksellä huomattavasti helpompaa. Projektiviestintään on saatavilla useita työkaluja. Sidosryhmien määrästä ja sijainnista riippuen tulisi heti projektin alkaessa sopia miten projektin aikana viestitään ja mitä viestintätyökalua käytetään. Tärkeää on pitää säännölliset projektitiimipalaverit. Palaverin tarkoitus ei suinkaan ole se, että projektipäällikkö yksistään käy läpi projektin tilanteen, vaan käydään yhdessä läpi jokaisen osalta mitä on tehty, mitä tullaan seuraavaksi tekemään ja mitä haasteita on ollut. Tiimipalaverissa on hyvä mahdollisuus jakaa hiljaista tietoa, joita projektitiimin jäsenillä on runsain määrin ja oppia toisilta.

Project Kick-off Meeting Agenda Template

Tehtävienhallinta

Tehtävienhallinta liittyy hyvin kiinteästi johtamiseen ja viestintään. Kesällä 16-vuotiaat teinimme muistuttivat viestinnän tärkeydestä. Tehtävät tulee kuvata täsmällisesti ja ymmärrettävästi. Tapanani oli poikien kuskatessa hiekka- ja multakuormia osoittaa paikka epämääräisesti termeillä tuonne, sinne, talon taakse tehostaen viestintää osoittamalla kädellä. Teinit kyllä uskalsivat kyseenalaistaa epämääräisen tehtävänannon ja vaativat tarkan tiedon, mihin täsmälleen kuorma tulee kipata. Tiimissä voi kuitenkin olla jäseniä, jotka eivät välttämättä uskalla kysyä. Projektipäällikön tuleekin muistaa varmistaa, että tehtävänannot on ymmärretty oikein.

Tehtäviä ei tehdä siiloissa, vaan tehtäviin tulisi kaikilla projektin jäsenillä olla reaaliaikainen näkyvyys eli mitä kukin tekee missäkin vaiheessa ja miten tehtävät riippuvat toisistaan. Hyvin usein käytetty Excel-dokumentti ei välttämättä ole kaikista toimivin työkalu isossa projektitiimissä. Usein koetaan, ettei työkalulla ole tehtävienhallinnassa niinkään merkitystä. Mielestäni sillä on hyvinkin ratkaiseva rooli projektin onnistumisen kannalta. Miten hallinnoida tehtäviä esimerkiksi monitoimittajaprojektissa jossa asiakaskin saattaa olla hajaantunut useampaan toimipisteeseen? 

Toimiva ja tarkoitukseen soveltuva tehtävienhallinta työkalu on suuri apu projektin tavoitteiden saavuttamiseksi. Tehtäviä tulee voida jakaa alitehtäviin ja niitä tulee voida kommentoida. Visuaalisuus on myös plussaa työkalulle. Joku tykkää käyttää Kanban menetelmää, joku tykkää nähdä tehtävät priorisoituina listana. Hyviä työkaluja on saatavilla paljon, esimerkiksi Agendium, Asana, eeedo, Jira, Trello, Yammer, Planner ja Todoist. Jokainen näistä varmasti päihittää projektipäällikön koneella, tai jossain verkon kulmalla, olevan Excel-dokumentin.

Miten voin kehittyä projektipäällikkönä?

Eräs hyvä keino kehittää projektipäällikön taitoja on mentorointi. Tehokas mentorointi auttaa parantamaan sekä projektinhallintaa että projektipäällikön käytännön taitoja ja osaamista. Hyvä mentori ei vain jaa neuvoja, vaan kuuntelee ja kysyy kysymyksiä, jotka auttavat mentoroitavaa löytämään ratkaisuja haasteisiin itse. Esimerkiksi projektien riskienhallintaa mentoroitaessa tarkoitus ei suinkaan ole, että mentori työstää valmiiksi riskianalyysin, vaan oman kokemuksen ja osaamisen pohjalta ohjaa analyysin tekemisessä. Mentorilla tulee olla laaja-alaista kokemusta erilaisista projekteista erilaisista ympäristöistä. Mentori antaa aloitteleville projektipäälliköille sellaista tietoa ja osaamista, mitä karttuu yleensä vain vuosien kokemuksella. Mentorointi onkin erinomainen tapa opastaa uusi tai junior tason projektipäällikkö tehtäviinsä.

Omia projektipäällikön taitojaan voi mitata projektin jälkeen tehtävällä kyselyllä, joka lähetetään projektitiimin jäsenille, ei vain asiakkaalle, kuten yleensä tehdään. Olen käyttänyt luomaani kysymyspatteristoa omissa projekteissani Webropolilla toteutettuna kyselynä. Kyselyn tulokset antavat hyvää pohjaa sille, mitä taitoja tulisi kehittää.