PROJEKTIKOKOUKSISSA SYNTYVÄN TIEDON HALLINNAN ...

TEKNILLINEN KORKEAKOULU 

Automaatio- ja systeemitekniikan osasto 

Heidi Pehu-Lehtonen 

ÄLYKKÄÄT PÖYTÄKIRJAT - 

PROJEKTIKOKOUKSISSA SYNTYVÄN TIEDON 

HALLINNAN TEHOSTAMINEN RAKENTEISEN 

DOKUMENTINHALLINNAN AVULLA 

Diplomityö 31.1.2002 

Työn valvoja Professori Pirkko Oittinen 

Työn ohjaaja DI Erik Rosenlew, Inforbis Oy

Työn nimi: 

Älykkäät pöytäkirjat - projektikokouksissa syntyvän tiedon hallinnan 

tehostaminen rakenteisen dokumentinhallinnan avulla 

Päivämäärä: 31.1.2002 

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

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

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.

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

(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

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.

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 4.3-4.5. 

2.2 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

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 5.2 - 5.4 ja rakenteisen projektipöytäkirjan 

malli luvussa 6.2. 

2.3 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 7.2-7.6. 

2.4 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 4.0.1 

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.

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 7.2-7.6.

9 

3 PROJEKTINHALLINNAN PERUSKÄSITTEITÄ 

3.1 Projekti 

Sanalle projekti löytyy kirjallisuudesta useita määritelmiä. Tässä työssä käytetään ISO 

10006 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-

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/

11 

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

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 10006- 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

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/:

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.

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.

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) 


(miksi asiat 

toimivat näin) 


hankinta 

• Esitettävän 

informaation 

valinta 


muokkaus 

• Sopivien 

kokonaisuuksien 

koostaminen 


tarkoitus 


muoto ja 

välineet 

• Tulevaisuuden 

suunnitelmat, 

skenaariot 


hallinta 


kulku 

• Osapuolten 

vuorovaikutus 

• Aikaisempi 

viestintä 


tarkoitus 

• Päätökset 

• Perustelut 


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

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

4.2 Tieto ja informaatio sekä niiden hallinta 

4.2.1 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-

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. 

4.2.2 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ä,

19 

jotka ulottuvat kaikille organisaatiotasoille ja jotka ovat muutakin kuin informaation 

syöttäminen ja järjestäminen, esimerkiksi johtamis- tai neuvottelukäytännöt. /18, 23/ 

Kuva 5. Informaation hallintaprosessi 

Organisaatioissa sanotaan olevan kolmenlaista tietoa tai tietämystä. Hiljaiseksi tai 

piilotietämykseksi (tacit knowledge) kutsutaan sellaista tietoa, joka on sidottu tiettyyn 

henkilöön tai ryhmään ja jota on vaikeaa jakaa muille. Tällaista tietoa on usein pitkään 

organisaatiossa olleilla henkilöillä, joille on karttunut paljon kokemusta työstään. Piilotietämystä 

on myös yksilön henkinen pääoma tai lahjakkuus. Piilotietämystä tai jopa 

kuollutta tietämystä on myös kaikki sellainen sähköisesti tai manuaalisesti arkistoitu 

projekti- ja käsikirjatietämys, mikä on vaikeasti haettavissa projektiorganisaation käyttöön 

tai minkä olemassaolosta projektiorganisaatio ei useasti edes tiedä tai saa tietoa. 

Avointa tietoa (explicit knowledge) ovat esimerkiksi organisaation rutiinit, säännöt ja 

standardit. Avoimelle tiedolle on tyypillistä, että sitä on helppo jakaa ja levittää muille ja 

se voidaan ilmaista esimerkiksi dokumentein. Kulttuurista tietoa (cultural knowledge) 

taas ovat esimerkiksi organisaation arvot ja työskentelytavat. /5, 22/ 

Informaation hallinnan ongelmallista suhdetta organisaatioissa olevaan tietämykseen 

voidaan kuvata esimerkiksi kuvassa 6 esitellyn kaavion avulla. Kaavion /15/ ajatuksena 

on, että informaation hallintaan käytettävien järjestelmien lisääntymisen myötä avoimen 

tiedon merkitys korostuu. Tämä on hyvä asia, sillä mitä enemmän organisaatiossa olevaa 

tietoa voidaan muuttaa avoimeen muotoon, sitä paremmin se on kaikkien käytettävissä ja 

hyödynnettävissä paremman kilpailuedun saavuttamiseksi. Avoimen tiedon lisääntyminen 

ei kuitenkaan tarkoita sitä, että hiljainen tieto muuttuisi avoimeksi, vaan pikemminkin 

saattaa aiheuttaa sen, että se jää käyttämättä. Tämä taas ei ole hyvä asia, sillä hiljaisella 

tiedolla on suuri merkitys organisaation suorituksen kannalta. Jos hiljainen tieto jää 

käyttämättä, tarvittaan parempia informaation hallintajärjestelmiä saman lopputuloksen 

saavuttamiseksi. 

Yllä esitetty näkökulma pyritään ottamaan huomioon tässä työssä siten, että tietoa 

ryhmiteltäessä ei tehdä niin jäykkiä ratkaisuja, että ne estävät hiljaisen tiedon saattamista 

avoimeen muotoon. Käytännössä tämä tarkoittaa, että projektipöytäkirjojen syöttämistä 

varten ei laadita jäykkää pohjaa, johon tieto on syötettävä, vaan järjestäminen tapahtuu 

ainoastaan tietotyypin tunnistamisen avulla. Silloin tiedon syöttäjä voi syöttää tiedon 

haluamaansa muotoon ja ainoastaan ilmoittaa, että kyseessä on esimerkiksi päätös. 

Tällöin kynnys hiljaisen tiedon saattamiseksi avoimeen muotoon laskee /21/.

20 

Kuva 6. Informaation hallinnan suhde organisaation tietämykseen /15/ 

4.2.3 Tietämys projekteissa 

Lähteessä /6/ on esitetty projekteihin liittyvän tietämyksen jakamista kolmeen osaan: 

tietämys projektista, projektissa oleva tietämys sekä projekteista saatava tietämys. Tämä 

kolmijako on esitetty kuvassa 7. 

Tietämystä projektista käytetään projektin hallintaan. Tällaista tietämystä ovat esimerkiksi 

projektin aikataulut, organisaatio, suunnitelmat ja työskentelytavat. Myös organisaation 

kulttuurinen tietämys kuuluu hyvin pitkälti tähän luokkaan. Etenkin projektin työskentelytapoihin 

liittyy paljon hiljaista tietämystä. Monet projektiorganisaation osapuolet voivat 

olla kokeneita projektinjohtajia tai työntekijöitä ja heidän hiljainen tietämyksensä projektin 

hallintaan liittyvissä asioissa korvaamatonta. /6, 22/ 

Tietämys projektissa liittyy projektin senhetkiseen suorittamiseen ja toimii projektin työn 

onnistuneen läpiviennin välineenä. Projektikokoukset ja niistä tehtävät dokumentit, tehtävälistat 

sekä tilanneraportit ovat tyypillisiä esimerkkejä tällaisista työvälineistä. Projektissa 

olevan tietämyksen lähteenä ovat projektin työntekijät ja mahdolliset asiantuntijat. /5, 

6/ 

Projektista saatava tietämys on tärkeää tulevia projekteja ajatellen. Tällaista tietämystä 

ovat esimerkiksi aikaisemmissa projekteissa käytetyt työskentelytavat sekä tehdyt virheet 

ratkaisuineen ja seurauksineen. Kolmesta projektin tietämysalueesta tällä alueella on 

eniten hiljaista tietoa ja siksi projektista saatavan tietämyksen hallinta on vaikeampaa 

kuin kahden muun edellä esitetyn alueen. /5, 6/

21 

Kuva 7. Projekteihin liittyvä tietämys /6/ 

4.3 Viestintä ja tiedon kulku projekteissa 

Kuvassa 8 on esitetty tämän työn puitteissa tyypillinen esimerkki siitä, kuinka projektin 

osapuolet kommunikoivat keskenään. Esimerkki on kuvattu pääkonsultin näkökulmasta. 

Suurin osa projektin osapuolten viestinnästä kulkee pääkonsultin kautta. Näin saadaan 

kootusti kaikki informaatio yhdelle osapuolelle. Kuten luvussa 3.4 todettiin, pääkonsultti 

siis toimii eräänlaisena rajapintana etenkin asiakkaan ja muiden osapuolten välillä. 

Käytännössä projektin muut osapuolet harvoin kommunikoivat keskenään ellei asian 

luonne kilpailutekijöistä tai eturistiriidoista johtuen niin vaadi. Tällaisia asioita saattavat 

olla esimerkiksi lopulliset hintaneuvottelut asiakkaan ja toimittajan välillä. /27/ 

Kuva 9 kuvaa projektin yhden yksittäisen osapuolen sisäistä kommunikaatiota sekä informaation 

tarvetta eri organisaatiotasoilla. Vasemmalla kuvassa on kuvattu informaation 

kulku. Projektiorganisaatiossa informaatio kerätään itse tapahtumapaikalta eli työnjohtajilta 

ja -tekijöiltä. Mentäessä organisaatiossa ylöspäin informaation määrän tarve ja sen 

kiireellisyys pienenevät. Vastaavasti ohjeet ja päätökset kulkevat projektiorganisaatiossa 

alaspäin. Oikealla kuvassa on kuvattu informaation tarve. Kahdella ylimmällä tasolla 

informaation tarve yksittäisistä projekteista rajoittuu tiivistettyihin yhteenvetoihin ja 

avaininformaatioon. Projektin johdon tehtävä on huolehtia siitä, että riittävä määrä 

informaatiota kulkee organisaatiossa sitä tarvitseville osapuolille. /26/

22 

Kuva 8. Esimerkki projektin osapuolten välisestä viestinnästä 

Projektin elinkaaren aikana viestinnän sisältö painottuu eri asioihin. Projektin alussa eli 

kehitysvaiheessa sekä toteutusvaiheen alussa tärkeitä asioita ovat projektin tavoitteet ja 

vastuut, hinta- ja hankinta-asiat sekä projektiin liittyvät suunnitelmat. Toteutusvaiheessa 

viestinnän sisältö painottuu tilannekatsauksiin ja niistä seuraaviin muutoksiin, avaintehtäviin, 

projektin tapahtumiin ja raportointiin. Projektin päätösvaiheessa tärkeitä 

viestintään liittyviä asioita ovat projektin tulos, tuotteen käyttöönottoon liittyvät tehtävät 

ja raportit sekä projektin osapuolilta saatu palaute. /26/ 

Kuva 9. Projektiorganisaation informaatiotarve /26/ 

Kuvassa 10 on esitetty malli tiedon kululle projekteissa. Malli perustuu lähteessä /16/ 

esitettyyn malliin tiedon kulusta tehdasprojektin elinkaaren eri vaiheissa.

23 

Kuva 10. Tiedon kulku projektin elinkaaren eri vaiheiden välillä /16/ 

Projektin elinkaaren kehitys- ja toteutusvaiheessa syntynyt tieto on hyödynnettävissä sekä 

tuotantovaiheessa että seuraavassa projektissa. Tuotantovaiheessa syntyy toimintakokemusta 

ja huoltohistoriaa, joista myös voidaan oppia seuraavaa projektia varten. Mikäli 

seuraava vastaavanlainen projekti käynnistyy, kun edellisen projektin tuote on vielä 

tuotannossa, uudessa projektissa syntyvää tietämystä voidaan hyödyntää vanhan jatkokehityksessä 

sekä ylläpidossa. Tarvitaan kuitenkin hyvää tiedonhallintaa, jotta projekteissa 

liikkuva tietämys saataisiin liikkumaan tehokkaasti projektin elinkaaren eri 

vaiheiden välillä ja että sitä voitaisiin hyödyntää tulevissa projekteissa. /6, 16/ 

4.4 Viestinnän hallinta projektissa 

4.4.1 Viestinnän hallintaprosessi 

Projektin viestinnän hallintaa varten on kuvassa 11 esitetty malli, jossa projektissa 

työskentelevät henkilöt on jaettu kolmeen eri rooliin. Nämä roolit ovat tietämysjohtaja, 

tietotyöntekijät sekä tiedon luojat ja käyttäjät. 

Tietämysjohtaja on useimmiten projektipäällikkö tai hän voi myös olla tehtävään nimetty 

muu vastuuhenkilö. Tietämysjohtaja vastaa viestinnän ja informaation hallinnasta 

projektissa, viestinnän suunnittelusta sekä laadusta. Mitä suuremmasta projektista on 

kyse, sitä enemmän tietämysjohtajan asema projektissa korostuu. Projektin johtamisen 

voidaankin ajatella olevan suurimmilta osin juuri tietämysjohtamista. /4/ 

Tietotyöntekijät vastaavat projektissa käytettyjen tietojärjestelmien toiminnasta tai jos 

mitään tiettyjä tietojärjestelmiä ei käytetä, projektidokumenttien ylläpidosta ja jakelusta. 

Tietotyöntekijöitä projektissa ovat siis esimerkiksi tietojärjestelmien ylläpitäjät, projektisihteeri 

sekä muut henkilöt, joiden tehtävänä on saattaa tietoa muiden saataville. /4/

24 

Kuva 11. Projektin työntekijöiden roolit tiedonhallinnan kannalta /4/ 

Muut projektin työntekijät ovat tiedon luojia ja käyttäjiä. Tietoa luovat esimerkiksi 

suunnittelijat tai muut vastaavassa asemassa olevat henkilöt. Kaikki projektin työntekijät 

käyttävät tietoa. /4/ 

Projektin viestinnän hallinnan voidaan ajatella koostuvan kolmesta erillisestä osaalueesta, 

jotka kaikki kuitenkin vaikuttavat toisiinsa /13/: 

• viestinnän suunnittelu, 

• informaation hallinta ja 

• viestinnän valvonta 

Viestinnän suunnittelussa päätetään käytettävistä informaatio- ja kommunikaatiojärjestelmistä 

ja -menetelmistä. Informaation hallinnan tehostamiseksi myös tiedon välitysmuoto, 

kieli ja taajuus määritellään yhteensopiviksi. Viestintäsuunnitelmassa määritellään 

projektikokousten ajoitus ja tarkoitus, tiedon säilytys ja tietoturvallisuusasiat. 

Tärkeää on myös määritellä projektin osapuolten tiedontarpeet. /13, 26, 28/ 

Informaation hallinta tapahtuu tyypillisesti viestintäsuunnitelmassa määritellyn järjestelmän 

avulla. Hyvä järjestelmä sisältää menettelyt tiedon valmistamiselle, keräämiselle, 

tunnistamiselle, luokittelulle, jakelulle, päivitykselle, arkistoinnille ja hakemiselle. Järjestelmän 

tehokas hyödyntäminen edellyttää kuitenkin, että se on kaikkien osapuolten 

tarpeisiin sopiva ja että sen käytöstä järjestetään koulutusta niille, jotka sitä eivät tunne. 

Mikäli tiedonhallinnassa ei käytetä mitään tiettyä järjestelmää, korostuu suunnittelun 

merkitys huomattavasti ja vastuuhenkilöiden, eli tietotyöntekijöiden rooli projektissa 

muuttuu huomattavasti. /13, 26, 30/

25 

Informaation hallintaan kuuluvat myös projektikokousten asialistojen sekä pöytäkirjojen 

laatiminen ja jakelu. Näitä käsitellään tarkemmin luvussa 5. 

Viestinnän valvonta käsittää käytetyn tietojärjestelmän toiminnan valvonnan sekä 

osapuolten muun viestinnän valvomisen. Tietämysjohtaja vastaa viestinnän valvonnasta, 

jonka tarkoituksena on siis varmistaa, että kaikki osapuolet saavat tarvitsemansa tiedon 

ajoissa. /4, 13, 26/ 

Projektin kommunikaation hallintaan on olemassa useita tekniikoita. Seuraavassa 

alaluvussa esitellään tekniikka nimeltä Goal Directed Project Management (GDPM), 

jossa tiedon tarve ja lähteet tulevat varsin hyvin määritellyiksi. 

4.4.2 Goal Directed Project Management (GDPM) projektin kommunikaation 

hallinnan välineenä 

Lähteessä /1/ on esitetty malli, jossa projektiorganisaation henkilöt voidaan jakaa 

kahdeksaan eri luokkaan. Mallin tarkoituksena on paitsi projektin resurssien suunnittelun 

helpottaminen, myös kommunikaation hallinnan tehostaminen. GDPM-mallin roolit on 

esitetty taulukossa 3. Roolit sinänsä eivät ole mitenkään sidottuja ja projektin aikana yksi 

henkilö voi toimia useassa roolissa. 

GDPM-mallin roolit voidaan luokitella kolmeen ryhmään. Ensimmäiseen ryhmään 

kuuluvat X-henkilöt. Nämä henkilöt ovat vastuussa työn suorittamisesta. Työllä 

käsitetään tässä yhteydessä myös sellainen työhön liittyvä suunnittelu, jota ei voida 

luokitella kuuluvaksi luvussa 3.5 esiteltyihin projektin hallintaprosesseihin. Toiseen 

ryhmään kuuluvat projektin hallinnasta vastuussa olevat henkilöt, eli D-, d-, P- ja T- 

henkilöt. Nämä vastaavat projektin hallintaprosesseista. /1/ 

Taulukko 3. Projektiorganisaation työntekijöiden roolit GDPM-mallissa /1/ 

Tyyppi Rooli tai vastuu 

X 

Työn suorittaja (eXecuter) 

D 

Itsenäinen päätöksentekijä (independent Decision taker) 

d 

Päätöksentekijä ryhmässä (joint decision taker) 

P 

Edistymisen valvoja (Progress controller) 

T 

Työn ohjaaja tai opettaja (Tuition provider) 

C 

Konsultoitava, ohjeita tarjoava (Consulted) 

I 

Tiedotettava (Informed) 

A 

Mahdollinen asiantuntija (possibly available for Advice) 

Kolmas osa on GDPM-mallin se osa, joka vaikuttaa projektin kommunikaation hallintaan. 

Tähän ryhmään kuuluvat siis C-, I- ja A-henkilöt. C-, I- ja A-henkilöt voivat kuulua 

kumpaan tahansa kahdesta edellisestä ryhmästä, mutta he voivat myös olla ulkopuolisia 

tahoja. Mallin ajatus kommunikaation hallinnan kannalta on, että taulukon GDPM viisi

26 

ensimmäistä työntekijätyyppiä ovat velvollisia ottamaan huomioon nämä kolme erilaista 

tiedon tarvetta tai -lähdettä. /1/ 

C-henkilöillä on tärkeää ja oleellista tietoa projektin suorittamisen kannalta. Näiden 

henkilöiden tietoa ja mielipiteitä siis ei voi jättää huomiotta. Toisaalta C-henkilöillä 

harvoin on suurta vastuuta projektin päätöksenteosta, joten heiltä saatua tietoa voidaan 

käyttää sellaisenaan tai muokata tilanteeseen sopivaksi. Tyypillisesti C-henkilöitä ovat 

sellaiset henkilöt, joilla on paljon käytännön kokemusta projektin jostain osa-alueesta ja 

tämän kokemuksen jättäminen huomiotta olisi projektin kannalta haitallista. /1, 30/ 

I-henkilöille pitää jakaa tietoa. I-henkilö voi esimerkiksi olla työntekijä, joka tarvitsee 

jotain tietoa jatkaakseen työtään tai johtaja, joka tarvitsee raportin projektin edistymisestä. 

Käytännössä projekteissa useimmat henkilöt ovat jossain projektin elinkaaren vaiheessa I- 

henkilöitä. Viestinnän hallinnan vaikein osuus onkin juuri I-henkilöiden hallinta, 

kartoittaminen ja vastaaminen siitä, että tieto kulkee heille oikeaan aikaan. Tästä 

tehtävästä huolehtii tietämysjohtaja. /1, 2, 30/ 

A-henkilöillä saattaa olla oleellista tietoa projektin jotain osa-aluetta koskien. Tätä ei 

kuitenkaan yleensä tiedetä etukäteen, vaan projektin tullessa tiettyyn vaiheeseen heiltä 

kysytään neuvoja. A-henkilöt ovat usein melko kapean alan asiantuntijoita, joilla on 

arvokasta tietoa projektin jostain osa-alueesta, mutta toisaalta A-henkilöiden näkemys 

saattaa yksinään olla liian kapea tai se ei aivan vastaa senhetkistä tarvetta. A-henkilöiden 

kaltaisten asiantuntijaverkostojen kartoittaminen on kuitenkin yksi oleellinen osa GDPMmallin 

kaltaista kommunikaation hallintaa. /1/ 

GDPM-mallin ajatuksen selventämisen vuoksi on taulukossa 4 esitetty yksinkertainen 

esimerkki mallin käytöstä. Käytännössä projekti siis jaetaan pieniin tehtäviin. Vastuut 

kustakin tehtävästä jaetaan edelleen taulukon 3 mukaisten vastuualueiden mukaisesti. 

Projektin kommunikaation hallinnan kannalta on oleellista tunnistaa jokaiselle tehtävälle 

C-, I- ja A- henkilöt, mikäli näitä on. 

Taulukko 4. Esimerkki GDPM-mallin käytöstä 

Tehtävä Henkilö 

Kuvaus 

A B C D 

T1 D P C I, X Henkilö A päättää asiasta yksin, mutta kysyy 

kuitenkin neuvoa henkilöltä C. Henkilö B valvoo 

tehtävän suorittamista ja päätöksestä pitää 

tiedottaa henkilölle D, joka myös tekee työn. 

T2 d, P d A I Henkilöt A ja B päättävät asiasta yhdessä. 

Henkilöllä C saattaa olla arvokasta tietoa, jota 

kannattaa kysyä ennen päätöksentekoa. Henkilö 

A valvoo prosessia. Päätöksestä tiedotetaan 

henkilölle D.

27 

GDPM-mallin hyvänä puolena voidaan pitää sitä, että tiedon kulkua eri osapuolten välillä 

voidaan sen avulla kätevästi hallita. Jos verrataan GPDM-mallia kuvassa 11 esitettyyn 

malliin projektin työntekijöiden tiedonhallintaan liittyvistä rooleista, voidaan X- henkilöiden 

ajatella kuuluvan tiedon luojien ja käyttäjien tasolle. D-henkilöt ovat tietämysjohtajia. 

P-, d- sekä T- henkilöt ovat tietotyöntekijöitä ja C-, I- ja A- henkilöt jakautuvat 

tietotyöntekijöihin ja tiedon luojiin sekä käyttäjiin. 

4.5 Pöytäkirjan asema projektin viestinnän välineenä 

Lähteessä /11/ on esitetty ajatus, että yritys tai projekti voi käyttää tietoa kymmenellä eri 

tavalla: 

1 Tiedon ja parhaiden toimintatapojen jakaminen 

2 Tiedon jakamisen kehittäminen 

3 Aikaisempien kokemuksien hyödyntäminen 

4 Tiedon hyödyntäminen tuotteissa, palveluissa ja prosesseissa 

5 Tiedon tuottaminen tuotteena 

6 Tiedon hyödyntäminen perustana uusille innovaatioille 

7 Asiantuntijaverkostojen kartoittaminen 

8 Asiakasverkostojen rakentaminen ja ylläpito 

9 Tiedon arvon mittaaminen ja ymmärtäminen 

10 Älylliseen pääomaan (esimerkiksi tekijänoikeudet, patentit) panostaminen 

Kuten lähteessä /11/ todetaan, tiedonhallintaa tärkeänä kilpailuetunaan pitävän yrityksen 

tulisi hallita kaikki kymmenen osa-aluetta. Nykyisessä muodossaan projektien 

pöytäkirjoja kuitenkin käytetään pääasiallisesti kohdan yksi mukaisessa tarkoituksessa. 

Rakenteisen tiedonhallinnan avulla projektipöytäkirjan käyttöä mahdollisesti voidaan 

laajentaa kattamaan ainakin kohdat 2, 3, 4, 6, 7 ja 8. Näistä mahdollisuuksista kerrotaan 

luvussa 7. 

Projekteissa pöytäkirja siis toimii tiedon jakamisen välineenä projektin osapuolten välillä. 

Sen avulla raportoidaan asiakkaalle projektin edistymisestä ja tiedotetaan projektin 

lähiajan tapahtumista. Pöytäkirjalla on myös melko vahva sopimuksellinen asema, eli 

hyväksyttyyn pöytäkirjaan kirjattu päätös on yleensä osapuolten välisen sopimuksen 

mukaan sitova. Kiistatilanteissa pöytäkirjoista joudutaankin usein tarkistamaan kirjattuja 

päätöksiä ja pöytäkirja saattaa hyvinkin toimia todisteena jonkin osapuolen väitteille. /27, 

28/ 

Vaikka projektipöytäkirjoihin onkin usein kirjattu paljon arvokasta tietoa, tiedon jakamisen 

lisäksi projektipöytäkirjoja käytetään melko vähän säännöllisessä projektinhallinnassa. 

Pelkän pöytäkirjan käyttäminen koko projektin tai projektin yksittäisen osan 

hallinnassa tuskin on mahdollista, mutta tiedon esitystapaa parantamalla siitä saataisiin 

suurta apua tavallisiin projektin hallintaprosesseihin.

Nykyisin projektipöytäkirjojen hallinnalle ei Jaakko Pöyry Oy:ssä ole mitään varsinaisia 

yhteisiä käytäntöjä. Pöytäkirjoille on kyllä olemassa pohja, joka sisältää tiettyjä kenttiä, 

kuten kokouspäivämäärän, kokouksen otsikon sekä läsnäolijat, mutta läheskään kaikkia 

pöytäkirjoja ei kuitenkaan ole arkistoitu mihinkään tiettyyn paikkaan. Riippuukin pitkälti 

projektin johdon aktiivisuudesta ja projektin osapuolten välisten, erikseen sovittujen 

pöytäkirjakäytäntöjen sisällöstä, mitkä kaikki pöytäkirjat ovat myöhemmin helposti 

saatavilla. 

28

29 

5 PROJEKTIKOKOUKSISSA SYNTYVÄ TIETO 

5.1 Yleistä 

Suurin osa projekteissa olevasta tiedosta syntyy muualla kuin kokouksissa. Kokouksissa 

käsiteltävät asiat tyypillisesti valmistellaan erikseen ja kokous toimii näiden asioiden 

välityskanavana. Samalla syntyy projektikokouksille tyypillisiä tietotyyppejä, kuten 

päätöksiä ja tiedotuksia. 

Projektikokouksissa syntyvää tietoa voidaan tarkastella kuvassa 12 esitetyn mallin mukaisesti, 

jossa tiedolle on esitetty kolme ulottuvuutta: kokoustyyppi, asia ja tietotyyppi. 

Kuva 12. Projektikokouksissa syntyvän tiedon kolme ulottuvuutta. 

Mallin ajatuksena on, että kokouksissa syntyvä tieto voidaan kohdistaa tietylle kokoustyypille. 

Erilaisissa kokouksissa taas käsitellään erilaisia asioita, mikä johtaa kullekin 

kokoustyypille ominaiseen asialistaan. Asialistan sisällöstä riippuen kokouksissa käsitellään 

erilaista tietoa, mikä voidaan luokitella erilaisiin tietotyyppeihin. Esimerkiksi 

suunnittelukokouksissa syntyy tietoa, joka edustaa tietotyyppiä suunnitelma. 

Projektikokoukset voidaan ryhmitellä usealla eri tavalla. Kaksi erilaista näkökulmaa projektin 

kokoustyyppeihin saadaan ryhmittelemällä ne projektin elinkaaren ja organisaation 

mukaisesti. Projektikokousten tarkastelu seuraavassa tapahtuu projektin pääkonsultin 

näkökulmasta. 

Kokousprosessi on yksi erikoistapaus kohdassa 4.1 esitellystä projektin viestintäprosessista. 

Prosessin voidaan ajatella alkavan tarpeesta pitää kokous ja päättyvän 

seuraavaan kokoukseen. Taulukossa 5 on esitetty kokousprosessi samassa kehysmallissa 

kuin projektin viestintäprosessi taulukossa 2.

30 

Taulukko 5. Projektin kokousprosessi viestintäprosessin erikoistapauksena 

Kokousprosessi Informaatio Tietämys 

Asiatieto, faktat 

(mitä asioista 

tiedetään) 

• Osallistujat 

• Kokoustyypit 

• Osallistujien 

tehtävät ja roolit 

projektiorganisaatiossa 

• Neuvottelu ja 

kokousdokumentit 

• Asialistat 

• Pöytäkirjat 

• Kokousdokumenttien 

hallintaan 

käytetyt 

menetelmät 

• Asiantuntijat, 

projektin johto, 

työntekijät 

• Asialistan sisältö 

• Pöytäkirjan 

sisältö 

Toiminnallinen 

tieto 

(miten asiat 

toimivat) 


(miksi asiat 

toimivat näin) 

• Kokouskutsun ja 

asialistan 

laadinta 

• Kokous 

• Pöytäkirjan 

elinkaari 

• Kokouksen 

tarkoitus 

• Kokoustekniikka: 

Videoneuvottelu, 

perinteinen 

kokous, puhelinneuvottelu 

tms. 

• Kokoustekniikat 


roolit 

kokouksessa 


aikaisemmat 

yhteydet 

• Kokousdokumentissa 

olevan 

informaation 

tarkoitus: tiedottaminen, 

raportointi, 

asian 

selvittäminen 

tms. 

• Pöytäkirjaan kirjattavat 

ja poisjätettävät 

asiat 

• Kokouksissa 

käsitellyt asiat 

• Kokouksessa 

tehdyt päätökset 

• Päätöksiin 

liittyvät syyt ja 

perustelut 

• Projektin 

tavoitteet 

• Tietotyypit, 

tiedon luokittelu 

• Pöytäkirjan tai 

asialistan muoto 

Projektikokousprosessissa asiatietoa ovat kokouksen osallistujalistat sekä erilaiset 

kokoustyypit. Toiminnallista tietoa taas ovat kokoukseen, sen valmisteluun ja pöytäkirjan 

laatimiseen liittyvä toiminta. Strategista tietoa kokousprosessista ovat kokouksen 

tarkoitus ja muoto. Strategiseen tietoon liittyy aina paljon hiljaista tietämystä, esimerkiksi 

kokenut projektipäällikkö tai muu projektin työntekijä voi tietää tietystä asiakkaan 

edustajasta, että tämä inhoaa virvokkeiden tarjoilua kokouksissa ja haluaa pysytellä 

kokouksen ajan ainoastaan asiassa. 

Kokousprosessissa kulkevaa informaatiota ovat kokousdokumentit: asialista ja pöytäkirja. 

Pelkät dokumentit eivät vielä ole tietämystä, vaan informaatiotasolla tehdään 

ratkaisut, joiden avulla varmistetaan, että tietämystä tarvitsevat henkilöt saavat sitä 

tarjolla olevasta informaatiosta. Asiatietoa tällä tasolla ovat itse dokumentit sekä niiden 

hallinnassa käytetyt järjestelmät. Toiminnallista tietoa taas ovat projektikokous-

31 

dokumenttien syntyyn ja laatimiseen vaikuttava informaatio: kokouksen osallistujien 

väliset yhteydet, osallistujien roolit kokouksessa sekä kokoustekniikat. Strategista tietoa 

ovat informaation tarkoitus sekä valinnat, joiden avulla informaatiosta pyritään saamaan 

halutunlaista tietämystä. 

Kokousprosessin tietämystasolla on kokousdokumenteista saatu tietämys, eli avoin 

tietämys ja hiljainen tietämys, jotka voivat olla mitä tahansa prosessissa syntyvää 

projektiin liittyvää tietämystä. Asiatietotasolla ovat tietämyksen lähteet: työntekijät, 

asiantuntijat ja projektin johto sekä kokousdokumenttien sisältö. Toiminnallista tietoa 

ovat kokouksissa käsitellyt asiat sekä perustelut niille. Strategista tietoa ovat tietämyksen 

tavoitteet eli projektin tavoitteet sekä tavoitteiden saavuttamiseen käytetyt keinot: tiedon 

luokittelu ja dokumenttien muoto. Näistä tämän työn pääkohteita ovat nimenomaan 

strategisen tiedon hallinnassa käytetyt, edellä esitetyt, keinot. 

5.2 Projektikokoukset 

5.2.1 Projektikokoukset projektin elinkaaren mukaisesti 

Kuvassa 13 on esitetty projektikokoukset sijoitettuna projektin elinkaarimalliin. Seuraavissa 

kohdissa käsitellään tarkemmin kunkin kokoustyypin asialistaa ja osallistujia. Koska 

työssä käsitellään nimenomaan projektin aikana syntyvää tietoa, tarkastellaan tässä 

projektin elinkaaren sitä osaa, joka ulottuu projektin varsinaisesta alkamisesta sen 

loppumiseen. 

Kuva 13. Projektikokoukset ryhmiteltynä projektin elinkaarimallin mukaisesti

32 

Projektin aloituskokous: 

Projektin aloituskokoukset voidaan karkeasti luokitella kahteen ryhmään niihin osallistujien 

mukaisesti: sisäisiin ja ulkoisiin aloituskokouksiin. Aloituskokous projektin asiakkaan 

kanssa pidetään projektin alkaessa. Muiden projektin kulkuun oleellisesti vaikuttavien 

ulkoisten osapuolien kanssa aloituskokous pidetään projektin elinkaaren siinä 

vaiheessa, kun kyseinen osapuoli tulee mukaan projektiin. Näitä osapuolia ovat käytännössä 

toimittajat ja urakoitsijat. /14, 26/ 

Sisäisiin aloituskokouksiin kuuluvat esimerkiksi koko projektin sisäinen aloituskokous 

sekä projektin eri työryhmien aloituskokoukset. Projektin sisäisessä aloituskokouksessa 

läsnä ovat projektin johto- ja avainhenkilöt sekä mahdollisesti muuta korkeampaa johtoa 

tai asiantuntijoita. Mukaan on myös mahdollisesti projektiin myöhemmin osallistuvia 

avainhenkilöitä. Sisäisen aloituskokouksen pääasiallinen tarkoitus on selvittää kaikille 

asianosaisille projektin laajuus, tavoitteet ja vaatimukset esimerkiksi seuraavan asialistan 

avulla /14, 26/: 

• sopimusteksti 

• tiedot tilaajasta ja heidän organisaatiostaan 

• tehtävänkuvaus 

• asiakkaan projektille asettamat laatu- ja muut vaatimukset 

• asiakkaan hankkeelle asettamat ympäristö- ja muut tavoitteet 

• sovellettava laatujärjestelmä 

• projektissa käytettävät työmenetelmät ja ohjelmistot 

• tiedonsiirtokäytännöt 

• oman projektiorganisaation esittely 

• linjajohdon ja projektijohdon periaatteellinen työnjako ja linjajohdon rooli 

projektissa 

• tuntiarvio 

• aikataulu 

• lähiajan tavoiteohjelma 

Työryhmien aloituskokouksissa läsnä ovat vastaavasti kunkin työryhmän johto- ja 

avainhenkilöt. Kokouksissa käytetään soveltuvin osin samaa asialistaa kuin koko projektin 

aloituskokouksessa. 

Ulkoisiin aloituskokouksiin kuuluvat aloituskokoukset asiakkaan kanssa sekä aloituskokoukset 

muiden osapuolten, esimerkiksi toimittajien, kanssa. Ulkoisten aloituskokousten 

laajuudet vaihtelevat riippuen siitä, mikä osapuoli on kyseessä ja mikä on tämän rooli 

projektin aikana. Seuraavat asiat käsitellään siltä osin kuin se kunkin osapuolen kannalta 

on tarpeellista /14/:

33 

• projektin kuvaus ja sopimus, 

• projektin tavoite-, osto-, suunnittelu- ja koordinointiaikataulut, 

• linjajohto tarkoituksenmukaisessa laajuudessa, 

• projektin avainhenkilöt ja heidän roolinsa, 

• projektissa käytettävät työmenetelmät ja ohjelmistot, 

• asiakkaan rooli päätösten teossa ja suunnittelutietojen vaihto-ohjelmissa, 

• tietojen elektroninen siirto projektin osapuolten välillä, 

• kokouskäytäntö ja pöytäkirjojen laatiminen, 

• asiakkaan ja kohdemaan erityisvaatimukset sekä 

• asiakkaan hankkeelle asettamat ympäristö- ja muut tärkeät tavoitteet. 

Etenkin ulkoiset aloituskokoukset voivat jakaantua projektin elinkaarella hyvin laajalle 

alueelle /26/. Vaikka aloituskokous pidetäänkin kaikkien osapuolten kanssa, asialistat 

voivat olla hyvin pelkistettyjä edellä esitetystä, jos osapuolet ovat toisilleen ennalta 

tuttuja. 

Asiantuntijakokous: 

Projektin asiantuntijakokoukset ajoittuvat elinkaarimallissa pääasiallisesti suunnitteluvaiheeseen, 

vaikka niitä esiintyy muissakin vaiheissa projektin suunnitteluaikataulun 

mukaisesti. Asiantuntijakokouksella on tietty aihe, esimerkiksi paperikoneen venttiilit, ja 

paikalla kokouksessa ovat kaikki aiheeseen liittyvät osapuolet. Tärkeimpiä käsiteltäviä 

asioita ovat /14/: 

• aiheeseen liittyvät tekniset asiat ja päätökset, 

• tarvittavien hankintojen suunnittelu, 

• vastuuhenkilöt eri työvaiheille, 

• aiheeseen liittyvät ohjeet ja standardit sekä 

• elinkaaren myöhemmissä vaiheissa aiheeseen liittyvät mahdolliset poikkeamat ja 

niiden selvittäminen. 

Asiantuntijakokoukset eivät ole luonteeltaan yhtä muodollisia kuin esimerkiksi aloituskokoukset, 

vaan niitä voidaan pitää suunnittelualan niin tahtoessa ja asialista saattaa 

sisältää vain osan edellä esitellyistä kohdista. Esimerkiksi kokoukset, joissa käsitellään 

vain teknisiä asioita, ovat yleisiä. 

Projektin seurantakokous: 

Projektin seurantakokoukset sijoittuvat elinkaarimallissa koko projektin elinkaarelle. 

Seurantakokouksia pidetään kaikkien osapuolten kanssa ja jokaisen osapuolen kanssa 

määritellään erikseen kuinka usein kokouksia pidetään ja mitä niissä käsitellään. Asiakkaan 

kanssa seurantakokouksia tyypillisesti pidetään säännöllisesti koko projektin ajan 

esimerkiksi kerran kuukaudessa, kun taas yksittäisen toimittajan kanssa seurantakokouksia 

saattaa olla vain yksi tai seuranta saatetaan jopa hoitaa ilman muodollista 

kokousta, esimerkiksi puhelimitse. /14, 30/

34 

Seurantakokouksen tarkoituksena on /26/ 

• projektin edistymisestä raportoiminen, 

• muutosten tai poikkeamien sekä niiden syiden selvittäminen sekä 

• päätöksenteko ja tehtävien jako projektin seuraavalle jaksolle. 

Sisäisissä seurantakokouksissa läsnä ovat projektipäällikkö sekä työryhmien edustajat. 

Työryhmien sisäisissä seurantakokouksissa taas voivat olla paikalla kaikki työryhmän 

työntekijät. Ulkoisissa seurantakokouksissa paikalla on sen osapuolen edustajia, jonka 

kanssa kokous pidetään, pääkonsultin edustajat, esimerkiksi projektipäällikkö ja suunnittelualojen 

johtajia, sekä tarvittaessa asiakkaan edustaja. 

Seurantakokouksessa käsitellään asioita esimerkiksi seuraavan asialistan mukaisesti: 

• projektin tilanne 

• edellisen pöytäkirjan läpikäynti 

• edistyminen, aikataulun seuranta 

• tekniset asiat ja hankinnat 

• muutokset ja poikkeamat 

• seuraavan kokouksen ajankohta 

Asialistan sisältö riippuu näissäkin kokouksissa hyvin paljon siitä, kenen kanssa kokousta 

pidetään ja kuinka iso rooli kyseisellä osapuolella on projektissa. 

Palautekokous: 

Projektin palautekokous pidetään projektin tuotteen käyttöönoton jälkeen. Palautekokouksessa 

paikalla ovat asiakkaan ja pääkonsultin edustajat. Kokouksessa käsitellään 

projektin onnistumista sekä kokonaisuutena että kunkin suunnittelualan kannalta. 

Projektin palautekokouksen tarkoituksena on hyödyntää projektissa saatua oppia tulevia 

projekteja ajatellen. 

5.2.2 Projektikokoukset projektiorganisaation mukaisesti 

Kuvassa 14 on esitetty malli, jossa säännöllisesti pidettävät projektikokoukset on ryhmitelty 

niihin osallistuvien henkilöiden mukaisesti. Mallin pohjana on luvussa 4.3 esitelty 

projektiorganisaatio ja siinä kulkeva informaatio (kuva 9). Ajatuksena on, että ylemmän 

tason kokous toimii syötteenä alemman tason kokouksille, eli ylemmän tason kokouksissa 

määritellään yleiset ohjeet ja päätetään asioista yleisellä tasolla. Alemman tason 

kokouksissa taas käsitellään tietyn alueen ratkaisuja yksityiskohtaisemmin annet-tujen 

yleisten ohjeiden mukaisesti. Voidaan siis ajatella, että asiat, jotka vaativat tietyn alan 

tarkkaa tuntemusta, käsitellään alemman tason kokouksissa. Vastaavasti asiat, joita ei 

osata tai voida ratkaista alemman tason kokouksessa, siirtyvät mallissa ylöspäin.

35 

Kuva 14. Projektikokoukset ryhmiteltynä osallistujien mukaan 

Ylimpänä mallissa ovat johtoryhmän kokoukset, joiden tehtävänä on toimia syötteenä 

projektin kaikille muille kokouksille. Johtoryhmän kokouksissa projektipäällikkö raportoi 

yrityksen johdolle projektin edistymisestä. Kokoukset järjestetään säännöllisin väliajoin 

ja niissä käsitellään projektin edistymisen lisäksi sellaisia asioita, joita alemman tason 

kokouksissa ei ole pystytty ratkaisemaan. Tyypillinen esimerkki tällaisesta asiasta on 

projektiin tuleva suuri muutostarve. Lisäksi johtoryhmän kokouksissa päätetään koko 

projektiin liittyvistä yleisistä suurista asioista, esimerkiksi projektin alussa projektiorganisaation 

rakenteesta, tärkeimmistä resursseista ja toimittajavalinnoista.. 

Projektikokous kuvassa 14 vastaa aiemmin esiteltyä koko projektin seurantakokousta. 

Tällainen kokous voidaan järjestää sekä sisäisesti että minkä tahansa ulkoisen osapuolen 

kanssa. 

Työryhmien viikkopalaverit ovat samalla työryhmien seurantakokouksia. Näissä kokouksissa 

käsitellään koko projektin seurantakokousta tarkemmin tietyn työryhmän teknisiä 

ratkaisuja ja vastuita sekä laajuusmuutoksia ja niiden aikataulu- ja kustannusvaikutuksia. 

Työryhmien viikkopalavereissa voidaan myös päättää pienemmistä hankinnoista, kun taas 

kalliimmat hankinnat siirtyvät mallissa ylöspäin, tyypillisesti asiakkaan kanssa pidettävän

36 

projektikokouksen päätettäviksi. Työryhmiä ovat sisäisten työryhmien lisäksi eri toimittajat 

tai urakoitsijat. 

Kuten aiemmin todettiin, asiantuntijakokouksissa käsitellään tiettyä aihetta. Asiantuntijakokouksissa 

pääasiallisesti suunnitellaan aiheeseen liittyviä ratkaisuja, hankintoja sekä 

resursseja ja ne esitellään sekä hyväksytetään viikkopalavereissa. 

Työmaapalaverit ovat usein epämuodollisia kokouksia, joissa työnjohtaja ja -tekijät 

keskenään ratkaisevat pieniä esille tulevia ongelmia tai sopivat työnjaosta. Työmaapalavereista 

ei läheskään aina laadita pöytäkirjoja, ellei niissä tule esille asioita, joita pitää 

siirtää käsiteltäviksi ylemmän tason kokouksiin kuten laajuusmuutokset ja niistä aiheutuvat 

muutos- tai lisätyöt aikataulu- ja kustannusvaikutuksineen.. 

Kuvista 13 ja 14 puuttuvat sellaiset kokoukset, joita projektissa saatetaan järjestää epäsäännöllisin 

väliajoin. Tällaisia kokouksia ovat esimerkiksi erilliset hankintakokoukset. 

Näitä kokouksia ei kuitenkaan sellaisenaan voi sijoittaa projektin elinkaari- tai 

organisaatiomalliin, sillä niihin saattaa liittyä useita projektin ulkopuolisia osapuolia, 

kuten talous- tai markkinointiosastojen edustajia. Ajallisesti näitä kokouksia voidaan pitää 

koska tahansa tai ne voidaan myös jättää pitämättä. 

5.3 Kokouspöytäkirjat 

Lähes kaikista projektikokouksista laaditaan pöytäkirja. Pöytäkirja on tyypillinen 

esimerkki dokumentista, jota käytetään projektissa tiedon jakamiseen projektin 

osapuolille. Yleisesti käsite dokumentti voidaan määritellä seuraavalla tavalla /8/: 

Dokumentti = {Data, metatieto}, missä 

Metatieto = {Omistaja, tekijä, versio, tila, linkit, datan kuvaus} ja 

Data = Mikä tahansa dokumenttiin kuuluva asia, esimerkiksi teksti tai kuva. 

Seuraavassa esitellään kokouspöytäkirjan muoto, elinkaari ja toteutus. Dokumentin elinkaarella 

tarkoitetaan tässä niitä vaiheita, joiden kautta dokumentti kulkee olemassaolonsa 

aikana. Toteutuksella taas tarkoitetaan dokumentin laadintaa ja siihen liittyviä prosesseja. 

Tehokkaan informaationhallinnan aikaansaamiseksi täytyy näiden lisäksi ymmärtää myös 

dokumentin käyttötarkoitus /8/. Tämä esiteltiin luvussa 4.5. 

Tyypillinen esimerkki nykyisen kokouspöytäkirjan muodosta voidaan esittää seuraavan 

viiden kohdan avulla: 

1) edellinen pöytäkirja 

2) projektin tilanne 

3) tekniset asiat 

4) muut asiat 

5) seuraava palaveri

37 

Kohdat edustavat siis pöytäkirjassa olevaa dataa. Metatietoa nykyisissä kokouspöytäkirjoissa 

taas ovat kokousaika, kokouspaikka, läsnäolijat ja jakelu. Kokouspöytäkirjojen 

muoto kuitenkin vaihtelee kokoustyypistä ja pöytäkirjan laatijasta riippuen. 

Tätä voidaan pitää sekä hyvänä että huonona asiana. Toisaalta kokouspöytäkirjojen vapaa 

muoto aiheuttaa sen, että kohdassa 4.2.2 esitettyjen ajatusten mukaisesti laatijan kynnys 

saattaa hiljaista tietoa avoimeen muotoon laskee, toisaalta taas yhtenäisen muotoisia 

pöytäkirjoja olisi helpompi seurata. Jälkimmäinen ei kuitenkaan ole kovin suuri ongelma, 

sillä käytännössä kuitenkaan pöytäkirjojen muoto ei tietyn kokoustyypin ja projektin 

sisällä vaihtele kovin paljon, koska laatijana on useimmiten sama henkilö. 

Kokouspöytäkirjan elinkaari on esitelty kuvassa 15. Kokouspöytäkirjan elinkaari alkaa jo 

ennen projektikokousta, jolloin syntyy tarve pitää kokous. Tavallaan pöytäkirjan 

ensimmäisenä asteena voidaan jo pitää kokouksen asialistaa, mitä lopullisen pöytäkirjan 

muoto hyvin usein noudatteleekin. 

Elinkaaren seuraava vaihe on projektikokous, jossa kokouksen sihteeri kirjoittaa ylös 

käsitellyt asiat. Sihteerinä toimiva henkilö vaihtelee kokoustyypistä riippuen. Esimerkiksi 

projektin seurantakokouksen sihteerinä toimii usein projektikoordinaattori kun taas 

asiantuntijakokouksen sihteerinä toimii joku riittävän asiantuntemuksen omaava henkilö. 

Kokousmuistiinpanojen pohjana toimii kokouksen asialista. 

Kuva 15. Projektikokouksen pöytäkirjan elinkaari 

Laatimisvaiheessa kokouksen sihteeri kirjoittaa puhtaaksi kokouksessa tehdyt muistiinpanot. 

Pöytäkirja laaditaan tietyn pohjan mukaisesti, usein asialistan mukaisten kohtien

38 

perusteella. Käytettävä pohja ja rakenne vaihtelevat riippuen siitä, onko kyseessä sisäinen 

vai ulkoinen kokous ja kenelle pöytäkirja jaetaan. Asiakkaalle annettavissa pöytäkirjoissa 

muotoseikat ovat virallisesti määriteltyjä. Sisäiset pöytäkirjat taas ovat melko vapaamuotoisia. 

Tarkistus- ja hyväksymisvaiheet eivät ole virallisia tai pakollisia käytäntöjä. Käytännössä 

pöytäkirjat kuitenkin aina tarkistetaan ja hyväksytään. Tarkistus- ja hyväksymisvaiheissa 

pöytäkirjan oikeellisuus tarkistetaan ja se hyväksytään jakeluun kelpaavaksi. Yleensä 

projektin seurantakokouksen pöytäkirjan tarkistaa kokouksessa läsnä ollut, tehtävään 

valittu henkilö, ja hyväksynnän suorittaa projektipäällikkö. Pienemmissä kokouksissa 

käytännöt eivät ole yhtä muodollisia. Toinen yleinen käytäntö on hyväksyä pöytäkirja 

seuraavassa kokouksessa. 

Pöytäkirjan jakelu tapahtuu viestintäsuunnitelmassa määritellyllä tavalla. Tavallisimmat 

tavat ovat sähköpostitse tai postitse. Jakelutavat ja -kohderyhmät valitsee projektipäällikkö 

ja itse jakelusta vastaa projektisihteeri. 

Kokouspöytäkirja toimii syötteenä seuraavalle kokoukselle, missä se tyypillisesti käydään 

läpi asialistan kohdassa edellinen pöytäkirja. Tämän jälkeen pöytäkirjaa saatetaan käyttää 

päätösten tarkistamiseen tai projektin historian selvittämiseen. Muita mahdollisia käyttöjä 

projektipöytäkirjalle esitellään luvussa 7. Näillä käyttötavoilla pöytäkirjan elinkaarta 

voidaan pidentää ja projektinhallintaa sen avulla tehostaa. 

Dokumentin elinkaareen kuuluvat myös dokumentin eri versiot /8/. Kokouspöytäkirja on 

kuitenkin nykyisessä muodossaan melko pysyvä dokumentti, eli sitä harvoin muutetaan 

sen jälkeen, kun se on seuraavassa kokouksessa käyty läpi. Osapuolten välisen sopimuksen 

mukaan pöytäkirjan muuttaminen sen hyväksymisen jälkeen on useimmiten 

kiellettyä ilman erillistä lupaa. 

5.4 Tietotyypit 

Kuvassa 12 esitetyn mallin mukaan projektikokouksessa syntyvän tiedon kolmas ulottuvuus 

on sen tietotyyppi. Tietotyypit voidaan edelleen jakaa kahteen osaan: jatkuvaan 

tietoon ja kertaluonteiseen tietoon. Kuvassa 16 on esitetty jatkuvan ja kertaluontoisen 

tiedon syntyminen projektin elinkaaren eri vaiheissa. 

Projektin alussa syntyy paljon pysyvää tietoa, esimerkiksi projektin toimintaohjeita, joita 

noudatetaan koko projektin ajan. Kuitenkin projektin edetessä pysyvän tiedon syntyminen 

vähenee melko nopeasti. Se ei kuitenkaan lopu kokonaan, sillä esimerkiksi projektin 

tuotteeseen liittyvä dokumentaatio on pysyvää tietoa. Pysyvän tiedon voi edelleen ajatella 

jakautuvan projektin aikaiseen tietoon ja projektin jälkeen voimassaolevaan tietoon. Tässä 

työssä kuitenkin pysyvällä tiedolla tarkoitetaan koko kokonaisuutta.

39 

Kertaluontoista tietoa on kaikki sellainen tieto, josta päätetään tai jota esimerkiksi 

suunnitellaan vain kerran tai melko lyhyellä aikavälillä ja johon sen jälkeen ei enää palata 

muutoin kuin tiedon tarkistustarkoituksessa. Kertaluontoisena tietona voidaan myös pitää 

sellaista tietoa, joka selkeästi voidaan kohdistaa lyhyelle projektin ajanjaksolle. 

Ongelmana kertaluontoisen tiedon käyttämisessä on, että siihen palaaminen on vaikeaa, 

koska se on usein kirjattuna lyhyesti useisiin eri paikkoihin, esimerkiksi kokouksen 

sihteerin asialistan kulmaan tai sellaiseen pöytäkirjaan, jonka pohjana ollut asialista ei 

anna viitteitä siihen suuntaan, että kyseinen päätös löytyisi tämän kokouksen 

pöytäkirjasta. Siksi esimerkiksi tulevissa projekteissa on vaikeaa hyödyntää tietoa siitä, 

mitä päätettiin jostain tietystä asiasta. Projektikokouksissa syntyvä tieto on pääasiallisesti 

kertaluontoista, vaikka niissäkin saatetaan suunnitella tai laatia pysyviä ohjeita tai 

dokumentaatiota. Kertaluontoista tietoa syntyy koko projektin elinkaaren ajan, eniten 

kuitenkin toteutusvaiheessa, jossa päätöksiä tehdään eniten. 

Kuva 16. Pysyvän ja kertaluontoisen tiedon syntyminen projektin eri vaiheissa 

Taulukossa 6 projektikokouksissa syntyvät tietotyypit on jaettu kertaluonteiseen ja 

pysyvään tietoon. Taulukossa olevat tietotyypit ovat tulos työssä tehdystä dokumenttianalyysista. 

Lista ei välttämättä ole täysin kattava, mutta sisältää ainakin ne tietotyypit, 

joita projektipöytäkirjoissa säännöllisesti esiintyy. 

Jotkin taulukossa 6 esitetyistä tietotyypeistä ovat osittain päällekkäisiä. Tässä vaiheessa 

lista on kuitenkin esitetty mahdollisimman yksityiskohtaisena, jotta projektikokouksissa 

esiintyvistä tietotyypeistä saataisiin riittävän perusteellinen näkemys. Myöhemmin tässä 

työssä pohditaan vielä tietotyyppien yhdistämistä ja siten rakenteisen pöytäkirjadokumentin 

yksinkertaistamista. 

Päätös on yleisin projektikokouksissa syntyvä tietotyyppi. Useimpiin muihin tietotyyppeihin 

liittyy tiedon olemassaolon jossain vaiheessa päätös, esimerkiksi suunnitelman 

hyväksyminen tai aikatauluista päättäminen. Tästä seuraa myös se, että päätökseen liittyy

40 

lähes aina jokin toinen tietotyyppi. Päätökset voidaan useimmiten kohdistaa tietylle 

projektin ajanjaksolle, henkilölle, suunnittelualalle tai tuotteen osalle. 

Taulukko 6. Projektipöytäkirjoissa esiintyvät tietotyypit luokiteltuina pysyvään ja 

kertaluonteiseen tietoon 

Tietotyyppi Pysyvä 

tieto 

Kertaluonteinen 

tieto 

päätös 

X 

tehtävä 

X 

aikataulu X X 

suunnitelma X X 

selvitettävä asia 

X 

tilanne 

X 

hankinta X X 

valitus 

X 

muutos 

X 

tiedotus 

X 

yhteystiedot 

X 

esittely 

X 

ohje 

X 

tehdyn tarkastaminen 

X 

Tehtävät seuraavat useimmiten päätöksistä. Tehtävällä on aina yksi tai useampi vastuuhenkilö 

ja se voidaan kohdistaa tietylle projektin alueelle, esimerkiksi tuotteen osalle. 

Tehtävällä on myös aina aikataulu. Aikataulut eivät kuitenkaan liity pelkästään tehtäviin 

vaan lähes kaikella projektin toiminnalla on aikataulu. Aikataulun yksittäinen osa tai 

tehtävä on kertaluonteista tietoa, mutta aikataulua kokonaisuudessaan voidaan pitää 

pysyvänä tietona, sillä usein se on laadittu pidemmälle ajanjaksolle. Erilliset aikataulut 

kuten tietyn tehtävän aikataulu voidaan aina sijoittaa koko projektin aikatauluun ja ne 

myös laaditaan koko projektin aikataulun perusteella. 

Suunnitelmia syntyy eniten suunnittelu- tai asiantuntijakokouksissa. Esimerkkejä 

suunnitelmista ovat projektin seuraavan ajanjakson toimintasuunnitelma, viestintäsuunnitelma 

ja suunnitelma tietyn toimittajan käyttämisestä. Etenkin laajemmat suunnitelmat 

laaditaan yleensä ennen projektikokousta ja kokouksessa ainoastaan tehdään päätös, eli 

hyväksytään tai hylätään suunnitelma. Suunnitelmaan liittyy läheisesti selvitettävä asia, 

joka eroaa kuitenkin suunnitelmasta siten, että siihen liittyy selkeästi toiminta ja 

vastuuhenkilö. Suunnitelmasta seuraa usein selvitettävä asia. Jos esimerkiksi suunnitellaan 

käytettävän tiettyä toimittajaa, seuraa tästä usein, että täytyy selvittää toimittajan 

luotettavuus, hinta ja toimitusehdot. Selvitettävistä asioista päätetään projektikokouksissa 

ja varsinaiset selvitykset tapahtuvat niiden jälkeen. Selvitettävää asiaa voidaan myös pitää 

tehtävän erikoistapauksena, joskin selvitettävään asiaan liittyy aina se, että sen tuloksena 

on selvitys.

41 

Tilanne tarkoittaa projektin edistymistilannetta. Tilanteiden avulla toteutetaan projektin 

seuranta. Raportointi asiakkaalle perustuu myös usein juuri tilanteisiin. Tilanteen tärkeimmät 

alaryhmät ovat aikataulutilanne, työvoimatilanne, poikkeamat, ongelmat ja lähiajan 

tapahtumat projektissa /26/. 

Hankinnat seuraavat yleensä päätöksistä. Hankinnat voidaan kohdistaa tietylle projektin 

osalle ja yhteen osaan liittyvistä hankinnoista usein päätetään yhdellä kerralla, tai ainakin 

lyhyellä aikavälillä. Hankintoihin liittyy myös aikataulu ja vastuuhenkilö tai -osasto. 

Suurin osa hankintoihin liittyvistä keskusteluista tapahtuu kokouksissa hankinnoista 

vastaavien toimittajien kanssa, niihin liittyvissä suunnittelukokouksissa sekä erillisissä 

hankintakokouksissa. 

Valitus on usein asiakkaan taholta tuleva tietotyyppi, mutta myös sisäisiä valituksia voi 

tulla esille projektikokouksissa. Valitukset voivat liittyä esimerkiksi poikkeamiin tai 

ongelmiin projektin tilanteessa. Valitus tietotyyppinä on usein ongelmallinen, sillä sen 

syiden tai seurausten selvittäminen saattaa olla vaikeaa, koska esimerkiksi valitukseen 

johtaneet päätökset voivat olla hajanaisesti kirjattuina useisiin paikkoihin. 

Asiakkaalta tulevasta valituksesta saattaa olla seurauksena muutos, joskin muutokset 

voivat olla seurauksina monista muistakin asioista, esimerkiksi tehottomista työskentelytavoista. 

Muutoksella tarkoitetaan asiakkaan tai muun osapuolen esittämää muutosvaatimusta 

projektin tavoitteisiin, laajuuteen tai esimerkiksi työskentelytapoihin. 

Projektinhallinnan kannalta muutokset ovat usein ongelmallisia, koska pienestäkin 

muutoksesta projektin tavoitteisiin voi seurata kaikkien aikataulujen uusiminen, uuden 

projektihenkilöstön rekrytointitarve tai muita taloudellisia menetyksiä aiheuttavia tekijöitä. 

Tiedotus on usein lyhyt asia, joka halutaan kertoa tietylle projektin ryhmälle, koko 

projektille tai yksittäiselle henkilölle. Seuraavan kokouksen ajankohta on tyypillinen 

tiedotusasia, joka löytyy lähes jokaisesta projektipöytäkirjasta. Tiedotuksen eräs tyyppi 

on yhteystiedot, joita voidaankin pitää yhtenä tiedotuksen erikoistapauksena. Yhteystiedot 

ovat periaatteessa luonteeltaan pysyvämpää tietoa kuin muut tiedotukset, vaikka 

käytännössä nekin usein muuttuvat projektin aikana. 

Projektikokouksissa esittely tarkoittaa pääasiallisesti aloituskokouksissa tapahtuvaa organisaatiokaavioiden, 

aikataulujen, budjetin tai muuta vastaavaa esittelyä. Esittelyjä ovat 

myös toimittajien hinta- tai tuote-esittelyt sekä ratkaisuehdotukset projektin ongelmiin. 

Myös tilanne on eräänlainen esittely. Kokouspöytäkirjoissa tilanne ja esittely tietotyyppeinä 

eroavat toisistaan siten, että esittelyn kohde on useimmiten pöytäkirjan liitteenä kun 

taas tilanne on kirjattuna varsinaiseen pöytäkirjaan. 

Ohje syntyy useimmiten siten, että projektissa tehdään virheitä tai projektissa ilmenee 

ongelmia ja niiden seurauksena keksitään uusia hyviä toimintatapoja. Ohjeita voi toki

42 

syntyä muutenkin projektin työntekijöiden hyvinä ajatuksina. Ohjeita sinänsä ei laadita 

projektikokouksissa, mutta niiden sisältöä käsitellään ja niitä hyväksytään näissä kokouksissa. 

Siksi ohjeista usein jää kirjauksia pöytäkirjoihin. 

Tehdyn tarkastaminen liittyy aina tehtävään. Tehtävästä voidaan tarkistaa joko sen tila 

(tehty/tekemättä) tai tulokset, eli kuinka hyvin tehtävä onnistui tai mitä siitä seurasi. 

Projektipöytäkirjoissa tätä tietotyyppiä löytyy useimmiten kohdasta, jossa on käsitelty 

edellisen palaverin pöytäkirjaa. 

Taulukossa 7 on esitetty kootusti edellä olleiden tietotyyppien mahdolliset ominaisuudet. 

Kaikilla tietotyypeillä ei siis välttämättä ole kaikkia taulukossa esitettyjä ominaisuuksia. 

Taulukko 7. Tietotyypit ja niiden ominaisuudet 

Tietotyyppi Ominaisuudet 

päätös 

vastuuhenkilö tai -osasto, laite tai projektin alue, perustelu 

tehtävä 

vastuuhenkilö tai -osasto, aikataulu, laite tai projektin alue, tila 

aikataulu 

projektin alue 

suunnitelma aikataulu, laite tai projektin alue 

selvitettävä asia vastuuhenkilö tai -osasto, aikataulu, laite tai projektin alue 

tilanne 

projektin alue, osasto 

hankinta 

vastuuhenkilö tai -osasto, aikataulu, laite tai projektin alue 

valitus 

vastuuhenkilö tai -osasto, laite tai projektin alue, syy, toiminta 

muutos 

vastuuhenkilö tai -osasto, laite tai projektin alue, syy 

tiedotus 

kohderyhmä, kohde 

yhteystiedot kohderyhmä, kohde 

esittely 

projektin alue 

ohje 

osasto, laite tai projektin alue 

tehdyn tarkastaminen kohde

43 

6 ÄLYKKÄÄN PÖYTÄKIRJAN ESIMERKKITOTEUTUS 

6.1 Toteutuksen taustaa 

Projektien pöytäkirjat ovat nykyisessä muodossaan täysin järjestämättömiä tekstidokumentteja, 

joiden sisällöstä tietokoneet eivät voi päätellä mitään. Tietyn pöytäkirjassa 

olevan lauseen, kappaleen tai muun kokonaisuuden sisällöstä ei myöskään voida sanoa 

mitään lukematta sitä. 

Seuraavassa esiteltävä älykkään projektipöytäkirjan esimerkkitoteutus koostuu kolmesta 

osasta: rakenteinen pöytäkirjamalli, dokumentin rakennekuvaus (Document Type 

Definition, DTD) ja hakuohjelma. Rakenteinen pöytäkirjamalli on laadittu pöytäkirjoista 

tehdyn dokumenttianalyysin perusteella. Dokumentin rakennekuvaus taas noudattaa tätä 

rakenteista mallia. Työssä tehty hakuohjelma noudattaa myös laadittua rakenteista mallia, 

mutta soveltuu minkä tahansa tämän perusteella tehdyn DTD:n analysoinnin välineeksi. 

Toteutuksen lähtökohtana on ollut kohdassa 2.3 määritelty tarveanalyysi. Pohdittaessa 

toteutukseen liittyviä ratkaisuja, tarveanalyysin tuloksena saadut tarpeet on pyritty huomioimaan 

mahdollisimman monipuolisesti. Käytännössä tämä tarkoittaa sellaisen 

rakenteisen mallin luomista, että kaikki tarpeisiin liittyvät tärkeimmät tavoitteet pystytään 

mallin avulla toteuttamaan. Tarveanalyysin lisäksi on otettu huomioon projektiorganisaation 

rakenne eri kokoustyyppien muodossa ja erityisesti Jaakko Pöyry Oy:n 

osastojen, laitteiden ja projektien luokittelustandardit. 

6.2 Rakenteinen pöytäkirjamalli 

Kuvissa 17a ja 17b on esitetty kaksi vaihtoehtoista tapaa järjestää projektikokouksen 

pöytäkirja rakenteiseen muotoon. Kuvassa 17a dokumentit on järjestetty dokumenttityypin 

mukaisesti kun taas kuvassa 17b järjestämisen kriteerinä on projektin numero tai 

nimi. Mikäli kuitenkin halutaan kehittää järjestelmä, jossa on muitakin 

dokumenttityyppejä kuin pöytäkirjoja, ei dokumentteja voida luokitella projektien 

mukaisesti. Tämä johtuu pääasiassa siitä, että esimerkiksi ohje on dokumentti, jota 

käytetään useissa projekteissa eikä sitä siten voida sijoittaa minkään tietyn projektin alle. 

Esimerkkitoteutuksessa käytetään siis kuvan 17a mukaista mallia. 

Rakenteinen pöytäkirjamalli noudattelee XML:n (eXtensible Markup Language) rakennetta, 

joka koostuu elementeistä ja niille annettavista ominaisuuksista eli attribuuteista. 

Jokainen pöytäkirjan kokonaisuus, esimerkiksi lause tai kappale, edustaa jotakin 

tietotyyppiä, jotka tässä on määritelty elementeiksi. Tämän lisäksi jokaiselle elementille 

voidaan määritellä haluttu määrä ominaisuuksia eli attribuutteja, jotka toimivat hakuohjelman 

hakukriteereinä. 

Tarkastellaan kuvan 17a mukaista mallia tarkemmin taso kerrallaan. Pöytäkirja tarkoittaa 

sitä, että dokumentti on tyyppiä pöytäkirja. Muita dokumenttityyppejä ovat esimerkiksi

44 

ohje tai sopimus. Seuraavalla tasolla on projekti, jotka luokitellaan joko numeron tai 

nimen mukaisesti. Pöytäkirjoja toki syntyy muuallakin kuin projekteissa. Nämä pöytäkirjat 

on kuitenkin rajattu tämän työn ulkopuolelle. Kolmannella tasolla on kokoustyyppi, 

jossa pöytäkirja on syntynyt. Kokoustyypit määriteltiin kohdassa 5.2. Kokoustyyppi 

sinänsä ei muuten ole välttämätön taso, mutta se saattaa tarjota arvokasta lisätietoa 

kokouksen asialistasta, osanottajista sekä kokouksen valtuuksista. Neljännellä tasolla ovat 

tietotyypit, jotka määriteltiin kohdassa 5.4. Tietotyypeillä on edelleen ominaisuuksia, 

jotka sijoittuvat viidennelle sekä mahdollisesti tästä eteenpäin oleville tasoille. 

a 

Kuva 17. Rakenteinen projektipöytäkirjamalli a) dokumenttityypin mukaan 

luokiteltuna b) projektitunnisteen mukaan luokiteltuna 

b 

Kuvassa 18 on esitetty vielä yksi vaihtoehtoinen tapa järjestää pöytäkirja rakenteisesti. 

Rakenteen etu on, että sitä käyttämällä voitaisiin hakukriteerinä käyttää esimerkiksi 

tiettyä laitetta, osastoa tai muuta ominaisuutta, joka on tiedon kohdistamisessa usein 

tärkeämpi kriteeri kuin tietotyyppi. Tietotyyppi pelkästään kertoo sisällöstä hyvin vähän, 

kun taas tieto siitä, että jokin asia liittyy esimerkiksi venttiileihin, on paljon havainnollisempaa. 

Käytännössä kuitenkin näitä ominaisuuksia on niin paljon, että käyttämällä 

kuvan 18 mukaista rakennetta pelkkien tietotyyppien, esimerkiksi kaikkien tehtävien, 

haku olisi tehdyssä esimerkkitoteutuksessa hankalaa. Hakuja varten pitäisi silloin tietää 

kaikki ominaisuudet, joista jokaisesta erikseen haettaisiin esimerkiksi tehtävät. 

Hakuohjelman käyttöperiaatteet esitellään tarkemmin kohdassa 6.4.

45 

Kuva 18. Vaihtoehtoinen rakenteinen malli projektipöytäkirjalle 

Vaikka kuvan 18 mukainen malli ei sovellukaan tässä työssä tehtyyn esimerkkitoteutukseen, 

sen käyttöä kannattaa harkita mahdollisessa jatkokehityksessä. Käyttäjille saattaa 

nimittäin olla luontevampaa tehdä hakuja ominaisuuksien kuin tietotyyppien perusteella. 

6.3 DTD 

Jaakko Pöyry Oy:n tarpeisiin soveltuvan DTD:n laadinnassa on käytetty kohdassa 6.2 

(kuva 17a) esitettyä rakenteista pöytäkirjamallia sekä kohdassa 5.4 esiteltyjä tietotyyppejä. 

Käytännössä kaikkia määriteltyjä tietotyyppejä ei kuitenkaan tarvita eikä niitä 

ole järkevää ottaa toteutukseen mukaan, jotta se säilyisi tarpeeksi yksinkertaisena. 

Tehdyssä DTD:ssä käytetyt tietotyypit ominaisuuksineen on esitetty taulukossa 8. 

Taulukko 8. DTD:ssä käytetyt tietotyypit ja niiden ominaisuudet 

Tietotyyppi Ominaisuudet 

päätös alue, laitenumero, vastuuhenkilö tai osasto, perustelu 

tehtävä alue, laitenumero, vastuuhenkilö tai osasto, määräaika, tila 

tilanne alue, osasto 

valitus alue, laitenumero, kohde, syy, toiminta 

muutos alue, laitenumero, kohde, syy 

tiedotus alue, laitenumero, kohderyhmä 

yhteystiedot osapuoli 

esittely alue, laitenumero, kohde

46 

Kohdassa 5.4 esitellyistä tietotyypeistä on tehdyssä DTD:ssä jätetty pois aikataulu, 

suunnitelma, selvitettävä asia, hankinta, ohje ja tehdyn tarkastaminen. Aikataulua ei 

tarvita, koska se voidaan aina esittää tilanteena. Suunnitelma voidaan esittää joko esittelynä, 

tehtävänä tai tilanteena. Selvitettävä asia voidaan esittää tehtävänä, hankinta on 

päätös tai tehtävä ja tehdyn tarkastaminen on tilanne tai tehtävään liittyvä tila-ominaisuus. 

Ohjeita pöytäkirjoissa esiintyy hyvin vähän ja lisäksi ne useimmiten voidaan ilmaista 

valituksista seuraavina toimintoina. Myöskään kaikkia kohdassa 5.4 määriteltyjä 

ominaisuuksia ei ole mukana tehdyssä DTD:ssä. Mukaan on otettu ne ominaisuudet, jotka 

ovat oleellisia Jaakko Pöyry Oy:n kannalta. 

Tehty DTD on esitetty liitteessä 1. Taulukossa 9 on esitetty DTD:n elementit selityksineen. 

Liitteessä 2 on esitetty esimerkki XML-muotoisesta pöytäkirjasta, joka käyttää tätä 

DTD:tä. Pöytäkirja on todellisen projektikokouksen pöytäkirja, jota on hieman muunneltu 

tunnistamisen välttämiseksi. 

Taulukko 9. DTD:n elementit ja ominaisuudet 

Elementti Attribuutti Selitys 

announcement 

(tiedotus) 

area valinnainen Kustannusalue. Jaakko Pöyry Oy:ssä 

projektit jaetaan kustannusalueisiin. 

Kustannusalueet näkyvät tehdyssä 

DTD:ssä (liite 1). 

change 

(muutos) 

claim 

(valitus) 

partnumber valinnainen Osanumero. Kaikki projektin laitteet tai 

osat saavat tietyn osanumeron, jonka 

perusteella ne voidaan tunnistaa. 

target_group valinnainen Tiedotuksen kohderyhmä. Tyypillisiä 

kohderyhmiä ovat koko projekti, 

yksittäinen osasto tai henkilö. 

area valinnainen Kustannusalue 

partnumber valinnainen Osanumero 

target valinnainen Muutoksen kohde. Mikäli muutosta ei 

voida kohdistaa kustannusalueelle tai 

osalle, vaan se koskee esimerkiksi 

projektiorganisaatiota tai standardeja, 

käytetään target-attribuuttia. 

reason pakollinen Muutoksen syy. Muutoksen syy pitää 

aina kirjata, jotta muutoksia voidaan 

myöhemmin analysoida. 

action pakollinen Valituksesta seuraava toiminta. 



target valinnainen Kohde 

reason pakollinen Valituksen syy

47 

contact_info 

(yhteystiedot) 

party pakollinen Osapuoli, jonka yhteystiedot ovat 

kyseessä. 

decision area valinnainen Kustannusalue 

(päätös) partnumber valinnainen Osanumero 

responsible valinnainen Päätöksestä vastaava henkilö tai osasto. 

reason valinnainen Päätöksen syy. Jos päätökseen liittyy 

selkeä syy tai perustelu, voidaan se 

kirjata attribuutiksi. 

introduction area valinnainen Kustannusalue 

(esittely) partnumber valinnainen Osanumero 

target valinnainen Muu kohde kuin alue tai osanumero 

meeting_minutes date pakollinen Kokouspäivämäärä 

(dokumentin place pakollinen Kokouspaikka 

tyyppi, present pakollinen Kokouksen osaanottajat 

juurielementti) distribution pakollinen Pöytäkirjan jakelu 

appendices valinnainen Liitteet. Liitteet ovat yleensä irrallinen 

osa itse pöytäkirjasta. Linkitystä tai 

muuta sijainnin ilmaisua varten ne 

voidaan ilmaista omalla attribuutilla. 

meeting_type 

(kokoustyyppi) 

type 

parties 

pakollinen 

pakollinen 

Kokoustyyppi. Kokoustyypit esiteltiin 

luvussa 5.2. 

Kokouksen osapuolet, eli siihen 

osallistuneiden yritysten nimet. 

project number pakollinen Jaakko Pöyry Oy:ssä jokaisella 

projektilla on numero, jolla projekti 

voidaan tunnistaa. 

status 


(tilanne) department valinnainen Osasto tai muu vastuualue. 

task 


deadline valinnainen Tehtävän määräaika 


responsible pakollinen Tehtävän vastuuhenkilö tai -osasto 

status pakollinen Tehtävän tila (tehty/ tekemättä) 

6.4 Hakuohjelma 

Tätä työtä varten tehty rakenteisille projektipöytäkirjoille tarkoitettu hakuohjelma on 

toteutettu Java-ohjelmointikielellä. Ohjelman UML (Unified Modelling Language)- 

luokkakaavio on esitetty kuvassa 19. Hakuohjelma tätä työtä varten on toteutettu itse 

kahdesta syystä. Ensinnäkin tällä hetkellä tarjolla olevat hakumahdollisuudet XMLdokumenteille 

eivät ole erityisen joustavia eikä niistä löytynyt tähän työhön soveltuvaa

48 

ratkaisua. Toiseksi nyt tehtyä hakuohjelmaa voidaan kehittää eteenpäin tai sillä voidaan 

myöhemmin tutkia muita mahdollisia rakenteita pienin muutoksin. 

Kuva 19. Hakuohjelman UML- luokkakaavio 

Ohjelma toimii siten, että MMinutesMain-luokka etsii hakemiston, jossa rakenteiset, 

XML-muotoiset, pöytäkirjadokumentit sijaitsevat. Hakemisto määritellään erilliseen 

tekstitiedostoon, josta sitä on helppo muuttaa tarvittaessa. Samaan tekstitiedostoon 

määritellään myös käytettävän DTD:n sijainti. MMinutesSearchEngine, joka on ohjelman 

tärkein luokka, kysyy tämän hakemiston polun ja jäsentää kaikki kyseisessä hakemistossa 

olevat XML-dokumentit. Jäsennyksessä käytetään sekä omia sisäisiä luokkia että 

Apachen Crimson-jäsennintä. Sisäisistä luokista MMinute edustaa yhtä yksittäistä pöytä-

49 

kirjaa. Yksi MMinute sisältää vaihtelevan määrän Element-olioita, jotka kuvaavat pöytäkirjan 

elementtejä. 

Työssä käytetty Crimson on Java XML-jäsennin, joka tukee XML v. 1.0:aa. Tällä hetkellä 

Crimson on yksi yleisimmin käytetyistä XML-jäsentimistä, joiden lähdekoodi on 

avoin. Crimson-jäsennin toteuttaa SAX 2.0 (Simple API for XML)-rajapinnat. SAX 2.0 

määrittää joukon rajapintoja, jotka määrittävät tapahtumapohjaisen XML-jäsentimen, 

tässä tapauksessa Crimson-jäsentimen, toiminnan. SAX 2.0 tukee myös muita ohjelmointikieliä 

kuin Javaa, esimerkiksi Perl- ja C++ -kieliä. 

MMinutesSearchEngine käynnistää SAX-jäsentimen ja jää kuuntelemaan sen lähettämiä 

tapahtumia. Jäsennin lähettää tapahtuman aina, kun se löytää jäsennettävästä dokumentista 

elementin tai attribuutin. Saadessaan SAX-jäsentimeltä tapahtuman, että juurielementti 

on löytynyt, MMinutesSearchEngine luo uuden MMinute-olion. Vastaavasti 

muista elementeistä luodaan Element-olioita. Luodut Element-oliot tallennetaan 

MMinute-luokan elements-vektoriin. Attribuutit tallennetaan Element-luokan attr-hajautustaulukkoon 

(hashtable) ja elementtien sisältö, eli haettava tieto, content-merkkijonoon 

(string). MyErrorHandler toteuttaa SAX- rajapintojen määrittämät pakolliset virheiden 

käsittelymetodit. 

MMinutesUI määrittää hakuohjelman käyttöliittymän. Ohjelman käyttöliittymä on esitetty 

kuvassa 20. 

Kuva 20. Esimerkkitoteutusta varten tehdyn ohjelman käyttöliittymä 

MMinutesUI kutsuu MMinutesSearchEngine-luokan search-metodia. Tämä metodi 

suorittaa määritellyt haut jäsennetyistä XML-dokumenteista ja palauttaa jokaisesta 

löydetystä hakutuloksesta MMinutesSearchEngineResult-olion. Nämä oliot sisältävät 

jokaisesta hakutuloksesta käyttöliittymässä määritellyt tiedot, eli kokouspäivämäärän,

50 

kokoustyypin, haetun elementin sisällön sekä tiedoston, josta kyseinen elementti löytyy. 

MMinutesUI myös määrittää käyttöliittymään sallitut elementit ja niiden attribuutit. 

Nämä on määritelty erillisessä, DTD:stä muodostetussa, XML-tiedostossa. Ohjelmalle 

voidaan siis antaa mikä tahansa DTD, josta on tehty XML-tiedosto. Esimerkki tällaisesta 

XML-tiedostosta on esitetty liitteessä 3. Kyseessä on kohdassa 6.3 esitellystä DTD:stä 

muodostettu XML-tiedosto. 

Ohjelmaa käytetään siten, että käyttäjä määrittää aluksi, mitä tietotyyppiä (elementti) hän 

tahtoo hakea. Tämän jälkeen käyttäjä valitsee tietotyypin ominaisuuden (attribuutti) ja 

kirjoittaa tekstikenttään ominaisuuden halutun hakuarvon. Ohjelman näyttämä hakutulos 

on esitetty kuvassa 21. Esimerkissä on haettu tehtäviä, joiden suorittamisesta vastaa 

Jaakko Pöyry Oy. 

Kuva 21. Esimerkkihaun tulos

Ohjelmalla voidaan myös hakea kaikkia tiettyyn elementtiin liittyviä attribuutteja 

valitsemalla attribuutin paikalle ALL. Tällöin hakutulokseksi saadaan esimerkiksi kaikki 

tehtävät. Lisäksi voidaan hakea kokouksia niiden päivämäärän, paikan tai läsnäolijoiden 

perusteella sekä muitakin elementtejä kuin tietotyyppejä sallitun DTD:n (taulukko 9) 

mukaisesti. Koska tehdyissä XML-dokumenteissa ainoastaan neljännen tason elementeillä 

(tietotyypit, kuva 17a) on varsinaista sisältöä, muunlaisista kuin tietotyyppeihin 

kohdistuvista hauista ei tulostu content-kenttään mitään. Sisältöhakuja ohjelma ei tee. 

51

52 

7 PROJEKTIPÖYTÄKIRJOJEN HYÖDYNTÄMINEN 

7.1 Yleistä 

Seuraavassa esitetään analyysi työssä laaditun tietorakenteen (kohta 6.2) soveltumisesta 

projektinhallinnan apuvälineeksi tehdyn esimerkkitoteutuksen avulla. Analyysi pohjautuu 

tarveanalyysin tuloksena määriteltyjen tarpeiden mukaisten käyttöskenaarioiden 

testaamiseen älykkään pöytäkirjan mahdollisilla käyttäjillä. Tutkimusmenetelmät on 

esitelty tarkemmin luvuissa 2.3 ja 2.4. 

Jokaisen tarpeen osalta esitellään ongelma, ratkaisu ongelmaan ja tulokset luvun 2.4 

mukaisista käyttäjätesteistä. Lisäksi jokaisen tarpeen kohdalla pohditaan muita 

mahdollisia käyttötarkoituksia tehdylle esimerkkisovelluksen mukaiselle rakenteiselle 

projektipöytäkirjadokumentille sekä sen pohjalle rakennettaville paremmille järjestelmille. 

7.2 Tiedon kohdistaminen 

7.2.1 Ongelma 

Nykyisissä Jaakko Pöyry Oy:n pöytäkirjojen arkistointikäytännöissä pöytäkirjat on 

jaoteltu kahden kriteerin, kokoustyypin ja kokouspäivämäärän, mukaisesti. Vaikka nämä 

ovat hyviä ja myös välttämättömiä kriteereitä, luokittelusta seuraa joukko ongelmia 

silloin, kun halutaan hakea tietoa useista pöytäkirjoista. Tarkastellaan esimerkkiä, jossa 

asiakas projektin loppupuolella tekee valituksen siitä, että paperikoneen venttiilit on 

säädetty väärin. Mikäli asia todella olisi näin ja säädöt täytyisi korjata, aiheutuisi tästä 

kenties suurtakin taloudellista vahinkoa, esimerkiksi työvoimakustannuksia. Jos asiasta 

tehtyjä päätöksiä joudutaan etsimään projektikokousten pöytäkirjoista, nykyisen 

arkistointikäytännön mukaan täytyy tietää kokoustyypit, joissa venttiilien säätöjä on 

käsitelty sekä ajankohta, jolloin kyseistä keskustelua on käyty. On myös mahdollista, että 

venttiilien säädöistä on keskusteltu useissa kokouksissa ja niistä on mahdollisesti tehty 

useita, toisilleen ristikkäisiä päätöksiä. Asiasta on myös mahdollisesti päätetty 

kokouksessa, jonka osallistujilla ei ollut kyseisiin päätöksiin edes valtuuksia ja 

mahdollisesti osa pöytäkirjoista löytyy ainoastaan kokousten osallistujilta, ei keskitetysti 

projektin sihteeriltä. Käytännössä tällaisessa tapauksessa jouduttaisiin siis käymään läpi 

kaikki projektin pöytäkirjat, joita voi projektin loppupuolella olla tuhansia. Olisi siis 

tärkeää saada helposti esille kaikki venttiilien säätöihin liittyvät päätökset, jotta valituksen 

aiheellisuus voidaan selvittää. Annetuilla kriteereillä se ei kuitenkaan ole mahdollista. 

Tiedon kohdistamismahdollisuuden puuttuminen on suurin ongelma, joka nykyisissä 

pöytäkirjakäytännöissä on. Jaakko Pöyry Oy:n asiakasprojektit ovat pääasiallisesti hyvin 

suuria projekteja, jotka kestävät usean vuoden ja joissa on hyvin paljon erilaisia 

sidosryhmiä. Tällaisen projektin aikana pidetään tuhansia kokouksia ja tehdään tuhansia 

pöytäkirjoja. Pöytäkirja dokumenttina on yksi tärkeimmistä tiedon välityksen kanavista.

53 

Projektin elinkaaren aikana myöhemmin mukaan tuleva osapuoli ei kuitenkaan välttämättä 

ole kiinnostunut kaikista pöytäkirjoista, vaan ainoastaan esimerkiksi venttiileihin 

liittyvistä asioista. Kuitenkin saadakseen kaiken venttiileihin liittyvän informaation, 

joutuu kyseinen osapuoli, kuten edellisessäkin esimerkissä, ainakin selaamaan läpi kaikki 

mahdolliset pöytäkirjat ja koska suurin osa informaatiosta luultavasti on hänen kannaltaan 

epäolennaista, saattaa myös olennainen informaatio jäädä huomiotta. 

Vastaavia esimerkkejä ongelmista voidaan löytää paljonkin. Kaikki tapaukset, joissa 

yksittäisistä tai pienestä joukosta pöytäkirjoja pitäisi löytää tarkkaan määriteltyä tietoa, 

kuuluvat tähän ryhmään. 

7.2.2 Ratkaisu ja tulokset 

Projektipöytäkirjojen rakenteisessa esimerkkitoteutuksessa tietoa haetaan nimenomaan 

kohdistamalla sitä tuloksena haluttuun tietotyyppiin (elementti) ja ominaisuuteen 

(attribuutti). Tilanteessa, jossa henkilö tarvitsee kaikki tietylle venttiilille kohdistuneet 

päätökset, hän valitsee elementiksi päätöksen ja attribuutiksi osanumeron, jonka jälkeen 

tekstikenttään voi syöttää haluamansa numeron tai osan siitä. Haku toimii vastaavalla 

tavalla muillakin tietotyypeillä. 

Hakuskenaarioina tiedon kohdistamista tutkittaessa käytettiin: 

• paperikoneeseen liittyvien päätösten haku, 

• kaikkien projektin osapuolten yhteystietojen haku ja 

• edellisessä kokouksissa läsnä olleiden henkilöiden selvittäminen. 

Testihenkilöt olivat yksimielisiä ja kokivat tehdyn ratkaisun "erittäin hyväksi". Mitään 

vastaavaa mahdollisuutta ei tällä hetkellä ole olemassa ja tiedon kohdistamismahdollisuuden 

koettiin olevan erittäin hyödyllinen projektinhallinnan työvälineenä. 

Hakutuloksena saatu tieto oli käyttäjien mielestä hyödyllistä ja oikeanlaista. Tiedon 

kohdistamistarkoitukseen tehty rakenne ei ollut liian yksityiskohtainen eikä liian 

yksinkertainen, vaan sillä voitiin hakea haluttuja asioita riittävällä tarkkuudella. 

Parannusehdotuksena käyttäjät toivoivat mahdollisuutta seurata tapahtumaketjuja. Esimerkkiratkaisussa 

ei ole mahdollista tutkia, onko esimerkiksi toimittajan tekemästä esittelystä 

seurannut hankintapäätös. Päätös (decision)- elementin syy (reason)- attribuuttia 

ehdotettiin siksi pakolliseksi. Lisäksi lopullista toteutusta varten toivottiin mahdollisuutta 

linkkien kautta seurata näitä tapahtumaketjuja. 

7.2.3 Muut mahdollisuudet 

Tiedon kohdistaminen on projektipöytäkirjan käyttömahdollisuus, jonka käyttöä voi harkita 

kaikissa projektin hallintaprosesseissa alkaen projektin eheyden ja laajuuden hallinnasta 

ja päättyen riskien ja muutosten hallintaan. Alla on esitetty muutamia esimerkkejä 

mahdollisuuksista niihin projektin hallintaprosesseihin liittyen, joita ei tarkastella 

erikseen.

54 

• Eheyden hallinta: Projektisuunnitelman laadinnassa voidaan käyttää edellisten 

projektien pöytäkirjoja ja hakea niistä projektisuunnitelman kohtiin liittyvää 

tietoa. Esimerkki tällaisesta käytöstä on aikaisemman projektiorganisaation 

esittelyn haku tai edellisen projektin tilanteiden yhdistäminen yhdeksi kokonaisuudeksi 

aikataulujen laatimista varten. 

• Laajuuden hallinta: Projektin tuotteeseen projektin aikana tulevat muutokset 

kirjataan aina pöytäkirjoihin. Laajuuden hallinnassa voidaan sopivia hakuja 

tekemällä selvittää muutosten aiheellisuus esimerkiksi hakemalla muutoksen 

kohteesta aikaisemmin sovittuja asioita, kuten päätöksiä ja tehtäviä. 

• Aikataulujen hallinta: Projektin pääaikataulu koostuu useista pienemmistä 

aikatauluista. Jos rakenteisesta pöytäkirjasta hakee tilanteita tai tehtyjä tehtäviä, 

niitä voidaan verrata projektin aikatauluihin ja käyttää apuna aikataulujen 

hallinnassa. 

• Kustannusten hallinta: Pöytäkirjoista voidaan hakea tehtäviä tai päätöksiä, jotka 

liittyvät hankintoihin. Lisäksi voidaan hakea toimittajien tekemiä esittelyjä. Myös 

aikatauluihin liittyvät haut koskevat läheisesti kustannusten hallintaa. 

• Laadun hallinta: Koska laadun hallinta on prosessi, joka ulottuu kaikkeen 

projektin työhön ja kaikkiin projektin hallintaprosesseihin, voidaan minkä tahansa 

haun, joka helpottaa projektin läpivientiä, ajatella olevan osa laadun hallintaa. 

• Hankintojen ja laitteistoresurssien hallinta: Projektikokouksissa käsitellään 

projektissa käytettäviä laitteita. Näiden hankinnoista ja ylläpidosta päätettäessä 

voidaan tutkia, mitä niistä on aikaisemmin päätetty. 

Projektipöytäkirjaa voidaan myös käyttää projektin hallinnan lisäksi esimerkiksi sen 

seuraamiseen tai siitä raportointiin. Esimerkiksi voidaan kohdistaa hakuja eri päivämäärille, 

jolloin projektipöytäkirjaa voidaan ajatella käytettävän projektin elinkaaren 

seuraamisen välineenä. 

7.3 Henkilöstön ja tehtävien hallinta 

7.3.1 Ongelma 

Projektikokouksissa tehtyjen päätösten seurauksena syntyy tehtäviä. Pöytäkirjat toimivat 

näiden tehtävien jakelukanavina. Usein kokouksissa päätetään myös tehtävistä sellaisille 

henkilöille, jotka eivät itse ole läsnä kokouksessa. Osa kokouksissa päätetyistä tehtävistä 

jää toisinaan ilman vastuuhenkilöä, joko erehdyksen vuoksi tai sen vuoksi, ettei tehtävää 

pystytä kokouksessa kohdistamaan kellekään henkilölle työtilanneinformaation puuttuessa. 

Jaakko Pöyry Oy:n nykyiseen pöytäkirjakäytäntöön kuuluu merkitä erilliseen sarakkeeseen 

pöytäkirjan oikeaan reunaan tehtävien vastuuhenkilöiden nimikirjaimet. Näin 

pyritään siihen, että vilkaisemalla pöytäkirjaa nopeasti, voi saada yleiskuvan siitä, onko 

omalle kohdalle merkitty tehtäviä. Ratkaisu ei kuitenkaan toimi silloin, kun vastuuhenkilö

55 

on jätetty merkitsemättä. Monesti myös vastuuhenkilön tilalle merkitään ainoastaan 

vastuuyrityksen nimi, jolloin tehtävien koordinointi jää sitä hoitavan henkilön, tyypillisesti 

projektipäällikön, vastuulle. Ongelmatilanne syntyy myös, jos vastuu on annettu 

henkilölle, joka ei ollut kokouksessa ja joka ei siis automaattisesti jakelun mukaan saa 

pöytäkirjaa. Tehtävä voi siis jäädä hoitamatta, jos kokouksessa tai muiden käytäntöjen 

mukaan ei ole määritelty, kenen pitää tehtävistä tiedottaa. 

Tehtävien hallinnassa on niiden jakamisen lisäksi toinen ongelma. Luettaessa tehtäviä 

vanhasta pöytäkirjasta ei voida tietää, onko tehtävä tehty tai mahdollisesti tekemättä. 

Käytännössä edelliseen pöytäkirjaan kirjattujen tehtävien tila tarkistetaan seuraavassa 

kokouksessa kohdassa edellinen pöytäkirja, mutta tämän jälkeen niihin ei enää palata 

riippumatta siitä, oliko tehtävä tehty. Asiakkaan valittaessa esimerkiksi, että sovittuihin 

muutoksiin liittyviä töitä ei ole tehty, voidaan kyllä tarkistaa onko kyseisistä tehtävistä 

sovittu, mutta ei sitä, onko niitä todella tehty. 


Rakenteisessa projektipöytäkirjassa tehtävällä on oma elementti (task). Tällä elementille 

voidaan antaa attribuutit vastuuhenkilö, määräaika, osanumero, kustannusalue ja tila. 

Näistä pakollisia ovat vastuuhenkilö (tai osasto, yritys) sekä tila. Pöytäkirjaa laadittaessa 

kaikkien tehtävien tila on oletusarvoisesti tekemättä. Jälkeenpäin tila korjataan tehdyksi. 

Esimerkkisovelluksessa korjaus täytyy tehdä manuaalisesti XML-tiedostoihin, mutta 

lopullisessa järjestelmässä korjaaminen voidaan automatisoida esimerkiksi sähkö-postilla 

tehtäväksi automaattiseksi toiminnoksi. 

Skenaarioina henkilöstöresurssien ja tehtävien hallintaa analysoitaessa käytettiin seuraavia 

hakuja: 

• kaikkien tehtävien hakua, joista testihenkilö itse oli tai oli ollut vastuussa, 

• kaikkien tekemättömien tehtävien hakua, 

• kaikkien paperikoneeseen liittyvien tehtävien hakua ja 

• kaikkien niiden tehtävien hakua, joille ei ollut määritetty vastuuhenkilöä. 

Testihenkilöt kokivat yksimielisesti tehdyn ratkaisun "melko hyödylliseksi". Tulos 

selittyy osittain sillä, että tehtävien hallintaan on jo olemassa oma pöytäkirjakäytäntönsä, 

joka puutteistaan huolimatta on ollut käytössä toimiva. "Erittäin hyödylliseksi" koettiin 

mahdollisuus hakea tekemättömiä tehtäviä. Viimeisen skenaarion toteuttaminen oli 

hankalampaa, sillä esimerkkisovelluksella ei voi hakea siten, että se hakisi elementtejä, 

joilta puuttuu tietty attribuutti. Skenaarion toteutus hoidettiin siten, että haettiin aluksi 

kaikki tehtävät ja sen jälkeen haettiin kaikki tehtävät, joilla oli responsible-attribuutti. 

Näitä kahta listaa vertaamalla saatiin kaikki tehtävät, joilla ei ollut vastuuhenkilöä. 

Parannusehdotuksena testihenkilöt toivoivat mahdollisuutta nähdä tehtävistä myös päivämäärän, 

jolloin se oli tehty. Esimerkkisovellus ei sisällä tällaista tietoa. Myös tehtävien

56 

kohdalle kaivattiin tapahtumaketjuja. Esimerkiksi haluttiin tietää, mistä päätöksestä jokin 

tehtävä oli seurannut. 


Tehtävien hallintaa varten rakenteisesta pöytäkirjasta voidaan muodostaa tehtävälistoja, 

joita projektipäälliköt tai muut tehtävien koordinoinnista vastaavat henkilöt voisivat 

käyttää apuna projektin seuraavaa ajanjaksoa suunniteltaessa. Listoista nähtäisiin kunkin 

projektityöntekijän tehtäväkuormitus sekä se, millaisia tehtäviä kullekin työntekijälle on 

annettu. Lisäksi tehtävien suoritusajoista voidaan saada apua aikataulujen laatimiseen, jos 

suorituspäivämäärä on kirjattu ylös. 

Samanlaisia tehtävälistoja voi jokainen työntekijä laatia itselleen. Lista voisi esimerkiksi 

olla standardoitu sen muotoiseksi, että siinä on nappi, jota painamalla lähtee tieto järjestelmälle, 

että tehtävä on tehty. Järjestelmä osaisi tämän perusteella muuttaa tehtävän 

tilaksi tehty ja kirjata suorituspäivämäärän. 

Tehtävien merkitsemisestä tehdyiksi seuraa kuitenkin yksi ongelma. Pöytäkirja on dokumentti, 

jota ei sen hyväksymisen jälkeen saisi muuttaa. Joko kokousosapuolten on sovittava 

siitä, että tehtävien tiloja saa muuttaa myös pöytäkirjan hyväksymisenkin jälkeen tai 

tehtävän tilan hallinta on toteutettava jollain muulla tapaa. Yksi vaihtoehto tähän on 

kaikkien avoimien tehtävien kuljettaminen mukana pöytäkirjoissa niin kauan, kunnes ne 

on tehty. Kaikille tehtäville olisi myös hyvä määrittää jokin yksiselitteinen tunniste, 

esimerkiksi tehtävänumero, jotta voitaisiin paremmin nähdä, liittyykö johonkin tehtävään 

useita päätöksiä tai työmääräyksiä. Kaksi eri henkilöä voivat kirjoittaa tehtävän ylös niin 

eri tavoin, etteivät kaikki ymmärrä kyseessä olevan sama tehtävä. Tunnisteen avulla 

pystyttäisiin aina tietämään varmasti, mikä tehtävä on kyseessä. 

Tehtävien jakamisongelmaan voidaan ottaa avuksi sähköposti. Järjestelmä voisi olla 

sellainen, että se automaattisesti osaisi yhdistää tehtävän saaneen henkilön ja tämän 

sähköpostiosoitteen. Kun henkilölle määrätään tehtävä, järjestelmä lähettää automaattisesti 

sähköpostia tehtävän saaneelle henkilölle. Vaihtoehtoisesti sähköpostijärjestelmä voi 

olla vapaaehtoinen siten, että sen käyttäjäksi voivat rekisteröityä sellaiset henkilöt, jotka 

eivät halua itse hakea heille määrättyjä tehtäviä joka kokouksen jälkeen. Ne taas, jotka 

eivät halua sähköpostia, voivat käyttää hakukonetta. 

7.4 Projekteista oppiminen 

7.4.1 Ongelma 

Projekteissa tehdään paljon virheitä ja niitä sekä korjaavia toimenpiteitä käsitellään 

projektikokouksissa. Tällöin syntyy usein paljon hyviä ideoita virheiden ennaltaehkäisemistä 

ajatellen, jotka kuitenkaan eivät ole millään tavoin muiden projektien 

käytettävissä. Käytännössä siis kaikissa projekteissa saatetaan tehdä samat virheet, koska

57 

vaatisi melkoisesti aktiivisuutta muutenkin kiireiseltä projektipäälliköltä tutkia muiden 

projektien pöytäkirjoja oppimismielessä. 

Myös kaikki projektin laajuuteen liittyvät muutokset kuuluvat sellaiseen informaatioon, 

jota tarvittaisiin projektin jälkeen. Suuri osa näistä muutoksista toki kirjataan muuallekin 

kuin pöytäkirjoihin, mutta esimerkiksi muutosten todelliset syyt saattavat jäädä huomiotta, 

jos pöytäkirjoissa oleva informaatio ei ole käytettävissä. Muutosten hallintaan liittyviin 

asioihin palataan kohdassa 7.6. 

Valitukset, sekä aiheelliset että aiheettomat, ovat informaatiota, jota tarvitaan projektin 

jälkeen. Valituksiin liittyvät virheet tai muut syyt pyritään seuraavissa projekteissa ennaltaehkäisemään. 

Suurin osa valituksista käsitellään projektikokouksissa ja myös niihin 

liittyvistä toiminnoista ja tehtävistä sovitaan. Muiden projektien riskien hallintaa ajatellen 

tällainen informaatio olisi erittäin tärkeää. 

Projekteista voidaan oppia muutenkin kuin virheistä ja valituksista. Kaikki projekteissa 

tehdyt ratkaisut ja päätökset vaikuttavat projektin kulkuun. Projektin jälkeen voidaan 

esimerkiksi tarkistaa kuinka venttiilit oli säädetty ja kun muistetaan, että kyseessä oli 

onnistunut projekti, tietoa voidaan käyttää seuraavassakin projektissa. Iso osa projekteissa 

tehtävistä päätöksistä onkin juuri sellaisia, jotka ovat sellaisenaan sovellettavissa kaikissa 

vastaavissa projekteissa ja käytännössä samoista asioista on aivan turhaa päättää useaan 

kertaan. Tällaiset päätökset ovat usein hiljaista tietoa kokeneella projektiorganisaatiolla, 

mutta uusilla projektityöntekijöillä tätä tietämystä ei vielä ole. Jos kuitenkin tämä informaatio 

on helposti saatavilla, voidaan kokousten asialistat jo laatia siten, että niissä on 

liitteenä ehdotus, joka vastaa edellisessä projektissa käsiteltyjä vastaavia asioita, mikä 

taas tehostaa myös kokouskäytäntöjä. 


Projekteista oppimista varten tehdyt ratkaisut ovat osittain samoja kuin kohdassa 7.2.2 

esitellyt tiedon kohdistamisratkaisut. Päätöksillä on oma elementti (decision), jolle voi 

määrittää attribuutiksi kustannusalueen, osanumeron, vastaavan tahon sekä syyn. Erityisesti 

syy (reason)- attribuutti on projekteista oppimisen kannalta tärkeä. Esimerkiksi jos 

paperitehtaan seinät on maalattu siniseksi, voi tähän olla syynä viranomaisten rakennuslupamääräys 

tai se, että asiakas ei pidä vihreästä. Projektista oppimisen kannalta on 

tärkeää tietää kummasta on kyse, jotta tiedetään, oliko se projekti- tai asiakaskohtainen 

ratkaisu vai ratkaisu, jota täytyy soveltaa tulevaisuudessakin kyseiselle alueelle rakennettaessa. 

Valituksista ja muutoksista oppimista varten on omat valitus (claim)- ja muutos (change)- 

attribuutit. Näille syy- attribuutti on pakollinen. Lisäksi valitukseen liittyy toiminta 

(action)- attribuutti. Myös tämä on pakollinen, joten käytännössä sen arvoksi on kirjattava 

ainakin, ettei tehty mitään, mikä on oppimisen kannalta myös arvokas tieto. Mikäli

58 

osapuolet suostuvat siihen, että pöytäkirjoja muutetaan jälkeenpäin, sen arvoa voi käydä 

muuttamassa, kun jotain tehdään. 

Skenaarioina projekteista oppimista tutkittaessa käytettiin: 

• kaikkien projektista tehtyjen valitusten hakua, 

• kaikkien paperikoneesta päätettyjen asioiden hakua ja niiden syiden selvittämistä 

sekä 

• kaikkien projektiorganisaatioon liittyvien muutosten hakua. 

Testihenkilöt kokivat ratkaisun antamien tulosten olevan "erittäin hyödyllisiä". Erityisesti 

mahdollisuus katsoa syitä päätösten, valitusten ja muutosten taustalla koettiin hyväksi. 

Esimerkkitoteutuksessa syyt käytännössä piti etsiä hakuohjelman ilmoittamista tiedostoista, 

sillä ohjelmassa ei ole toiminnallisuutta, joka tulostaisi syyt näkyviin. Lopulliseen 

järjestelmään voidaan kuitenkin rakentaa mahdollisuus myös syiden tulostamiseen. Tämä 

oli myös testihenkilöiden ehdottama parannusidea. 


Jos käytössä on usean projektin rakenteiset pöytäkirjat, järjestelmän avulla on helppoa 

koota tilastoa projekteissa esiintyneistä valituksista. Näitä tilastoja voidaan kohdistaa eri 

tuotteille, toiminnoille tai osastoille ja käyttää kokonaisten prosessien parantamiseen. 

Tilastojen avulla voidaan siis selvittää projektien selkeitä ongelmakohtia ja käyttää siten 

projektien laadun parantamisessa ja laadunvalvonnassa. 

Myös projektien valituksista ja muutoksista rakennetut tilastolliset jakaumat ovat 

projektin riskinhallinnan kannalta hyödyllisiä. Tulevissa projekteissa niitä voidaan 

käyttää riskien tunnistamiseen ja ennaltaehkäisyyn. Kohdassa 7.6 on käsitelty enemmän 

muutosten hallintaan liittyvää pöytäkirjojen käyttöä. 

Tavallisia päätöksiä projekteista oppimistarkoitukseen voi käyttää esimerkiksi laatimalla 

kaikista useimmissa projekteissa olevista tavallisista osista omia elinkaaria ja käyttää 

näitä seuraavien projektien kokouksissa pohjatietona. Tällaisia elinkaaria, jotka sisältävät 

siis kaikki kyseiseen osaan liittyvät päätökset ja muut oleelliset tietotyypit, voidaan myös 

käyttää projektiohjeiden laatimisen ja parantamisen perustana. Esimerkiksi jos paperikoneen 

elinkaaren aikana siitä tehdään muutamia tarjousesittelyjä, hankintapäätös, tuhat 

tavallista päätöstä ja valmistumispäätös, saadaan kyseiset päätökset lukemalla varsin 

selkeä kuva paperikoneen rakentamisen elinkaaresta. Lisäksi voidaan liittää elinkaareen 

kaikki paperikoneeseen liittyvät tehtävät. 

Koska pitkät merkkijonot tai jopa lauseet tietoelementtien attribuutteina heikentävät itse 

dokumentin luettavuutta, syy- ja toiminta-attribuuteille voitaisiin myös määrittää jonkinlaiset 

numero- tai nimitunnisteet. Tällöin ei tarvitsisi kirjoittaa koko syytä tai toimintaa 

itse dokumenttiin. Esimerkiksi syy voitaisiin kirjoittaa erilliseen tekstitiedostoon, jonka 

nimi annetaan syy-attribuutiksi. Järjestelmän tehtävänä olisi tällöin hakea tiedoston sisältö

59 

niin haluttaessa. Tämä on kuitenkin lähinnä ulkonäköseikka, jolla ei käytännössä ole 

oleellista merkitystä. Tarkoituksena ei nimittäin ole, että kukaan järjestelmän käyttäjä 

lukisi XML-dokumentteja sellaisinaan. 

7.5 Projektin tilanteen seuraaminen 

7.5.1 Ongelma 

Projektikokoukset ovat pääasiallinen kanava projektin tilanteesta raportoimiseksi ulkoisille 

tahoille, esimerkiksi asiakkaalle. Tätä tarkoitusta varten projektin seurantakokousten 

asialistoissa on erikseen kohta, jossa käsitellään projektin sen hetkistä tilannetta. 

Samoissa kokouksissa käsitellään kuitenkin myös projektin pienempien osien tilanteita, 

joita kuitenkaan ei kirjata mitenkään keskitetysti mihinkään, vaan informaatiota näistä 

tilanteista löytyy useista paikoista. Myös eri osapuolien kanssa käsitellään erilaista 

tilanneinformaatiota. 

Projekteissa täytyy kuitenkin laatia tilanneraportteja esimerkiksi yrityksen ylimmälle 

johdolle sekä myös asiakkaalle. Informaatio näitä raportteja varten kerätään useista 

kokouksista, esimerkiksi työryhmien viikkopalavereista ja jopa työmaapalavereista. 

Käytäntö on ongelmallinen, koska se vaatii monien pöytäkirjojen lukemista tilanneraporttia 

laadittaessa, tilannetietojen kohdistamista oikealla projektin osalle sekä oletusta siitä, 

että kaikki informaatio löytyy pöytäkirjoista. 


Rakenteisessa pöytäkirjassa tilanteella on oma elementti (status). Koska tilanneraportit 

laaditaan pääasiallisesti kustannusalueittain tai osastoittain, tilanne-elementin attribuuttina 

ovat juuri kustannusalue (area) ja osasto (department). Käytännössä osastoksi voidaan 

myös määritellä koko projekti, jolloin saadaan koko projektia koskevat tilannetiedot. 

Kaikki tilannetiedot taas saadaan määrittämällä attribuutiksi ALL. 

Testihenkilöille annettiin kaksi skenaariota, jotka olivat 

• projektin tilanteen tämänhetkinen selvittäminen sekä 

• jonkin kustannusalueen tämänhetkisen tilanteen selvittäminen 

Oletuksena skenaarioissa oli lisäksi, että kyseinen projekti oli vielä käynnissä ja pöytäkirja, 

jossa oli uusin päivämäärä, oli tämänhetkinen tilanne. 

Testihenkilöt kokivat saadun tiedon "jonkin verran hyödylliseksi". Tulokseen vaikutti 

suuresti se, että käytetyissä pöytäkirjoissa oli melko vähän muuta tilannetietoa kuin koko 

projektiin liittyvää. Toinen tulokseen vaikuttava seikka oli, että testihenkilöt ovat 

tottuneet selaamaan tilannetietoa etsiessään pöytäkirjoja, koska se kuitenkin on ollut 

esitettynä selkeästi omassa kohdassaan. Lisäksi tilannetieto pelkästään koettiin melko 

irralliseksi. Esimerkiksi lause "75 % of piles has been driven, casting of slab proceeding 

in 3 fronts" liitteessä 2, jonka saa siis hakutuloksena valitsemalla elementiksi tilanteen ja 

osastoksi koko projektin, irroitettuna asiakokonaisuudesta koettiin hyvin mitäänsanomat-

60 

tomana. Asiakokonaisuudella tarkoitetaan tässä koko pöytäkirjaa ja siinä erityisesti 

kohtaa projektin tilanne. 

Tilanteisiin liittyvien hakujen kohdalla täytyykin siis miettiä hakutulosten esittämismuotoa. 

Nykyinen ohjelma tulostaa päivämäärän, johon tilanne liittyy, mutta pelkkä 

päivämäärä ei tehtyjen testien mukaan riittänyt. Tulokseen voitaisiin harkita tulostettavan 

esimerkiksi kokouksen osapuolet tai muuta tietoa, joka auttaisi ohjelman käyttäjää hahmottamaan 

kokonaisuuden paremmin. Toinen asia, joka käyttäjätesteissä tuli ilmi, oli 

tilannetietojen huono esitysmuoto projektipöytäkirjoissa. Tämä asia ei varsinaisesti liity 

tämän työn aiheeseen, mutta käyttäjät ilmaisivat toivomuksensa pöytäkirjoja laativille 

henkilöille, että tilannetieto kirjattaisiin dokumentteihin hiukan yksityiskohtaisemmin. 

Parempi kirjaamistapa saattaisi myös auttaa edellä esitetyn hahmottamisongelman ratkaisemiseen. 


Mikäli pöytäkirjoihin kirjoitettaisiin yksityiskohtaisempaa tilannetietoa, tilanneraporttien 

laatiminen voitaisiin osittain automatisoida. Laatiminen voisi silloin tapahtua hakemalla 

kaikki tilannetieto raportin aiheen mukaisilla attribuuteilla ja ohjelma voisi tulostaa 

valmiin pohjan mukaisen raportin. Tähän automaattiseen raporttiin voisi sitten lisätä 

kohtia tai siitä voitaisiin poistaa niitä halutulla tavalla. Tällainen automaattinen tilanneraporttien 

laatiminen vaatisi kuitenkin, että pöytäkirjoihin osattaisiin kirjata asiat oikeassa 

muodossa. 

Toinen mahdollinen käyttö on tilanteiden vertaaminen projektin aikatauluihin ja budjettiin. 

Pöytäkirjaan on kyllä useimmiten kirjattu, jos projektin jokin osa on myöhässä, mutta 

ei esimerkiksi sitä, jos se on etuajassa ja koko projektin suorittamista voitaisiinkin 

nopeuttaa. Hakemalla pöytäkirjoista tilannetietoa, voidaan tätä verrata projektin aikatauluun 

ja budjettiin ja siten pöytäkirjaa voidaan käyttää apuna projektinhallintaan liittyvien 

tunnuslukujen laskemisessa. Tällaisia tunnuslukuja ovat esimerkiksi tuloksen arvo 

(earned value), aikatauluero (schedule variance) tai tuloksen kustannukset (actual cost for 

work performed). Lisätietoa näistä projektin kustannusten hallintaan liittyvistä tunnusluvuista 

löytyy esimerkiksi lähteistä /26, 30/. 

7.6 Muutosten hallinta 

7.6.1 Ongelma 

Muutosten hallinnan ongelmat liittyvät osittain luvussa 7.4 esittyihin projektista 

oppimisen ongelmiin. Muutokset ovat kuitenkin ongelmallisia jo projektin aikana. Aivan 

projektin alussa tehdyt muutokset eivät ole yhtä ongelmallisia kuin projektin elinkaaren 

myöhemmissä vaiheissa tehdyt ovat. Muutokset projektin laajuuteen voivat seurata 

esimerkiksi virheellisestä työstä tai suunnittelusta, mutta myös asiakkaan tarpeiden 

muuttumisesta tai siitä, että huomataan tietynlaisen toteutuksen olevan mahdoton tai

61 

huono. Koska muutokset usein seuraavat valituksista, myös valitukset liittyvät muutosten 

hallintaan. 

Mikäli asiakas vaatii muutosta valituksen seurauksena, projektipöytäkirjoja tarvitaan 

siihen, että etsitään valituksen aiheellisuuden syytä. Kuten jo kohdassa 7.2.1 todettiin, 

näitä pöytäkirjoja voi olla tuhansia ja käytännössä ne kaikki joudutaan silloin ainakin 

selaamaan läpi. Myös tehdyt muutokset ovat ongelma: jos tehty muutos ei tuotakaan 

haluttua tulosta, saattaa seurauksena olla, että muutettu asia joudutaan muuttamaan 

takaisin ja kustannukset tästä pitäisi pyrkiä kohdistamaan sille osapuolelle, joka muutosta 

on vaatinut. Jos tätä ei ole missään virallisessa sopimuksessa määritelty, seuraava lähde, 

mistä asiaa tutkitaan, ovat projektin pöytäkirjat. 

Muutokset projektin laajuudessa vaikuttavat myös suuresti projektin aikatauluun ja 

budjettiin. Projektin aikana näitä vaikutuksia on kuitenkin vaikeaa tutkia, sillä käytössä ei 

varsinaisesti ole mitään systeemiä, versionumeroinnin lisäksi, jolla tietty laajuuden 

muutos voitaisiin yhdistää tiettyihin aikataulu- tai budjettimuutoksiin. Sama pätee myös 

muihin suuntiin. 


Esimerkkitoteutuksessa muutoksella on oma change-elementti. Lisäksi valituksella on 

elementti claim. Näillä molemmilla on pakolliset syy-attribuutit, jonka lisäksi ne voidaan 

kohdistaa muillekin ominaisuuksille (taulukot 8 ja 9). Valituksen toiminta-attribuutin 

arvoksi voidaan antaa sama, kuin siitä seuraavan muutoksen syyksi. Tällöin voidaan 

yhdistää toisiinsa valitus ja muutos. Myös muutos-elementin sisältö voidaan antaa 

valituksen toiminta-attribuutin arvoksi. 

Käytetyt hakuskenaariot olivat 

• kaikkien paperikonetta koskevien muutosten haku ja syiden selvittäminen sekä 

• valituksista seuranneiden muutosten hakeminen 

Ensimmäisestä skenaariosta saadut tulokset koettiin "erittäin hyödyllisiksi". Toisen skenaarion 

toteuttaminen oli kommenttien mukaan hiukan hankalampaa: aluksi piti hakea 

valituksia ja niiden toiminta-attribuuttien arvojen perusteella muutoksia. Saatuja tuloksia 

pidettiin myös "erittäin hyödyllisinä" ja niiden katsottiin olevan hyvä apuväline projektin 

budjetin, aikataulun ja laajuuden yhdistämisessä siten, että valituksen päivämäärää ja 

muutoksen päivämäärää voidaan verrata aikatauluihin ja budjettiin ja niissä tehtyjen 

muutospäivämäärien avulla selvittää yhteys. Hakumenetelmää tosin toivottiin kehitettävän 

paremmaksi. 


Projektin aikataulun, budjetin ja laajuuden yhdistäminen paremmin projekteissa tapahtuviin 

muutoksiin on projektipöytäkirjan käyttämistä muutosten hallinnan apuvälineenä 

ajatellen oleellinen asia. Muutoksen attribuutiksi voidaan esimerkiksi lisätä linkki siihen

62 

liittyvään aikatauluun ja versioon, johon muutos on vaikuttanut. Tämä tosin edellyttää 

myös aikataulujen ja muiden vastaavien projektinhallinnan välineiden siirtämistä 

sellaiseen paikkaan, että ne ovat järjestelmän käytettävissä. 

7.7 Rakenteisesta tiedonhallinnasta seuraavat ongelmat 

Rakenteinen projektipöytäkirjan hallinta ratkaisee monia projektinhallintaan liittyviä 

ongelmia, mutta sen mukana tulee myös uusia ongelmia tai asioita, joihin toteutettaessa 

älykästä projektipöytäkirjaa, täytyy ottaa kantaa. Seuraavaksi esitellään muutamia 

tärkeimpiä ongelmia, joiden ratkaisuja täytyy pohtia esimerkkisovelluksen pohjalta 

rakennettavaa järjestelmää kehitettäessä. 

Yksi tietoelementti voi edustaa useaa eri tietotyyppiä. Kokouksessa voidaan esimerkiksi 

päättää, että tehtaan seinien väri pitää muuttaa vihreästä siniseksi. Tämä on silloin sekä 

päätös, tehtävä että muutos. Esimerkkitoteutuksessa on ajateltu, että muutos on tehtävän 

erikoistapaus ja tehtävä on päätöksen erikoistapaus. Tällöin kyseinen tietoele-mentti 

voidaan luokitella muutokseksi. Vastaavia ongelmia kuitenkin varmasti ilmenee myös 

muunlaisia, jolloin jokaiseen tulee etsiä erikseen ratkaisu. Ei myöskään ole itsestäänselvyys, 

että pöytäkirjaa laativa henkilö ratkaisee vastaavat tilanteet samalla tavalla, 

kuin joku muu, joka tietoa tarvitsee. 

Hyvin samanlainen ongelma syntyy tapahtumaketjuista. Tällainen on esimerkiksi valituksesta 

seuraava päätös, josta seuraa muutos, josta seuraa tehtävä, josta seuraa taas uusi 

valitus jne. Tällaisia tapahtumaketjuja tosin ei pystytä hallitsemaan nytkään, mutta 

tapahtumaketjujen hallinta on yksi asia, jonka toteutustapa tulevaa sovellusta 

rakennettaessa pitää ratkaista. 

Liian tarkka tietoelementtien luokittelu tekee rakenteisen dokumentin hyvin jäykäksi. 

Tällöin, jos halutaan tehdä haku suuremmasta kokonaisuudesta, esimerkiksi paperikoneesta, 

saatetaan joutua hakemaan monta kertaa, mikä vähentää rakenteisen pöytäkirjan 

käyttöarvoa. Toisaalta liian löysä luokittelu johtaa taas siihen, että pieniä tietokokonaisuuksia 

on vaikeaa löytää. Esimerkkitoteutuksessa ollutta rakennetta pidettiin 

yleisesti ottaen hyvänä, mutta toisaalta vertailukohdetta ei ole. Samaten attribuuttien 

tarkkuutta pitää harkita. Toisaalta on hyvä, että voidaan hakea paperikoneen millä tahansa 

pikkuosalla, toisaalta taas saatetaan hakea pelkällä paperikoneella. Tämän ongelman tosin 

voi ratkaista siten, että hakemalla pelkällä osanumeron alkuosalla saadaan isompi 

kokonaisuus ja tarkalla numerolla tietty yksittäinen osa. Jaakko Pöyry Oy:ssä osanumerot 

on standardoitu siten, että numeron tietty osa tarkoittaa tiettyä asiaa. 

Jos jokin tietotyyppi kohdistuu usealle osalle tai alueelle, se pitää luultavasti luokitella 

niiden kaikkien mukaan, jotta se tarvittaessa löytyisi. Tällöin pitää standardoida muoto, 

jossa osat syötetään, esimerkiksi "osa1, osa2, osa3" tai "osa1; osa2; osa3". Tämä tosin 

riippuu pöytäkirjan syöttämiseen käytetyistä työkaluista siten, että se voidaan myös 

muuttaa toiminnaksi, jonka ohjelma hoitaa itse. Tällöin käyttäjien ei tarvitsisi miettiä

63 

asiaa pöytäkirjoja laatiessa. Standardointiin liittyy myös joukko muita ongelmia, esimerkiksi 

se, kuinka kaikki attribuuttien mahdolliset arvot saadaan standardoiduksi siten, että 

hakukone varmasti löytää kaikki mahdolliset tulokset. 

7.8 Johtopäätökset 

Käyttäjätutkimuksen päätarkoitus oli selvittää tehdyn tietorakennemallin (kuva 17a) 

soveltumista projektihallinnan apuvälineeksi. Tehty tietorakenne osoittautui hyväksi. Se 

ei ollut liian yksityiskohtainen mutta ei myöskään liian löysä. Ainoastaan tilanne (status)- 

elementin sisältämä tieto oli sellaista, että sen esitysmuotoon tai sisältöön toivottiin 

parannusta. 

Muutamia esimerkkisovelluksen puutteita lukuunottamatta älykkään projektipöytäkirjan 

esimerkkitoteutus koettiin erittäin hyödylliseksi. Myös ajatusta älykkäästä projektipöytäkirjasta 

projektihallinnan apuvälineenä pidettiin hyvänä. Johtopäätöksenä tuloksista 

voidaan sanoa, että älykkään projektipöytäkirjan kaltainen apuväline on erittäin hyvä ja 

tarpeellinen. Se tarjoaa mahdollisuuksia hyödyntää projektien pöytäkirjoja aivan uusilla 

tavoilla, niin koko projektin hallinnan kuin yksittäisen projektityöntekijän kannalta. 

Käytön mahdollisuudet riippuvat pitkälti siitä, kuinka älykäs pöytäkirja toteutetaan. 

Esimerkkitoteutuksen käyttöä vaikeutti lähinnä sen käyttöliittymän rajoittuneisuus. 

Läheskään kaikkea haluttua ja myös tarjolla olevaa informaatiota ei saanut helposti 

käyttöön, mikä testihenkilöiden mukaan varmasti rajoittaisi ihmisten halua käyttää sitä. 

Jatkokehityksessä täytyykin ottaa huomioon, että kaikki rakenteisen pöytäkirjadokumentin 

sisältö olisi helposti hyödynnettävissä. Ei ole kenenkään kannalta 

mielekästä syöttää dokumentteihin suurta määrää tietoa, jota ei sitten helposti voi käyttää. 

Tässä työssä ei kuitenkaan ollut tarkoitus kehittää täydellistä hakuohjelmaa vaan tehdyn 

sovelluksen tarkoituksena oli tutkia älykkään pöytäkirjan rakenteen järkevyyttä. Tähän 

tarkoitukseen sovellus koettiin riittävän hyväksi. 

Käyttöliittymän lisäksi parannus- ja jatkokehitysajatuksina toivottiin eniten mahdollisuutta 

seurata pöytäkirjoissa olevia tapahtumaketjuja. Tehty tietorakenne ei tällaisenaan 

tarjoa siihen kuin melko alkeellisia mahdollisuuksia. Näitä ovat esimerkiksi päätöksen 

syy-attribuutti ja muutoksen tai valituksen syy- ja toiminta-attribuutit. 

Kaikkien tässä luvussa esitettyjen tulosten luotettavuutta heikentää jonkin verran se, että 

kyseessä on täysin uusi pöytäkirjan käyttömuoto, eikä vertailukohdetta siis ole. 

Testihenkilöitä pyydettiin vertaamaan hakujen tuloksia niihin käytäntöihin, joilla he 

nykyisin hoitavat kyseessä olevaa tehtävää. Voidaan kuitenkin vain todeta, että testattu 

tietorakenne tarjoaa hyödyllistä tai hyödytöntä informaatiota, ei sitä, tarjoaisiko jokin 

muu rakenne parempaa tai huonompaa informaatiota. 

Toinen luotettavuutta hieman heikentävä seikka on käytetyn pöytäkirjamateriaalin 

pienehkö määrä (30 kpl). Pöytäkirjat oli valittu siten, että kaikki tietotyypit kaikkine 

ominaisuuksineen olivat edustettuina, mutta toisaalta tämä valinta myös saattoi jalostaa

64 

hakujen tuottaman informaation sellaiseksi, että se väistämättä oli hyödyllistä. Myös 

skenaariot on valittu siten, että ne tuottavat ainakin kohtuullisen määrän järkevää 

informaatiota. Toisaalta testikäyttäjät saivat myös tehdä vapaita hakuja, joten ei voida 

väittää skenaarioiden kovin pahasti rajoittavan saatuja tuloksia. Se, että käytetyt 

pöytäkirjat olivat todellisesta projektista ja sisälsivät siis informaatiota, jota oikeasti on 

käsitelty, lisää tulosten luotettavuutta siltä osin, että voidaan todeta rakenteen ja hakujen 

soveltuvan oikeiden pöytäkirjojen käsittelyyn. 

Kaikki testikäyttäjät olivat kiinnostuneita järjestelmästä, jolla voitaisiin hallita projektien 

pöytäkirjoja. Muutosvastarinnan vaikutusta tulevan järjestelmän mahdolliseen käyttöön ei 

siis tässä työssä ole huomioitu.

65 

8 JATKOKEHITYS 

8.1 Tietoelementit ja -attribuutit 

Pöytäkirjojen hallintajärjestelmän jatkokehitys voidaan jakaa kahteen osaan: tietoelementtien 

ja -attribuuttien valinta ja standardointi sekä tarvittavista tekniikoista ja työkaluista 

päättäminen. Ajatuksia jatkokehityksessä tehtävistä lisätoiminnallisuuksista tuli 

esille tehdyissä käyttäjätesteissä ja niitä esiteltiin luvussa 7. 

Älykkään projektipöytäkirjan esimerkkitoteutus tarjoaa yhden ehdotuksen valittavista 

tietoelementeistä. Tämä rakenne myös todettiin käyttäjätesteissä hyväksi. Sovelluksesta 

hieman riippuen kuvan 18 mukaista rakennetta voi harkita. Käytännössä tämä ei kuitenkaan 

vaikuta itse tietoelementtien valintaan, vaan ainoastaan niiden järjestämiseen. Sovelluksesta 

voidaan myös tehdä sellainen, että hakuja ei rajoita taustalla oleva tietorakenne, 

vaan haut voidaan tehdä joko tietotyypin tai sen ominaisuuden perusteella riippumatta 

siitä käytetäänkö kuvan 17a vai kuvan 18 mukaista rakennetta. Tärkeää on ainoastaan 

käyttää kaikille pöytäkirjoille samaa rakennetta. 

Attribuuttien valinta riippuu älykästä pöytäkirjaa käyttävän organisaation käytännöistä. 

Kohdassa 6.2 esitelty DTD soveltuu Jaakko Pöyry Oy:n käyttöön sekä sellaisille 

yrityksille, joissa esimerkiksi osat tai osastot luokitellaan vastaavalla tavalla. Käytännössä 

kuitenkin jokaiselle organisaatiolle on luotava oma DTD. Attribuuttien sallitut arvot on 

syytä myös standardoida mahdollisimman pitkälle. Tämä lisää tehtävien hakujen 

luotettavuutta huomattavasti. Jos esimerkiksi osat voidaan yksiselitteisesti luokitella 

numerotunnisteen perusteella, sitä kannattaa käyttää mieluummin kuin osan nimeä. 

Nimen käyttämisessä ongelma on aina se, että eri ihmiset saattavat käyttää eri nimeä ja 

esimerkiksi kirjoitusvirheet aiheuttavat sen, että osaa ei löydykään. Numerotunnistetta 

käytettäessä järjestelmä voi tarkistaa, että kyseinen osanumero on olemassa, mikä osittain 

vähentää kirjoitusvirheiden aiheuttamia ongelmatilanteita. Lisäksi järjestelmässä voisi 

olla toiminnallisuus, joka osaa yhdistää osanumeron sen nimeen, jolloin haun voi tehdä 

myös nimellä, jos tietää osan virallisen ja standardoidun nimen. 

Attribuuttien sallituille arvoille pitää myös standardoida kieli. Käytännössä Jaakko Pöyry 

Oy:ssä kaikki suurten projektien pöytäkirjat ovat englanniksi, jolloin luonnollinen kielivalinta 

on englanti. Kieltä ei automaattisesti voi valita sen mukaisesti, millä kielellä itse 

pöytäkirja on, sillä suuressa projektissa saatetaan pitää kokouksia useilla kielillä. Siksi 

kieleksi pitää valita koko projektin virallinen kieli ja lisäksi sellainen, jota ainakin valtaosa 

projektin työntekijöistä ymmärtää. 

8.2 Tekniikat ja työkalut 

Älykästä pöytäkirjajärjestelmää kehitettäessä voidaan pohjaksi ottaa nykyinen esimerkkisovellus 

ja lisätä siihen toiminnallisuutta. Käytännössä tämä ei kuitenkaan olisi paras 

mahdollinen ratkaisu, sillä projektissa pöytäkirjoja voi olla useita tuhansia, eikä toteutus-

66 

tapa, jossa jäsennetään ja käydään läpi joukko XML-dokumentteja ole erityisen nopea. Se 

soveltui hyvin muutamien kymmenien dokumenttien läpikäymiseen, mutta jos pöytäkirjoja 

on esimerkiksi 10 000 kappaletta, haku on melko hidas. Erilaiset pöytäkirjat voidaan 

tietysti tallettaa eri hakemistoihin. Tämä nopeuttaa hakua, mutta saattaa aiheuttaa tilanteita, 

joissa jokin pöytäkirja on tallennettu väärään paikkaan ja siksi siinä ollut informaatio 

jää haussa löytämättä. Niin kauan kuin pöytäkirjojen määrä on pienehkö, esimerkiksi 

muutamia satoja, ratkaisu, jossa haut tehdään suoraan jäsennetyistä dokumenteista 

on yksinkertaisin ja selkein. 

Toinen, ja käytännössä parempi, vaihtoehto on tallentaa pöytäkirjat tietokantoihin. Relaatiotietokannassa 

jokainen tietoelementti esitetään omana relaatiotaulunaan, kun taas 

oliotietokannassa yksi olio edustaa yhtä tietoelementtiä /17/. Kumpaa tahansa voidaan 

käyttää ja molemmilla on hyvät ja huonot puolensa. Kuvissa 23 ja 24 on esitetty päätöselementin 

relaatiotaulu ja päätös-elementistä luotu olio. 

Kuva 23. Päätös-elementin relaatiotaulu 

Kuva 24. Päätös-elementti olio 

Relaatiokannassa tietoelementtien yhdistäminen toisiinsa tapahtuu tunnisteen eli Idkentän 

mukaisesti. Oliokannassa taas yhdistäminen tapahtuu viittausten avulla. Käytännössä 

oliokanta-ajattelu on lähempänä rakenteisen dokumentin mallia ja siksi se voisi olla 

parempi ratkaisu älykkään dokumentin tallennustavaksi. Relaatiokannan etu oliokantaan 

nähden on se, että se on perinteisempi ja enemmän käytetty ratkaisu. /17/

67 

Hakutulosten esitysmuoto on yksi jatkokehityksen kohteista. Yksi vaihtoehto on laatia 

XSL (eXtensible Stylesheet Language)- kielellä erilaisia tyylisivuja, joiden avulla hakutuloksista 

voidaan muokata erilaisia raportteja, tehtävälistoja tai aivan perinteisen pöytäkirjan 

näköinen dokumentti. 

Iso kysymys on myös käytettävien työkalujen valinta. Pöytäkirjojen syöttäminen XMLeditorilla 

tuskin tulee kysymykseen, ellei editori ole hyvin helppokäyttöinen. Käytännössä 

ongelma on, että helpoimmassakin XML-editorissa syöttäjällä täytyy olla perustiedot 

XML:n rakenteesta. Syöttäminen tavallisella tekstinkäsittelyohjelmalla, esimerkiksi MS 

Word:llä, olisi tavallisen käyttäjän kannalta helpoin ratkaisu. Taustalla voisi olla ohjelma, 

jolle kerrotaan, mistä tietoelementistä on kyse ja joka osaisi sitten kysyä arvoja attribuuteille. 

Yksi vaihtoehto on myös laatia valmis lomake, jota voisi käyttää tavallisilla 

Internet-selaimilla. Lomakkeessa olisi tekstikenttiä ja niihin liittyviä elementti- ja 

attribuuttikenttiä, joihin voisi valita sallittuja elementtejä ja attribuutteja valikosta.

68 

9 YHTEENVETO 

Työssä käsiteltiin viestintää projekteissa ja yhtä viestinnän erikoistapausta: projektikokouksia. 

Projektissa, jossa on useita osapuolia, projektikokoukset ovat pääasiallinen 

viestintäkanava projektin osapuolten välillä. Projektikokouksissa päätetään lähes kaikki 

projektiin liittyvät asiat, niissä raportoidaan projektin kulusta ja keskustellaan projektin 

läpiviemisen strategioista. 

Suuret projektit voivat kestää useita vuosia. Näin pitkällä aikavälillä kokouksia ehditään 

pitää tuhansia. Vastaavasti myös kokouspöytäkirjoja tehdään tuhansia. Kokouspöytäkirjat 

projekteissa ovat tärkeitä dokumentteja, joihin kirjatut päätökset ovat osapuolten välisen 

sopimuksen mukaan laillisesti sitovia. Siksi niihin kirjatut asiat tulisi olla helposti tarkistettavissa. 

Nykyisin projektien pöytäkirjat ovat tallennettuina vaihteleviin paikkoihin eikä 

niille ole toteutettu minkäänlaista hakumahdollisuutta. Käytännössä kaikki tarkistukset 

pitää siis tehdä manuaalisesti pöytäkirjoja selaamalla, mikä on muutenkin kiireisessä 

projektissa liikaa aikaa vievä prosessi. 

Tässä työssä tutkittiin mahdollisuutta järjestää kokouspöytäkirjat älykkääseen muotoon. 

Älykäs dokumentti on sellainen, että siihen on lisätty tietoa sen sisällöstä ja se voidaan 

muuntaa moniin eri tarkoituksiin sopiviin muotoihin. Työssä kartoitettiin dokumenttianalyysin 

avulla projektikokouksissa syntyvä tieto ja luotiin rakenteinen malli projektikokouksen 

pöytäkirjalle. Saatua mallia testattiin työssä tehdyn esimerkkisovelluksen 

avulla siten, että projektinhallintaa työkseen tekevät henkilöt käyttivät sovellusta ja 

arvioivat rakenteen hyödyllisyyttä. Mallin suunnittelussa ja käyttäjätesteissä lähtökohtana 

pidettiin käyttäjien tarpeita, jotka kartoitettiin ennen suunnittelutyön aloittamista. Tällä 

tavoin pyrittiin ratkaisuun, joka olisi sellainen, että käyttäjät kokisivat saavansa siitä 

todellista hyötyä projektinhallinnan apuvälineenä. Kartoitettuja ja testattuja tarpeita oli 

yhteensä viisi. Jokaiseen liittyen annettiin käyttäjille hakuskenaarioita, joiden tuloksia 

käyttäjät arvioivat. Lisäksi pohdittiin muita käyttömahdollisuuksia jokaiseen tarpeeseen 

liittyen. 

Käyttäjät kokivat mallin ja hakusovelluksen tuottaman informaation pääosin 

hyödylliseksi jokapäiväiseenkin käyttöön. Myös ajatus hakutoiminnosta pöytäkirjoille 

koettiin hyväksi. Tuloksena saatiin myös joukko parannusehdotuksia ja -ideoita. 

Testien tuloksia voidaan pitää luotettavina. Käytetty materiaali oli peräisin oikeasta 

projektista, sitä oli paljon ja se oli monipuolista. Kaikki työssä kartoitetut tietoelementit 

attribuutteineen olivat edustettuina. Luotettavuutta hiukan heikentää se, että testeissä ei 

ollut mahdollisuutta käyttää kovin suurta määrää pöytäkirjoja, joten suuresta joukosta 

jouduttiin valitsemaan sellaisia, joissa oli mahdollisimman erityylistä tietoa. Tämä saattoi 

jonkin verran jalostaa hakujen tuloksia. Toinen luotettavuutta hiukan heikentävä seikka 

oli, että testihenkilöt olivat kaikki innostuneita ajatuksesta, että pöytäkirjat olisivat 

älykkäässä muodossa, joten muutosvastarinnan vaikutuksesta ei voida tämän tutkimuksen

69 

perusteella esittää johtopäätöksiä. Koska tehdylle tietorakenteelle ei ollut minkäänlaista 

vertailukohdetta, ei myöskään voida sanoa rakenteen olevan paras mahdollinen, 

ainoastaan, että se toimi hyvin. 

Työn lopussa tarkasteltiin vielä lyhyesti ratkaisuja, joita täytyy tehdä kehitettäessä oikeaa 

järjestelmää älykkäille pöytäkirjoille. Työssä tehty esimerkkisovellus ei ole soveltuva 

laajamittaisempaan käyttöön.

70 

LÄHDELUETTELO 

/1/ Andersen, E. S., Grude, K. V., Haug, T. Goal Directed Project Management. Kogan 

Page, Lontoo 1998. 192 s. 

/2/ Artto, K. Managing Business by Projects - the Basics of Project Management from a 

new perspective, Teknillinen korkeakoulu, Tuotantotalouden osasto. Helsinki 2000. 265 s. 

/3/ Beyer, H., Holtzblatt, K. Contextual Design : A Customer-Centered Approach to 

Systems Designs. Morgan Kaufmann, San Fransisco 1997. 350 s. 

/4/ Blessing, D., Goerk, M., Bach, V. Management of Customer and Project Knowledge: 

Solutions and Experience at SAP. Knowledge and Process Management 8(2001)2, s 75 – 

90. 

/5/ Choo, C. W. The Knowing Organization.How Organizations Use Information to 

Construct Meaning, Create Knowledge and Make Decisions. Oxford University Press, 

New York 1998, 320 s. 

/6/ Damm, D., Schindler, M. Security issues of a knowledge medium for distributed 

project work. International Journal of Project Management 20(2002)1. s. 37-47. 

/7/ Dias, C. Corporate portals: a literature review of a new concept in Information 

Management. International Journal of Information Management 21(2001)4. s. 269 –287. 

/8/ Eloranta, E., Hameri, A-P., Lahti, M. Improved project management through 

improved document management. Computers in Industry 45(2001)3. s. 224–231. 

/9/ Feigenbaum, E., McCorduck, P. Viides sukupolvi: Japanin haaste. Kirjayhtymä. 

Helsinki 1985, 275 s. 

/10/ Galliers, R. D. In search of a paradigm for information systems research. In: 

Mumford, E., Hirschheim, R., Fitzgerald, G., Wood-Harper, T.(toim.). Research methods 

in information systems. Amsterdam 1985. Elsevier Science Publishers B.V. s. 281-290. 

/11/ Holtshorne, D. Ten Knowledge Domains: Model of a Knowledge-Driven Company 

Knowledge and Process Management 6(1999)1. s. 3-8. 

/12/ Huuskonen, P. Model-based explanation of plant knowledge. Valtion teknillinen 

tutkimuskeskus, Espoo 1997, 232 s. 

/13/ ISO 10006. Quality management - Guidelines to quality in project management. The 

International Organization for Standardization, 1997. 23 s.

71 

/14/ Jaakko Pöyry Oy. Project Management Procedure Manual. Jaakko Pöyry Oy, 

Vantaa 1998. 

/15/ Johannessen, J-A., Olaisen, J., Olsen, B. Mismanagement of tacit knowledge: the 

importance of tacit knowledge, the danger of information technology, and what to do 

about it. International Journal on Information Management 21(2001)1, s. 3-20. 

/16/ Kaarela, K., Huuskonen, P., Leiviskä, K. The role of design knowledge in 

industrial plant projects. In: Proceedings of the 4 th International Conference on Cognitive 

and Computer Sciences for Organizations, Montreal 1993, s. 173-183. 

/17/ Karjalainen, A. M. Etäoppimateriaalin rakenteistaminen. Jyväskylän yliopisto, 

Tietojenkäsittelytieteiden laitos. Jyväskylä 1997. 106 s. 

/18/ Koulopoulos, T. M., Frappaolo, C. Electronic Document Management Systems. A 

Portable Consultant. McGraw-Hill Inc. USA 1995. 313 s. 

/19/ Maler, E., El Andaloussi, J., Developing SGML DTDs. From text to model to 

markup. Prentice Hall. New Jersey 1996. 532 s. 

/20/ Niiniluoto, I. Tieto, Informaatio ja Yhteiskunta. Hallinnon kehittämiskeskus. 

Helsinki 1997. 136 s. 

/21/ Nissen, H-E. Acquiring Knowledge of Information Systems - Research in a 

Methodological Quagmire. In: Mumford, E., Hirschheim, R., Fitzgerald, G., Wood- 

Harper, T.(toim.), Research methods in information systems, Amsterdam 1985, Elsevier 

Science Publishers B.V., s. 39-51. 

/22/ Nonaka, I. The knowledge-creating company: how Japanese companies create the 

dynamics of innovation. Oxford University Press, New York 1995. 284 s. 

/23/ Nyman, G. Henkisten voimavarojen hallinta verkottuneessa liiketoiminnassa, Luento 

31.5.2001. Professori. Helsingin yliopisto, Psykologian laitos. 

/24/ Oakland, J. S. Statistical process control. Butterworth-Heinemann. Oxford 1999. 

425 s. 

/25/ Oittinen, P. AS-75.100 Mediatekniikka, Luentokalvoja. Teknillinen korkeakoulu, 

Viestintätekniikan laboratorio. Espoo 2000. 194 s. 

/26/ Pelin, R. Projektihallinnan käsikirja, Gummerus Kirjapaino Oy. Jyväskylä 1999. 

438 s.

72 

/27/ Pitkänen, S. S. Haastattelu 17.9.2001. Projektipäällikkö. Stora Enso Oyj, 

Kanavaranta 1, 00101 Helsinki, Finland. 

/28/ Project Management Institute. Guide to the Project Management Body of 

Knowledge 2000 edition. USA 2000. 176 s. 

/29/ Robertson, S. Requirements trawling: techniques for discovering 

requirements. International Journal on Human-Computer Studies 55(2001)4. s. 405-421. 

/30/ Turner, R. The Handbook of Project-based Management. McGraw-Hill. Cambrigde 

1999. 529 s. 

/31/ Wiio, O. A., Johdatus viestintään. Weilin+Göös. Porvoo 1994. 271 s.

LIITE 1. PÖYTÄKIRJOJEN HALLINNASSA KÄYTETTY 

DTD 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

LIITE 2. ESIMERKKI XML-MUOTOISESTA 

PÖYTÄKIRJASTA 

 

 

 

 

 

 

75 % of piles has been driven, casting of slab 

proceeding in 3 fronts 

Wire silo level will be lowered by 100 

mm 

Customer presented document delivery time 

schedule, no critical items. 

Stainless steel piping to be used for condensate 

lines after the condensate pump if pump is stainless steel material. 

 

Approach Flow System: Butterfly type valve to 

be used as shut-off valve before machine screens. Valve will be located into 

pipe between the flanges. 

Approach 

Flow System: Correct flow balance for dilution headbox. 

Approach Flow System: Drains after machine 

screens duplicated in Supplier flow sheet, second one to be 

removed. 

Approach flow system: Wire silo might be in 

unbalanced situation. To guarantee constant level is silo, recirculation with 

level control valve to be arranged. 

Approach 

flow system: Supplier to give outline dimensioning for hydraulic curve 

before headbox. 

Vacuum system: Flow measurement from wet 

suction box not required 

Vacuum system: Level control valve of 1st 

suction box filtrate in Supplier scope, to be indicated in flowsheet 

accordingly. 

Vacuum system: Bleed for high vacuum box 

will be taken from Nash channel and located physically close to vacuum 

pumps.

Shower water system: No potable water will be 

used, Supplier to correct flowsheet. Condensate for Duo Cleaners need to be 

cooled down to 55 C. The cooled condensate will be taken from trim squirt 

heat exchanger. 

Shower water system: Chemical/hot water 

showers to be located above the collector tray in press section to avoid water 

drops on paper. 

Shower water system: Tray water from couch to 

be led into white water tank (ww2) with individual line. Water from wire 

basin is led into press water tank. 

Shower water 

system: Supplier to confirm if 4 bar water is enough for size press showers. 

In flowsheet 5 bar is indicated. 

Steam and condensate system: Steam condersers 

for pre and after dryers will be located into operating floor. 

Steam and condensate system: Steam headers 

were rearranged to release more space for other piping. The main header 

remain in operating floor and additional consumer headers are located into 

mezzanine level. 

Steam and 

condensate system: Total steam flow to PM 2 will be measured. 

Steam and condensate system: Steam flow for 

drying will be measured, that means one orifice before predryer, one orifice 

before after dryer, one orifice before hood supply units (in mezzanine floor) 

and one orifice for steam flow box. 

Steam and condensate system: Secondary 

consumers to be measured are process water heating and white water 

heating. 

Dryer fabric is used for conveyor. 

Trim squirt nozzles will be rubin 

type. 

Next meeting to be agreed with 

Supplier and Customer representative 

 

 

LIITE 3. HAKUOHJELMAN KÄYTTÄMÄ XML-TIEDOSTO

PROJEKTIKOKOUKSISSA SYNTYVÄN TIEDON HALLINNAN ...

Create successful ePaper yourself

Delete template?

Save as template?