ÄLYKKÄÄT PÖYTÄKIRJAT - PROJEKTIKOKOUKSISSA SYNTYVÄN TIEDON HALLINNAN TEHOSTAMINEN RAKENTEISEN DOKUMENTINHALLINNAN AVULLA

Transkriptio

1 TEKNILLINEN KORKEAKOULU Automaatio- ja systeemitekniikan osasto Heidi Pehu-Lehtonen ÄLYKKÄÄT PÖYTÄKIRJAT - PROJEKTIKOKOUKSISSA SYNTYVÄN TIEDON HALLINNAN TEHOSTAMINEN RAKENTEISEN DOKUMENTINHALLINNAN AVULLA Diplomityö Työn valvoja Professori Pirkko Oittinen Työn ohjaaja DI Erik Rosenlew, Inforbis Oy

2 Työn nimi: Älykkäät pöytäkirjat - projektikokouksissa syntyvän tiedon hallinnan tehostaminen rakenteisen dokumentinhallinnan avulla Päivämäärä: Sivumäärä: 69 Valvoja: Ohjaaja: Professori Pirkko Oittinen DI Erik Rosenlew, Inforbis Oy Osasto, professuuri: Automaatio- ja systeemitekniikan osasto, AS-75 Viestintätekniikka Pääaine: Sivuaineet: Viestintä yritystoiminnassa Teollisuustalous, Vuorovaikutteinen digitaalinen media Tiivistelmä: Tässä työssä käsiteltiin viestintää projekteissa ja yhtä sen erikoistapausta eli projektikokouksia. Projektikokoukset ovat suurissa projekteissa projektin osapuolten pääasiallinen virallinen viestintäkanava. Lähes kaikki projektiin liittyvät päätökset tehdään kokouksissa ja siksi kokouksissa syntyvä tieto on erittäin tärkeää ja sen tulisi olla helposti saatavilla. Projektikokouksista laaditaan pöytäkirjoja, joihin kirjatut päätökset ovat osapuolten välisten sopimusten mukaan sitovia. Pöytäkirja nykyisessä muodossaan on tavallinen paperidokumentti, jonka muoto on melko vapaa ja sisältö täysin järjestämätön. Tässä työssä tutkittiin projektipöytäkirjan muuttamista älykkääseen muotoon, jotta sen sisältö olisi helpommin ja monipuolisemmin käytettävissä. Älykäs dokumentti on sellainen, johon on lisätty tietoa sen sisällöstä ja ympäristöstä. Työn tärkeimmät tavoitteet olivat projektissa tapahtuvan viestinnän kartoittaminen, projektikokousprosessin kartoittaminen ja ymmärtäminen, projektikokouksissa syntyvän tiedon luokittelu ja projektipöytäkirjojen käyttömahdollisuuksien selvittäminen esimerkkisovelluksen avulla. Työssä analysoitiin joukko vanhoja pöytäkirjoja ja tämän dokumenttianalyysin pohjalta laadittiin rakennemalli älykkäälle pöytäkirjalle. Mallia testattiin käyttäjillä, jotka ovat projektinhallintaa työnään tekeviä henkilöitä. Tutkimusta varten tehtiin esimerkkitoteutus, johon kuului joukko rakenteiseen muotoon syötettyjä pöytäkirjoja sekä hakuohjelma. Tulosten perusteella pohdittiin älykkään pöytäkirjan hyödyllisyyttä projektin hallinnan apuvälineenä ja esitettiin jatkokehitysajatuksia älykkäälle pöytäkirjajärjestelmälle. Avainsanat: projektinhallinta, informaation hallinta, rakenteiset dokumentit, projektikokoukset, älykäs pöytäkirja, dokumenttianalyysi, tietämyksen hallinta

3 1 1 JOHDANTO 1.1 Taustaa Projektinhallinta on alue, jolla tapahtuu jatkuvasti muutoksia. Projekteille asetetut vaatimukset kasvavat, aikataulut kiristyvät ja projektiorganisaatioiden koko kasvaa. Lisäksi kannattavuusvaatimukset asettavat projekteille suuria haasteita sekä investointi- että käyttökustannusten vähentämiseksi. Uudet tekniset informaation hallintamahdollisuudet eivät välttämättä ole pelkästään hyödyllisiä projektinhallinnan apuvälineitä. Ne aiheuttavat osittain myös sen, että projektien oletetaan sujuvan entistä nopeammin ja sujuvammin. Lisäksi viestintäkanavavaihtoehdot, posti, sähköposti, puhelin, kokoukset, Internet jne., aiheuttavat sen, että informaatiota on tarjolla huomattavan paljon, mutta toisaalta sen hallinta ja löytäminen on vaikeaa. Teknisen kehityksen mukanaan tuomat vaatimukset ihmisten työskentelytapojen uudistamiseksi kuitenkin synnyttävät muutosvastarintaa. Vanhoista työskentelytavoista ei haluta luopua ja siksi hyväkin informaation hallintajärjestelmä saattaa jäädä käyttämättä tai sitä käytetään niin, ettei siitä saada mahdollisimman suurta hyötyä. Projektinhallinnan vaatimusten kasvaessa informaation hallintajärjestelmien kehittäminen ja käyttö on kuitenkin välttämätöntä. Informaation hallinta onkin asia, jonka ottaminen osaksi kaikkiin työvaiheisiin tulisi olla jokaisen projektiorganisaation tavoitteena. Ei voida olettaa, että kun informaatio tuodaan tietokoneella kaikkien saataville, sitä automaattisesti hyödynnettäisiin. Kaikkia käytäntöjä, johtamista ja muita työskentelytapoja tulisi kehittää informaatiolähtöisemmiksi. Tietämyksenhallinta on lähtökohta paremmalle viestinnälle ja sitä kautta tehokkaammin läpiviedyille projekteille. Ihmisten osaamisen ja tietämyksen kartoittaminen sekä kehittäminen ovat välttämättömiä osa-alueita tietämyksenhallinnassa. Vielä tärkeämpää on kuitenkin tarpeiden kartoitus: mitä tehdään ja voitaisiinko se tehdä tehokkaammin paremmilla välineillä. Tarpeiden perusteella voidaan rakentaa järjestelmiä, jotka ovat oikeasti hyödyllisiä. Tarpeiden kartoitus on tärkeää, sillä jos tehtyjen järjestelmien koetaan olevan hyviä ja riittävän helppokäyttöisiä apuvälineitä, niitä myös käytetään. Kaikessa projektinhallinnassa, erityisesti kuitenkin sellaisissa projekteissa, joissa on paljon osapuolia, erittäin tärkeä viestintäkanava ovat projektikokoukset. Yritysten asiakasprojekteissa, kuten esimerkiksi rakennus- tai tuotekehitysprojekteissa, projektikokoukset ja niistä tehtävät pöytäkirjadokumentit ovat projektin osapuolten pääasiallinen virallinen viestintäkanava. Projektikokouksissa myös syntyy hyvin paljon informaatiota ja tietämystä, joiden jakelu kuitenkin on monella tapaa ongelmallista. Ensinnäkin projektikokouksissa käsitellään hyvin suurta asiamäärää, jolloin oleellisen informaation löytäminen on vaikeaa. Toiseksi projektikokouksia pidetään pitkän projektin aikana jopa useita satoja ja useiden eri osapuolten kanssa. Näin suuressa määrässä kokouksia syntyy paljon informaatiota. Samaa asiaa saatetaan käsitellä useissa kokouksissa ja siitä saatetaan

4 2 jopa päättää usealla eri tavalla, mikä on projektin läpiviennin kannalta ongelmallinen tilanne. Projekteissa pidetään myös paljon pieniä neuvotteluja, joista ei välttämättä tehdä virallisia pöytäkirjoja, mutta joiden päätöksiä osapuolten kuitenkin odotetaan noudattavan. Älykkääksi dokumentiksi kutsutaan dokumenttia, johon on lisätty tietämystä sen omasta sisällöstä ja ympäristöstä. Älykkään dokumentin määritelmään kuuluu myös, että se voidaan käyttäjän antamien käskyjen perusteella muuntaa moniin eri muotoihin. Älykkäitä dokumentteja voidaan tehdä järjestämällä dokumentin sisältö rakenteiseen muotoon jollain siihen soveltuvalla kielellä. Älykkäät projektipöytäkirjat ovat siis rakenteiseen muotoon luokiteltuja projektikokousten pöytäkirjadokumentteja. Pöytäkirjojen rakenteinen ja älykäs hallinta ei ole projektinhallinnassa uusi ajatus. Käytännössä sen toteuttaminen aikaisemmin on kuitenkin ollut vaikeaa, koska siihen soveltuvia käytännönläheisiä teknisiä apuvälineitä ei ole ollut olemassa. Projektikokousten pöytäkirjoja laativat henkilöt ovat tekniseltä osaamiseltaan hyvin vaihtelevan tasoisia, eikä näiden henkilöiden voida olettaa käyttävän vaikeita järjestelmiä jokapäiväisessä työssään, kuten pöytäkirjojen laatimisessa. Projektipöytäkirjojen ollessa rakenteisessa muodossa, projektikokouksissa syntyvää tietoa voidaan helpommin hakea. Sitä voidaan myös kohdistaa tietyille projektin kapeille osaalueille ja siten projektipöytäkirjoja voitaisiin tehokkaammin käyttää projektinhallinnan välineinä. Tämän työn aiheena on selvittää rakenteisen projektipöytäkirjan soveltuvuutta ratkaisuna aikaisemmin esitettyihin ongelmakohtiin. Tässä työssä tutkitaan projekteissa tapahtuvaa viestintää ja projektikokouksia yhtenä viestinnän erikoistapauksena. Materiaalia aikaisemmista projektikokouksiin liittyvistä tutkimusta ei tämän tutkimuksen aikana ole ollut saatavilla, joten tutkimus pohjautuu materiaaliin, joka liittyy projekteissa tapahtuvaan viestintään, tietämyksenhallintaan sekä projekteissa kulkevaan informaatioon. 1.2 Työn tavoitteet Työssä tutustutaan projekteissa tapahtuvaan viestintään ja tiedon syntymiseen. Sitä kautta tutkitaan projektikokouksissa syntyvää tietoa ja sen hallinnan mahdollisuuksia ja ongelmia. Työn pääasialliset tavoitteet ovat projektissa tapahtuvan viestinnän kartoittaminen, projektikokousprosessin kartoittaminen ja ymmärtäminen, projektikokouksissa syntyvän tiedon luokittelu ja projektipöytäkirjojen käyttömahdollisuuksien selvittäminen esimerkkisovelluksen avulla.

5 3 Edellä mainittuihin kohtiin liittyen työn tavoitteena on kehittää rakenteinen projektipöytäkirjamalli, jonka avulla projektipöytäkirjat voidaan kirjoittaa älykkääseen muotoon. Mallin vaatimuksena on toisaalta riittävä yksinkertaisuus, jotta se säilyisi helppokäyttöisenä, toisaalta taas kattavuus, jotta siitä saataisiin riittävää hyötyä. Malli rakennetaan luokitellun tiedon avulla. Työn tavoitteena on myös tehdä Jaakko Pöyry Oy:n käyttöön soveltuva dokumentin rakennekuvaus (Document Type Definition, DTD). Malliin perustuen tehdään esimerkkisovellus, jolla mallin hyödyllisyyttä projektinhallinnan apuvälineenä voidaan analysoida. Tavoitteena on selvittää rakenteisen projektipöytäkirjasovelluksen jatkokehitystä varten ehdotetun mallin toimivuutta sekä mahdollisia parannusideoita. Tämän työn tavoitteena ei ole kehittää lopullista toimivaa ratkaisua vaan ainoastaan esimerkkisovellus, jonka avulla voidaan testata ajatusta projektipöytäkirjojen rakenteisesta toteutuksesta. 1.3 Työn rajaukset Projektikokouksiin ja niiden pöytäkirjoihin tutustutaan Jaakko Pöyry Oy:n asiakasprojektien avulla. Tutkittavaa materiaalia on paljon ja se on sisällöltään monipuolista. Ei voida kuitenkaan olettaa, että tässä työssä tehdyt ratkaisut olisivat yleispäteviä kaikkia mahdollisia projekteja ajatellen. Rakenteinen pöytäkirjamalli suunnitellaan Inforbis Oy:n ja Jaakko Pöyry Oy:n tarpeita ajatellen. Siitä pyritään tekemään mahdollisimman joustava, mutta se ei välttämättä ole sellainen, että se soveltuisi käyttöön, jossa kokoustai dokumentinhallintakäytännöt ovat hyvin erilaisia kuin Inforbis Oy:ssä tai Jaakko Pöyry Oy:ssä. Tarkastelun ulkopuolelle jäävät myös muut kuin tavalliset tekstimuotoiset pöytäkirjat. Esimerkiksi videoneuvotteluista tehdyt videopöytäkirjat tai nauhoitettujen kokousten äänimuotoiset pöytäkirjat eivät kuulu tämän työn piiriin. Tehtävän rakenteisen pöytäkirjamallin teknisten ratkaisujen teoriaa ei käsitellä yksityiskohtaisesti. Toteutuksessa käytetyistä teknisistä ratkaisuista käsitellään lyhyesti niitä, jotka oleellisesti vaikuttavat toteutukseen. Tämän työn ymmärtäminen vaatii jonkinverran tietämystä rakenteisen dokumentinhallinnan perusteista. Esimerkkisovelluksen ymmärtäminen taas vaatii lisäksi perustietämystä ohjelmoinnin peruskäsitteistä sekä olioohjelmoinnista. 1.4 Työn rakenne Työ jakautuu neljään osaan. Ensimmäisessä osassa (luku 3) määritellään työssä käytettävä projektinhallinnan peruskäsitteistö kirjallisuuden perusteella. Ensimmäisen osan tarkoitus on selvittää lukijalle ympäristö ja tarpeet, joihin tämä työ liittyy. Toisessa osassa (luku 4) käsitellään viestintää projekteissa kirjallisuuden avulla. Tarkoituksena on luoda riittävä ymmärrys viestinnästä projekteissa, jotta voidaan tarkastella projektikokouksia yhtenä projektin viestintäkanavana. Kolmannessa osassa (luku 5) tarkastellaan projektikokouksia ja niissä syntyvää tietoa sekä projektipöytäkirjoja. Neljännessä osassa

6 (luvut 6, 7 ja 8) esitellään edellisissä luvuissa tapahtuneen tarkastelun perusteella rakennettu esimerkkisovellus, jolla voidaan hallita älykkäitä projektipöytäkirjoja. Lisäksi tutkitaan sen käytön mahdollisuuksia projektinhallinnassa käyttäjätestien avulla, tarkastellaan testeistä saatuja tuloksia ja tulosten pohjalta pohditaan sen jatkokehitystä projektikokouksissa syntyvän informaation hallintajärjestelmäksi. Työssä käytetyt tutkimusmenetelmät määritellään erikseen luvussa 2. 4

7 5 2 TUTKIMUKSESSA KÄYTETYT MENETELMÄT 2.1 Kirjallisuuskatsaus Työn kirjallisuuskatsauksessa tarkastellaan kahta muun työn kannalta tärkeää osa-aluetta: projektinhallinnan peruskäsitteitä sekä viestintäprosessia ja tiedon syntymistä projektissa. Projektinhallinnan peruskäsitteiden tunteminen on välttämätöntä, jotta projektipöytäkirjojen käyttömahdollisuuksia voitaisiin ymmärtää. Viestintäprosessia ja tiedon syntymistä projekteissa taas tarkastellaan, koska projektikokousprosessi on yksi viestintäprosessin erikoistapaus. Viestintäprosessin ja projekteissa syntyvän tiedon luokitteluun ja mallinnukseen käytetään lähteessä /12/ esiteltyä tehdasprosessin ja tehtaassa syntyvän tiedon matriisimuotoista luokittelumallia. Mallin viitekehys ja muutamia esimerkkikysymyksiä jokaiseen lokeroon on esitetty taulukossa 1. Taulukko 1. Projektin viestintäprosessin luokitteluun käytetty malli /12/ Prosessitaso Informaatiotaso Tietämystaso Asiatieto Keitä prosessiin osallistuu? Mitä välineitä prosessissa käytetään? Mitä informaatiota prosessissa syntyy? Mitä tietoa prosessissa syntyy? Kuka tarvitsee tietoa? Toiminnallinen tieto Strateginen tieto Mitä prosessissa tapahtuu? Mitkä ovat prosessin vaiheet? Miksi prosessia tarvitaan? Miten prosessin tavoitteet aiotaan saavuttaa? Miten informaatio syntyy? Mikä on informaation tarkoitus? Miten tarkoitus saavutetaan? Miten tietämys syntyy? Miksi tietämystä tarvitaan? Miten tieto pitäisi esittää? Matriisin vaakariveillä tieto luokitellaan kolmeen osa-alueeseen: asiatietoon, toiminnalliseen tietoon ja strategiseen tietoon. Asiatiedolla tarkoitetaan sitä, mitä asioista tiedetään, toiminnallisella tiedolla sitä, miten asiat toimivat ja strategisella tiedolla sitä, miksi asiat toimivat tietyllä tavalla /12/. Pystyriveillä taas kuvataan projektissa tapahtuvan viestinnän ja siinä syntyvän tiedon kolme ulottuvuutta: itse viestintäprosessi, prosessissa kulkeva informaatio sekä siitä syntyvä tietämys. Informaation ja tietämyksen käsitteitä käsitellään erikseen luvussa 4.2.

8 6 Viestintäprosessista luodun matriisimallin perusteella valitaan ne projekteissa tapahtuvan viestinnän osa-alueet, jotka ovat tärkeitä projektikokousprosessin kannalta. Näitä tarkastellaan erikseen luvuissa Tiedon kartoitus Tiedon kartoitus tässä työssä tehdään käyttötapaus (use case) tutkimuksena analysoimalla vanhoja projektipöytäkirjoja. Tällainen dokumenttianalyysi on eräs yleisimmistä tavoista selvittää ja mallintaa dokumentin rakennetta /19/. Analysoitavia pöytäkirjoja on 300 kappaletta. Kaikki pöytäkirjat ovat yhdestä suuresta Jaakko Pöyry Oy:n vuosina 1999 ja 2000 tekemästä asiakasprojektista, jossa rakennettiin paperitehdas Portugaliin. Pöytäkirjamateriaali kattaa kaikki kyseisen projektin arkistoidut pöytäkirjat. Yhden projektin kaikkien pöytäkirjojen valitsemiseen dokumenttianalyysin materiaaliksi on päädytty, jotta saataisiin mahdollisimman kattava kuva tyypillisen asiakasprojektin kulusta. Toisaalta useamman kuin yhden projektin kaikkien pöytäkirjojen analysointi tämän työn puitteissa ei ole mahdollista. Tutkitusta pöytäkirjamateriaalista selvitetään asiakasprojekteissa esiintyvät erilaiset kokoustyypit, niiden tyypilliset asialistat sekä kokouksissa esiintyvät tietotyypit. Tieto kartoitetaan sekä jaetaan luokkiin ja näiden perusteella luodaan yleinen rakenteinen malli, jota voidaan käyttää kaikille pöytäkirjatyypeille. Tutkimuksessa apuna käytetään lähteessä /24/ olevaa kysymyslistaa, jonka tarkoituksena on minkä tahansa prosessin ymmärtäminen ja parantaminen. Tässä prosessina on projektikokousprosessi sekä erityisesti projektikokouksissa oleva tiedon syntymis- ja hallintaprosessi. Kysymykset voidaan jakaa viiteen pääluokkaan, jotka kysymyksineen sovellettuna projektikokousprosessiin ovat: Tarkoitus: Paikka/Tilaisuus: Yhteys/Tilanne: Ihmiset: Minkälaista tietoa projektikokouksissa syntyy? Miksi kokouksissa syntyvää tai käsiteltävää tietoa tarvitaan? Millaista muuta tietoa voisi tai pitäisi käsitellä? Minkälaisia projektikokouksia pidetään? Miksi tietynlaisia kokouksia pidetään? Tarvitaanko muunlaisia kokouksia? Minkälaisessa yhteydessä/tilanteessa projektikokouksissa syntyvää tietoa käytetään? Miksi juuri silloin? Onko muita yhteyksiä, joissa tietoa voisi tarvita? Ketkä käyttävät projektikokouksissa syntynyttä tietoa? Miksi juuri nämä henkilöt käyttävät tietoa?

9 7 Kuka muu voisi tarvita tietoa? Menetelmä: Miten projektikokouksissa syntynyt tieto on saatavilla? Miksi juuri tällä tavalla? Voisiko tiedon esittää jollain vaihtoehtoisella tavalla? Tulokset tiedon kartoittamisesta esitetään luvuissa ja rakenteisen projektipöytäkirjan malli luvussa Tiedon käyttötarpeet Projekteissa työskentelevien henkilöiden tiedonkäyttötarpeiden kartoittamiseen käytetään kahta menetelmää: haastattelut sekä työhön tutustuminen. Haastatteluissa kysytään sekä Jaakko Pöyry Oy:n edustajien että asiakkaiden näkemyksiä projektipöytäkirjojen nykyisestä käytöstä, käytön ongelmista ja tarpeista, joita projektipöytäkirjojen käytölle projektinhallinnassa olisi. Haastateltavia henkilöitä on yhteensä kymmenen. Haastattelujen ongelmaksi saattaa kuitenkin muodostua se, etteivät kaikki haastateltavat osaa kertoa todellisista tarpeistaan. Tämän takia haastattelujen lisäksi käytetään lähteissä /3, 29/ esiteltyä työhön tutustumis- menetelmää. Menetelmän ajatuksena on työn seuraaminen sekä kysymyksien esittäminen sen tekijöille ja sitä kautta varsinaisten tarpeiden kartoittaminen. Menetelmässä työtä opetellaan sen verran, että selviää, mitä voi tehdä paremmin. Haastattelujen ja tutustumismenetelmän perusteella valitaan tärkeimmät tarpeet, joiden perusteella selvitetään luvussa 6.2 esitellyn rakenteisen pöytäkirjamallin mahdollisuuksia sekä hyödyllisyyttä. Tarpeet ja niihin liittyvät ongelmat on esitellään luvuissa Tiedon käyttömahdollisuudet Tiedon käyttömahdollisuuksia tässä työssä tutkitaan aiemmin esiintulleiden tarpeiden perusteella. Koska kyseessä on täysin uuden käyttömahdollisuuden tutkiminen, käytetään lähteessä /10/ esiteltyä skenaariomenetelmää. Skenaariomenetelmässä testikäyttäjille esitellään erilaisia käyttömahdollisuuksia ja käyttäjät saavat sanoa mielipiteensä tutkittavan ohjelman, systeemin tai rakenteen soveltuvuudesta kyseiseen skenaarioon. Menetelmä soveltuu etenkin tapauksiin, joissa halutaan tutkia uuden informaatiosysteemin vaikutusta joko organisaatioon, yksilöön tai yhteiskuntaan. Tutkimusta varten syötetään 30 vanhaa projektipöytäkirjaa rakenteiseen muotoon XML (extensible Markup Language) - kielellä. Pöytäkirjat valitaan siten, että niissä esiintyy kaikkia dokumenttianalyysin tuloksena saatuja tietotyyppejä mahdollisimman kattavasti. Myös kaikki kokoustyypit ovat edustettuina. Syöttämiseen käytetään XML Spy ohjelmaa. Pöytäkirjojen käsittelyä varten luodaan Jaakko Pöyry Oy:n tarkoituksiin soveltuva dokumentin rakennekuvaus (Document Type Definition, DTD). DTD tehdään siten, että se noudattaa työssä tehtyä rakenteista pöytäkirjamallia.

10 8 Käyttömahdollisuuksien tutkimista varten tehdään ohjelma, jolla voidaan tehdä hakuja XML-muotoisista pöytäkirjoista. Ohjelman toteutus- ja käyttöperiaatteet esitellään luvussa 6.4. Skenaariotutkimus tehdään käyttäjätutkimuksena kuudelle henkilölle. Testikäyttäjät ovat sekä projektinhallinnan että tuotekehityksen parissa työskenteleviä henkilöitä. Testikäyttäjien määräksi on valittu kuusi, koska siten testeihin saadaan edustaja kaikista Jaakko Pöyry Oy:n erityyppisistä projekteista. Toisaalta, koska tutkitaan vasta mahdollisuuksia ja testihenkilöiltä vaaditaan osaamista projektinhallinnan alalta, ei ole perusteltua tehdä testejä useampien henkilöiden kanssa. Skenaarioina käytetään aikaisemmin kartoitettuja tarpeita ja niihin liittyviä esimerkkitilanteita. Rakenteiseen muotoon syötetyistä pöytäkirjoista tehdään ohjatussa tilaisuudessa hakuja ja testihenkilöt kertovat samalla, miten tehtyjen hakujen tuloksia voitaisiin projektinhallinnassa hyödyntää ja miten hyödyllisiksi he saadut tulokset kokevat kartoitettuja tarpeita ajatellen. Hyödyllisyyttä arvioidaan asteikolla: erittäin hyödyllinen melko hyödyllinen jonkin verran hyödyllinen ei lainkaan hyödyllinen. Skenaariotutkimuksen lisäksi käyttäjät saavat tehdä vapaita hakuja ja esittää parannusehdotuksia. Tulokset esitellään luvuissa

11 9 3 PROJEKTINHALLINNAN PERUSKÄSITTEITÄ 3.1 Projekti Sanalle projekti löytyy kirjallisuudesta useita määritelmiä. Tässä työssä käytetään ISO standardissa /13/ olevaa määritelmää, jonka mukaan Projekti on ainutkertainen prosessi, joka käsittää joukon koordinoituja, ohjattuja ja valvottuja tehtäviä, joilla on alku- ja loppupäivämäärät ja jonka tuloksena syntyy ainutlaatuinen tuote tai palvelu. Projekti ei siis määritelmänsä mukaisesti voi toistua samanlaisena. Projekteista saatua oppia voidaan kuitenkin hyödyntää tulevissa projekteissa tehokkaan tiedonhallinnan avulla. Projektin määritelmää voidaan vielä täsmentää seuraavien, Project Management Body of Knowledge 2000:ssa /28/ mainittujen, kohtien avulla: projektin suorittavat aina ihmiset, projektin resurssit ovat rajatut ja projektiin kuuluu selkeä jako: suunnittelu-toteutus-valvonta. 3.2 Projektin elinkaari Kuten projekti, myös sen elinkaari voidaan määritellä monella eri tavalla. Tässä työssä käytetään Jaakko Pöyry Oy:n ohjeistuksen /14/ mukaista määritelmää, jossa projektin voidaan ajatella jakautuvan seuraavaan neljään vaiheeseen: kehitys, toteutus, tuotanto ja rationalisointi eli uusinta. Työssä käytetty projektin elinkaarimalli on esitetty kuvassa 1. Projektin elinkaari alkaa liikeideasta. Kehitysvaiheessa liikeidean soveltuvuutta toteutettavaksi tutkitaan esimerkiksi kannattavuusselvitysten avulla. Kehitysvaihe voidaan edelleen jakaa kolmeen vaiheeseen: ideointi, esiselvitys ja esisuunnittelu. Jokaisessa vaiheessa tehdään kannattavuusselvitys ja idea etenee seuraavaan vaiheeseen vain, jos se todetaan kannattavaksi jollain määritellyllä kriteerillä. Tyypillistä kullekin vaiheelle on, että sen lopussa on useita ideoita tai suunnitelmia, joista vain parhaat etenevät seuraavaan vaiheeseen. Kehitysvaiheen tavoitteena on siis tehdä kattava selvitys siitä, kannattaako tiettyä liikeideaa lähteä toteuttamaan. Esisuunnitteluvaiheessa käynnistetään jo varsinaisen toteutuksen valmistelu, esimerkiksi laatimalla alustava ehdotus projektin pääaikatauluksi sekä alustava projektisuunnitelma. Ajatuksena tässä on edelleen selvittää projektin kannat-

12 10 tavuutta, mutta myös nopeuttaa toteutusvaiheen käynnistymistä. Mikäli liikeidea on tarpeeksi hyvä, kehitysvaiheen lopuksi tehdään investointipäätös ja varsinainen projekti alkaa. /14, 30/ Kuva 1. Projektin elinkaari /14/ Toteutusvaiheessa projektin aikataulun mukaiset vaiheet toteutetaan. Toteutusvaiheeseen kuuluvat esimerkiksi varsinaisen projektisuunnitelman yksityiskohtainen laatiminen, tarvittavat hankinnat, tekninen tai muu tuotteeseen liittyvä toteutus ja testaus. Lisäksi toteutusvaiheeseen kuuluvat projektin hallintaprosessit kuten muutosten ja riskien hallinta, kommunikaation hallinta, kustannusvalvonta ja henkilöstön hallinta. Projektin hallintaprosessit esitellään tarkemmin luvussa 3.5. Toteutusvaiheen päätteeksi projektin tuote luovutetaan asiakkaalle. /2, 13, 14/ Tuotantovaiheessa projektin tuotetta kehitetään edelleen. Tuote on siis käytössä, mutta jos tarvetta ilmenee, tuotteeseen voidaan vielä tehdä muutoksia ja sen toimintaa voidaan parantaa. Tuotantovaiheen alkuun kuuluu myös tuotteen käyttöönotto ja siihen liittyvät prosessit. Käyttöönoton jälkeen varsinainen projekti päättyy. Projektin elinkaaren voidaan kuitenkin ajatella jatkuvan, sillä esimerkiksi kokonaiskannattavuuteen ja kunnossapitoon liittyvät tukitoiminnot ja jatkokehitys usein jatkuvat myös tästä eteenpäin. /13, 14/ Rationalisointi- eli uusintavaiheen aikana projektin tuote on edelleen tuotannossa. Kysynnän ja tarjonnan tuleva kehitys markkina-alueittain ja tuotteittain sekä tuotteen hintataso vaikuttavat siihen, milloin sen tuotanto kuitenkin lakkautetaan ja projektin elinkaari saadaan päätökseen. /14/

13 Projektityypit Vaikka tässä työssä pyritään saamaan aikaan sellaisia ratkaisuja, jotka soveltuvat kaikentyyppisille projekteille, on kuitenkin syytä jakaa projektit luokkiin, koska tiedontarve erilaisissa projekteissa saattaa olla varsin erilainen. Tätä tarkoitusta varten on lähteessä /30/ esitelty malli, jossa projektit jaetaan neljään ryhmään niiden tavoitteiden ja toimintatapojen mukaisesti. Malli soveltuu hyvin tähän työhön, sillä pääasialliset tiedontarpeet projektin aikana liittyvät juuri projektin tavoitteisiin ja projektin toimintatapoihin. Tämä tavoite-toiminta matriisi on esitetty kuvassa 2. Kuva 2. Tavoite-toiminta matriisi /30/ Tavoite-toiminta matriisin avulla projektit voidaan jakaa neljään ryhmään /26, 30/: Ryhmä 1: Ryhmän projekteissa sekä tavoite että toimintatavat ovat hyvin määriteltyjä. Esimerkiksi monet rakennusprojektit kuuluvat tähän ryhmään. Ryhmän projekteille tyypillistä on, että vastaavanlaisia projekteja on tehty aikaisemminkin ja vanhoista projekteista saatu tieto on hyödynnettävissä. Koska toiminta on selkeää ja hyvin suunniteltua, tärkeintä tietoa projektin etenemisen kannalta ovat aikataulut ja edistymisraportit. Ryhmä 2: Tämän ryhmän projekteissa tavoitteet ovat selkeät, mutta toimintatavat eivät ole. Tyypillinen esimerkki ryhmän projektista on tuotekehitysprojekti. Tärkeää tietoa ovat erityisesti tehdyt toimenpiteitä koskevat päätökset sekä oppimisen kannalta toimenpiteiden seuraukset.

14 12 Ryhmä 3: Toimenpiteet on hyvin määritelty mutta tavoite ei ole. Esimerkiksi useat konsultointiprojektit kuuluvat tähän ryhmään. Tärkeää on pyrkiä selvittämään projektin todellinen tavoite. Tärkeää tietoa ovat mahdolliset muutokset tavoitteissa ja muutosten aiheuttamat uudet toimenpiteet. Ryhmä 4: Ryhmän projekteissa sekä tavoitteet että toimintatavat on huonosti määritelty. Esimerkiksi tutkimusprojektit kuuluvat usein tähän ryhmään. Tässä ryhmässä on tärkeää tiedottaa, mitä on tehty, mitä siitä on seurannut ja mitä seuraavaksi pitää tehdä. Todellisuudessa suuret projektit ovat usean ylläesitellyn projektityypin kombinaatioita. Vastaavasti siis myös tiedon tarve voi olla yhdistelmä useamman projektityypin eri tarpeista. Tiedon tarpeen määrä ja kiireellisyys kasvavat mentäessä tavoite-toiminta matriisissa ylös ja oikealle. Vastaavasti kasvavat myös riskien määrä ja projektin epäonnistumisen todennäköisyys. /2, 26, 30/ 3.4 Projektin osapuolet Luvussa 4 tarkastellaan viestintää ja tiedontarvetta projekteissa. Tarkastelun pohjana on ISO standardin /13/ mukainen jaottelu tyypillisen projektin osapuolista. Tämä on esitetty kuvassa 3. Kuva 3. Projektin osapuolet /13/ Projektin asiakkaaksi tai omistajaksi kutsutaan osapuolta, joka ostaa tai rahoittaa projektin. Projektilla on aina asiakas, joko yrityksen sisäinen henkilö tai osasto tai ulkoinen yritys. Asiakkuuden voidaan myös ajatella jakautuvan usealle tasolle /2/. Tarkastellaan esimerkkiä, jossa asiakasyritys ostaa projektin tuotteena paperitehtaan. Tällöin asiakkaita voidaan ajatella olevan projektin rahoittaneen yrityksen lisäksi ainakin tulevan tehtaan

15 13 työntekijät sekä tehtaan tuottaman paperin ostajat. Toisaalta näitä osapuolia voidaan myös ajatella erillisinä käyttäjinä, jotka eivät varsinaisesti ole projektin asiakkaita. Projektin suunnittelussa ja hallinnassa asiakkaan tarpeiden tulisi olla etusijalla ja siis myös projektin viestinnän suunnittelun on lähdettävä asiakkaan näkökulmasta. Pääkonsultti on osapuoli, joka hoitaa suurimman osan kommunikaatiosta projektin osapuolten välillä. Pääkonsultti siis tavallaan tarjoaa rajapinnan asiakkaan ja muiden osapuolten välille. Kaikissa projekteissa ei ole pääkonsulttia ja asiakkaasta riippuen pääkonsultin rooli vaihtelee projektin kaikkien asioiden hoitamisesta yksittäisten asioiden konsultointiin. Kirjallisuudessa pääkonsulttia kutsutaan myös usein suorittavaksi organisaatioksi, jolla tarkoitetaan sitä projektin osapuolta, joka tekee suurimman osan projektiin liittyvästä työstä ja koordinoinnista /2, 28/. Pääkonsultin lisäksi projektissa voi olla yksi tai useampi muu konsultti. Käytännössä jokainen näistä hoitaa tiettyä kapeaa erikoisalaa. Etenkin suurissa projekteissa voi olla useita konsultteja. /2, 13/ Toimittaja ja urakoitsija voivat olla kaksi eri osapuolta tai yksi osapuoli voi edustaa näitä molempia. Toimittajan tehtävänä on toimittaa projektissa tarvittavia erillisiä osia, komponentteja, palveluita tai raaka-aineita. Projektin koosta riippuen ulkopuolisia toimittajia on useimmiten enemmän kuin yksi ja jokaisella on melko pieni oma erikoisalansa. Urakoitsijan tehtävä projektissa on hoitaa projektiin liittyvä rakennustyö tai osa siitä. /2, 13, 26/ Viranomaisten tehtävänä projektissa on valvoa, että projektissa noudatetaan erilaisia lakeja ja määräyksiä, esimerkiksi ympäristö- ja työsuojeluvaatimuksia Viranomaiset myös myöntävät projektiin liittyvät luvat, esimerkiksi rakennus- ja poikkeusluvat. /13, 26/ Projektin muita osapuolia voivat olla esimerkiksi rahoittajat, yliopistot, korkeakoulut, tutkimuslaitokset, yhteistyöyritykset tai tiedotusvälineet. Projektin koosta riippuen näiden määrä vaihtelee. /2, 13/ 3.5 Projektin hallintaprosessit Tässä työssä käytetään termistä projektinhallinta Project Management Body of Knowledge 2000:n /28/ mukaista määritelmää, jonka mukaan Projektinhallinta on tietojen, taitojen, työkalujen sekä tekniikoiden käyttämistä projektin tehtäviin siten, että pyritään saavuttamaan projektin tavoitteet ja saavuttamaan tai ylittämään osapuolten tarpeet tai odotukset. Käytännössä projektin osapuolten kaikkien tarpeiden saavuttaminen tai ylittäminen vaatii tasapainottamista toisilleen ristiriitaisten tai kilpailevien vaatimusten välillä. Merkittävimmät projektiin kohdistuvat vaatimukset ovat seuraavat /2/:

16 14 projektin tavoitteet eli sen laajuus, aika ja kustannukset, projektin osapuolten toisistaan eroavat edut sekä asiakkaan tiedostetut vaatimukset ja tiedostamattomat vaatimukset projektin tuotteelle. Projektinhallinta voidaan edelleen lähteestä riippuen luokitella yhdeksään tai kymmeneen tietämysalueeseen tai hallintaprosessiin. Joissakin lähteissä laitteistoresurssien hallinta lasketaan erilliseksi hallintaprosessiksi kun taas toisissa se katsotaan osaksi hankintojen hallintaa. Pääpiirteissään kuitenkin käytetyissä lähteissä noudatettiin seuraavissa kappaleissa esiteltyä luokittelua. /2, 13, 26, 28, 30/ Projektin eheyden hallintaan kuuluvat ne toimenpiteet, joilla varmistetaan projektin kunnollinen koordinointi. Esimerkiksi projektin organisointi ja avainhenkilöiden valinta, projektisuunnitelman laatiminen ja sen toteuttaminen, sekä näiden toimenpiteiden valvonta ja raportointi kuuluvat projektin eheyden hallintaan. Projektin laajuudella tarkoitetaan käytännössä projektin tuotetta, sen tarkoitusta ja siihen liittyviä toimenpiteitä. Projektin laajuuden hallintaan siis kuuluvat esimerkiksi laajuuden määrittely ja varmennus sekä mahdollisten laajuuteen liittyvien muutosten hallinta. Projektin aikataulujen hallintaan kuuluvat aikataulujen laatiminen, tehtävien järjestäminen siten, että ne voidaan aikatauluttaa sekä aikataulujen valvonnan kautta projektin edistymisestä raportoiminen. Aikataulujen hallintaa ovat myös mahdollisten aikataulumuutosten ennakoiminen sekä niiden aiheuttamien vaikutusten analysointi ja liityntöjen selvittäminen projektin muihin osapuoliin, aikatauluihin tai kustannuksiin. Kustannusten hallinta projektissa tarkoittaa kaikkia niitä toimenpiteitä, joita tarvitaan projektin suorittamiseen budjetin mukaisesti. Näitä toimenpiteitä ovat esimerkiksi kustannusarvioiden laatiminen, niiden valvominen ja niistä raportoiminen. Projektin laadunvalvonnan tehtävänä on varmistaa, että projekti täyttää ne tavoitteet tai vaatimukset, jotka sille on määritelty. Laadun hallintaan siis kuuluvat esimerkiksi laatusuunnittelu, laadun varmistaminen ja laadunvalvonta. Laadun hallinta ei kuitenkaan ole yksittäinen prosessi vaan osa kaikkia muita hallintaprosesseja. Henkilöstöresurssien hallinnalla tarkoitetaan projektissa työskentelevien henkilöiden tietojen ja taitojen hyödyntämistä mahdollisimman tehokkaasti. Laitteistoresurssien hallinta taas käsittää ne toimenpiteeet, joita tarvitaan riittävien työkalujen hankintaan ja ylläpitoon. Varsinainen laitteiden, ohjelmien ja muiden työkalujen hankinta voidaan katsoa kuuluvan hankintojen hallintaan, mutta niiden koordinointi ja ylläpito kuuluvat laitteistoresurssien hallintaan.

17 15 Viestintä projekteissa on alue, johon vasta viime aikoina projektien laajuuksien kasvaessa on kiinnitetty enemmän huomiota. Projektin viestinnän hallinnalla tarkoitetaan viestinnän suunnittelua ja valvontaa, viestinnän koordinointia sekä projektin tiedonhallintaa. Viestinnästä projekteissa sekä sen hallinnasta kerrotaan enemmän luvussa 4. Projektin riskien hallinnalla tarkoitetaan niitä toimenpiteitä, joita tarvitaan projektin riskien tunnistamista ja analysointia varten sekä toimenpiteitä, joilla riskeiltä suojaudutaan tai joihin ryhdytään riskien toteutuessa. Koska muutokset useimmiten seuraavat riskien toteutumisesta, katsotaan myös muutosten hallinnan kuuluvan osaksi riskien hallintaa. Hankintojen hallinta käsittää ne toimenpiteet, joilla varmistetaan ulkopuolisilta toimittajilta tulevien raaka-aineiden, komponenttien ja palveluiden saanti. Näitä toimenpiteitä ovat esimerkiksi hankintojen suunnittelu, toimittajien kanssa neuvottelu, sopimusneuvotteluiden täytäntöönpanon valvonta ja raportointi sekä tilausmuutosten käsittely ja hallinta.

18 16 4 VIESTINTÄ PROJEKTEISSA 4.1 Viestintäprosessi Projekteissa tapahtuvaa viestintää ja tiedon syntymistä voidaan kuvata taulukossa 2 esitetyn matriisin avulla. Matriisin viitekehys on lähteestä /12/ ja se esiteltiin tarkemmin taulukossa 1. Taulukko 2. Projektissa syntyvän tiedon ulottuvuudet /7, 12, 25, 26, 31/ Viestintäprosessi Informaatio Tietämys Asiatieto, faktat (mitä asioista tiedetään) Projektin osapuolet Peruskäsitteet Osapuolten väliset yhteydet Viestinnässä käytetyt välineet Dokumentit Keskustelut Kokoukset Informaatiojärjestelmät Informaation määrä Tiedon lähteet Viestinnän sisältö Tiedon kohderyhmät Toiminnallinen tieto (miten asiat toimivat) Strateginen tieto (miksi asiat toimivat näin) Informaation hankinta Esitettävän informaation valinta Informaation muokkaus Sopivien kokonaisuuksien koostaminen Viestinnän tarkoitus Viestinnän muoto ja välineet Tulevaisuuden suunnitelmat, skenaariot Viestinnän hallinta Informaation kulku Osapuolten vuorovaikutus Aikaisempi viestintä Informaation tarkoitus Päätökset Perustelut Viestinnän kohdistaminen Projektin tavoitteet Asiatiedolla tarkoitetaan perusasioita, jotka prosessista tiedetään. Asiatietoa projektin viestintäprosessista ovat esimerkiksi projektin osapuolet sekä yhteydet heidän välillään. Toiminnallista tietoa ovat viestintäprosessin vaiheet ja strategista tietoa viestinnän

19 17 tarkoitus sekä tarkoitusta tukevat keinot, kuten viestinnän hallinta ja muoto sekä viestinnän hallinnassa käytetyt menetelmät. Seuraavalla tasolla on projektin viestintäprosessissa kulkeva informaatio. Projekteissa virallinen informaatio kulkee pääasiallisesti dokumenteissa ja kokouksissa /27/. Epävirallista informaatiota taas ovat esimerkiksi kahden osapuolen väliset keskustelut tai sähköpostiviestit /27/. Asiatietoa ovat lisäksi informaation hallinnassa käytetyt menetelmät. Toiminnallista tietoa ovat informaation syntymiseen liittyvät asiat, esimerkiksi projektin osapuolten väliset yhteydet ja aikaisempi viestintä, sekä informaation kulku ja elinkaari projektissa. Strategista tietoa on informaation tarkoitus. Informaation olemassaolon pääasiallinen tarkoitus on tietämyksen tarjoaminen. Projektin viestintäprosessin seuraava taso on tietämys, joka informaatiosta syntyy. Tällä tasolla asiatietoa ovat tiedon lähteet, viestinnän sisältö ja viestinnän kohderyhmät. Toiminnallista tietoa ovat tietämyksen syntyyn liittyvät toiminnot, eli viestinnän kohdistaminen sekä viestintäprosessiin liittyvät päätökset perusteluineen. Strategista tietoa projektin viestintäprosessin tietämystasolla on projektin tarkoitus. Projektin kokousprosessia ajatellen taulukon 2 alueista tärkeää on tuntea projektin osapuolet, projektin osapuolien välinen viestintä ja sen tarkoitus sekä informaation kulku projektin eri vaiheissa. Projektin osapuolet esiteltiin kohdassa 3.4. Kohdassa 4.3 tarkastellaan projektin viestintäprosessin tärkeitä osa-alueita. Kohdassa 4.4 tarkastellaan erikseen projektin viestinnän hallintaa yhtenä projektin hallintaprosessina sekä tutustutaan yhteen projektin viestinnän hallinnassa käytettyyn tekniikkaan. Pöytäkirjan käyttöön ja asemaan projektin viestinnän välineenä tutustutaan kohdassa Tieto ja informaatio sekä niiden hallinta Peruskäsitteitä Kirjallisuudesta voidaan käsitteelle tieto löytää useita määritelmiä. Platonin klassisen tietoteorian mukaan tieto on hyvin perusteltu tosi uskomus. Lähteessä /9/ tietämys on määritelty siten, että siihen kuuluvat: 1) Alan tosiasiat, alan harjoittajien yleisesti hyväksymät tiedot, jotka on kirjattu oppikirjoihin ja ammattijulkaisuihin ja jotka muodostavat alan professorien luentojen perustan. 2) Heuristinen tieto, kokemuksen ja hyvän arvostelukyvyn tuottama alan tieto. Tämän työn kannalta oleellista on erottaa toisistaan käsitteet data, informaatio ja tieto. Työssä käytetään määritelmiä lähteestä /20/. Informaatio voidaan jakaa alaluokkiin. Näitä luokkia ovat ei-kielellinen informaatio, eli fysikaalisen tai henkisen maailman järjestyneisyys, informaatiota kantavat merkit tai merkkijonot, eli data sekä kielellinen informaatio. Kielellinen informaatio jakautuu edelleen syntaktiseen, semanttiseen ja prag-

20 18 maattiseen informaatioon. Syntaktisella informaatiolla tarkoitetaan informaation rakennetta, eli siinä esiintyvien merkkien esiintymistiheyttä. Semanttinen informaatio ilmaisee väitelauseen ilmaisuvoimaa tai sisältöä. Pragmaattisella informaatiolla taas tarkoitetaan lauseen sisällöllistä merkityksellisyyttä kielen käyttäjälle. Tieto tai tietämys on informaation suppeampi erikoistapaus, johon liittyy perusteltavuus, totuudenmukaisuus sekä jonkinlainen ymmärrys. Kuva 4. Informaatiohierarkia viestintäprosessissa /25/ Kuvassa 4 on esitetty informaatiohierarkia viestinnässä. Datan, informaation ja tietämyksen lisäksi informaatiohierarkiaan kuuluu viisaus. Viisaus on filosofinen käsite, jonka määrittely ei kuulu tämän työn aihepiiriin Informaation hallinta Edellisessä luvussa esitettyjen määritelmien perusteella informaationhallinta voidaan ajatella prosessiksi, jossa sisääntulona on järjestämätön informaatio tai data ja ulostulona tietoa tai tietämystä. Informaationhallinnan tarkoituksena siis on järjestää informaatio tai data saataville siten, että se muuttuu tiedoksi tai tietämykseksi sitä hakevalle, selaavalle ja lukevalle henkilölle. Aiemmin määriteltyjen käsitteiden mukaan informaationhallinta ei ole sama asia kuin datanhallinta, siis esimerkiksi pelkkä tietokone ei ole informaation hallintajärjestelmä, koska se osaa käsitellä ainoastaan dataa. Sen sijaan, kun ihminen syöttää tai käsittelee informaatiota tietokoneen avulla, voidaan jo puhua informaation hallintajärjestelmästä. Informaation hallintaprosessin perusajatus on esitetty kuvassa 5. Informaation hallintaa ei kuitenkaan voida ajatella pelkästään joukoksi yksittäisiä toimenpiteitä, joita informaation hallintaan koulutetut ihmiset informaatiolle tekevät. Yritysten suuntaukset kohti verkottuneita yhteisöjä, uudet tietotekniset ratkaisut ja informaation kasvava määrä aiheuttavat sen, että informaatiota työkseen käsittelevien ihmisten määrä kasvaa. Siksi informaation hallinta yrityksessä pitää ennemminkin nähdä toimenpiteinä,