Skip to content

    20.04.2017 — lukuaika 2 minuuttia

    Projektikommunikoinnista konkursseihin

    Työura kun on jatkunut kohta jo 20 vuotta (huh!), valehtelisin, jos väittäisin, etten olisi ollut mukana epäonnistuneissakin projekteissa. Pienemmistä aikataulumyöhästymisistä järkyttäviin lomautuksia ja konkursseja aiheuttaneisiin mammuttiprojekteihin. Sen lisäksi olisin myös tyhmä, jos en olisi yrittänyt niistä mitään oppia.

    On toki monta toinen toistaan mahtavampia tapoja munia projekti jo lähtötilanteessa. Nyt ei kuitenkaan mennä niihin. Yllättävän moni omalle kohdalle osunut epäonnistunut projekti on kärsinyt samasta ongelmasta: liian vähäisestä tai huonosta kommunikoinnista asiakkaan kanssa. Olisiko kommunikoinnilla voitu vielä pelastaa jotain - tai olisiko edes ajauduttu ongelmiin, jos kommunikointi olisi hoidettu paremmin? Väitän että kommunikointi on projektinhallinnan ehkä se tärkein väline. Ja edelleen näissä DW/BI-projekteissa, jotka ovat aina olleet keskimääräistä IT-projektia iteratiivisempia, kommunikoinnin tärkeys vain korostuu.

    Rikkoutunut puhelin

    BI-miehen teesit asiakaskommunikoinnille projekteissa:

    • Älä valehtele tai kaunistele asioita. Jäät mistä tahansa valheesta kiinni ennemmin tai myöhemmin.
    • Kerro avoimesti, jos et osaa. Selvitä ja opettele, kerro asiakkaalle, että tästä harjoittelusta ei laskuteta.
    • Kerro rehellisesti tekemisistäsi virheistä ja ongelmista - kerro myös, että ne on jo korjattu.
    • Opi tuntemaan asiakas, ole epämuodollinen.
    • Älä koskaan aliarvioi asiakkaan teknistä osaamista. Kerro mieluummin enemmän kuin mitä asiakas ymmärtää. Älä myöskään yliarvioi omaa teknistä osaamistasi. Käytä aina tarvittaessa muita osaajia tässä apuna.
    • Jos ei ole ollut asiaa asiakkaalle pitkään aikaan, tee sitä vaikka tikusta. Änkeä lounaalle. Suosi puhelinta sähköpostin sijaan.

    Itse olen yrittänyt noita teesejä noudattaa viime vuosien aikana. Yksi ex-työkaveri tokaisi joku aika sitten: "Olet yhteyksissä asiakkaisiin enemmän kuin kukaan muu, jonka tunnen." Ei ollut ihan väärässä.

    Eikös yksi perimmäinen syy agilen paremmuudelle vesiputoukseen verrattuna ole juurikin se, että se pakottaa (parhaassa tapauksessa) asiakkaan mukaan jopa päivittäisiin scrumeihin?

    Jani Liimatta

    Jani on tehnyt Business Intelligencen ja tietovarastoinnin parissa töitä 15 vuotta. Häntä kiinnostaa erityisesti tietovarastoarkkitehtuurit sekä datan visualisointi aina konsultoinnista toteutukseen. Syvällinen tuntemus eri ERP-järjestelmistä sekä liiketoiminnan prosesseista luo tälle hyvän pohjan.

    Business Intelligence, agile, scrum