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ää.

Tehtävienhallinta projektin onnistumisen pullonkaula?

Projektien onnistumisen haasteena on usein resurssien- ja aikataulunhallinta. Harvoin syyksi mainitaan epäonnistunutta tehtävienhallintaa, vaikka tämä saattaa usein, ainakin osaltaan, olla syynä edellä mainittuihin ongelmiin. Olen projekteissani kuullut mm. seuraavanlaisia kommentteja: ”Liian monta projektia päällekkäin, ei pysty hoitamaan tehtäviä sovitussa ajassa” tai ”puhtaasti toive ajattelua, että projektityöt on mahdollista tehdä siinä sivussa päätyön lisäksi”. Nämä ovat hyvin tyypillisiä haasteita.

Muokkasin perinteisestä projektikolmiosta uuden version tehtävienhallinnan näkökulmasta. Keskelle lisäsin viestinnän, sillä projektiviestinnällä on keskeinen rooli myös tehtävienhallinnassa. Kuten edellä mainituista kommenteista käy ilmi, ongelmiin vaikuttaa useampi tekijä ja joskus on vaikea osoittaa mistä ongelmat alkoivat ja mikä on juurisyy. Onko se epäonnistunut resurssienhallinta, tehtävienhallinta vai onko vika jo projektin huonosti suunnitellussa aikataulussa? 
Miten tehtävienhallinnalla voidaan vaikuttaa projektin onnistumiseen? Keinoja on monia ja tässä postauksessa käyn läpi ainoastaan tehtävienhallintaa vaikkakin resurssien-, tehtävien- ja aikataulunhallinta liittyvät saumattomasti toisiinsa.

Ilman yhteistä työkalua projektin tehtävienhallinta ei onnistu. Mietitäänpä projektia, jossa on mukana useampi toimittaja, alihankkija, tiimin jäseniä useasta eri yksiköstä ja asiakas aktiivisessa roolissa tiimin jäsenenä. Paljonko aikaa meneekään hukkaan pyöritettäessä pitkää tehtävälistaa, mahdollisesti Excelin avulla, osapuolelta toiselle – vaikkakin se oli pilvessä kaikkien saatavilla? Miten voidaan varmistaa, että jokainen on selvillä mitä kunkin pitää tehdä missäkin vaiheessa?

Uutta projektia aloitettaessa jaetaan tehtävät aluksi yleensä karkealla tasolla. Tehtävät täsmentyvät projektin eri vaiheissa. Projektitiimiin saattaa tulla eri vaiheissa uusia jäseniä, joille myös jaetaan tehtäviä. Yksi projektin onnistumisen edellytys on, että jokainen tiimin jäsen ymmärtää omien tehtäviensä merkityksen kokonaisuuden kannalta sekä riippuvuudet tehtävien välillä. Projekteilta vaaditaan yhä enemmän ketteryyttä, sillä projektit harvemmin etenevät alkuperäisen suunnitelman mukaan. Kaikkia tehtäviä ei voida listata projektin alkuvaiheessa. Projektitiimin on kyettävä reagoimaan muutoksiin hyvinkin ketterästi. Tehtävienhallinnan kanssa kulkee rinnakkain viestintä ja kommunikointi. Ei riitä, että tehtävät kirjataan jonnekin, ne pitää olla kaikkien osapuolten saatavilla nopeasti, helppokäyttöisesti ja mielellään visuaalisesti.

Työkaluja tehtävien hallintaan löytyy runsain määrin. Olen käyttänyt muun muassa Exceliä, Powerpointtia, Lotus Notesia, Accept360:ia, Outlookin tehtäväluetteloa, Jiraa, Trelloa, Agendiumia, Todoist-sovellusta, Hubspotia, Project-TOPia, MS Projectia ja MS Planneria. Näistä mielestäni parhaimmat ovat ehdottomasti Agendium ja Trello. Kummallakin sovelluksella on oma käyttötarkoituksensa ja käyttö riippuu mihin tarkoitukseen ja miten laajaan käyttöön sovellusta tarvitaan. Kumpikin sovellus perustuu Kanban-menetelmään, joka on visuaalinen ja auttaa ennakoimaan ja hallinnoimaan tehtävien kulkua. Kanban-menetelmä näyttää nykytilanteen ja mahdolliset ongelmat nopealla silmäyksellä. Lisäksi säästän vaivaa, kun tehtäviä voi siirtää nopeasti työnkulun vaiheista toiseen vain hiirellä vetämällä.

Trellosta olen käyttänyt vain ilmaisversiota, ja se on riittänyt hyvin puutteineenkin omaan käyttöön pienemmässä ympäristössä (maks. 10 käyttäjää). Trellossa pidän erityisesti tehtävien visuaalisesta ilmeestä. Trello on myös samantien käyttövalmis. Aluksi tarvitsee vain luoda uusi Kanban-taulu ja työnkulku. Aikaa tähän menee noin minuutti, mikäli et jää pähkäilemään työnkulun vaiheita. Suurimpana puutteena pidän taas alitehtävien ja yhteenvetojen (raportointi) puuttumista.

Agendiumia olen käyttänyt omien tehtävien hallintaan ja asiakasprojekteissa. Agendium taipuu hyvin moneen tarkoitukseen. Uudessa versiossa raportointikin alkaa olla jo melko kattava. Mallipohjien luonti on erinomainen ominaisuus toistuville työlistoille ja nopeuttaa suuresti työskentelyä. Tehtävät saa näkyviin Kanban-tauluna, aikajanalla sekä perinteisenä listana.

Olen koonnut tähän vinkkejä projektin tehtävienhallintaan. Työkalun valintaan en ota kantaa. Kuten aiemmin mainitsin, niitä on saatavilla runsain määrin ja valinta riippuu mm. projektin koosta, projektitiimistä ja projektin sidosryhmistä. Sovelluksia, jotka tukevat Kanban-menetelmää, on paljon muitakin kuin suosimani Agendium ja Trello. Esimerkiksi Officen mukana tulevaa Planneria kehitetään koko ajan. Planner on kätevä ja helppokäyttöinen työkalu, joka tällä hetkellä toimii pienissä yksittäisissä projekteissa.

LeanKit ja TargetProcess ovat hyviä vaihtoehtoja vaativampaan käyttöön. Jira taipuu moneen, mikäli löytyy osaava henkilö konfiguroimaan sen tarpeita vastaavaksi.

Vinkkejä (projektin) tehtävienhallintaan

1. Tee karkea tehtäväjaottelu (WBS, Work Breakdown Structure) projektinhallintatyökaluun. Työkalulla ei ole niinkään väliä, kunhan saat realistisen arvion projektin aikataulusta tärkeimpien etappien osalta. Projektilla on aina aloituspäivä (kickoff) ja määräpäivä (deadline).
2. Valitse tehtävienhallintaan vain yksi menetelmä ja yksi työkalu – huolimatta siitä, että toimittaja haluaa käyttää omaansa, asiakas haluaa käyttää omaansa jne. Sopikaa YKSI yhteinen sovellus, jota käytätte projektin ajan!
3. Riko isoja tehtäväkokonaisuuksia pienempiin tehtäviin ja alitehtäviin projektin edetessä. Peukalosääntönä tehtävän maksikoolla voidaan pitää 40 tuntia.
4. Varmista, että tehtävät osoitetaan oikeille henkilöille. Huomioi tiimin jäsenten osaaminen ja muut työt.
5. Määrittele tehtäville määräpäivät (deadline). Vaikka se olisi vain arvio, annettu määräpäivä lisää todennäköisyyttä saada tehtävä tehdyksi ajallaan.

6. Mieti tehtävien deadlinet yhdessä tekijöiden kanssa. Tehtävän suorittajan tulee olla mukana arvioimassa tehtävän kestoa ja tehtävän mahdollisia riippuvuuksia. Tehtävän suorittajalla on yleensä kokemusta ja tietämystä arvioida kauanko tehtävän suorittamiseen kuluu aikaa. Huomioi myös muut työtehtävät, riippuvuudet muista tehtävistä ja toimittajien osuus ja vaikutukset tehtäviin. 
7. Priorisoi tehtävät selvästi ja ymmärrettävästi. Älä käytä ”ASAP” (as soon as possible) tai ”valmis ennen tehtävä X:ää” tai muita epämääräisiä ilmauksia. 
8. Tehtävän nimellä (otsikolla) on merkitystä. Otsikon tulee vastata tehtävän kuvausta ja antaa ensi silmäyksellä kuva mitä tehtävän odotetaan tekevän. Esimerkiksi tehtävä ”Kirjoita kampanjaan blogi” ei kerro juurikaan mitään. Sen sijaan esimerkiksi ”Kirjoita viikkopostaus kampanjan Y blogiin X” kertoo jo enemmän mitä pitää tehdä ja kenelle. Tehtäväkuvaus sisältää yksityiskohtaisempaa tietoa postauksen aiheesta, pituudesta yms. 
9. Visualisoi. Kanban-menetelmä on erinomainen, oli käytössä sähköinen työkalu tai seinätaulu PostIt lappuineen.

10. Käy tehtäviä läpi säännöllisesti. Aikataulut muuttuvat, uudelleen priorisointia tarvitaan ja henkilöt projektissa saattavat vaihtua. Projektin kriittisimmissä vaiheissa tehtäviä tulee käydä yhdessä useammin läpi. Esimerkiksi yliheitot, jotka usein tehdään viikonloppuisin varsinaisen työajan ulkopuolella, ovat haastavia. Tietoliikenneoperaattorin vaihto organisaatiossa vaatii melkoisesti erilaisia tehtäviä ennen yliheittoa, yliheiton aikana sekä yliheiton jälkeen, puhumattakaan yllättävistä jälkitöistä, joita usein ilmaantuu ja jotka vaativat useamman eri osapuolen panostusta. Näissä tapauksissa tehtävien jakaminen oikeille osapuolille on tapahduttava nopeasti ja kuittaamalla tehtävät tehdyksi varmistetaan, että kaikki tarvittava on tehty ajallaan.

Linkkejä:
Try Kanban Board - the #1 way to improve the efficiency of your team

Top 10 Tips for Effective Team TaskManagement

Projektin ohjausryhmä, pakollinen paha vai onnistumisen edellytys?

Terveisiä Projektipäiviltä!

Projektipäivillä oli jälleen paljon mielenkiintoisia seminaareja. Aikataulujen päällekkäisyyksien vuoksi olikin vaikea valita, mitä kulloinkin mennä kuuntelemaan. Yksi erityisen mieleenpainuva ja mukaansa tempaiseva oli Paula Aaltosen Ohjausryhmän six-packista.  

Esitys oli rakennettu mielenkiintoisesti six-packin muotoon ja herätti paljon kysymyksiä, esimerkiksi mistä ohjausryhmä vastaa, tai sen tulisi vastata? Tämä ei monestikaan ole selvää. Tyypillisesti ohjausryhmä vastaa projektikolmion mukaan kustannuksissa, aikataulussa ja laajuudessa pysymisestä. Menestyksekäs ohjausryhmän toiminta on paljon muutakin. Projektit eivät ole tyhjiössä ja useimmat projektit koskettavat jollain tavalla myös muita projekteja ja vaikuttavat useisiin sidosryhmiin. Ohjausryhmän vastuulla on koordinoida näitä tahoja, jotta esimerkiksi yhteisistä resursseista kilpailevat projektit saavat tarvittavat resurssinsa oikeaan aikaan. Ohjausryhmä on myös vastuussa eri sidosryhmien tuen ja yhteistyön varmistamisesta projektin onnistumiseksi sekä viestinnästä eri sidosryhmille.

Paulan ohjausryhmän six-packissa käytiin läpi kuvan mukaiset kuusi kohtaa, joista jokaisesta voisi rakentaa oman esityksensä. Käyn tässä lyhyesti läpi vain muutaman mielestäni tärkeimmän kohdan. Klikkaamalla kuvia saat ne suuremmaksi.

Ohjausryhmän six-pack

Asenne ja esimerkki 

”Ohjausryhmän näkyvyys – jalkautuminen projektiin ja linjaorganisaatioon”. Miten ohjausryhmä saadaan jalkautumaan projektiin ja linjaorganisaatioon? Eihän ohjausryhmän toiminta yleensä näy kuin projektipäällikölle, joka raportoi projektin kuulumisia ohjausryhmän kokouksissa. Olisiko mahdotonta ohjausryhmän osallistua projektin kick off tilaisuuteen? Olettaen, ettei kyseessä ole miltei 20 hengen ohjausryhmä, joihin silloin tällöin törmää. Millä muulla tavoin ohjausryhmä saadaan näkyvämmäksi projektitiimille ja muille sidosryhmille? Ohjausryhmän jäsenten tarkoitushan on edustaa omaa yksikköään ohjausryhmässä, jolloin hänen roolinaan on välittää ohjausryhmässä tehtyjä päätöksiä omalla tahollaan, sekä erityisesti tuoda edustamiensa henkilöiden tarpeita ja huolenaiheita esiin. Ohjausryhmän jäsenen rooli on paljolti vuorovaikutusta projektin sidosryhmien kanssa. Ohjausryhmä hyväksyy tai hylkää päätettäväksi tuodut muutokset. Päätökset tulee perustella ymmärrettävästi ja viestiä tarvittaville tahoille.

Rooli ja vastuu

Paulan esityksessä, rooli ja vastuut sivulla, silmiin pisti lause ”Ohjausryhmän tulee estää projekti- ja linjaorganisaatioiden väliset kilpailuasetelmat ja taata työrauha”. Miten ohjausryhmässä käytännössä voi taata työrauhan projektitiimille? Ohjausryhmän tulee vastata projektipäällikön kanssa viestinnästä projektin sidosryhmiin ja näin taata rauha projektitiimille. Monille on varmasti tuttua se, että loppukäyttäjä tai asiakas ottaa suoraan yhteyttä johonkin tiimin jäseneen ehdottaakseen pieniä muutoksia vaatimuksiin, tai lisättäväksi jotain uutta.

Projektipäällikkö ohjausryhmässä

Projektipäällikkö tyypillisesti esittelee ohjausryhmässä vakioagendan mukaiset asiat, eli projektin tilanteen (aikataulu, kustannukset, laajuus, riskien top 3) ja päätettävät asiat, esimerkiksi muutosehdotukset tai uudet vaatimukset. Projektipäällikkö toimii tavallisesti kokouksessa sihteerinä ilman päätöksentekovaltaa. Ajattelemisen aihetta herätti se, onko projektipäällikön oltava sihteeri kokouksessa, jossa hän esittelee oman projektinsa asioita ohjausryhmälle päätettäväksi ja kirjaa päätökset. Miten projektipäällikkö voi keskittyä näihin kahteen asiaan? Voisiko sihteerin virkaa ohjausryhmässä kenties kierrättää? Tai valita sihteeri jo ohjausryhmän ensimmäisessä kokouksessa?

Entä jos projektissa on junior tason projektipäällikkö ja ohjausryhmän koko on suuri, niin eikö vaarana ole, että projektipäällikkö kertoo juuri sen, mitä ohjausryhmä haluaa kuulla? Tai projektipäällikkö vääristelee projektin tilannetta positiivisempaan suuntaan? Miten ohjausryhmä voi varmistaa pysyvänsä projektin tilanteesta ajan tasalla? Mielestäni ohjausryhmän kokouksessa aikaa ei saisi tuhlata projektin tilanteen yksityiskohtaiseen läpikäymiseen. Projektipäällikön tulee pitää ohjausryhmä tilanteesta ajan tasalla säännöllisellä raportoinnilla. Mikäli käytössä ei ole jotain projektihallinnan työkalua, jonka dashboardin avulla ohjausryhmän jäsenet saisivat reaaliaikaisen näkymän projektin tilanteeseen, projektipäällikön tulee raportoida säännöllisesti projektin aloitusvaiheessa sovittujen käytäntöjen mukaan. Projektin edetessä sovittujen toleranssien puitteissa, ja jollei muutoksiakaan ole tiedossa, ei mielestäni ole syytä järjestää turhaan ohjausryhmän palaveria.

Esimerkki erään projektin dashboardista (projektin työkaluna Project-TOP)

Miten mitata ohjausryhmän työskentelyä?

Veikkaan, että ohjausryhmän toimintaa mitataan harvoin, jos lainkaan. Kenen sitä kuuluisi mitata? Kuuluuko ohjausryhmän toiminnan mittaaminen projektipäällikölle projektin muiden mittareiden ohessa? Vai kuuluuko se PMO:lle tai salkunomistajalle? Mielestäni luonnollisin taho olisi PMO tai salkunomistaja, mikäli PMO:ta ei ole. Kerätäänkö ohjausryhmän työskentelystä opittuja asioita? Mutta mitä sitten mitata? Tilaisuudessa heitettiin muutamia ehdotuksia kuten esimerkiksi:

• muutospyyntöjen läpimenoaika,
• päätösten määrä,
• paljonko käytettiin puheenvuoroja,
• asiakastyytyväisyys tai
• miten tyytyväisiä projektipäällikkö ja projektitiimi ovat ohjausryhmän toimintaan.

Laadullisesti ohjausryhmän toimintaa voidaan arvioida kysymällä palautetta sidosryhmiltä ja projektitiimiltä esimerkiksi, onko ohjausryhmän tuki ollut riittävää, onko viestintää ollut riittävästi, sekä onko ohjausryhmän rooli ja vastuut olleet selvillä sidosryhmille. Tyytyväisyyskyselyä tehtäessä kannattaa muistaa ohjausryhmän osuus ja merkitys projektin onnistumisen kannalta.

Yhteenvetona esityksestä jäi mieleen se, että ohjausryhmän toiminta tulee tehdä näkyvämmäksi projektin kaikille sidosryhmille muillakin tavoin kuin lähettämällä ohjausryhmän kokousten muistiot sähköpostitse, yleensä ohjausryhmän jäsenille itselleen. Tarvitaan myös enemmän vuorovaikutusta projektin sidosryhmien ja ohjausryhmän välillä, jämäkkää päätöksentekoa ja otetta ristiriitatilanteisiin sekä näkyvyyttä organisaation projektin kokonaistilanteeseen.

Linkkejä

How poor Steering Committees cause projects to fail

Forming a steering group; what makes a good group?

The Four Keys to Successful Project Steering Committees

Projektin onnistumisen tärkeimmät tekijät, osa I

Hyvä ja toimiva projektitiimi

Kysely projektitiimin jäsenten motivaatiotekijöistä on edennyt viimeiseen kysymykseen. Muistin virkistykseksi anonyymissä kyselyssä esitettiin viiden organisaation projektitiimin jäsenille seuraavat viisi kysymystä:

1.       Mitkä asiat projektissa motivoivat sinua parhaiten?                  

2.       Mikä seikkamielestäsi projektissa syö eniten motivaatiota?  

3.       Miten toimiihyvä ja motivoitunut projektitiimi?                         

4.       Mitäprojektipäällikkö voi tehdä parantaakseen projektitiimin jäsenen motivaatiota?          

5.       Mitkä ovat projektin onnistumisen tärkeimmät tekijät?

Kyselyyn osallistuneilta tuli runsaasti loistavia ajatuksia projektin onnistumiseksi, joten olen jakanut postauksen kahteen osaan. Olen koonnut vastausten perusteella yhdeksän tärkeintä tekijää yhteenvedoksi ja lisännyt vinkkejä käytännön toteutukseen ja projektin onnistumisen parantamiseen. Kymmenenneksi olen lisännyt tekijän, jolla varmistetaan näiden yhdeksän onnistumisen edellytyksen noudattaminen projektin aikana. Ensimmäisessä postauksesssa käsittelen vastaajien mielestä neljä tärkeintä onnistumisen tekijää, ja seuraavassa postauksessa loput. Jokainen voi itse laittaa nämä onnistumisen tekijät tärkeysjärjestykseen omien näkemystensä mukaan, lisätä jonkun muun tekijän tai poistaa jonkun ”vähemmän tärkeän” tekijän. Vastaajien kommentit on merkitty postaukseen kursiivilla suluissa.

Kyselyyn vastanneiden mielestä suurimmat tekijät projektin onnistumiseksi oli 

• selkeä tavoite ja hyvin määritelty projekti,
• selkeät vastuut ja roolit, kuten eräs vastaajista kiteytti: ”Se, että jokainen tuntee täsmälleen yhteiset tavoitteet ja oman roolinsa”
• omistautuneita ja motivoituneita tiimin jäseniä, jotka ovat sitoutuneet tekemiseen, esimerkiksi: ”Projektiin omistautuneet tekijät”, ”motivoituneet ja toistensa kanssa hyvin toimeentulevat henkilöt, ”Sitoutuneisuus tavoitteiden saavuttamiseen tiimin jäsenten kanssa”. 

Seuraavaksi painotettiin ammattitaitoisia ja osaavia projektin jäseniä sekä erityisesti projektipäällikön osaamista (”PP:lla on osaamista projektin johtamisessa”, ”asiaan perehtynyt projektipäällikkö”, ”Ambitiolla työtään tekevä projektipäällikkö, joka liidaa keikan asiantuntijaresurssien kanssa maaliin”). Vastauksissa mainittiin myös palkitseminen ja palaute (”lopussa kunnollinen palaute ja oppiminen tehdyistä virheistäkin"). Projektikolmiosta mainittiin useasti aikataulun merkitys onnistumisen kannalta, kuten esimerkiksi ”Sopivan haasteelliset aikataulut…” ja ”realistinen aikataulu”. 

Kuva 1 Pasaatin projektikolmio

Vastauksissa painottui selvästi projektikolmion oikea kulma, ihmisten osuus projektin onnistumisessa. Yksikään vastaajista ei maininnut teknologioihin tai esimerkiksi prosesseihin liittyviä asioita. Olisikin mielenkiintoista tehdä sama kysely projektipäälliköille. Painotus saattaisi olla hyvinkin erilainen, vai olisiko?

Yhteinen tavoite, ongelman ymmärtäminen

Projektin omistajalla, ohjausryhmän jäsenillä, projektipäälliköllä, projektitiimillä, loppukäyttäjillä ja muilla kriittisillä sidosryhmillä tulee olla yhtenäinen ymmärrys projektin tavoitteesta. Mitä ongelmaa projektin avulla ratkaistaan? Mikä on odotettu lopputulos ja sen merkitys loppukäyttäjälle? Kuinka usein projektin lopputuotoksen merkityksellisyyttä ajatellaan sen ruohonjuuritason loppukäyttäjän näkökulmasta? Miten tuotos vaikuttaa loppukäyttäjän jokapäiväiseen työhön? Mitä vaikutusta sillä on työskentelymenetelmiin? Mitä hyötyjä projekti tuo? Projektitiimin jäseniltä tuli tähän liittyen useita erinomaisia kommentteja, kuten esimerkiksi seuraavat: ”Projektin lopputuloksen merkityksellisyyden sisäistäminen/ymmärtäminen.” ja ”Tehtävänannon tai ongelman kunnollinen tai jopa syvällinen ymmärtäminen.” Projektin tavoitteen tulee vastata kysymyksiin MITÄ, MIKSI ja KENELLE.

Projektin suunnitteluvaihe on projektin kriittisin vaihe, johon tulee panostaa, vaikkakin tämä koetaan monesti liikaa aikaa vieväksi. Tavoite tulee määritellä yhdessä asiakkaan kanssa ja se tulee jalkauttaa viimeistään kick off tilaisuudessa muille kriittisten sidosryhmien jäsenille sekä projektitiimin jäsenille, mikäli he eivät ole osallistuneet tavoitteiden määrittelyyn. Ohjausryhmä on myös perehdytettävä uuteen projektiin. Tavoitteet tulee olla mitattavissa. Selvät ja mitattavat tavoitteet auttavat määrittämään ja pitämään kurissa projektin laajuutta, scope creepiä. SMART-sääntö kannattaakin pitää mielessä koko projektin ajan.

Vastuut ja roolit, organisointi

Projektin aloitusvaiheessa suosittelen tekemään kattavan sidosryhmäanalyysin, jossa määritellään jokaisen sidosryhmän, esimerkiksi ohjausryhmän jäsenten, asiakkaan ja toimittajan roolit projektissa. Projektitiimin, joka on vastuussa projektin suunnittelusta ja toteutuksesta, roolit ja vastuut määritellään tarkemmin. Projektipäällikön vastuulla on varmistaa, että jokainen myös ymmärtää oman roolinsa ja oman työnsä merkityksen projektin onnistumiseksi. Projektin kriittisille avainhenkilöille on muistettava määritellä varahenkilöt.

”Projekti on hyvin organisoitu. Sen avulla mm. täsmennetään ja kannetaan vastuuta - syntyy roolit.”
”Ohjausryhmän ja projektin omistajan tuki keskiössä.”
”Se että jokainen tuntee täsmälleen yhteiset tavoitteet ja oman roolinsa”

Sidosryhmäanalyysin tekemisestä on suuri apu projektia organisoitaessa. Sen avulla varmistetaan, että kaikki projektiin vaikuttavat sekä tahot, joihin projekti vaikuttaa, tulee huomioitua. Projektin organisoinnissa tulee huomioida eri sidosryhmien osallistuminen projektin eri vaiheisiin ja ennakoida resurssitarpeita jo hyvissä ajoin. 

Kuva 2 Yhteenveto projektipäällikön, projektitiimin jäsenten ja ohjausryhmä jäsenten vastuista

Osaaminen ja osaamisen kehittäminen

Usein puhutaan projektipäällikön urapolusta ja projektipäälliköille kohdistetuista koulutuksista, tarvittavista taidoista ja osaamisesta. Entä projektitiimin jäsenet? Usein yrityksissä unohdetaan projektitiimin jäsenet kokonaan. Projektipäällikkö suorittaa tahollaan sertifikaatteja ja käy kursseilla parantamassa osaamistaan.  Miten projektitiimin jäsenet voivat kehittää projektinhallinnan osaamistaan? Mitä osaamista projektitiimin jäsen tarvitsee? Mitä ovat ”Ammattitaitoiset ja osaavat projektin jäsenet”? Oman kokemukseni pohjalta projektitiimin jäsenenä ja projektipäällikkönä toimiessani seuraavat kuusi taitoa ovat edellytyksenä projektitiimin jäsenelle:

• Oman alan substanssiosaaminen
• Perustietämys ja ymmärrys projektinhallinnasta
• Ongelmanratkaisutaitoja
• Viestintätaitoja
• Yhteistyötaitoja (tiimityöskentely)
• Organisointitaitoja

Eräs keino kehittää osaamistaan on lukea omatoimisesti alan kirjallisuutta. Tämä ei oppimisen kannalta ole välttämättä parhain ratkaisu. Yksin puurtaminen teoreettisen kirjallisuuden parissa ei välttämättä houkuttele moniakaan ja opitun soveltaminen käytäntöön saattaa jäädä. Oman työn ohessa jää harvoin aikaakaan keskittyä omatoimiseen opiskeluun. Toinen vaihtoehto on sertifioitua, kuten projektipäällikötkin. Projektipäälliköille saattaa olla tuttu PMI:n PMP sertifikaatti. Harva tietää, että PMI tarjoaa myös projektitiimin jäsenille sertifiointeja. Certified Associate in Project Management (CAPM®) on tarkoitettu projektitiimin jäsenille, jotka haluavat kehittää taitojaan toimia projektitiimissä. Tämäkään, hyvin teoreettisena ratkaisuna, ei mielestäni ole kovin hyvä ratkaisu. 

Kolmas vaihtoehto on osallistua ulkopuolisen järjestämälle kurssille. Projektitiimit ovat usein virtuaalisia, ja tiimin jäsenet tekevät myös linjaorganisaation tehtäviä tai ovat useammassa projektissa yhtä aikaa. Tällöin osallistuminen päivänkin kurssille saattaa tuntua mahdottomalta. Kurssille osallistumisessa on se hyvä puoli, että kurssilla tapaa myös muita, voi keskustella ja jakaa osaamistaan ja oppia muilta osallistujilta.  Opittujen asioiden soveltaminen omaan työhön kurssin jälkeen ei välttämättä olekaan niin helppoa kuin kurssilla teoriassa kuultuna.

Vaihtoehtona voi olla myös yrityskohtainen työpajamainen päivän koulutus. Työpajassa käydään läpi ensin teoreettisesti perusasioita, ja sen jälkeen pohditaan yhdessä ryhmätöiden merkeissä omien projektien haasteita ja ratkaisuja niihin. Tällöin saadaan siirrettyä hiljaista tietoa tiimin jäsenien kesken. Soveltamalla asioita käytäntöön tapahtuu oppimistakin huomattavasti paremmin.

Kuva 3 Osaamisen kehittäminen projektissa

Neljäs vaihtoehto on osallistua webinaareihin. Olen kouluttanut mm. projektiviestintää, sekä pitänyt projektinhallinnan webinaareja projektitiimin jäsenille. Tunnin pituiset webinaari-sessiot ovat loistava keino kehittää osaamistaan, sillä aikaa ei kulu liikaa, ja aihe on usein selkeästi rajattu tiettyyn projektinhallinnan osa-alueeseen. Vuorovaikutus on haasteena webinaareissakin. Kysymyksiä voi laittaa koko webinaarin ajan, mutta keskustelu ei rajoitetun aikataulun vuoksi ole mahdollista.

Lessons Learnt tilaisuudet ovat myös erinomainen keino jakaa osaamista. Yksi projektitoimiston vetäjän tai projektisalkun omistajan tehtävistä on järjestää yrityksen koko projektihenkilöstölle Lessons Learnt-tilaisuuksia, joissa jaetaan tietämystä ja kokemuksia muiden kanssa. Ennen kaikkea näissä tilaisuuksissa siirtyy hiljaista tietoa, jota muutoin on haasteellista jakaa.

Tiimityö ja tiimityötaidot

Projektitiimin jäsenet ovat oman alansa asiantuntijoita ja tulevat usein linjaorganisaation eri yksiköistä. Projektitiimissä saattaa olla mukana myös asiakas, loppukäyttäjä, toimittajan edustaja ja muita sidosryhmien edustajia projektin eri vaiheissa. Jokainen tiimin jäsen on yksilö, ja joskus työskentely uusien tiimin jäsenten kanssa aiheuttaa haasteita. Tiimin jäsen tarvitsee mm. seuraavia tiimityötaitoja:

• Suullista ja kirjallista viestintää
• Ongelman ratkaisutaitoja
• Konfliktien hallintaa
• Taitoa kuunella ja huomioida muita tiimin jäseniä
• Neuvottelutaitoja
• Kykyä antaa ja vastaanottaa palautetta
• Positiivista asennetta

Kuva 4 Hyvän kuuntelijan taidot

LinkedInissä on jaettu ylläolevaa kuvaa erinomaisesta kuuntelijasta. Kuva soveltuu hyvin projektityöskentelyyn, erityisesti projektin viikkopalavereissa noudatettavaksi. Kuva tiivistää kaiken tarpeellisen: dialogi, vuorovaikutus, palaute, avoimuus vaihtoehdoille ja uusille ideoille, katsekontakti, non-verbaalinen viestintä ja empatia.

Tiimin jäseniltä odotetaan tiimisuuntautuneisuutta ja tiimityötaitoja, joita vastaajat ovat painottaneet, esimerkiksi ”Motivoituneet ja toistensa kanssa hyvin toimeentulevat henkilöt” ja ”Kaikki sitoutuvat tekemiseen ja päämäärään”. Tiimisuuntautuneisuudella tarkoitan muiden tiimin jäsenten huomioimista tiimityöskentelyssä sekä empatiaa, joka edellisessä kuvassakin mainittiin ja tiimin tavoitteiden laittamista henkilökohtaisten tavoitteiden edelle.

Mitä ketterämpää tiimityöskentely on, sitä enemmän tarvitaan avointa ja tiivistä kommunikointia, mikä edellyttää tiimin jäseniltä hyviä sosiaalisia ja kognitiivisia taitoja sekä yhteistyökykyä. (”Vapaaehtoiset jäsenet, jotka tutustutetaan toisiin edes jollain tasolla. Tiivis yhteistyö ja avoin kommunikointi, tavalla, jonka kaikki ymmärtää.”) Sosiaalisia taitoja tarvitaan erityisesti tiimin ollessa kuohuntavaiheessa, jolloin jäsenet tutustuvat toisiinsa. Kuohuntavaihe on projektin haasteellisin vaihe. Silloin esiintyy eniten konflikteja vuorovaikutussuhteissa ja kritiikkiä alkavaa projektia ja esimerkiksi tehtävänantoja kohtaan.

Aina kaikkien jäsenten kemiat eivät kohtaa (”Tiimin jäsenten välinen kemia”). Virtuaalitiimeillä on usein haasteita, mikäli tiimin jäsenet eivät pääse aloittamaan projektia yhdessä kasvotusten jolloin tutustuminen toisiin tiimin jäseniin ja sitoutuminen projektiin luonnistuu paremmin. Projektipäällikön rooliin ja vastuulle kuuluu luoda positiivinen me-henki tiimissä.

Kuva 5 Tiimin hioutumisen vaiheet

Suosittelen uuden projektin alkaessa projektitiimiä tekemään Belbinin tiimiroolitestin ja jakamaan tulokset tiimin jäsenten kesken. Testissä määritellyt yhdeksän tiimiroolia kuvaavat henkilölle luonteenomaisia käyttäytymistapoja suhteessa tiimin toisiin jäseniin. Tavoitteena on testitulosten avulla oppia tuntemaan ja säätelemään omaa tapaa toimia eri tilanteissa sekä tunnistamaan omat heikkoudet ja vahvuudet.

Seuraavassa postauksessa käyn läpi loput kuusi projektin onnistumisen tekijää. Sitä odotellessa itse kukin voi jatkaa listaa oman näkemystensä mukaan!

Vuorovaikutuksella tulokseen: kokonaisarkkitehtuuria ja projektiviestintää

Sytykkeen ja Tivian laivaseminaari 2016: Vuorovaikutuksella tuloksiin

Osallistuin Pitkyn edustajana ensimmäistä kertaa Sytykkeen isännöimään laivaseminaariin, jossa teemana oli vuorovaikutus ja viestintätaidot kokonaisarkkitehtuurin näkökulmasta. Sytykkeen ja Kaaoksen esityksiä oli rinnakkain, mikä tuotti vaikeuksia päättää, kumpaan mielenkiintoiseen esitykseen osallistut. 

Esityksiä oli kahden päivän aikana paljon, joten valitsin lähempään tarkasteluun tähän neljä itsestäni mielenkiintoisinta esitystä ja yritin koota niistä parhaimmat vinkit sovellettavaksi myös muille projekteissaan. Pokemonia käsittelevä esitys on hieman irrallaan (projekti)viestinnästä, mutta koska meidän perheen teinitkin kesällä siihen hurahtivat ja pelin menestys oli niin suuri, oli mielenkiintoista kuulla mitä pelin menestyksen taustalla oikein on.

PokemonGo, miten pitkään nostalgia vie eteenpäin?

Emilia Hjelm Open Knowledge Finlandista kertoi PokemonGO –pelin peruja ja menestyksen taustaa.  Vuonna 2010 julkaistiin suomalaisen Grey Area –studion jo lakkautettu, GPS-paikannukseen perustuva videopeli, Shadow Cities iOS alustalle. Myös tässä pelissä yhteisöllä oli vahva rooli. Tästä päästäänkin Ingressiin, jonka Niantic Labs julkaisi vuonna 2012 saavuttaen 7 miljoonaa pelaajaa (vuonna 2015). Ingressissä portaalit olivat tosimaailman paikkoja, johon tiedot kerättiin joukkoistamalla, eli pelaajat ehdottivat portaaleja (sijainti ja kuva). Ingressin pelaajat olivatkin aluksi ”aikuisia nörttejä”, jotka järjestivät omia tapahtumiaan. Niantic Labs julkaisi kesällä 2016 Ingressin päälle rakennetun Pokemon Go pelin, jossa portaalit ovat joko PokeStoppeja tai Gymejä.

Kysymykseen miksi Pokemon valloitti maailman (mihin Ingress ja Shadow Cities eivät kyenneet) on vastauksena kenties se, että pohjatyö oli tehty jo Ingressissä, jolloin pelimekaniikka oli kunnossa ja ennen kaikkea Pokemon hahmot olivat valmiiksi tuttuja. Peliä voidaankin pitää nostalgisena, jota vanhemmat ovat jo lapsena pelanneet ja siirtävät nyt lapsilleen. Peli on koko perheen peli, toisin kuin aiemmat vastaavanlaiset (Shadow Cities ja Ingress). Kilpailu alalla on todella kovaa. Luin juuri mobiili.fi:n sivuilta Supercellin Clash Royalen ja Clash of Clansin ohittaneen PokemonGo:n tuottavampina sovelluksina. En kuitenkaan epäile, etteikö PokemonGo:n suosio jatku vielä pitkään lasten ja perheiden keskuudessa. Pelin juoni on monille tuttu ja japanilaisten animaatioiden tapaan franchise-näkökulmalla suunniteltu peli tulee mitä luultavammin tekemään vielä pitkään tulosta oheistuotemyynnillään.

Viestintää johdolle ja vähän muillekin

Myllymäen Reinon CxO Professional Oy:stä esitys ”Ammattilaisen viestintä CIO:n näkökulmasta” kolahti minuun projektiviestintää kouluttaneena sidosryhmät ja myöhäisvaikutuksen mekanismi. Sidosryhmienhallintaa kouluttaneena jaksan yhä toistaa toistamistani kattavan sidosryhmäanalyysin merkitystä. Ilman sitä on mahdoton suunnitella projektiviestintää. Tämä työ maksaa siihen käytetyn ajan varmasti takaisin tyytyväisinä sidosryhmän jäseninä.

Myllymäen mukaan mielemme torjuu tietoa, jos pidämme lähdettä epäuskottavana. Jokainen on varmaan törmännyt tilanteeseen, kun tietohallintojohtaja (CIO) puhuu johtoryhmän kokouksessa, ja jokainen tietää puhujan edustavan IT:tä, niin sanoma ei ehkä mene toivotulla tavalla perille. Miten CIO sitten saa asiansa eteenpäin? Jos CIO:n puheissa on kuitenkin järkeä, suhtautuminen voi muuttua, kun tiedosta irtoaa ajan myötä linkki sen lähteeseen. Riittävä ja riittävän aikainen valmistelu ennen kaikkea varmistaa asian perille menon. Vastapuolella on annettava aikaa sulatella asiaa. Sama pätee myös projekti ohjausryhmän kokouksiin. Ei riitä, että projektipäällikkö tulee kokoukseen paikalle esittelemään projektin tilanteen ja esittelee ehdotuksensa. Ehei, ei se niin onnistu. Mieti huolella etukäteen, mistä halutaan päätös ja kerro se ymmärrettävästi hyvissä ajoin etukäteen ohjausryhmälle. Kokouksessa ei ole tarkoitus alkaa märehtiä asiaa, vaan tehdä päätös. Tärkeät asiat on pantava liikkeelle ajoissa ja mitä tärkeämmästä asiasta on kyse, on aikaa varattava enemmän jotta myöhäisvaikutukselle jää aikaa.

Löytäkää yhteinen kieli (ohjausryhmä, projektipäällikkö, projektitiimin jäsenet), ei ammattislangia (IT-jargonia), perustele asiat ymmärrettävästi ja ennen kaikkea ole liikenteessä ajoissa, vältä ”viime tippaa”!
Seuraavassa Reinon esityksestä lainaus asian erilaisesta tulkinnasta:

Kun IT-asiantuntijan sanoo:

”Kyllä se periaatteessa onnistuu!”

Liiketoiminta kuulee lausahduksen muodossa: ”Kyllä se onnistuu!”,

vaikka IT-asiantuntija tarkoittaa, että: ”Ei se käytännössä onnistu!”

Miten valitettavan harvoin IT-projekteissa nähdään se vaiva, että tehtäisiin liiketoimintasuunnitelma eli kannattavuusselvitys, eikä lähdettäisi soitellen sotaan tai tässä tapauksessa projektiin.

Todellisuus vastaan kokonaisarkkitehtuuri, 3-0? 4. erä voiton puolella?

Kaaoksen esityksistä kävin kuuntelemassa Anu Ylä-Pietilän esityksen Trafin kokonaisarkkitehtuurin määrittelyn haasteisiin ja hankaluuksiin. Esityksen nimi, Todellisuus vastaan KA, 3-0?, oli jo itsessään sen verran houkutteleva. Kokonaisarkkitehtuurityö Trafissa alkoi vuonna 2010 ja nyt edetään jo vaiheessa 4 ja ollaan voiton puolella.

Hypevaiheessa (erä 1) tuli vastaan projekteissakin eteen tulevia sudenkuoppia: ylenmääräinen kontrolli, käytettiin jargonia ja työtä tehtiin norsunluutornissa. Matalan profiilin vaiheessa (erä 2) ryhdyttiin arkkitehtuurisuunnittelua tekemään projekteille jolloin saatiin jo enemmän tuloksia ja vähemmän puhetta. Kakkoserässä ei ollut linkitystä strategiaan ja tavoiteltuihin liiketoimintahyötyihin, tavoitteet ja mittarit puuttuivat ja kokonaisarkkitehtuuri oli liikaa ICT:n kontolla.

ICT-painotus vaiheessa alettiin jo pääsemään voiton puolelle, vaikkakin vaihe osui pahimpaan Agile- hypetyksen vaiheeseen. Kokonaisarkkitehtuuri oli kuitenkin yhä liikaa ICT:n vastuulla ja irrallaan liiketoiminnasta.

Erä 4 on nyt meneillään. Kokonaisarkkitehtuurityö on viety lähelle johtamisjärjestelmää ja strategiatyötä. Vaiheessa on kuitenkin omat sudenkuoppansa, sillä nykytilaan on keskitetty liikaa, tehty ylenmääräistä hallintaa ja varmistelua ja laiminlyöty jatkuva tiedonvaihto ja yhteydenpito liiketoiminnan kanssa, mutta jossain varmasti monessakin asiassa, on kuitenkin onnistuttu, koska työ yhä jatkuu ja ollaan jo neljännessä erässä.

Trafin kokonaisarkkitehtuurin vaiheet

Eräs asia mikä esityksessä pisti silmään, oli erittäin kattava sidosryhmäanalyysi. Sen merkitystä projekteissa ei useinkaan ymmärretä, tai ei nähdä sitä laajemmassa merkityksessä.

Ydinajatus jonka Anun esityksestä sain, on se, että arkkitehtien tulee tulla alas norsunluutorneistaan ja jalkautua projekteihin sekä lähemmäksi liiketoimintaa. Kokonaisarkkitehtuurityötä ei pidä tehdä ainoastaan IT-ihmisten kesken (sidosryhmien määrittämisen tärkeys) ja erityisesti jatkuvaan viestintään tulee panostaa. Kokonaisarkkitehtuurityö ei lopulta ole mitään rakettitiedettä, kun mukana on oikeat ihmiset. Se on jatkuvaa työtä, jota ei pidä lähteä tekemään työkalu edellä. Muiden kokemuksia ja osaamista kannattaa ehdottomasti hyödyntää.

Anun esityksestä jäi mieleen myös se, että he pitivät muun muassa projektipäällikköverkostolle oman esityksen siitä, mitä kokonaisarkkitehtuuri. Viestinnällä on suuri merkitys siinä, miten kokonaisarkkitehtuuri ymmärretään organisaatiossa. Kokonaisarkkitehtuuri ei suinkaan ole ICT-arkkitehtuuria, jota tehdään norsunluutornissa liiketoiminnasta vieraantuneena. Sudenkuoppa, mihin usein kokonaisarkkitehtuuria määriteltäessä sorrutaan ja johon itsekin olen valitettavasti joskus sortunut, on nykytilan liian tarkka kuvaaminen sen sijaan, että määriteltäisiin tavoitetilaa. Kokonaisarkkitehtuurin määrittäminen ei suinkaan ole kertaluontoinen projekti, vaan jatkuvaa toimintaa, sillä asiat muuttuvat ja muutoksiin pitää sopeutua. 

Liisa kokonaisarkkitehtuurin ihmemaassa

Toinen hyvin mielenkiintoinen kokonaisarkkitehtuuriin liittyvä esitys, johon en valitettavasti osallistunut päällekkäisyyden vuoksi, oli Conversatumin Atrain-ryhmittymästä Satu Pajuniemen Liisa kokonaisarkkitehtuurin ihmemaassa. Osallistujat pohtivat ryhmissä kokonaisarkkitehtuurin keskeisten termien avaamista toiminnan edustajille. Sain Sadulta jälkeenpäin kootun materiaalin ja otan siitä muutaman idean tähän. Prosessien määrittely on monesti haastavaa. Helpoin tapa on antaa käyttäjän kuvata prosessi konkreettisesti jokapäiväisten tekoja kautta vaihe vaiheelta mahdollisimman yksinkertaisesti piirtäen, kuten seuraavassa kuvassa Liisa Laskuttaja on tehnyt. 

Kuva on täysin notaatiovapaa, eikä käyttäjältä voida vaatiakaan jonkin notaatiokielen, esimerkiksi UML:n tai BPMN:n käyttämistä saatikka jonkun työvälineen, esimerkiksi Sparxin, jota Trafi käyttää, käyttöä.

Kokonaisarkkitehtuuri tulee nähdä viestinnän välineenä. Kuten edellisessä kuvassa, kaavio paikantaa oman työn kokonaisuuteen. Kokonaisarkkitehtuuri tulee olla osa liiketoimintaa, ei ainoastaan IT:n asia!  Se on tiedolla johtamista, toiminnan kehittämistä ja muutoksen johtamista.

Sadun esityksestä suora lainaus:

“What is the use of a book,' thought Alice, 'without pictures or conversations?'"

- Lewis Carroll, Alice in Wonderland

Työkalu, kahvi ja kälikuvat, otteita IT-konsultin paremman kommunikoinnin käsikirjasta                     

Karri-Pekka Laakso Reaktorilta piti esityksessään lupauksensa olla puhumatta teoriaa lainkaan. Sen sijaan saimme useita erinomaisia vinkkejä projektitoimintaan. Karri-Pekka korosti esityksessään kasvokkain tapahtuvaa yhteistä tekemistä. Suosittelen aina pitämään projektin aloituskokouksen (kick offin) kasvokkain, jotta tiimin jäsenet tutustuvat paremmin toisiinsa. Sekään ei kuitenkaan riitä. Sytykkeen vuorovaikutus face-to-face vs. digitaalinen vuorovaikutus työpajassa joku kertoi, että kasvokkain tapaamisen voima kestää kuusi kuukautta. Projektin kuluessa, mahdollisuuksien mukaan toki, tulisikin järjestää muitakin tapaamisia ja yhteistä tekemistä. Toki tämä vaatii projektipäälliköltä monesti aikaa ja vaivaa, mutta uskon sen olevan sen väärti. Projektitiimin jäsenille tekemässäni motivaatiokyselyssä korostui erityisesti projektipäällikön läsnäolo. Sama toki pätee projektitiimiin. Mikäli projektitiimi työskentelee samoissa tiloissa, on yhteistyö ja viestintä ymmärrettävästi huomattavasti sujuvampaa.

Toinen seikka, mitä Karri-Pekka korosti, oli asiakkaan kohtaaminen kasvokkain ja nimenomaan loppukäyttäjän, ei hänen edustajan ja siellä missä käyttäjät ovat, jotta saadaan ymmärrys mitä käyttäjät tekevät ja millaisessa ympäristössä (kenttätutkimusta). Projektipäälliköllä ja projektitiimin jäsenillä tulee olla ymmärrys siitä, mitä asiakas todella haluaa, ja mikä on asiakkaan todellinen tarve.

Vuorovaikutus face-to-face vs. digitaalinen vuorovaikutus

Vuorovaikutus face-to-face vs. digitaalinen vuorovaikutus työpajassa käytiin runsaasti keskustelua viestinnässä käytettävistä työkaluista. Projektitiimit ovat usein virtuaalitiimejä, jolloin kasvokkain tapaamiset jäävät pakon sanelemana vähäisiksi. Erityisesti monitoimittajaprojekteissa, ja projektin sidosryhmien määrän kasvaessa, on yhteisen työkalun valinta haastavaa.

Työpajassa lista käytetyistä työkaluista kasvoi nopeasti. Projektiviestintään käytetään hyvin monenlaisia työkaluja, kuten esimerkiksi: Trello, Slack, Messenger, Facebook, Wiki, Whats Up, Foko, Yammer, Agendium, Lync, Skype ja sähköposti. Samaa mieltä oltiin kasvokkain viestinnän tärkeydestä, vaikkakin sähköposti projektiviestinnän välineenä pitää yhä paikkansa.

Illan viestintäaiheiseen paneelikeskusteluun koottiin osallistujat eri rooleista alla olevan kuvan mukaisesti. Moni varmaan tunnistanee itsensä kuvan jostain roolista?

Yhteenvetona kahden päivän tiivistä seminaariohjelmasta voi kiteyttää tärkeimmäksi sidosryhmien tunnistamisen ja jatkuvan viestinnän, erityisesti kasvokkain tapahtuvan, sekä muiden kokemusten ja osaamisen hyödyntämisen oli kyse sitten kokonaisarkkitehtuurista tai projektin vetämisestä.

Kaiken kaikkiaan laivaseminaari oli hyvin antoisa, jopa niin antoisa, että Sytyke sai meidän perheestä kaksi uutta jäsentä. Haasteellisinta oli valita ohjelmasta Sytykkeen viestinnän ja Kaaoksen kokonaisarkkitehtuurin key notesien välillä. Key Notesit kun oli aikataulutettu rinnakkain. Kenties ohjelmaa voisi venyttää hieman myöhempään iltaan vaihtoehtona iltaseminaarille (?).

Verkostoitumisessa suomalaisilla on yhä petrattavaa, joten tähän tulisi kenties jatkossa kiinnittää enemmän huomioita. Kiitokset Matiakselle, joka hoiti esimerkillisesti Sytyke-työpajan alkuesittelykierroksen kera! Keskustelu sujui luontevasti ja vapautuneesti sen jälkeen!

Suosittelen lämpimästi osallistumaan ensi vuoden seminaariin, joka tehdään sillä kertaa Pietarin suuntaan.

Seminaariterveisin,

Päivi
Pitkyn hallituksen jäsen
PM Club Tampereen vetäjä