PROJEKTIKOKOUKSISSA SYNTYVÄN TIEDON HALLINNAN ...
PROJEKTIKOKOUKSISSA SYNTYVÄN TIEDON HALLINNAN ...
PROJEKTIKOKOUKSISSA SYNTYVÄN TIEDON HALLINNAN ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
TEKNILLINEN KORKEAKOULU<br />
Automaatio- ja systeemitekniikan osasto<br />
Heidi Pehu-Lehtonen<br />
ÄLYKKÄÄT PÖYTÄKIRJAT -<br />
<strong>PROJEKTIKOKOUKSISSA</strong> <strong>SYNTYVÄN</strong> <strong>TIEDON</strong><br />
<strong>HALLINNAN</strong> TEHOSTAMINEN RAKENTEISEN<br />
DOKUMENTIN<strong>HALLINNAN</strong> AVULLA<br />
Diplomityö 31.1.2002<br />
Työn valvoja Professori Pirkko Oittinen<br />
Työn ohjaaja DI Erik Rosenlew, Inforbis Oy
Työn nimi:<br />
Älykkäät pöytäkirjat - projektikokouksissa syntyvän tiedon hallinnan<br />
tehostaminen rakenteisen dokumentinhallinnan avulla<br />
Päivämäärä: 31.1.2002<br />
Sivumäärä: 69<br />
Valvoja:<br />
Ohjaaja:<br />
Professori Pirkko Oittinen<br />
DI Erik Rosenlew, Inforbis Oy<br />
Osasto, professuuri: Automaatio- ja systeemitekniikan osasto, AS-75 Viestintätekniikka<br />
Pääaine:<br />
Sivuaineet:<br />
Viestintä yritystoiminnassa<br />
Teollisuustalous, Vuorovaikutteinen digitaalinen media<br />
Tiivistelmä:<br />
Tässä työssä käsiteltiin viestintää projekteissa ja yhtä sen erikoistapausta eli<br />
projektikokouksia. Projektikokoukset ovat suurissa projekteissa projektin osapuolten<br />
pääasiallinen virallinen viestintäkanava. Lähes kaikki projektiin liittyvät päätökset tehdään<br />
kokouksissa ja siksi kokouksissa syntyvä tieto on erittäin tärkeää ja sen tulisi olla helposti<br />
saatavilla.<br />
Projektikokouksista laaditaan pöytäkirjoja, joihin kirjatut päätökset ovat osapuolten välisten<br />
sopimusten mukaan sitovia. Pöytäkirja nykyisessä muodossaan on tavallinen<br />
paperidokumentti, jonka muoto on melko vapaa ja sisältö täysin järjestämätön. Tässä työssä<br />
tutkittiin projektipöytäkirjan muuttamista älykkääseen muotoon, jotta sen sisältö olisi<br />
helpommin ja monipuolisemmin käytettävissä. Älykäs dokumentti on sellainen, johon on<br />
lisätty tietoa sen sisällöstä ja ympäristöstä.<br />
Työn tärkeimmät tavoitteet olivat<br />
• projektissa tapahtuvan viestinnän kartoittaminen,<br />
• projektikokousprosessin kartoittaminen ja ymmärtäminen,<br />
• projektikokouksissa syntyvän tiedon luokittelu ja<br />
• projektipöytäkirjojen käyttömahdollisuuksien selvittäminen esimerkkisovelluksen avulla.<br />
Työssä analysoitiin joukko vanhoja pöytäkirjoja ja tämän dokumenttianalyysin pohjalta<br />
laadittiin rakennemalli älykkäälle pöytäkirjalle. Mallia testattiin käyttäjillä, jotka ovat<br />
projektinhallintaa työnään tekeviä henkilöitä. Tutkimusta varten tehtiin esimerkkitoteutus,<br />
johon kuului joukko rakenteiseen muotoon syötettyjä pöytäkirjoja sekä hakuohjelma.<br />
Tulosten perusteella pohdittiin älykkään pöytäkirjan hyödyllisyyttä projektin hallinnan<br />
apuvälineenä ja esitettiin jatkokehitysajatuksia älykkäälle pöytäkirjajärjestelmälle.<br />
Avainsanat:<br />
projektinhallinta, informaation hallinta, rakenteiset dokumentit,<br />
projektikokoukset, älykäs pöytäkirja, dokumenttianalyysi, tietämyksen hallinta
1<br />
1 JOHDANTO<br />
1.1 Taustaa<br />
Projektinhallinta on alue, jolla tapahtuu jatkuvasti muutoksia. Projekteille asetetut vaatimukset<br />
kasvavat, aikataulut kiristyvät ja projektiorganisaatioiden koko kasvaa. Lisäksi<br />
kannattavuusvaatimukset asettavat projekteille suuria haasteita sekä investointi- että<br />
käyttökustannusten vähentämiseksi. Uudet tekniset informaation hallintamahdollisuudet<br />
eivät välttämättä ole pelkästään hyödyllisiä projektinhallinnan apuvälineitä. Ne aiheuttavat<br />
osittain myös sen, että projektien oletetaan sujuvan entistä nopeammin ja sujuvammin.<br />
Lisäksi viestintäkanavavaihtoehdot, posti, sähköposti, puhelin, kokoukset, Internet<br />
jne., aiheuttavat sen, että informaatiota on tarjolla huomattavan paljon, mutta toisaalta sen<br />
hallinta ja löytäminen on vaikeaa.<br />
Teknisen kehityksen mukanaan tuomat vaatimukset ihmisten työskentelytapojen uudistamiseksi<br />
kuitenkin synnyttävät muutosvastarintaa. Vanhoista työskentelytavoista ei<br />
haluta luopua ja siksi hyväkin informaation hallintajärjestelmä saattaa jäädä käyttämättä<br />
tai sitä käytetään niin, ettei siitä saada mahdollisimman suurta hyötyä. Projektinhallinnan<br />
vaatimusten kasvaessa informaation hallintajärjestelmien kehittäminen ja käyttö on<br />
kuitenkin välttämätöntä. Informaation hallinta onkin asia, jonka ottaminen osaksi kaikkiin<br />
työvaiheisiin tulisi olla jokaisen projektiorganisaation tavoitteena. Ei voida olettaa, että<br />
kun informaatio tuodaan tietokoneella kaikkien saataville, sitä automaattisesti hyödynnettäisiin.<br />
Kaikkia käytäntöjä, johtamista ja muita työskentelytapoja tulisi kehittää informaatiolähtöisemmiksi.<br />
Tietämyksenhallinta on lähtökohta paremmalle viestinnälle ja sitä kautta tehokkaammin<br />
läpiviedyille projekteille. Ihmisten osaamisen ja tietämyksen kartoittaminen sekä<br />
kehittäminen ovat välttämättömiä osa-alueita tietämyksenhallinnassa. Vielä tärkeämpää<br />
on kuitenkin tarpeiden kartoitus: mitä tehdään ja voitaisiinko se tehdä tehokkaammin<br />
paremmilla välineillä. Tarpeiden perusteella voidaan rakentaa järjestelmiä, jotka ovat<br />
oikeasti hyödyllisiä. Tarpeiden kartoitus on tärkeää, sillä jos tehtyjen järjestelmien koetaan<br />
olevan hyviä ja riittävän helppokäyttöisiä apuvälineitä, niitä myös käytetään.<br />
Kaikessa projektinhallinnassa, erityisesti kuitenkin sellaisissa projekteissa, joissa on<br />
paljon osapuolia, erittäin tärkeä viestintäkanava ovat projektikokoukset. Yritysten<br />
asiakasprojekteissa, kuten esimerkiksi rakennus- tai tuotekehitysprojekteissa, projektikokoukset<br />
ja niistä tehtävät pöytäkirjadokumentit ovat projektin osapuolten pääasiallinen<br />
virallinen viestintäkanava. Projektikokouksissa myös syntyy hyvin paljon informaatiota ja<br />
tietämystä, joiden jakelu kuitenkin on monella tapaa ongelmallista. Ensinnäkin<br />
projektikokouksissa käsitellään hyvin suurta asiamäärää, jolloin oleellisen informaation<br />
löytäminen on vaikeaa. Toiseksi projektikokouksia pidetään pitkän projektin aikana jopa<br />
useita satoja ja useiden eri osapuolten kanssa. Näin suuressa määrässä kokouksia syntyy<br />
paljon informaatiota. Samaa asiaa saatetaan käsitellä useissa kokouksissa ja siitä saatetaan
2<br />
jopa päättää usealla eri tavalla, mikä on projektin läpiviennin kannalta ongelmallinen<br />
tilanne. Projekteissa pidetään myös paljon pieniä neuvotteluja, joista ei välttämättä tehdä<br />
virallisia pöytäkirjoja, mutta joiden päätöksiä osapuolten kuitenkin odotetaan<br />
noudattavan.<br />
Älykkääksi dokumentiksi kutsutaan dokumenttia, johon on lisätty tietämystä sen omasta<br />
sisällöstä ja ympäristöstä. Älykkään dokumentin määritelmään kuuluu myös, että se<br />
voidaan käyttäjän antamien käskyjen perusteella muuntaa moniin eri muotoihin.<br />
Älykkäitä dokumentteja voidaan tehdä järjestämällä dokumentin sisältö rakenteiseen<br />
muotoon jollain siihen soveltuvalla kielellä.<br />
Älykkäät projektipöytäkirjat ovat siis rakenteiseen muotoon luokiteltuja projektikokousten<br />
pöytäkirjadokumentteja. Pöytäkirjojen rakenteinen ja älykäs hallinta ei ole<br />
projektinhallinnassa uusi ajatus. Käytännössä sen toteuttaminen aikaisemmin on<br />
kuitenkin ollut vaikeaa, koska siihen soveltuvia käytännönläheisiä teknisiä apuvälineitä ei<br />
ole ollut olemassa. Projektikokousten pöytäkirjoja laativat henkilöt ovat tekniseltä<br />
osaamiseltaan hyvin vaihtelevan tasoisia, eikä näiden henkilöiden voida olettaa käyttävän<br />
vaikeita järjestelmiä jokapäiväisessä työssään, kuten pöytäkirjojen laatimisessa.<br />
Projektipöytäkirjojen ollessa rakenteisessa muodossa, projektikokouksissa syntyvää tietoa<br />
voidaan helpommin hakea. Sitä voidaan myös kohdistaa tietyille projektin kapeille osaalueille<br />
ja siten projektipöytäkirjoja voitaisiin tehokkaammin käyttää projektinhallinnan<br />
välineinä. Tämän työn aiheena on selvittää rakenteisen projektipöytäkirjan soveltuvuutta<br />
ratkaisuna aikaisemmin esitettyihin ongelmakohtiin.<br />
Tässä työssä tutkitaan projekteissa tapahtuvaa viestintää ja projektikokouksia yhtenä<br />
viestinnän erikoistapauksena. Materiaalia aikaisemmista projektikokouksiin liittyvistä<br />
tutkimusta ei tämän tutkimuksen aikana ole ollut saatavilla, joten tutkimus pohjautuu<br />
materiaaliin, joka liittyy projekteissa tapahtuvaan viestintään, tietämyksenhallintaan sekä<br />
projekteissa kulkevaan informaatioon.<br />
1.2 Työn tavoitteet<br />
Työssä tutustutaan projekteissa tapahtuvaan viestintään ja tiedon syntymiseen. Sitä kautta<br />
tutkitaan projektikokouksissa syntyvää tietoa ja sen hallinnan mahdollisuuksia ja<br />
ongelmia. Työn pääasialliset tavoitteet ovat<br />
• projektissa tapahtuvan viestinnän kartoittaminen,<br />
• projektikokousprosessin kartoittaminen ja ymmärtäminen,<br />
• projektikokouksissa syntyvän tiedon luokittelu ja<br />
• projektipöytäkirjojen käyttömahdollisuuksien selvittäminen esimerkkisovelluksen<br />
avulla.
3<br />
Edellä mainittuihin kohtiin liittyen työn tavoitteena on kehittää rakenteinen projektipöytäkirjamalli,<br />
jonka avulla projektipöytäkirjat voidaan kirjoittaa älykkääseen muotoon.<br />
Mallin vaatimuksena on toisaalta riittävä yksinkertaisuus, jotta se säilyisi helppokäyttöisenä,<br />
toisaalta taas kattavuus, jotta siitä saataisiin riittävää hyötyä. Malli rakennetaan<br />
luokitellun tiedon avulla. Työn tavoitteena on myös tehdä Jaakko Pöyry Oy:n käyttöön<br />
soveltuva dokumentin rakennekuvaus (Document Type Definition, DTD).<br />
Malliin perustuen tehdään esimerkkisovellus, jolla mallin hyödyllisyyttä projektinhallinnan<br />
apuvälineenä voidaan analysoida. Tavoitteena on selvittää rakenteisen projektipöytäkirjasovelluksen<br />
jatkokehitystä varten ehdotetun mallin toimivuutta sekä mahdollisia<br />
parannusideoita. Tämän työn tavoitteena ei ole kehittää lopullista toimivaa ratkaisua<br />
vaan ainoastaan esimerkkisovellus, jonka avulla voidaan testata ajatusta projektipöytäkirjojen<br />
rakenteisesta toteutuksesta.<br />
1.3 Työn rajaukset<br />
Projektikokouksiin ja niiden pöytäkirjoihin tutustutaan Jaakko Pöyry Oy:n asiakasprojektien<br />
avulla. Tutkittavaa materiaalia on paljon ja se on sisällöltään monipuolista. Ei<br />
voida kuitenkaan olettaa, että tässä työssä tehdyt ratkaisut olisivat yleispäteviä kaikkia<br />
mahdollisia projekteja ajatellen. Rakenteinen pöytäkirjamalli suunnitellaan Inforbis Oy:n<br />
ja Jaakko Pöyry Oy:n tarpeita ajatellen. Siitä pyritään tekemään mahdollisimman<br />
joustava, mutta se ei välttämättä ole sellainen, että se soveltuisi käyttöön, jossa kokoustai<br />
dokumentinhallintakäytännöt ovat hyvin erilaisia kuin Inforbis Oy:ssä tai Jaakko<br />
Pöyry Oy:ssä.<br />
Tarkastelun ulkopuolelle jäävät myös muut kuin tavalliset tekstimuotoiset pöytäkirjat.<br />
Esimerkiksi videoneuvotteluista tehdyt videopöytäkirjat tai nauhoitettujen kokousten<br />
äänimuotoiset pöytäkirjat eivät kuulu tämän työn piiriin.<br />
Tehtävän rakenteisen pöytäkirjamallin teknisten ratkaisujen teoriaa ei käsitellä yksityiskohtaisesti.<br />
Toteutuksessa käytetyistä teknisistä ratkaisuista käsitellään lyhyesti niitä,<br />
jotka oleellisesti vaikuttavat toteutukseen. Tämän työn ymmärtäminen vaatii jonkinverran<br />
tietämystä rakenteisen dokumentinhallinnan perusteista. Esimerkkisovelluksen<br />
ymmärtäminen taas vaatii lisäksi perustietämystä ohjelmoinnin peruskäsitteistä sekä olioohjelmoinnista.<br />
1.4 Työn rakenne<br />
Työ jakautuu neljään osaan. Ensimmäisessä osassa (luku 3) määritellään työssä käytettävä<br />
projektinhallinnan peruskäsitteistö kirjallisuuden perusteella. Ensimmäisen osan<br />
tarkoitus on selvittää lukijalle ympäristö ja tarpeet, joihin tämä työ liittyy. Toisessa osassa<br />
(luku 4) käsitellään viestintää projekteissa kirjallisuuden avulla. Tarkoituksena on luoda<br />
riittävä ymmärrys viestinnästä projekteissa, jotta voidaan tarkastella projektikokouksia<br />
yhtenä projektin viestintäkanavana. Kolmannessa osassa (luku 5) tarkastellaan<br />
projektikokouksia ja niissä syntyvää tietoa sekä projektipöytäkirjoja. Neljännessä osassa
(luvut 6, 7 ja 8) esitellään edellisissä luvuissa tapahtuneen tarkastelun perusteella<br />
rakennettu esimerkkisovellus, jolla voidaan hallita älykkäitä projektipöytäkirjoja. Lisäksi<br />
tutkitaan sen käytön mahdollisuuksia projektinhallinnassa käyttäjätestien avulla,<br />
tarkastellaan testeistä saatuja tuloksia ja tulosten pohjalta pohditaan sen jatkokehitystä<br />
projektikokouksissa syntyvän informaation hallintajärjestelmäksi. Työssä käytetyt<br />
tutkimusmenetelmät määritellään erikseen luvussa 2.<br />
4
5<br />
2 TUTKIMUKSESSA KÄYTETYT MENETELMÄT<br />
2.1 Kirjallisuuskatsaus<br />
Työn kirjallisuuskatsauksessa tarkastellaan kahta muun työn kannalta tärkeää osa-aluetta:<br />
projektinhallinnan peruskäsitteitä sekä viestintäprosessia ja tiedon syntymistä projektissa.<br />
Projektinhallinnan peruskäsitteiden tunteminen on välttämätöntä, jotta projektipöytäkirjojen<br />
käyttömahdollisuuksia voitaisiin ymmärtää. Viestintäprosessia ja tiedon syntymistä<br />
projekteissa taas tarkastellaan, koska projektikokousprosessi on yksi viestintäprosessin<br />
erikoistapaus.<br />
Viestintäprosessin ja projekteissa syntyvän tiedon luokitteluun ja mallinnukseen käytetään<br />
lähteessä /12/ esiteltyä tehdasprosessin ja tehtaassa syntyvän tiedon matriisimuotoista<br />
luokittelumallia. Mallin viitekehys ja muutamia esimerkkikysymyksiä jokaiseen<br />
lokeroon on esitetty taulukossa 1.<br />
Taulukko 1. Projektin viestintäprosessin luokitteluun käytetty malli /12/<br />
Prosessitaso Informaatiotaso Tietämystaso<br />
Asiatieto<br />
• Keitä prosessiin<br />
osallistuu<br />
• Mitä välineitä<br />
prosessissa<br />
käytetään<br />
• Mitä<br />
informaatiota<br />
prosessissa<br />
syntyy<br />
• Mitä tietoa<br />
prosessissa<br />
syntyy<br />
• Kuka tarvitsee<br />
tietoa<br />
Toiminnallinen tieto<br />
Strateginen tieto<br />
• Mitä prosessissa<br />
tapahtuu<br />
• Mitkä ovat<br />
prosessin vaiheet<br />
• Miksi prosessia<br />
tarvitaan<br />
• Miten prosessin<br />
tavoitteet aiotaan<br />
saavuttaa<br />
• Miten<br />
informaatio<br />
syntyy<br />
• Mikä on<br />
informaation<br />
tarkoitus<br />
• Miten tarkoitus<br />
saavutetaan<br />
• Miten tietämys<br />
syntyy<br />
• Miksi<br />
tietämystä<br />
tarvitaan<br />
• Miten tieto<br />
pitäisi esittää<br />
Matriisin vaakariveillä tieto luokitellaan kolmeen osa-alueeseen: asiatietoon, toiminnalliseen<br />
tietoon ja strategiseen tietoon. Asiatiedolla tarkoitetaan sitä, mitä asioista tiedetään,<br />
toiminnallisella tiedolla sitä, miten asiat toimivat ja strategisella tiedolla sitä, miksi asiat<br />
toimivat tietyllä tavalla /12/. Pystyriveillä taas kuvataan projektissa tapahtuvan viestinnän<br />
ja siinä syntyvän tiedon kolme ulottuvuutta: itse viestintäprosessi, prosessissa kulkeva<br />
informaatio sekä siitä syntyvä tietämys. Informaation ja tietämyksen käsitteitä käsitellään<br />
erikseen luvussa 4.2.
6<br />
Viestintäprosessista luodun matriisimallin perusteella valitaan ne projekteissa tapahtuvan<br />
viestinnän osa-alueet, jotka ovat tärkeitä projektikokousprosessin kannalta. Näitä tarkastellaan<br />
erikseen luvuissa 4.3-4.5.<br />
2.2 Tiedon kartoitus<br />
Tiedon kartoitus tässä työssä tehdään käyttötapaus (use case) tutkimuksena analysoimalla<br />
vanhoja projektipöytäkirjoja. Tällainen dokumenttianalyysi on eräs yleisimmistä tavoista<br />
selvittää ja mallintaa dokumentin rakennetta /19/.<br />
Analysoitavia pöytäkirjoja on 300 kappaletta. Kaikki pöytäkirjat ovat yhdestä suuresta<br />
Jaakko Pöyry Oy:n vuosina 1999 ja 2000 tekemästä asiakasprojektista, jossa rakennettiin<br />
paperitehdas Portugaliin. Pöytäkirjamateriaali kattaa kaikki kyseisen projektin arkistoidut<br />
pöytäkirjat. Yhden projektin kaikkien pöytäkirjojen valitsemiseen dokumenttianalyysin<br />
materiaaliksi on päädytty, jotta saataisiin mahdollisimman kattava kuva tyypillisen<br />
asiakasprojektin kulusta. Toisaalta useamman kuin yhden projektin kaikkien pöytäkirjojen<br />
analysointi tämän työn puitteissa ei ole mahdollista.<br />
Tutkitusta pöytäkirjamateriaalista selvitetään asiakasprojekteissa esiintyvät erilaiset<br />
kokoustyypit, niiden tyypilliset asialistat sekä kokouksissa esiintyvät tietotyypit. Tieto<br />
kartoitetaan sekä jaetaan luokkiin ja näiden perusteella luodaan yleinen rakenteinen malli,<br />
jota voidaan käyttää kaikille pöytäkirjatyypeille.<br />
Tutkimuksessa apuna käytetään lähteessä /24/ olevaa kysymyslistaa, jonka tarkoituksena<br />
on minkä tahansa prosessin ymmärtäminen ja parantaminen. Tässä prosessina on projektikokousprosessi<br />
sekä erityisesti projektikokouksissa oleva tiedon syntymis- ja hallintaprosessi.<br />
Kysymykset voidaan jakaa viiteen pääluokkaan, jotka kysymyksineen sovellettuna<br />
projektikokousprosessiin ovat:<br />
Tarkoitus:<br />
Paikka/Tilaisuus:<br />
Yhteys/Tilanne:<br />
Ihmiset:<br />
Minkälaista tietoa projektikokouksissa syntyy<br />
Miksi kokouksissa syntyvää tai käsiteltävää tietoa tarvitaan<br />
Millaista muuta tietoa voisi tai pitäisi käsitellä<br />
Minkälaisia projektikokouksia pidetään<br />
Miksi tietynlaisia kokouksia pidetään<br />
Tarvitaanko muunlaisia kokouksia<br />
Minkälaisessa yhteydessä/tilanteessa projektikokouksissa syntyvää<br />
tietoa käytetään<br />
Miksi juuri silloin<br />
Onko muita yhteyksiä, joissa tietoa voisi tarvita<br />
Ketkä käyttävät projektikokouksissa syntynyttä tietoa<br />
Miksi juuri nämä henkilöt käyttävät tietoa
7<br />
Kuka muu voisi tarvita tietoa<br />
Menetelmä:<br />
Miten projektikokouksissa syntynyt tieto on saatavilla<br />
Miksi juuri tällä tavalla<br />
Voisiko tiedon esittää jollain vaihtoehtoisella tavalla<br />
Tulokset tiedon kartoittamisesta esitetään luvuissa 5.2 - 5.4 ja rakenteisen projektipöytäkirjan<br />
malli luvussa 6.2.<br />
2.3 Tiedon käyttötarpeet<br />
Projekteissa työskentelevien henkilöiden tiedonkäyttötarpeiden kartoittamiseen käytetään<br />
kahta menetelmää: haastattelut sekä työhön tutustuminen. Haastatteluissa kysytään sekä<br />
Jaakko Pöyry Oy:n edustajien että asiakkaiden näkemyksiä projektipöytäkirjojen<br />
nykyisestä käytöstä, käytön ongelmista ja tarpeista, joita projektipöytäkirjojen käytölle<br />
projektinhallinnassa olisi. Haastateltavia henkilöitä on yhteensä kymmenen.<br />
Haastattelujen ongelmaksi saattaa kuitenkin muodostua se, etteivät kaikki haastateltavat<br />
osaa kertoa todellisista tarpeistaan. Tämän takia haastattelujen lisäksi käytetään lähteissä<br />
/3, 29/ esiteltyä työhön tutustumis- menetelmää. Menetelmän ajatuksena on työn seuraaminen<br />
sekä kysymyksien esittäminen sen tekijöille ja sitä kautta varsinaisten tarpeiden<br />
kartoittaminen. Menetelmässä työtä opetellaan sen verran, että selviää, mitä voi tehdä<br />
paremmin. Haastattelujen ja tutustumismenetelmän perusteella valitaan tärkeimmät<br />
tarpeet, joiden perusteella selvitetään luvussa 6.2 esitellyn rakenteisen pöytäkirjamallin<br />
mahdollisuuksia sekä hyödyllisyyttä. Tarpeet ja niihin liittyvät ongelmat on esitellään<br />
luvuissa 7.2-7.6.<br />
2.4 Tiedon käyttömahdollisuudet<br />
Tiedon käyttömahdollisuuksia tässä työssä tutkitaan aiemmin esiintulleiden tarpeiden<br />
perusteella. Koska kyseessä on täysin uuden käyttömahdollisuuden tutkiminen, käytetään<br />
lähteessä /10/ esiteltyä skenaariomenetelmää. Skenaariomenetelmässä testikäyttäjille<br />
esitellään erilaisia käyttömahdollisuuksia ja käyttäjät saavat sanoa mielipiteensä<br />
tutkittavan ohjelman, systeemin tai rakenteen soveltuvuudesta kyseiseen skenaarioon.<br />
Menetelmä soveltuu etenkin tapauksiin, joissa halutaan tutkia uuden informaatiosysteemin<br />
vaikutusta joko organisaatioon, yksilöön tai yhteiskuntaan.<br />
Tutkimusta varten syötetään 30 vanhaa projektipöytäkirjaa rakenteiseen muotoon XML<br />
(eXtensible Markup Language) - kielellä. Pöytäkirjat valitaan siten, että niissä esiintyy<br />
kaikkia dokumenttianalyysin tuloksena saatuja tietotyyppejä mahdollisimman kattavasti.<br />
Myös kaikki kokoustyypit ovat edustettuina. Syöttämiseen käytetään XML Spy 4.0.1<br />
ohjelmaa. Pöytäkirjojen käsittelyä varten luodaan Jaakko Pöyry Oy:n tarkoituksiin<br />
soveltuva dokumentin rakennekuvaus (Document Type Definition, DTD). DTD tehdään<br />
siten, että se noudattaa työssä tehtyä rakenteista pöytäkirjamallia.
8<br />
Käyttömahdollisuuksien tutkimista varten tehdään ohjelma, jolla voidaan tehdä hakuja<br />
XML-muotoisista pöytäkirjoista. Ohjelman toteutus- ja käyttöperiaatteet esitellään<br />
luvussa 6.4.<br />
Skenaariotutkimus tehdään käyttäjätutkimuksena kuudelle henkilölle. Testikäyttäjät ovat<br />
sekä projektinhallinnan että tuotekehityksen parissa työskenteleviä henkilöitä.<br />
Testikäyttäjien määräksi on valittu kuusi, koska siten testeihin saadaan edustaja kaikista<br />
Jaakko Pöyry Oy:n erityyppisistä projekteista. Toisaalta, koska tutkitaan vasta mahdollisuuksia<br />
ja testihenkilöiltä vaaditaan osaamista projektinhallinnan alalta, ei ole<br />
perusteltua tehdä testejä useampien henkilöiden kanssa. Skenaarioina käytetään<br />
aikaisemmin kartoitettuja tarpeita ja niihin liittyviä esimerkkitilanteita. Rakenteiseen<br />
muotoon syötetyistä pöytäkirjoista tehdään ohjatussa tilaisuudessa hakuja ja testihenkilöt<br />
kertovat samalla, miten tehtyjen hakujen tuloksia voitaisiin projektinhallinnassa<br />
hyödyntää ja miten hyödyllisiksi he saadut tulokset kokevat kartoitettuja tarpeita<br />
ajatellen. Hyödyllisyyttä arvioidaan asteikolla:<br />
• erittäin hyödyllinen<br />
• melko hyödyllinen<br />
• jonkin verran hyödyllinen<br />
• ei lainkaan hyödyllinen.<br />
Skenaariotutkimuksen lisäksi käyttäjät saavat tehdä vapaita hakuja ja esittää<br />
parannusehdotuksia. Tulokset esitellään luvuissa 7.2-7.6.
9<br />
3 PROJEKTIN<strong>HALLINNAN</strong> PERUSKÄSITTEITÄ<br />
3.1 Projekti<br />
Sanalle projekti löytyy kirjallisuudesta useita määritelmiä. Tässä työssä käytetään ISO<br />
10006 standardissa /13/ olevaa määritelmää, jonka mukaan<br />
Projekti on ainutkertainen prosessi, joka käsittää joukon koordinoituja, ohjattuja ja<br />
valvottuja tehtäviä, joilla on alku- ja loppupäivämäärät ja jonka tuloksena syntyy<br />
ainutlaatuinen tuote tai palvelu.<br />
Projekti ei siis määritelmänsä mukaisesti voi toistua samanlaisena. Projekteista saatua<br />
oppia voidaan kuitenkin hyödyntää tulevissa projekteissa tehokkaan tiedonhallinnan<br />
avulla.<br />
Projektin määritelmää voidaan vielä täsmentää seuraavien, Project Management Body of<br />
Knowledge 2000:ssa /28/ mainittujen, kohtien avulla:<br />
• projektin suorittavat aina ihmiset,<br />
• projektin resurssit ovat rajatut ja<br />
• projektiin kuuluu selkeä jako: suunnittelu-toteutus-valvonta.<br />
3.2 Projektin elinkaari<br />
Kuten projekti, myös sen elinkaari voidaan määritellä monella eri tavalla. Tässä työssä<br />
käytetään Jaakko Pöyry Oy:n ohjeistuksen /14/ mukaista määritelmää, jossa projektin<br />
voidaan ajatella jakautuvan seuraavaan neljään vaiheeseen:<br />
• kehitys,<br />
• toteutus,<br />
• tuotanto ja<br />
• rationalisointi eli uusinta.<br />
Työssä käytetty projektin elinkaarimalli on esitetty kuvassa 1. Projektin elinkaari alkaa<br />
liikeideasta. Kehitysvaiheessa liikeidean soveltuvuutta toteutettavaksi tutkitaan esimerkiksi<br />
kannattavuusselvitysten avulla. Kehitysvaihe voidaan edelleen jakaa kolmeen vaiheeseen:<br />
ideointi, esiselvitys ja esisuunnittelu. Jokaisessa vaiheessa tehdään kannattavuusselvitys<br />
ja idea etenee seuraavaan vaiheeseen vain, jos se todetaan kannattavaksi<br />
jollain määritellyllä kriteerillä. Tyypillistä kullekin vaiheelle on, että sen lopussa on useita<br />
ideoita tai suunnitelmia, joista vain parhaat etenevät seuraavaan vaiheeseen. Kehitysvaiheen<br />
tavoitteena on siis tehdä kattava selvitys siitä, kannattaako tiettyä liikeideaa<br />
lähteä toteuttamaan. Esisuunnitteluvaiheessa käynnistetään jo varsinaisen toteutuksen<br />
valmistelu, esimerkiksi laatimalla alustava ehdotus projektin pääaikatauluksi sekä<br />
alustava projektisuunnitelma. Ajatuksena tässä on edelleen selvittää projektin kannat-
10<br />
tavuutta, mutta myös nopeuttaa toteutusvaiheen käynnistymistä. Mikäli liikeidea on<br />
tarpeeksi hyvä, kehitysvaiheen lopuksi tehdään investointipäätös ja varsinainen projekti<br />
alkaa. /14, 30/<br />
Kuva 1. Projektin elinkaari /14/<br />
Toteutusvaiheessa projektin aikataulun mukaiset vaiheet toteutetaan. Toteutusvaiheeseen<br />
kuuluvat esimerkiksi varsinaisen projektisuunnitelman yksityiskohtainen laatiminen,<br />
tarvittavat hankinnat, tekninen tai muu tuotteeseen liittyvä toteutus ja testaus. Lisäksi<br />
toteutusvaiheeseen kuuluvat projektin hallintaprosessit kuten muutosten ja riskien<br />
hallinta, kommunikaation hallinta, kustannusvalvonta ja henkilöstön hallinta. Projektin<br />
hallintaprosessit esitellään tarkemmin luvussa 3.5. Toteutusvaiheen päätteeksi projektin<br />
tuote luovutetaan asiakkaalle. /2, 13, 14/<br />
Tuotantovaiheessa projektin tuotetta kehitetään edelleen. Tuote on siis käytössä, mutta<br />
jos tarvetta ilmenee, tuotteeseen voidaan vielä tehdä muutoksia ja sen toimintaa voidaan<br />
parantaa. Tuotantovaiheen alkuun kuuluu myös tuotteen käyttöönotto ja siihen liittyvät<br />
prosessit. Käyttöönoton jälkeen varsinainen projekti päättyy. Projektin elinkaaren<br />
voidaan kuitenkin ajatella jatkuvan, sillä esimerkiksi kokonaiskannattavuuteen ja<br />
kunnossapitoon liittyvät tukitoiminnot ja jatkokehitys usein jatkuvat myös tästä<br />
eteenpäin. /13, 14/<br />
Rationalisointi- eli uusintavaiheen aikana projektin tuote on edelleen tuotannossa.<br />
Kysynnän ja tarjonnan tuleva kehitys markkina-alueittain ja tuotteittain sekä tuotteen<br />
hintataso vaikuttavat siihen, milloin sen tuotanto kuitenkin lakkautetaan ja projektin<br />
elinkaari saadaan päätökseen. /14/
11<br />
3.3 Projektityypit<br />
Vaikka tässä työssä pyritään saamaan aikaan sellaisia ratkaisuja, jotka soveltuvat kaikentyyppisille<br />
projekteille, on kuitenkin syytä jakaa projektit luokkiin, koska tiedontarve<br />
erilaisissa projekteissa saattaa olla varsin erilainen. Tätä tarkoitusta varten on lähteessä<br />
/30/ esitelty malli, jossa projektit jaetaan neljään ryhmään niiden tavoitteiden ja<br />
toimintatapojen mukaisesti. Malli soveltuu hyvin tähän työhön, sillä pääasialliset<br />
tiedontarpeet projektin aikana liittyvät juuri projektin tavoitteisiin ja projektin<br />
toimintatapoihin. Tämä tavoite-toiminta matriisi on esitetty kuvassa 2.<br />
Kuva 2. Tavoite-toiminta matriisi /30/<br />
Tavoite-toiminta matriisin avulla projektit voidaan jakaa neljään ryhmään /26, 30/:<br />
• Ryhmä 1: Ryhmän projekteissa sekä tavoite että toimintatavat ovat hyvin määriteltyjä.<br />
Esimerkiksi monet rakennusprojektit kuuluvat tähän ryhmään. Ryhmän<br />
projekteille tyypillistä on, että vastaavanlaisia projekteja on tehty aikaisemminkin ja<br />
vanhoista projekteista saatu tieto on hyödynnettävissä. Koska toiminta on selkeää ja<br />
hyvin suunniteltua, tärkeintä tietoa projektin etenemisen kannalta ovat aikataulut ja<br />
edistymisraportit.<br />
• Ryhmä 2: Tämän ryhmän projekteissa tavoitteet ovat selkeät, mutta toimintatavat<br />
eivät ole. Tyypillinen esimerkki ryhmän projektista on tuotekehitysprojekti. Tärkeää<br />
tietoa ovat erityisesti tehdyt toimenpiteitä koskevat päätökset sekä oppimisen kannalta<br />
toimenpiteiden seuraukset.
12<br />
• Ryhmä 3: Toimenpiteet on hyvin määritelty mutta tavoite ei ole. Esimerkiksi useat<br />
konsultointiprojektit kuuluvat tähän ryhmään. Tärkeää on pyrkiä selvittämään<br />
projektin todellinen tavoite. Tärkeää tietoa ovat mahdolliset muutokset tavoitteissa ja<br />
muutosten aiheuttamat uudet toimenpiteet.<br />
• Ryhmä 4: Ryhmän projekteissa sekä tavoitteet että toimintatavat on huonosti<br />
määritelty. Esimerkiksi tutkimusprojektit kuuluvat usein tähän ryhmään. Tässä<br />
ryhmässä on tärkeää tiedottaa, mitä on tehty, mitä siitä on seurannut ja mitä<br />
seuraavaksi pitää tehdä.<br />
Todellisuudessa suuret projektit ovat usean ylläesitellyn projektityypin kombinaatioita.<br />
Vastaavasti siis myös tiedon tarve voi olla yhdistelmä useamman projektityypin eri<br />
tarpeista. Tiedon tarpeen määrä ja kiireellisyys kasvavat mentäessä tavoite-toiminta<br />
matriisissa ylös ja oikealle. Vastaavasti kasvavat myös riskien määrä ja projektin<br />
epäonnistumisen todennäköisyys. /2, 26, 30/<br />
3.4 Projektin osapuolet<br />
Luvussa 4 tarkastellaan viestintää ja tiedontarvetta projekteissa. Tarkastelun pohjana on<br />
ISO 10006- standardin /13/ mukainen jaottelu tyypillisen projektin osapuolista. Tämä on<br />
esitetty kuvassa 3.<br />
Kuva 3. Projektin osapuolet /13/<br />
Projektin asiakkaaksi tai omistajaksi kutsutaan osapuolta, joka ostaa tai rahoittaa projektin.<br />
Projektilla on aina asiakas, joko yrityksen sisäinen henkilö tai osasto tai ulkoinen<br />
yritys. Asiakkuuden voidaan myös ajatella jakautuvan usealle tasolle /2/. Tarkastellaan<br />
esimerkkiä, jossa asiakasyritys ostaa projektin tuotteena paperitehtaan. Tällöin asiakkaita<br />
voidaan ajatella olevan projektin rahoittaneen yrityksen lisäksi ainakin tulevan tehtaan
13<br />
työntekijät sekä tehtaan tuottaman paperin ostajat. Toisaalta näitä osapuolia voidaan myös<br />
ajatella erillisinä käyttäjinä, jotka eivät varsinaisesti ole projektin asiakkaita. Projektin<br />
suunnittelussa ja hallinnassa asiakkaan tarpeiden tulisi olla etusijalla ja siis myös<br />
projektin viestinnän suunnittelun on lähdettävä asiakkaan näkökulmasta.<br />
Pääkonsultti on osapuoli, joka hoitaa suurimman osan kommunikaatiosta projektin osapuolten<br />
välillä. Pääkonsultti siis tavallaan tarjoaa rajapinnan asiakkaan ja muiden osapuolten<br />
välille. Kaikissa projekteissa ei ole pääkonsulttia ja asiakkaasta riippuen pääkonsultin<br />
rooli vaihtelee projektin kaikkien asioiden hoitamisesta yksittäisten asioiden konsultointiin.<br />
Kirjallisuudessa pääkonsulttia kutsutaan myös usein suorittavaksi organisaatioksi,<br />
jolla tarkoitetaan sitä projektin osapuolta, joka tekee suurimman osan projektiin<br />
liittyvästä työstä ja koordinoinnista /2, 28/.<br />
Pääkonsultin lisäksi projektissa voi olla yksi tai useampi muu konsultti. Käytännössä<br />
jokainen näistä hoitaa tiettyä kapeaa erikoisalaa. Etenkin suurissa projekteissa voi olla<br />
useita konsultteja. /2, 13/<br />
Toimittaja ja urakoitsija voivat olla kaksi eri osapuolta tai yksi osapuoli voi edustaa näitä<br />
molempia. Toimittajan tehtävänä on toimittaa projektissa tarvittavia erillisiä osia, komponentteja,<br />
palveluita tai raaka-aineita. Projektin koosta riippuen ulkopuolisia toimittajia on<br />
useimmiten enemmän kuin yksi ja jokaisella on melko pieni oma erikoisalansa. Urakoitsijan<br />
tehtävä projektissa on hoitaa projektiin liittyvä rakennustyö tai osa siitä. /2, 13, 26/<br />
Viranomaisten tehtävänä projektissa on valvoa, että projektissa noudatetaan erilaisia<br />
lakeja ja määräyksiä, esimerkiksi ympäristö- ja työsuojeluvaatimuksia Viranomaiset<br />
myös myöntävät projektiin liittyvät luvat, esimerkiksi rakennus- ja poikkeusluvat. /13, 26/<br />
Projektin muita osapuolia voivat olla esimerkiksi rahoittajat, yliopistot, korkeakoulut,<br />
tutkimuslaitokset, yhteistyöyritykset tai tiedotusvälineet. Projektin koosta riippuen näiden<br />
määrä vaihtelee. /2, 13/<br />
3.5 Projektin hallintaprosessit<br />
Tässä työssä käytetään termistä projektinhallinta Project Management Body of Knowledge<br />
2000:n /28/ mukaista määritelmää, jonka mukaan<br />
Projektinhallinta on tietojen, taitojen, työkalujen sekä tekniikoiden käyttämistä<br />
projektin tehtäviin siten, että pyritään saavuttamaan projektin tavoitteet ja saavuttamaan<br />
tai ylittämään osapuolten tarpeet tai odotukset.<br />
Käytännössä projektin osapuolten kaikkien tarpeiden saavuttaminen tai ylittäminen vaatii<br />
tasapainottamista toisilleen ristiriitaisten tai kilpailevien vaatimusten välillä. Merkittävimmät<br />
projektiin kohdistuvat vaatimukset ovat seuraavat /2/:
14<br />
• projektin tavoitteet eli sen laajuus, aika ja kustannukset,<br />
• projektin osapuolten toisistaan eroavat edut sekä<br />
• asiakkaan tiedostetut vaatimukset ja tiedostamattomat vaatimukset projektin<br />
tuotteelle.<br />
Projektinhallinta voidaan edelleen lähteestä riippuen luokitella yhdeksään tai kymmeneen<br />
tietämysalueeseen tai hallintaprosessiin. Joissakin lähteissä laitteistoresurssien hallinta<br />
lasketaan erilliseksi hallintaprosessiksi kun taas toisissa se katsotaan osaksi hankintojen<br />
hallintaa. Pääpiirteissään kuitenkin käytetyissä lähteissä noudatettiin seuraavissa<br />
kappaleissa esiteltyä luokittelua. /2, 13, 26, 28, 30/<br />
Projektin eheyden hallintaan kuuluvat ne toimenpiteet, joilla varmistetaan projektin<br />
kunnollinen koordinointi. Esimerkiksi projektin organisointi ja avainhenkilöiden valinta,<br />
projektisuunnitelman laatiminen ja sen toteuttaminen, sekä näiden toimenpiteiden<br />
valvonta ja raportointi kuuluvat projektin eheyden hallintaan.<br />
Projektin laajuudella tarkoitetaan käytännössä projektin tuotetta, sen tarkoitusta ja siihen<br />
liittyviä toimenpiteitä. Projektin laajuuden hallintaan siis kuuluvat esimerkiksi laajuuden<br />
määrittely ja varmennus sekä mahdollisten laajuuteen liittyvien muutosten hallinta.<br />
Projektin aikataulujen hallintaan kuuluvat aikataulujen laatiminen, tehtävien järjestäminen<br />
siten, että ne voidaan aikatauluttaa sekä aikataulujen valvonnan kautta projektin<br />
edistymisestä raportoiminen. Aikataulujen hallintaa ovat myös mahdollisten aikataulumuutosten<br />
ennakoiminen sekä niiden aiheuttamien vaikutusten analysointi ja liityntöjen<br />
selvittäminen projektin muihin osapuoliin, aikatauluihin tai kustannuksiin.<br />
Kustannusten hallinta projektissa tarkoittaa kaikkia niitä toimenpiteitä, joita tarvitaan<br />
projektin suorittamiseen budjetin mukaisesti. Näitä toimenpiteitä ovat esimerkiksi<br />
kustannusarvioiden laatiminen, niiden valvominen ja niistä raportoiminen.<br />
Projektin laadunvalvonnan tehtävänä on varmistaa, että projekti täyttää ne tavoitteet tai<br />
vaatimukset, jotka sille on määritelty. Laadun hallintaan siis kuuluvat esimerkiksi<br />
laatusuunnittelu, laadun varmistaminen ja laadunvalvonta. Laadun hallinta ei kuitenkaan<br />
ole yksittäinen prosessi vaan osa kaikkia muita hallintaprosesseja.<br />
Henkilöstöresurssien hallinnalla tarkoitetaan projektissa työskentelevien henkilöiden<br />
tietojen ja taitojen hyödyntämistä mahdollisimman tehokkaasti. Laitteistoresurssien<br />
hallinta taas käsittää ne toimenpiteeet, joita tarvitaan riittävien työkalujen hankintaan ja<br />
ylläpitoon. Varsinainen laitteiden, ohjelmien ja muiden työkalujen hankinta voidaan<br />
katsoa kuuluvan hankintojen hallintaan, mutta niiden koordinointi ja ylläpito kuuluvat<br />
laitteistoresurssien hallintaan.
15<br />
Viestintä projekteissa on alue, johon vasta viime aikoina projektien laajuuksien kasvaessa<br />
on kiinnitetty enemmän huomiota. Projektin viestinnän hallinnalla tarkoitetaan viestinnän<br />
suunnittelua ja valvontaa, viestinnän koordinointia sekä projektin tiedonhallintaa.<br />
Viestinnästä projekteissa sekä sen hallinnasta kerrotaan enemmän luvussa 4.<br />
Projektin riskien hallinnalla tarkoitetaan niitä toimenpiteitä, joita tarvitaan projektin<br />
riskien tunnistamista ja analysointia varten sekä toimenpiteitä, joilla riskeiltä<br />
suojaudutaan tai joihin ryhdytään riskien toteutuessa. Koska muutokset useimmiten<br />
seuraavat riskien toteutumisesta, katsotaan myös muutosten hallinnan kuuluvan osaksi<br />
riskien hallintaa.<br />
Hankintojen hallinta käsittää ne toimenpiteet, joilla varmistetaan ulkopuolisilta toimittajilta<br />
tulevien raaka-aineiden, komponenttien ja palveluiden saanti. Näitä toimenpiteitä<br />
ovat esimerkiksi hankintojen suunnittelu, toimittajien kanssa neuvottelu, sopimusneuvotteluiden<br />
täytäntöönpanon valvonta ja raportointi sekä tilausmuutosten käsittely ja<br />
hallinta.
16<br />
4 VIESTINTÄ PROJEKTEISSA<br />
4.1 Viestintäprosessi<br />
Projekteissa tapahtuvaa viestintää ja tiedon syntymistä voidaan kuvata taulukossa 2 esitetyn<br />
matriisin avulla. Matriisin viitekehys on lähteestä /12/ ja se esiteltiin tarkemmin<br />
taulukossa 1.<br />
Taulukko 2. Projektissa syntyvän tiedon ulottuvuudet /7, 12, 25, 26, 31/<br />
Viestintäprosessi Informaatio Tietämys<br />
Asiatieto, faktat<br />
(mitä asioista<br />
tiedetään)<br />
• Projektin<br />
osapuolet<br />
• Peruskäsitteet<br />
• Osapuolten<br />
väliset yhteydet<br />
• Viestinnässä<br />
käytetyt välineet<br />
• Dokumentit<br />
• Keskustelut<br />
• Kokoukset<br />
• Informaatiojärjestelmät<br />
• Informaation<br />
määrä<br />
• Tiedon lähteet<br />
• Viestinnän<br />
sisältö<br />
• Tiedon<br />
kohderyhmät<br />
Toiminnallinen<br />
tieto<br />
(miten asiat<br />
toimivat)<br />
Strateginen tieto<br />
(miksi asiat<br />
toimivat näin)<br />
• Informaation<br />
hankinta<br />
• Esitettävän<br />
informaation<br />
valinta<br />
• Informaation<br />
muokkaus<br />
• Sopivien<br />
kokonaisuuksien<br />
koostaminen<br />
• Viestinnän<br />
tarkoitus<br />
• Viestinnän<br />
muoto ja<br />
välineet<br />
• Tulevaisuuden<br />
suunnitelmat,<br />
skenaariot<br />
• Viestinnän<br />
hallinta<br />
• Informaation<br />
kulku<br />
• Osapuolten<br />
vuorovaikutus<br />
• Aikaisempi<br />
viestintä<br />
• Informaation<br />
tarkoitus<br />
• Päätökset<br />
• Perustelut<br />
• Viestinnän<br />
kohdistaminen<br />
• Projektin<br />
tavoitteet<br />
Asiatiedolla tarkoitetaan perusasioita, jotka prosessista tiedetään. Asiatietoa projektin<br />
viestintäprosessista ovat esimerkiksi projektin osapuolet sekä yhteydet heidän välillään.<br />
Toiminnallista tietoa ovat viestintäprosessin vaiheet ja strategista tietoa viestinnän
17<br />
tarkoitus sekä tarkoitusta tukevat keinot, kuten viestinnän hallinta ja muoto sekä viestinnän<br />
hallinnassa käytetyt menetelmät.<br />
Seuraavalla tasolla on projektin viestintäprosessissa kulkeva informaatio. Projekteissa<br />
virallinen informaatio kulkee pääasiallisesti dokumenteissa ja kokouksissa /27/. Epävirallista<br />
informaatiota taas ovat esimerkiksi kahden osapuolen väliset keskustelut tai sähköpostiviestit<br />
/27/. Asiatietoa ovat lisäksi informaation hallinnassa käytetyt menetelmät.<br />
Toiminnallista tietoa ovat informaation syntymiseen liittyvät asiat, esimerkiksi projektin<br />
osapuolten väliset yhteydet ja aikaisempi viestintä, sekä informaation kulku ja elinkaari<br />
projektissa. Strategista tietoa on informaation tarkoitus.<br />
Informaation olemassaolon pääasiallinen tarkoitus on tietämyksen tarjoaminen. Projektin<br />
viestintäprosessin seuraava taso on tietämys, joka informaatiosta syntyy. Tällä tasolla<br />
asiatietoa ovat tiedon lähteet, viestinnän sisältö ja viestinnän kohderyhmät. Toiminnallista<br />
tietoa ovat tietämyksen syntyyn liittyvät toiminnot, eli viestinnän kohdistaminen sekä<br />
viestintäprosessiin liittyvät päätökset perusteluineen. Strategista tietoa projektin<br />
viestintäprosessin tietämystasolla on projektin tarkoitus.<br />
Projektin kokousprosessia ajatellen taulukon 2 alueista tärkeää on tuntea projektin<br />
osapuolet, projektin osapuolien välinen viestintä ja sen tarkoitus sekä informaation kulku<br />
projektin eri vaiheissa. Projektin osapuolet esiteltiin kohdassa 3.4. Kohdassa 4.3 tarkastellaan<br />
projektin viestintäprosessin tärkeitä osa-alueita. Kohdassa 4.4 tarkastellaan erikseen<br />
projektin viestinnän hallintaa yhtenä projektin hallintaprosessina sekä tutustutaan yhteen<br />
projektin viestinnän hallinnassa käytettyyn tekniikkaan. Pöytäkirjan käyttöön ja asemaan<br />
projektin viestinnän välineenä tutustutaan kohdassa 4.5.<br />
4.2 Tieto ja informaatio sekä niiden hallinta<br />
4.2.1 Peruskäsitteitä<br />
Kirjallisuudesta voidaan käsitteelle tieto löytää useita määritelmiä. Platonin klassisen<br />
tietoteorian mukaan tieto on hyvin perusteltu tosi uskomus. Lähteessä /9/ tietämys on<br />
määritelty siten, että siihen kuuluvat:<br />
1) Alan tosiasiat, alan harjoittajien yleisesti hyväksymät tiedot, jotka on kirjattu<br />
oppikirjoihin ja ammattijulkaisuihin ja jotka muodostavat alan professorien<br />
luentojen perustan.<br />
2) Heuristinen tieto, kokemuksen ja hyvän arvostelukyvyn tuottama alan tieto.<br />
Tämän työn kannalta oleellista on erottaa toisistaan käsitteet data, informaatio ja tieto.<br />
Työssä käytetään määritelmiä lähteestä /20/. Informaatio voidaan jakaa alaluokkiin. Näitä<br />
luokkia ovat ei-kielellinen informaatio, eli fysikaalisen tai henkisen maailman<br />
järjestyneisyys, informaatiota kantavat merkit tai merkkijonot, eli data sekä kielellinen<br />
informaatio. Kielellinen informaatio jakautuu edelleen syntaktiseen, semanttiseen ja prag-
18<br />
maattiseen informaatioon. Syntaktisella informaatiolla tarkoitetaan informaation rakennetta,<br />
eli siinä esiintyvien merkkien esiintymistiheyttä. Semanttinen informaatio ilmaisee<br />
väitelauseen ilmaisuvoimaa tai sisältöä. Pragmaattisella informaatiolla taas tarkoitetaan<br />
lauseen sisällöllistä merkityksellisyyttä kielen käyttäjälle. Tieto tai tietämys on informaation<br />
suppeampi erikoistapaus, johon liittyy perusteltavuus, totuudenmukaisuus sekä<br />
jonkinlainen ymmärrys.<br />
Kuva 4. Informaatiohierarkia viestintäprosessissa /25/<br />
Kuvassa 4 on esitetty informaatiohierarkia viestinnässä. Datan, informaation ja tietämyksen<br />
lisäksi informaatiohierarkiaan kuuluu viisaus. Viisaus on filosofinen käsite, jonka<br />
määrittely ei kuulu tämän työn aihepiiriin.<br />
4.2.2 Informaation hallinta<br />
Edellisessä luvussa esitettyjen määritelmien perusteella informaationhallinta voidaan<br />
ajatella prosessiksi, jossa sisääntulona on järjestämätön informaatio tai data ja ulostulona<br />
tietoa tai tietämystä. Informaationhallinnan tarkoituksena siis on järjestää informaatio tai<br />
data saataville siten, että se muuttuu tiedoksi tai tietämykseksi sitä hakevalle, selaavalle ja<br />
lukevalle henkilölle. Aiemmin määriteltyjen käsitteiden mukaan informaationhallinta ei<br />
ole sama asia kuin datanhallinta, siis esimerkiksi pelkkä tietokone ei ole informaation<br />
hallintajärjestelmä, koska se osaa käsitellä ainoastaan dataa. Sen sijaan, kun ihminen<br />
syöttää tai käsittelee informaatiota tietokoneen avulla, voidaan jo puhua informaation<br />
hallintajärjestelmästä. Informaation hallintaprosessin perusajatus on esitetty kuvassa 5.<br />
Informaation hallintaa ei kuitenkaan voida ajatella pelkästään joukoksi yksittäisiä toimenpiteitä,<br />
joita informaation hallintaan koulutetut ihmiset informaatiolle tekevät. Yritysten<br />
suuntaukset kohti verkottuneita yhteisöjä, uudet tietotekniset ratkaisut ja informaation<br />
kasvava määrä aiheuttavat sen, että informaatiota työkseen käsittelevien ihmisten määrä<br />
kasvaa. Siksi informaation hallinta yrityksessä pitää ennemminkin nähdä toimenpiteinä,
19<br />
jotka ulottuvat kaikille organisaatiotasoille ja jotka ovat muutakin kuin informaation<br />
syöttäminen ja järjestäminen, esimerkiksi johtamis- tai neuvottelukäytännöt. /18, 23/<br />
Kuva 5. Informaation hallintaprosessi<br />
Organisaatioissa sanotaan olevan kolmenlaista tietoa tai tietämystä. Hiljaiseksi tai<br />
piilotietämykseksi (tacit knowledge) kutsutaan sellaista tietoa, joka on sidottu tiettyyn<br />
henkilöön tai ryhmään ja jota on vaikeaa jakaa muille. Tällaista tietoa on usein pitkään<br />
organisaatiossa olleilla henkilöillä, joille on karttunut paljon kokemusta työstään. Piilotietämystä<br />
on myös yksilön henkinen pääoma tai lahjakkuus. Piilotietämystä tai jopa<br />
kuollutta tietämystä on myös kaikki sellainen sähköisesti tai manuaalisesti arkistoitu<br />
projekti- ja käsikirjatietämys, mikä on vaikeasti haettavissa projektiorganisaation käyttöön<br />
tai minkä olemassaolosta projektiorganisaatio ei useasti edes tiedä tai saa tietoa.<br />
Avointa tietoa (explicit knowledge) ovat esimerkiksi organisaation rutiinit, säännöt ja<br />
standardit. Avoimelle tiedolle on tyypillistä, että sitä on helppo jakaa ja levittää muille ja<br />
se voidaan ilmaista esimerkiksi dokumentein. Kulttuurista tietoa (cultural knowledge)<br />
taas ovat esimerkiksi organisaation arvot ja työskentelytavat. /5, 22/<br />
Informaation hallinnan ongelmallista suhdetta organisaatioissa olevaan tietämykseen<br />
voidaan kuvata esimerkiksi kuvassa 6 esitellyn kaavion avulla. Kaavion /15/ ajatuksena<br />
on, että informaation hallintaan käytettävien järjestelmien lisääntymisen myötä avoimen<br />
tiedon merkitys korostuu. Tämä on hyvä asia, sillä mitä enemmän organisaatiossa olevaa<br />
tietoa voidaan muuttaa avoimeen muotoon, sitä paremmin se on kaikkien käytettävissä ja<br />
hyödynnettävissä paremman kilpailuedun saavuttamiseksi. Avoimen tiedon lisääntyminen<br />
ei kuitenkaan tarkoita sitä, että hiljainen tieto muuttuisi avoimeksi, vaan pikemminkin<br />
saattaa aiheuttaa sen, että se jää käyttämättä. Tämä taas ei ole hyvä asia, sillä hiljaisella<br />
tiedolla on suuri merkitys organisaation suorituksen kannalta. Jos hiljainen tieto jää<br />
käyttämättä, tarvittaan parempia informaation hallintajärjestelmiä saman lopputuloksen<br />
saavuttamiseksi.<br />
Yllä esitetty näkökulma pyritään ottamaan huomioon tässä työssä siten, että tietoa<br />
ryhmiteltäessä ei tehdä niin jäykkiä ratkaisuja, että ne estävät hiljaisen tiedon saattamista<br />
avoimeen muotoon. Käytännössä tämä tarkoittaa, että projektipöytäkirjojen syöttämistä<br />
varten ei laadita jäykkää pohjaa, johon tieto on syötettävä, vaan järjestäminen tapahtuu<br />
ainoastaan tietotyypin tunnistamisen avulla. Silloin tiedon syöttäjä voi syöttää tiedon<br />
haluamaansa muotoon ja ainoastaan ilmoittaa, että kyseessä on esimerkiksi päätös.<br />
Tällöin kynnys hiljaisen tiedon saattamiseksi avoimeen muotoon laskee /21/.
20<br />
Kuva 6. Informaation hallinnan suhde organisaation tietämykseen /15/<br />
4.2.3 Tietämys projekteissa<br />
Lähteessä /6/ on esitetty projekteihin liittyvän tietämyksen jakamista kolmeen osaan:<br />
tietämys projektista, projektissa oleva tietämys sekä projekteista saatava tietämys. Tämä<br />
kolmijako on esitetty kuvassa 7.<br />
Tietämystä projektista käytetään projektin hallintaan. Tällaista tietämystä ovat esimerkiksi<br />
projektin aikataulut, organisaatio, suunnitelmat ja työskentelytavat. Myös organisaation<br />
kulttuurinen tietämys kuuluu hyvin pitkälti tähän luokkaan. Etenkin projektin työskentelytapoihin<br />
liittyy paljon hiljaista tietämystä. Monet projektiorganisaation osapuolet voivat<br />
olla kokeneita projektinjohtajia tai työntekijöitä ja heidän hiljainen tietämyksensä projektin<br />
hallintaan liittyvissä asioissa korvaamatonta. /6, 22/<br />
Tietämys projektissa liittyy projektin senhetkiseen suorittamiseen ja toimii projektin työn<br />
onnistuneen läpiviennin välineenä. Projektikokoukset ja niistä tehtävät dokumentit, tehtävälistat<br />
sekä tilanneraportit ovat tyypillisiä esimerkkejä tällaisista työvälineistä. Projektissa<br />
olevan tietämyksen lähteenä ovat projektin työntekijät ja mahdolliset asiantuntijat. /5,<br />
6/<br />
Projektista saatava tietämys on tärkeää tulevia projekteja ajatellen. Tällaista tietämystä<br />
ovat esimerkiksi aikaisemmissa projekteissa käytetyt työskentelytavat sekä tehdyt virheet<br />
ratkaisuineen ja seurauksineen. Kolmesta projektin tietämysalueesta tällä alueella on<br />
eniten hiljaista tietoa ja siksi projektista saatavan tietämyksen hallinta on vaikeampaa<br />
kuin kahden muun edellä esitetyn alueen. /5, 6/
21<br />
Kuva 7. Projekteihin liittyvä tietämys /6/<br />
4.3 Viestintä ja tiedon kulku projekteissa<br />
Kuvassa 8 on esitetty tämän työn puitteissa tyypillinen esimerkki siitä, kuinka projektin<br />
osapuolet kommunikoivat keskenään. Esimerkki on kuvattu pääkonsultin näkökulmasta.<br />
Suurin osa projektin osapuolten viestinnästä kulkee pääkonsultin kautta. Näin saadaan<br />
kootusti kaikki informaatio yhdelle osapuolelle. Kuten luvussa 3.4 todettiin, pääkonsultti<br />
siis toimii eräänlaisena rajapintana etenkin asiakkaan ja muiden osapuolten välillä.<br />
Käytännössä projektin muut osapuolet harvoin kommunikoivat keskenään ellei asian<br />
luonne kilpailutekijöistä tai eturistiriidoista johtuen niin vaadi. Tällaisia asioita saattavat<br />
olla esimerkiksi lopulliset hintaneuvottelut asiakkaan ja toimittajan välillä. /27/<br />
Kuva 9 kuvaa projektin yhden yksittäisen osapuolen sisäistä kommunikaatiota sekä informaation<br />
tarvetta eri organisaatiotasoilla. Vasemmalla kuvassa on kuvattu informaation<br />
kulku. Projektiorganisaatiossa informaatio kerätään itse tapahtumapaikalta eli työnjohtajilta<br />
ja -tekijöiltä. Mentäessä organisaatiossa ylöspäin informaation määrän tarve ja sen<br />
kiireellisyys pienenevät. Vastaavasti ohjeet ja päätökset kulkevat projektiorganisaatiossa<br />
alaspäin. Oikealla kuvassa on kuvattu informaation tarve. Kahdella ylimmällä tasolla<br />
informaation tarve yksittäisistä projekteista rajoittuu tiivistettyihin yhteenvetoihin ja<br />
avaininformaatioon. Projektin johdon tehtävä on huolehtia siitä, että riittävä määrä<br />
informaatiota kulkee organisaatiossa sitä tarvitseville osapuolille. /26/
22<br />
Kuva 8. Esimerkki projektin osapuolten välisestä viestinnästä<br />
Projektin elinkaaren aikana viestinnän sisältö painottuu eri asioihin. Projektin alussa eli<br />
kehitysvaiheessa sekä toteutusvaiheen alussa tärkeitä asioita ovat projektin tavoitteet ja<br />
vastuut, hinta- ja hankinta-asiat sekä projektiin liittyvät suunnitelmat. Toteutusvaiheessa<br />
viestinnän sisältö painottuu tilannekatsauksiin ja niistä seuraaviin muutoksiin, avaintehtäviin,<br />
projektin tapahtumiin ja raportointiin. Projektin päätösvaiheessa tärkeitä<br />
viestintään liittyviä asioita ovat projektin tulos, tuotteen käyttöönottoon liittyvät tehtävät<br />
ja raportit sekä projektin osapuolilta saatu palaute. /26/<br />
Kuva 9. Projektiorganisaation informaatiotarve /26/<br />
Kuvassa 10 on esitetty malli tiedon kululle projekteissa. Malli perustuu lähteessä /16/<br />
esitettyyn malliin tiedon kulusta tehdasprojektin elinkaaren eri vaiheissa.
23<br />
Kuva 10. Tiedon kulku projektin elinkaaren eri vaiheiden välillä /16/<br />
Projektin elinkaaren kehitys- ja toteutusvaiheessa syntynyt tieto on hyödynnettävissä sekä<br />
tuotantovaiheessa että seuraavassa projektissa. Tuotantovaiheessa syntyy toimintakokemusta<br />
ja huoltohistoriaa, joista myös voidaan oppia seuraavaa projektia varten. Mikäli<br />
seuraava vastaavanlainen projekti käynnistyy, kun edellisen projektin tuote on vielä<br />
tuotannossa, uudessa projektissa syntyvää tietämystä voidaan hyödyntää vanhan jatkokehityksessä<br />
sekä ylläpidossa. Tarvitaan kuitenkin hyvää tiedonhallintaa, jotta projekteissa<br />
liikkuva tietämys saataisiin liikkumaan tehokkaasti projektin elinkaaren eri<br />
vaiheiden välillä ja että sitä voitaisiin hyödyntää tulevissa projekteissa. /6, 16/<br />
4.4 Viestinnän hallinta projektissa<br />
4.4.1 Viestinnän hallintaprosessi<br />
Projektin viestinnän hallintaa varten on kuvassa 11 esitetty malli, jossa projektissa<br />
työskentelevät henkilöt on jaettu kolmeen eri rooliin. Nämä roolit ovat tietämysjohtaja,<br />
tietotyöntekijät sekä tiedon luojat ja käyttäjät.<br />
Tietämysjohtaja on useimmiten projektipäällikkö tai hän voi myös olla tehtävään nimetty<br />
muu vastuuhenkilö. Tietämysjohtaja vastaa viestinnän ja informaation hallinnasta<br />
projektissa, viestinnän suunnittelusta sekä laadusta. Mitä suuremmasta projektista on<br />
kyse, sitä enemmän tietämysjohtajan asema projektissa korostuu. Projektin johtamisen<br />
voidaankin ajatella olevan suurimmilta osin juuri tietämysjohtamista. /4/<br />
Tietotyöntekijät vastaavat projektissa käytettyjen tietojärjestelmien toiminnasta tai jos<br />
mitään tiettyjä tietojärjestelmiä ei käytetä, projektidokumenttien ylläpidosta ja jakelusta.<br />
Tietotyöntekijöitä projektissa ovat siis esimerkiksi tietojärjestelmien ylläpitäjät, projektisihteeri<br />
sekä muut henkilöt, joiden tehtävänä on saattaa tietoa muiden saataville. /4/
24<br />
Kuva 11. Projektin työntekijöiden roolit tiedonhallinnan kannalta /4/<br />
Muut projektin työntekijät ovat tiedon luojia ja käyttäjiä. Tietoa luovat esimerkiksi<br />
suunnittelijat tai muut vastaavassa asemassa olevat henkilöt. Kaikki projektin työntekijät<br />
käyttävät tietoa. /4/<br />
Projektin viestinnän hallinnan voidaan ajatella koostuvan kolmesta erillisestä osaalueesta,<br />
jotka kaikki kuitenkin vaikuttavat toisiinsa /13/:<br />
• viestinnän suunnittelu,<br />
• informaation hallinta ja<br />
• viestinnän valvonta<br />
Viestinnän suunnittelussa päätetään käytettävistä informaatio- ja kommunikaatiojärjestelmistä<br />
ja -menetelmistä. Informaation hallinnan tehostamiseksi myös tiedon välitysmuoto,<br />
kieli ja taajuus määritellään yhteensopiviksi. Viestintäsuunnitelmassa määritellään<br />
projektikokousten ajoitus ja tarkoitus, tiedon säilytys ja tietoturvallisuusasiat.<br />
Tärkeää on myös määritellä projektin osapuolten tiedontarpeet. /13, 26, 28/<br />
Informaation hallinta tapahtuu tyypillisesti viestintäsuunnitelmassa määritellyn järjestelmän<br />
avulla. Hyvä järjestelmä sisältää menettelyt tiedon valmistamiselle, keräämiselle,<br />
tunnistamiselle, luokittelulle, jakelulle, päivitykselle, arkistoinnille ja hakemiselle. Järjestelmän<br />
tehokas hyödyntäminen edellyttää kuitenkin, että se on kaikkien osapuolten<br />
tarpeisiin sopiva ja että sen käytöstä järjestetään koulutusta niille, jotka sitä eivät tunne.<br />
Mikäli tiedonhallinnassa ei käytetä mitään tiettyä järjestelmää, korostuu suunnittelun<br />
merkitys huomattavasti ja vastuuhenkilöiden, eli tietotyöntekijöiden rooli projektissa<br />
muuttuu huomattavasti. /13, 26, 30/
25<br />
Informaation hallintaan kuuluvat myös projektikokousten asialistojen sekä pöytäkirjojen<br />
laatiminen ja jakelu. Näitä käsitellään tarkemmin luvussa 5.<br />
Viestinnän valvonta käsittää käytetyn tietojärjestelmän toiminnan valvonnan sekä<br />
osapuolten muun viestinnän valvomisen. Tietämysjohtaja vastaa viestinnän valvonnasta,<br />
jonka tarkoituksena on siis varmistaa, että kaikki osapuolet saavat tarvitsemansa tiedon<br />
ajoissa. /4, 13, 26/<br />
Projektin kommunikaation hallintaan on olemassa useita tekniikoita. Seuraavassa<br />
alaluvussa esitellään tekniikka nimeltä Goal Directed Project Management (GDPM),<br />
jossa tiedon tarve ja lähteet tulevat varsin hyvin määritellyiksi.<br />
4.4.2 Goal Directed Project Management (GDPM) projektin kommunikaation<br />
hallinnan välineenä<br />
Lähteessä /1/ on esitetty malli, jossa projektiorganisaation henkilöt voidaan jakaa<br />
kahdeksaan eri luokkaan. Mallin tarkoituksena on paitsi projektin resurssien suunnittelun<br />
helpottaminen, myös kommunikaation hallinnan tehostaminen. GDPM-mallin roolit on<br />
esitetty taulukossa 3. Roolit sinänsä eivät ole mitenkään sidottuja ja projektin aikana yksi<br />
henkilö voi toimia useassa roolissa.<br />
GDPM-mallin roolit voidaan luokitella kolmeen ryhmään. Ensimmäiseen ryhmään<br />
kuuluvat X-henkilöt. Nämä henkilöt ovat vastuussa työn suorittamisesta. Työllä<br />
käsitetään tässä yhteydessä myös sellainen työhön liittyvä suunnittelu, jota ei voida<br />
luokitella kuuluvaksi luvussa 3.5 esiteltyihin projektin hallintaprosesseihin. Toiseen<br />
ryhmään kuuluvat projektin hallinnasta vastuussa olevat henkilöt, eli D-, d-, P- ja T-<br />
henkilöt. Nämä vastaavat projektin hallintaprosesseista. /1/<br />
Taulukko 3. Projektiorganisaation työntekijöiden roolit GDPM-mallissa /1/<br />
Tyyppi Rooli tai vastuu<br />
X<br />
Työn suorittaja (eXecuter)<br />
D<br />
Itsenäinen päätöksentekijä (independent Decision taker)<br />
d<br />
Päätöksentekijä ryhmässä (joint decision taker)<br />
P<br />
Edistymisen valvoja (Progress controller)<br />
T<br />
Työn ohjaaja tai opettaja (Tuition provider)<br />
C<br />
Konsultoitava, ohjeita tarjoava (Consulted)<br />
I<br />
Tiedotettava (Informed)<br />
A<br />
Mahdollinen asiantuntija (possibly available for Advice)<br />
Kolmas osa on GDPM-mallin se osa, joka vaikuttaa projektin kommunikaation hallintaan.<br />
Tähän ryhmään kuuluvat siis C-, I- ja A-henkilöt. C-, I- ja A-henkilöt voivat kuulua<br />
kumpaan tahansa kahdesta edellisestä ryhmästä, mutta he voivat myös olla ulkopuolisia<br />
tahoja. Mallin ajatus kommunikaation hallinnan kannalta on, että taulukon GDPM viisi
26<br />
ensimmäistä työntekijätyyppiä ovat velvollisia ottamaan huomioon nämä kolme erilaista<br />
tiedon tarvetta tai -lähdettä. /1/<br />
C-henkilöillä on tärkeää ja oleellista tietoa projektin suorittamisen kannalta. Näiden<br />
henkilöiden tietoa ja mielipiteitä siis ei voi jättää huomiotta. Toisaalta C-henkilöillä<br />
harvoin on suurta vastuuta projektin päätöksenteosta, joten heiltä saatua tietoa voidaan<br />
käyttää sellaisenaan tai muokata tilanteeseen sopivaksi. Tyypillisesti C-henkilöitä ovat<br />
sellaiset henkilöt, joilla on paljon käytännön kokemusta projektin jostain osa-alueesta ja<br />
tämän kokemuksen jättäminen huomiotta olisi projektin kannalta haitallista. /1, 30/<br />
I-henkilöille pitää jakaa tietoa. I-henkilö voi esimerkiksi olla työntekijä, joka tarvitsee<br />
jotain tietoa jatkaakseen työtään tai johtaja, joka tarvitsee raportin projektin edistymisestä.<br />
Käytännössä projekteissa useimmat henkilöt ovat jossain projektin elinkaaren vaiheessa I-<br />
henkilöitä. Viestinnän hallinnan vaikein osuus onkin juuri I-henkilöiden hallinta,<br />
kartoittaminen ja vastaaminen siitä, että tieto kulkee heille oikeaan aikaan. Tästä<br />
tehtävästä huolehtii tietämysjohtaja. /1, 2, 30/<br />
A-henkilöillä saattaa olla oleellista tietoa projektin jotain osa-aluetta koskien. Tätä ei<br />
kuitenkaan yleensä tiedetä etukäteen, vaan projektin tullessa tiettyyn vaiheeseen heiltä<br />
kysytään neuvoja. A-henkilöt ovat usein melko kapean alan asiantuntijoita, joilla on<br />
arvokasta tietoa projektin jostain osa-alueesta, mutta toisaalta A-henkilöiden näkemys<br />
saattaa yksinään olla liian kapea tai se ei aivan vastaa senhetkistä tarvetta. A-henkilöiden<br />
kaltaisten asiantuntijaverkostojen kartoittaminen on kuitenkin yksi oleellinen osa GDPMmallin<br />
kaltaista kommunikaation hallintaa. /1/<br />
GDPM-mallin ajatuksen selventämisen vuoksi on taulukossa 4 esitetty yksinkertainen<br />
esimerkki mallin käytöstä. Käytännössä projekti siis jaetaan pieniin tehtäviin. Vastuut<br />
kustakin tehtävästä jaetaan edelleen taulukon 3 mukaisten vastuualueiden mukaisesti.<br />
Projektin kommunikaation hallinnan kannalta on oleellista tunnistaa jokaiselle tehtävälle<br />
C-, I- ja A- henkilöt, mikäli näitä on.<br />
Taulukko 4. Esimerkki GDPM-mallin käytöstä<br />
Tehtävä Henkilö<br />
Kuvaus<br />
A B C D<br />
T1 D P C I, X Henkilö A päättää asiasta yksin, mutta kysyy<br />
kuitenkin neuvoa henkilöltä C. Henkilö B valvoo<br />
tehtävän suorittamista ja päätöksestä pitää<br />
tiedottaa henkilölle D, joka myös tekee työn.<br />
T2 d, P d A I Henkilöt A ja B päättävät asiasta yhdessä.<br />
Henkilöllä C saattaa olla arvokasta tietoa, jota<br />
kannattaa kysyä ennen päätöksentekoa. Henkilö<br />
A valvoo prosessia. Päätöksestä tiedotetaan<br />
henkilölle D.
27<br />
GDPM-mallin hyvänä puolena voidaan pitää sitä, että tiedon kulkua eri osapuolten välillä<br />
voidaan sen avulla kätevästi hallita. Jos verrataan GPDM-mallia kuvassa 11 esitettyyn<br />
malliin projektin työntekijöiden tiedonhallintaan liittyvistä rooleista, voidaan X- henkilöiden<br />
ajatella kuuluvan tiedon luojien ja käyttäjien tasolle. D-henkilöt ovat tietämysjohtajia.<br />
P-, d- sekä T- henkilöt ovat tietotyöntekijöitä ja C-, I- ja A- henkilöt jakautuvat<br />
tietotyöntekijöihin ja tiedon luojiin sekä käyttäjiin.<br />
4.5 Pöytäkirjan asema projektin viestinnän välineenä<br />
Lähteessä /11/ on esitetty ajatus, että yritys tai projekti voi käyttää tietoa kymmenellä eri<br />
tavalla:<br />
1 Tiedon ja parhaiden toimintatapojen jakaminen<br />
2 Tiedon jakamisen kehittäminen<br />
3 Aikaisempien kokemuksien hyödyntäminen<br />
4 Tiedon hyödyntäminen tuotteissa, palveluissa ja prosesseissa<br />
5 Tiedon tuottaminen tuotteena<br />
6 Tiedon hyödyntäminen perustana uusille innovaatioille<br />
7 Asiantuntijaverkostojen kartoittaminen<br />
8 Asiakasverkostojen rakentaminen ja ylläpito<br />
9 Tiedon arvon mittaaminen ja ymmärtäminen<br />
10 Älylliseen pääomaan (esimerkiksi tekijänoikeudet, patentit) panostaminen<br />
Kuten lähteessä /11/ todetaan, tiedonhallintaa tärkeänä kilpailuetunaan pitävän yrityksen<br />
tulisi hallita kaikki kymmenen osa-aluetta. Nykyisessä muodossaan projektien<br />
pöytäkirjoja kuitenkin käytetään pääasiallisesti kohdan yksi mukaisessa tarkoituksessa.<br />
Rakenteisen tiedonhallinnan avulla projektipöytäkirjan käyttöä mahdollisesti voidaan<br />
laajentaa kattamaan ainakin kohdat 2, 3, 4, 6, 7 ja 8. Näistä mahdollisuuksista kerrotaan<br />
luvussa 7.<br />
Projekteissa pöytäkirja siis toimii tiedon jakamisen välineenä projektin osapuolten välillä.<br />
Sen avulla raportoidaan asiakkaalle projektin edistymisestä ja tiedotetaan projektin<br />
lähiajan tapahtumista. Pöytäkirjalla on myös melko vahva sopimuksellinen asema, eli<br />
hyväksyttyyn pöytäkirjaan kirjattu päätös on yleensä osapuolten välisen sopimuksen<br />
mukaan sitova. Kiistatilanteissa pöytäkirjoista joudutaankin usein tarkistamaan kirjattuja<br />
päätöksiä ja pöytäkirja saattaa hyvinkin toimia todisteena jonkin osapuolen väitteille. /27,<br />
28/<br />
Vaikka projektipöytäkirjoihin onkin usein kirjattu paljon arvokasta tietoa, tiedon jakamisen<br />
lisäksi projektipöytäkirjoja käytetään melko vähän säännöllisessä projektinhallinnassa.<br />
Pelkän pöytäkirjan käyttäminen koko projektin tai projektin yksittäisen osan<br />
hallinnassa tuskin on mahdollista, mutta tiedon esitystapaa parantamalla siitä saataisiin<br />
suurta apua tavallisiin projektin hallintaprosesseihin.
Nykyisin projektipöytäkirjojen hallinnalle ei Jaakko Pöyry Oy:ssä ole mitään varsinaisia<br />
yhteisiä käytäntöjä. Pöytäkirjoille on kyllä olemassa pohja, joka sisältää tiettyjä kenttiä,<br />
kuten kokouspäivämäärän, kokouksen otsikon sekä läsnäolijat, mutta läheskään kaikkia<br />
pöytäkirjoja ei kuitenkaan ole arkistoitu mihinkään tiettyyn paikkaan. Riippuukin pitkälti<br />
projektin johdon aktiivisuudesta ja projektin osapuolten välisten, erikseen sovittujen<br />
pöytäkirjakäytäntöjen sisällöstä, mitkä kaikki pöytäkirjat ovat myöhemmin helposti<br />
saatavilla.<br />
28
29<br />
5 <strong>PROJEKTIKOKOUKSISSA</strong> SYNTYVÄ TIETO<br />
5.1 Yleistä<br />
Suurin osa projekteissa olevasta tiedosta syntyy muualla kuin kokouksissa. Kokouksissa<br />
käsiteltävät asiat tyypillisesti valmistellaan erikseen ja kokous toimii näiden asioiden<br />
välityskanavana. Samalla syntyy projektikokouksille tyypillisiä tietotyyppejä, kuten<br />
päätöksiä ja tiedotuksia.<br />
Projektikokouksissa syntyvää tietoa voidaan tarkastella kuvassa 12 esitetyn mallin mukaisesti,<br />
jossa tiedolle on esitetty kolme ulottuvuutta: kokoustyyppi, asia ja tietotyyppi.<br />
Kuva 12. Projektikokouksissa syntyvän tiedon kolme ulottuvuutta.<br />
Mallin ajatuksena on, että kokouksissa syntyvä tieto voidaan kohdistaa tietylle kokoustyypille.<br />
Erilaisissa kokouksissa taas käsitellään erilaisia asioita, mikä johtaa kullekin<br />
kokoustyypille ominaiseen asialistaan. Asialistan sisällöstä riippuen kokouksissa käsitellään<br />
erilaista tietoa, mikä voidaan luokitella erilaisiin tietotyyppeihin. Esimerkiksi<br />
suunnittelukokouksissa syntyy tietoa, joka edustaa tietotyyppiä suunnitelma.<br />
Projektikokoukset voidaan ryhmitellä usealla eri tavalla. Kaksi erilaista näkökulmaa projektin<br />
kokoustyyppeihin saadaan ryhmittelemällä ne projektin elinkaaren ja organisaation<br />
mukaisesti. Projektikokousten tarkastelu seuraavassa tapahtuu projektin pääkonsultin<br />
näkökulmasta.<br />
Kokousprosessi on yksi erikoistapaus kohdassa 4.1 esitellystä projektin viestintäprosessista.<br />
Prosessin voidaan ajatella alkavan tarpeesta pitää kokous ja päättyvän<br />
seuraavaan kokoukseen. Taulukossa 5 on esitetty kokousprosessi samassa kehysmallissa<br />
kuin projektin viestintäprosessi taulukossa 2.
30<br />
Taulukko 5. Projektin kokousprosessi viestintäprosessin erikoistapauksena<br />
Kokousprosessi Informaatio Tietämys<br />
Asiatieto, faktat<br />
(mitä asioista<br />
tiedetään)<br />
• Osallistujat<br />
• Kokoustyypit<br />
• Osallistujien<br />
tehtävät ja roolit<br />
projektiorganisaatiossa<br />
• Neuvottelu ja<br />
kokousdokumentit<br />
• Asialistat<br />
• Pöytäkirjat<br />
• Kokousdokumenttien<br />
hallintaan<br />
käytetyt<br />
menetelmät<br />
• Asiantuntijat,<br />
projektin johto,<br />
työntekijät<br />
• Asialistan sisältö<br />
• Pöytäkirjan<br />
sisältö<br />
Toiminnallinen<br />
tieto<br />
(miten asiat<br />
toimivat)<br />
Strateginen tieto<br />
(miksi asiat<br />
toimivat näin)<br />
• Kokouskutsun ja<br />
asialistan<br />
laadinta<br />
• Kokous<br />
• Pöytäkirjan<br />
elinkaari<br />
• Kokouksen<br />
tarkoitus<br />
• Kokoustekniikka:<br />
Videoneuvottelu,<br />
perinteinen<br />
kokous, puhelinneuvottelu<br />
tms.<br />
• Kokoustekniikat<br />
• Osallistujien<br />
roolit<br />
kokouksessa<br />
• Osallistujien<br />
aikaisemmat<br />
yhteydet<br />
• Kokousdokumentissa<br />
olevan<br />
informaation<br />
tarkoitus: tiedottaminen,<br />
raportointi,<br />
asian<br />
selvittäminen<br />
tms.<br />
• Pöytäkirjaan kirjattavat<br />
ja poisjätettävät<br />
asiat<br />
• Kokouksissa<br />
käsitellyt asiat<br />
• Kokouksessa<br />
tehdyt päätökset<br />
• Päätöksiin<br />
liittyvät syyt ja<br />
perustelut<br />
• Projektin<br />
tavoitteet<br />
• Tietotyypit,<br />
tiedon luokittelu<br />
• Pöytäkirjan tai<br />
asialistan muoto<br />
Projektikokousprosessissa asiatietoa ovat kokouksen osallistujalistat sekä erilaiset<br />
kokoustyypit. Toiminnallista tietoa taas ovat kokoukseen, sen valmisteluun ja pöytäkirjan<br />
laatimiseen liittyvä toiminta. Strategista tietoa kokousprosessista ovat kokouksen<br />
tarkoitus ja muoto. Strategiseen tietoon liittyy aina paljon hiljaista tietämystä, esimerkiksi<br />
kokenut projektipäällikkö tai muu projektin työntekijä voi tietää tietystä asiakkaan<br />
edustajasta, että tämä inhoaa virvokkeiden tarjoilua kokouksissa ja haluaa pysytellä<br />
kokouksen ajan ainoastaan asiassa.<br />
Kokousprosessissa kulkevaa informaatiota ovat kokousdokumentit: asialista ja pöytäkirja.<br />
Pelkät dokumentit eivät vielä ole tietämystä, vaan informaatiotasolla tehdään<br />
ratkaisut, joiden avulla varmistetaan, että tietämystä tarvitsevat henkilöt saavat sitä<br />
tarjolla olevasta informaatiosta. Asiatietoa tällä tasolla ovat itse dokumentit sekä niiden<br />
hallinnassa käytetyt järjestelmät. Toiminnallista tietoa taas ovat projektikokous-
31<br />
dokumenttien syntyyn ja laatimiseen vaikuttava informaatio: kokouksen osallistujien<br />
väliset yhteydet, osallistujien roolit kokouksessa sekä kokoustekniikat. Strategista tietoa<br />
ovat informaation tarkoitus sekä valinnat, joiden avulla informaatiosta pyritään saamaan<br />
halutunlaista tietämystä.<br />
Kokousprosessin tietämystasolla on kokousdokumenteista saatu tietämys, eli avoin<br />
tietämys ja hiljainen tietämys, jotka voivat olla mitä tahansa prosessissa syntyvää<br />
projektiin liittyvää tietämystä. Asiatietotasolla ovat tietämyksen lähteet: työntekijät,<br />
asiantuntijat ja projektin johto sekä kokousdokumenttien sisältö. Toiminnallista tietoa<br />
ovat kokouksissa käsitellyt asiat sekä perustelut niille. Strategista tietoa ovat tietämyksen<br />
tavoitteet eli projektin tavoitteet sekä tavoitteiden saavuttamiseen käytetyt keinot: tiedon<br />
luokittelu ja dokumenttien muoto. Näistä tämän työn pääkohteita ovat nimenomaan<br />
strategisen tiedon hallinnassa käytetyt, edellä esitetyt, keinot.<br />
5.2 Projektikokoukset<br />
5.2.1 Projektikokoukset projektin elinkaaren mukaisesti<br />
Kuvassa 13 on esitetty projektikokoukset sijoitettuna projektin elinkaarimalliin. Seuraavissa<br />
kohdissa käsitellään tarkemmin kunkin kokoustyypin asialistaa ja osallistujia. Koska<br />
työssä käsitellään nimenomaan projektin aikana syntyvää tietoa, tarkastellaan tässä<br />
projektin elinkaaren sitä osaa, joka ulottuu projektin varsinaisesta alkamisesta sen<br />
loppumiseen.<br />
Kuva 13. Projektikokoukset ryhmiteltynä projektin elinkaarimallin mukaisesti
32<br />
Projektin aloituskokous:<br />
Projektin aloituskokoukset voidaan karkeasti luokitella kahteen ryhmään niihin osallistujien<br />
mukaisesti: sisäisiin ja ulkoisiin aloituskokouksiin. Aloituskokous projektin asiakkaan<br />
kanssa pidetään projektin alkaessa. Muiden projektin kulkuun oleellisesti vaikuttavien<br />
ulkoisten osapuolien kanssa aloituskokous pidetään projektin elinkaaren siinä<br />
vaiheessa, kun kyseinen osapuoli tulee mukaan projektiin. Näitä osapuolia ovat käytännössä<br />
toimittajat ja urakoitsijat. /14, 26/<br />
Sisäisiin aloituskokouksiin kuuluvat esimerkiksi koko projektin sisäinen aloituskokous<br />
sekä projektin eri työryhmien aloituskokoukset. Projektin sisäisessä aloituskokouksessa<br />
läsnä ovat projektin johto- ja avainhenkilöt sekä mahdollisesti muuta korkeampaa johtoa<br />
tai asiantuntijoita. Mukaan on myös mahdollisesti projektiin myöhemmin osallistuvia<br />
avainhenkilöitä. Sisäisen aloituskokouksen pääasiallinen tarkoitus on selvittää kaikille<br />
asianosaisille projektin laajuus, tavoitteet ja vaatimukset esimerkiksi seuraavan asialistan<br />
avulla /14, 26/:<br />
• sopimusteksti<br />
• tiedot tilaajasta ja heidän organisaatiostaan<br />
• tehtävänkuvaus<br />
• asiakkaan projektille asettamat laatu- ja muut vaatimukset<br />
• asiakkaan hankkeelle asettamat ympäristö- ja muut tavoitteet<br />
• sovellettava laatujärjestelmä<br />
• projektissa käytettävät työmenetelmät ja ohjelmistot<br />
• tiedonsiirtokäytännöt<br />
• oman projektiorganisaation esittely<br />
• linjajohdon ja projektijohdon periaatteellinen työnjako ja linjajohdon rooli<br />
projektissa<br />
• tuntiarvio<br />
• aikataulu<br />
• lähiajan tavoiteohjelma<br />
Työryhmien aloituskokouksissa läsnä ovat vastaavasti kunkin työryhmän johto- ja<br />
avainhenkilöt. Kokouksissa käytetään soveltuvin osin samaa asialistaa kuin koko projektin<br />
aloituskokouksessa.<br />
Ulkoisiin aloituskokouksiin kuuluvat aloituskokoukset asiakkaan kanssa sekä aloituskokoukset<br />
muiden osapuolten, esimerkiksi toimittajien, kanssa. Ulkoisten aloituskokousten<br />
laajuudet vaihtelevat riippuen siitä, mikä osapuoli on kyseessä ja mikä on tämän rooli<br />
projektin aikana. Seuraavat asiat käsitellään siltä osin kuin se kunkin osapuolen kannalta<br />
on tarpeellista /14/:
33<br />
• projektin kuvaus ja sopimus,<br />
• projektin tavoite-, osto-, suunnittelu- ja koordinointiaikataulut,<br />
• linjajohto tarkoituksenmukaisessa laajuudessa,<br />
• projektin avainhenkilöt ja heidän roolinsa,<br />
• projektissa käytettävät työmenetelmät ja ohjelmistot,<br />
• asiakkaan rooli päätösten teossa ja suunnittelutietojen vaihto-ohjelmissa,<br />
• tietojen elektroninen siirto projektin osapuolten välillä,<br />
• kokouskäytäntö ja pöytäkirjojen laatiminen,<br />
• asiakkaan ja kohdemaan erityisvaatimukset sekä<br />
• asiakkaan hankkeelle asettamat ympäristö- ja muut tärkeät tavoitteet.<br />
Etenkin ulkoiset aloituskokoukset voivat jakaantua projektin elinkaarella hyvin laajalle<br />
alueelle /26/. Vaikka aloituskokous pidetäänkin kaikkien osapuolten kanssa, asialistat<br />
voivat olla hyvin pelkistettyjä edellä esitetystä, jos osapuolet ovat toisilleen ennalta<br />
tuttuja.<br />
Asiantuntijakokous:<br />
Projektin asiantuntijakokoukset ajoittuvat elinkaarimallissa pääasiallisesti suunnitteluvaiheeseen,<br />
vaikka niitä esiintyy muissakin vaiheissa projektin suunnitteluaikataulun<br />
mukaisesti. Asiantuntijakokouksella on tietty aihe, esimerkiksi paperikoneen venttiilit, ja<br />
paikalla kokouksessa ovat kaikki aiheeseen liittyvät osapuolet. Tärkeimpiä käsiteltäviä<br />
asioita ovat /14/:<br />
• aiheeseen liittyvät tekniset asiat ja päätökset,<br />
• tarvittavien hankintojen suunnittelu,<br />
• vastuuhenkilöt eri työvaiheille,<br />
• aiheeseen liittyvät ohjeet ja standardit sekä<br />
• elinkaaren myöhemmissä vaiheissa aiheeseen liittyvät mahdolliset poikkeamat ja<br />
niiden selvittäminen.<br />
Asiantuntijakokoukset eivät ole luonteeltaan yhtä muodollisia kuin esimerkiksi aloituskokoukset,<br />
vaan niitä voidaan pitää suunnittelualan niin tahtoessa ja asialista saattaa<br />
sisältää vain osan edellä esitellyistä kohdista. Esimerkiksi kokoukset, joissa käsitellään<br />
vain teknisiä asioita, ovat yleisiä.<br />
Projektin seurantakokous:<br />
Projektin seurantakokoukset sijoittuvat elinkaarimallissa koko projektin elinkaarelle.<br />
Seurantakokouksia pidetään kaikkien osapuolten kanssa ja jokaisen osapuolen kanssa<br />
määritellään erikseen kuinka usein kokouksia pidetään ja mitä niissä käsitellään. Asiakkaan<br />
kanssa seurantakokouksia tyypillisesti pidetään säännöllisesti koko projektin ajan<br />
esimerkiksi kerran kuukaudessa, kun taas yksittäisen toimittajan kanssa seurantakokouksia<br />
saattaa olla vain yksi tai seuranta saatetaan jopa hoitaa ilman muodollista<br />
kokousta, esimerkiksi puhelimitse. /14, 30/
34<br />
Seurantakokouksen tarkoituksena on /26/<br />
• projektin edistymisestä raportoiminen,<br />
• muutosten tai poikkeamien sekä niiden syiden selvittäminen sekä<br />
• päätöksenteko ja tehtävien jako projektin seuraavalle jaksolle.<br />
Sisäisissä seurantakokouksissa läsnä ovat projektipäällikkö sekä työryhmien edustajat.<br />
Työryhmien sisäisissä seurantakokouksissa taas voivat olla paikalla kaikki työryhmän<br />
työntekijät. Ulkoisissa seurantakokouksissa paikalla on sen osapuolen edustajia, jonka<br />
kanssa kokous pidetään, pääkonsultin edustajat, esimerkiksi projektipäällikkö ja suunnittelualojen<br />
johtajia, sekä tarvittaessa asiakkaan edustaja.<br />
Seurantakokouksessa käsitellään asioita esimerkiksi seuraavan asialistan mukaisesti:<br />
• projektin tilanne<br />
• edellisen pöytäkirjan läpikäynti<br />
• edistyminen, aikataulun seuranta<br />
• tekniset asiat ja hankinnat<br />
• muutokset ja poikkeamat<br />
• seuraavan kokouksen ajankohta<br />
Asialistan sisältö riippuu näissäkin kokouksissa hyvin paljon siitä, kenen kanssa kokousta<br />
pidetään ja kuinka iso rooli kyseisellä osapuolella on projektissa.<br />
Palautekokous:<br />
Projektin palautekokous pidetään projektin tuotteen käyttöönoton jälkeen. Palautekokouksessa<br />
paikalla ovat asiakkaan ja pääkonsultin edustajat. Kokouksessa käsitellään<br />
projektin onnistumista sekä kokonaisuutena että kunkin suunnittelualan kannalta.<br />
Projektin palautekokouksen tarkoituksena on hyödyntää projektissa saatua oppia tulevia<br />
projekteja ajatellen.<br />
5.2.2 Projektikokoukset projektiorganisaation mukaisesti<br />
Kuvassa 14 on esitetty malli, jossa säännöllisesti pidettävät projektikokoukset on ryhmitelty<br />
niihin osallistuvien henkilöiden mukaisesti. Mallin pohjana on luvussa 4.3 esitelty<br />
projektiorganisaatio ja siinä kulkeva informaatio (kuva 9). Ajatuksena on, että ylemmän<br />
tason kokous toimii syötteenä alemman tason kokouksille, eli ylemmän tason kokouksissa<br />
määritellään yleiset ohjeet ja päätetään asioista yleisellä tasolla. Alemman tason<br />
kokouksissa taas käsitellään tietyn alueen ratkaisuja yksityiskohtaisemmin annet-tujen<br />
yleisten ohjeiden mukaisesti. Voidaan siis ajatella, että asiat, jotka vaativat tietyn alan<br />
tarkkaa tuntemusta, käsitellään alemman tason kokouksissa. Vastaavasti asiat, joita ei<br />
osata tai voida ratkaista alemman tason kokouksessa, siirtyvät mallissa ylöspäin.
35<br />
Kuva 14. Projektikokoukset ryhmiteltynä osallistujien mukaan<br />
Ylimpänä mallissa ovat johtoryhmän kokoukset, joiden tehtävänä on toimia syötteenä<br />
projektin kaikille muille kokouksille. Johtoryhmän kokouksissa projektipäällikkö raportoi<br />
yrityksen johdolle projektin edistymisestä. Kokoukset järjestetään säännöllisin väliajoin<br />
ja niissä käsitellään projektin edistymisen lisäksi sellaisia asioita, joita alemman tason<br />
kokouksissa ei ole pystytty ratkaisemaan. Tyypillinen esimerkki tällaisesta asiasta on<br />
projektiin tuleva suuri muutostarve. Lisäksi johtoryhmän kokouksissa päätetään koko<br />
projektiin liittyvistä yleisistä suurista asioista, esimerkiksi projektin alussa projektiorganisaation<br />
rakenteesta, tärkeimmistä resursseista ja toimittajavalinnoista..<br />
Projektikokous kuvassa 14 vastaa aiemmin esiteltyä koko projektin seurantakokousta.<br />
Tällainen kokous voidaan järjestää sekä sisäisesti että minkä tahansa ulkoisen osapuolen<br />
kanssa.<br />
Työryhmien viikkopalaverit ovat samalla työryhmien seurantakokouksia. Näissä kokouksissa<br />
käsitellään koko projektin seurantakokousta tarkemmin tietyn työryhmän teknisiä<br />
ratkaisuja ja vastuita sekä laajuusmuutoksia ja niiden aikataulu- ja kustannusvaikutuksia.<br />
Työryhmien viikkopalavereissa voidaan myös päättää pienemmistä hankinnoista, kun taas<br />
kalliimmat hankinnat siirtyvät mallissa ylöspäin, tyypillisesti asiakkaan kanssa pidettävän
36<br />
projektikokouksen päätettäviksi. Työryhmiä ovat sisäisten työryhmien lisäksi eri toimittajat<br />
tai urakoitsijat.<br />
Kuten aiemmin todettiin, asiantuntijakokouksissa käsitellään tiettyä aihetta. Asiantuntijakokouksissa<br />
pääasiallisesti suunnitellaan aiheeseen liittyviä ratkaisuja, hankintoja sekä<br />
resursseja ja ne esitellään sekä hyväksytetään viikkopalavereissa.<br />
Työmaapalaverit ovat usein epämuodollisia kokouksia, joissa työnjohtaja ja -tekijät<br />
keskenään ratkaisevat pieniä esille tulevia ongelmia tai sopivat työnjaosta. Työmaapalavereista<br />
ei läheskään aina laadita pöytäkirjoja, ellei niissä tule esille asioita, joita pitää<br />
siirtää käsiteltäviksi ylemmän tason kokouksiin kuten laajuusmuutokset ja niistä aiheutuvat<br />
muutos- tai lisätyöt aikataulu- ja kustannusvaikutuksineen..<br />
Kuvista 13 ja 14 puuttuvat sellaiset kokoukset, joita projektissa saatetaan järjestää epäsäännöllisin<br />
väliajoin. Tällaisia kokouksia ovat esimerkiksi erilliset hankintakokoukset.<br />
Näitä kokouksia ei kuitenkaan sellaisenaan voi sijoittaa projektin elinkaari- tai<br />
organisaatiomalliin, sillä niihin saattaa liittyä useita projektin ulkopuolisia osapuolia,<br />
kuten talous- tai markkinointiosastojen edustajia. Ajallisesti näitä kokouksia voidaan pitää<br />
koska tahansa tai ne voidaan myös jättää pitämättä.<br />
5.3 Kokouspöytäkirjat<br />
Lähes kaikista projektikokouksista laaditaan pöytäkirja. Pöytäkirja on tyypillinen<br />
esimerkki dokumentista, jota käytetään projektissa tiedon jakamiseen projektin<br />
osapuolille. Yleisesti käsite dokumentti voidaan määritellä seuraavalla tavalla /8/:<br />
Dokumentti = {Data, metatieto}, missä<br />
Metatieto = {Omistaja, tekijä, versio, tila, linkit, datan kuvaus} ja<br />
Data = Mikä tahansa dokumenttiin kuuluva asia, esimerkiksi teksti tai kuva.<br />
Seuraavassa esitellään kokouspöytäkirjan muoto, elinkaari ja toteutus. Dokumentin elinkaarella<br />
tarkoitetaan tässä niitä vaiheita, joiden kautta dokumentti kulkee olemassaolonsa<br />
aikana. Toteutuksella taas tarkoitetaan dokumentin laadintaa ja siihen liittyviä prosesseja.<br />
Tehokkaan informaationhallinnan aikaansaamiseksi täytyy näiden lisäksi ymmärtää myös<br />
dokumentin käyttötarkoitus /8/. Tämä esiteltiin luvussa 4.5.<br />
Tyypillinen esimerkki nykyisen kokouspöytäkirjan muodosta voidaan esittää seuraavan<br />
viiden kohdan avulla:<br />
1) edellinen pöytäkirja<br />
2) projektin tilanne<br />
3) tekniset asiat<br />
4) muut asiat<br />
5) seuraava palaveri
37<br />
Kohdat edustavat siis pöytäkirjassa olevaa dataa. Metatietoa nykyisissä kokouspöytäkirjoissa<br />
taas ovat kokousaika, kokouspaikka, läsnäolijat ja jakelu. Kokouspöytäkirjojen<br />
muoto kuitenkin vaihtelee kokoustyypistä ja pöytäkirjan laatijasta riippuen.<br />
Tätä voidaan pitää sekä hyvänä että huonona asiana. Toisaalta kokouspöytäkirjojen vapaa<br />
muoto aiheuttaa sen, että kohdassa 4.2.2 esitettyjen ajatusten mukaisesti laatijan kynnys<br />
saattaa hiljaista tietoa avoimeen muotoon laskee, toisaalta taas yhtenäisen muotoisia<br />
pöytäkirjoja olisi helpompi seurata. Jälkimmäinen ei kuitenkaan ole kovin suuri ongelma,<br />
sillä käytännössä kuitenkaan pöytäkirjojen muoto ei tietyn kokoustyypin ja projektin<br />
sisällä vaihtele kovin paljon, koska laatijana on useimmiten sama henkilö.<br />
Kokouspöytäkirjan elinkaari on esitelty kuvassa 15. Kokouspöytäkirjan elinkaari alkaa jo<br />
ennen projektikokousta, jolloin syntyy tarve pitää kokous. Tavallaan pöytäkirjan<br />
ensimmäisenä asteena voidaan jo pitää kokouksen asialistaa, mitä lopullisen pöytäkirjan<br />
muoto hyvin usein noudatteleekin.<br />
Elinkaaren seuraava vaihe on projektikokous, jossa kokouksen sihteeri kirjoittaa ylös<br />
käsitellyt asiat. Sihteerinä toimiva henkilö vaihtelee kokoustyypistä riippuen. Esimerkiksi<br />
projektin seurantakokouksen sihteerinä toimii usein projektikoordinaattori kun taas<br />
asiantuntijakokouksen sihteerinä toimii joku riittävän asiantuntemuksen omaava henkilö.<br />
Kokousmuistiinpanojen pohjana toimii kokouksen asialista.<br />
Kuva 15. Projektikokouksen pöytäkirjan elinkaari<br />
Laatimisvaiheessa kokouksen sihteeri kirjoittaa puhtaaksi kokouksessa tehdyt muistiinpanot.<br />
Pöytäkirja laaditaan tietyn pohjan mukaisesti, usein asialistan mukaisten kohtien
38<br />
perusteella. Käytettävä pohja ja rakenne vaihtelevat riippuen siitä, onko kyseessä sisäinen<br />
vai ulkoinen kokous ja kenelle pöytäkirja jaetaan. Asiakkaalle annettavissa pöytäkirjoissa<br />
muotoseikat ovat virallisesti määriteltyjä. Sisäiset pöytäkirjat taas ovat melko vapaamuotoisia.<br />
Tarkistus- ja hyväksymisvaiheet eivät ole virallisia tai pakollisia käytäntöjä. Käytännössä<br />
pöytäkirjat kuitenkin aina tarkistetaan ja hyväksytään. Tarkistus- ja hyväksymisvaiheissa<br />
pöytäkirjan oikeellisuus tarkistetaan ja se hyväksytään jakeluun kelpaavaksi. Yleensä<br />
projektin seurantakokouksen pöytäkirjan tarkistaa kokouksessa läsnä ollut, tehtävään<br />
valittu henkilö, ja hyväksynnän suorittaa projektipäällikkö. Pienemmissä kokouksissa<br />
käytännöt eivät ole yhtä muodollisia. Toinen yleinen käytäntö on hyväksyä pöytäkirja<br />
seuraavassa kokouksessa.<br />
Pöytäkirjan jakelu tapahtuu viestintäsuunnitelmassa määritellyllä tavalla. Tavallisimmat<br />
tavat ovat sähköpostitse tai postitse. Jakelutavat ja -kohderyhmät valitsee projektipäällikkö<br />
ja itse jakelusta vastaa projektisihteeri.<br />
Kokouspöytäkirja toimii syötteenä seuraavalle kokoukselle, missä se tyypillisesti käydään<br />
läpi asialistan kohdassa edellinen pöytäkirja. Tämän jälkeen pöytäkirjaa saatetaan käyttää<br />
päätösten tarkistamiseen tai projektin historian selvittämiseen. Muita mahdollisia käyttöjä<br />
projektipöytäkirjalle esitellään luvussa 7. Näillä käyttötavoilla pöytäkirjan elinkaarta<br />
voidaan pidentää ja projektinhallintaa sen avulla tehostaa.<br />
Dokumentin elinkaareen kuuluvat myös dokumentin eri versiot /8/. Kokouspöytäkirja on<br />
kuitenkin nykyisessä muodossaan melko pysyvä dokumentti, eli sitä harvoin muutetaan<br />
sen jälkeen, kun se on seuraavassa kokouksessa käyty läpi. Osapuolten välisen sopimuksen<br />
mukaan pöytäkirjan muuttaminen sen hyväksymisen jälkeen on useimmiten<br />
kiellettyä ilman erillistä lupaa.<br />
5.4 Tietotyypit<br />
Kuvassa 12 esitetyn mallin mukaan projektikokouksessa syntyvän tiedon kolmas ulottuvuus<br />
on sen tietotyyppi. Tietotyypit voidaan edelleen jakaa kahteen osaan: jatkuvaan<br />
tietoon ja kertaluonteiseen tietoon. Kuvassa 16 on esitetty jatkuvan ja kertaluontoisen<br />
tiedon syntyminen projektin elinkaaren eri vaiheissa.<br />
Projektin alussa syntyy paljon pysyvää tietoa, esimerkiksi projektin toimintaohjeita, joita<br />
noudatetaan koko projektin ajan. Kuitenkin projektin edetessä pysyvän tiedon syntyminen<br />
vähenee melko nopeasti. Se ei kuitenkaan lopu kokonaan, sillä esimerkiksi projektin<br />
tuotteeseen liittyvä dokumentaatio on pysyvää tietoa. Pysyvän tiedon voi edelleen ajatella<br />
jakautuvan projektin aikaiseen tietoon ja projektin jälkeen voimassaolevaan tietoon. Tässä<br />
työssä kuitenkin pysyvällä tiedolla tarkoitetaan koko kokonaisuutta.
39<br />
Kertaluontoista tietoa on kaikki sellainen tieto, josta päätetään tai jota esimerkiksi<br />
suunnitellaan vain kerran tai melko lyhyellä aikavälillä ja johon sen jälkeen ei enää palata<br />
muutoin kuin tiedon tarkistustarkoituksessa. Kertaluontoisena tietona voidaan myös pitää<br />
sellaista tietoa, joka selkeästi voidaan kohdistaa lyhyelle projektin ajanjaksolle.<br />
Ongelmana kertaluontoisen tiedon käyttämisessä on, että siihen palaaminen on vaikeaa,<br />
koska se on usein kirjattuna lyhyesti useisiin eri paikkoihin, esimerkiksi kokouksen<br />
sihteerin asialistan kulmaan tai sellaiseen pöytäkirjaan, jonka pohjana ollut asialista ei<br />
anna viitteitä siihen suuntaan, että kyseinen päätös löytyisi tämän kokouksen<br />
pöytäkirjasta. Siksi esimerkiksi tulevissa projekteissa on vaikeaa hyödyntää tietoa siitä,<br />
mitä päätettiin jostain tietystä asiasta. Projektikokouksissa syntyvä tieto on pääasiallisesti<br />
kertaluontoista, vaikka niissäkin saatetaan suunnitella tai laatia pysyviä ohjeita tai<br />
dokumentaatiota. Kertaluontoista tietoa syntyy koko projektin elinkaaren ajan, eniten<br />
kuitenkin toteutusvaiheessa, jossa päätöksiä tehdään eniten.<br />
Kuva 16. Pysyvän ja kertaluontoisen tiedon syntyminen projektin eri vaiheissa<br />
Taulukossa 6 projektikokouksissa syntyvät tietotyypit on jaettu kertaluonteiseen ja<br />
pysyvään tietoon. Taulukossa olevat tietotyypit ovat tulos työssä tehdystä dokumenttianalyysista.<br />
Lista ei välttämättä ole täysin kattava, mutta sisältää ainakin ne tietotyypit,<br />
joita projektipöytäkirjoissa säännöllisesti esiintyy.<br />
Jotkin taulukossa 6 esitetyistä tietotyypeistä ovat osittain päällekkäisiä. Tässä vaiheessa<br />
lista on kuitenkin esitetty mahdollisimman yksityiskohtaisena, jotta projektikokouksissa<br />
esiintyvistä tietotyypeistä saataisiin riittävän perusteellinen näkemys. Myöhemmin tässä<br />
työssä pohditaan vielä tietotyyppien yhdistämistä ja siten rakenteisen pöytäkirjadokumentin<br />
yksinkertaistamista.<br />
Päätös on yleisin projektikokouksissa syntyvä tietotyyppi. Useimpiin muihin tietotyyppeihin<br />
liittyy tiedon olemassaolon jossain vaiheessa päätös, esimerkiksi suunnitelman<br />
hyväksyminen tai aikatauluista päättäminen. Tästä seuraa myös se, että päätökseen liittyy
40<br />
lähes aina jokin toinen tietotyyppi. Päätökset voidaan useimmiten kohdistaa tietylle<br />
projektin ajanjaksolle, henkilölle, suunnittelualalle tai tuotteen osalle.<br />
Taulukko 6. Projektipöytäkirjoissa esiintyvät tietotyypit luokiteltuina pysyvään ja<br />
kertaluonteiseen tietoon<br />
Tietotyyppi Pysyvä<br />
tieto<br />
Kertaluonteinen<br />
tieto<br />
päätös<br />
X<br />
tehtävä<br />
X<br />
aikataulu X X<br />
suunnitelma X X<br />
selvitettävä asia<br />
X<br />
tilanne<br />
X<br />
hankinta X X<br />
valitus<br />
X<br />
muutos<br />
X<br />
tiedotus<br />
X<br />
yhteystiedot<br />
X<br />
esittely<br />
X<br />
ohje<br />
X<br />
tehdyn tarkastaminen<br />
X<br />
Tehtävät seuraavat useimmiten päätöksistä. Tehtävällä on aina yksi tai useampi vastuuhenkilö<br />
ja se voidaan kohdistaa tietylle projektin alueelle, esimerkiksi tuotteen osalle.<br />
Tehtävällä on myös aina aikataulu. Aikataulut eivät kuitenkaan liity pelkästään tehtäviin<br />
vaan lähes kaikella projektin toiminnalla on aikataulu. Aikataulun yksittäinen osa tai<br />
tehtävä on kertaluonteista tietoa, mutta aikataulua kokonaisuudessaan voidaan pitää<br />
pysyvänä tietona, sillä usein se on laadittu pidemmälle ajanjaksolle. Erilliset aikataulut<br />
kuten tietyn tehtävän aikataulu voidaan aina sijoittaa koko projektin aikatauluun ja ne<br />
myös laaditaan koko projektin aikataulun perusteella.<br />
Suunnitelmia syntyy eniten suunnittelu- tai asiantuntijakokouksissa. Esimerkkejä<br />
suunnitelmista ovat projektin seuraavan ajanjakson toimintasuunnitelma, viestintäsuunnitelma<br />
ja suunnitelma tietyn toimittajan käyttämisestä. Etenkin laajemmat suunnitelmat<br />
laaditaan yleensä ennen projektikokousta ja kokouksessa ainoastaan tehdään päätös, eli<br />
hyväksytään tai hylätään suunnitelma. Suunnitelmaan liittyy läheisesti selvitettävä asia,<br />
joka eroaa kuitenkin suunnitelmasta siten, että siihen liittyy selkeästi toiminta ja<br />
vastuuhenkilö. Suunnitelmasta seuraa usein selvitettävä asia. Jos esimerkiksi suunnitellaan<br />
käytettävän tiettyä toimittajaa, seuraa tästä usein, että täytyy selvittää toimittajan<br />
luotettavuus, hinta ja toimitusehdot. Selvitettävistä asioista päätetään projektikokouksissa<br />
ja varsinaiset selvitykset tapahtuvat niiden jälkeen. Selvitettävää asiaa voidaan myös pitää<br />
tehtävän erikoistapauksena, joskin selvitettävään asiaan liittyy aina se, että sen tuloksena<br />
on selvitys.
41<br />
Tilanne tarkoittaa projektin edistymistilannetta. Tilanteiden avulla toteutetaan projektin<br />
seuranta. Raportointi asiakkaalle perustuu myös usein juuri tilanteisiin. Tilanteen tärkeimmät<br />
alaryhmät ovat aikataulutilanne, työvoimatilanne, poikkeamat, ongelmat ja lähiajan<br />
tapahtumat projektissa /26/.<br />
Hankinnat seuraavat yleensä päätöksistä. Hankinnat voidaan kohdistaa tietylle projektin<br />
osalle ja yhteen osaan liittyvistä hankinnoista usein päätetään yhdellä kerralla, tai ainakin<br />
lyhyellä aikavälillä. Hankintoihin liittyy myös aikataulu ja vastuuhenkilö tai -osasto.<br />
Suurin osa hankintoihin liittyvistä keskusteluista tapahtuu kokouksissa hankinnoista<br />
vastaavien toimittajien kanssa, niihin liittyvissä suunnittelukokouksissa sekä erillisissä<br />
hankintakokouksissa.<br />
Valitus on usein asiakkaan taholta tuleva tietotyyppi, mutta myös sisäisiä valituksia voi<br />
tulla esille projektikokouksissa. Valitukset voivat liittyä esimerkiksi poikkeamiin tai<br />
ongelmiin projektin tilanteessa. Valitus tietotyyppinä on usein ongelmallinen, sillä sen<br />
syiden tai seurausten selvittäminen saattaa olla vaikeaa, koska esimerkiksi valitukseen<br />
johtaneet päätökset voivat olla hajanaisesti kirjattuina useisiin paikkoihin.<br />
Asiakkaalta tulevasta valituksesta saattaa olla seurauksena muutos, joskin muutokset<br />
voivat olla seurauksina monista muistakin asioista, esimerkiksi tehottomista työskentelytavoista.<br />
Muutoksella tarkoitetaan asiakkaan tai muun osapuolen esittämää muutosvaatimusta<br />
projektin tavoitteisiin, laajuuteen tai esimerkiksi työskentelytapoihin.<br />
Projektinhallinnan kannalta muutokset ovat usein ongelmallisia, koska pienestäkin<br />
muutoksesta projektin tavoitteisiin voi seurata kaikkien aikataulujen uusiminen, uuden<br />
projektihenkilöstön rekrytointitarve tai muita taloudellisia menetyksiä aiheuttavia tekijöitä.<br />
Tiedotus on usein lyhyt asia, joka halutaan kertoa tietylle projektin ryhmälle, koko<br />
projektille tai yksittäiselle henkilölle. Seuraavan kokouksen ajankohta on tyypillinen<br />
tiedotusasia, joka löytyy lähes jokaisesta projektipöytäkirjasta. Tiedotuksen eräs tyyppi<br />
on yhteystiedot, joita voidaankin pitää yhtenä tiedotuksen erikoistapauksena. Yhteystiedot<br />
ovat periaatteessa luonteeltaan pysyvämpää tietoa kuin muut tiedotukset, vaikka<br />
käytännössä nekin usein muuttuvat projektin aikana.<br />
Projektikokouksissa esittely tarkoittaa pääasiallisesti aloituskokouksissa tapahtuvaa organisaatiokaavioiden,<br />
aikataulujen, budjetin tai muuta vastaavaa esittelyä. Esittelyjä ovat<br />
myös toimittajien hinta- tai tuote-esittelyt sekä ratkaisuehdotukset projektin ongelmiin.<br />
Myös tilanne on eräänlainen esittely. Kokouspöytäkirjoissa tilanne ja esittely tietotyyppeinä<br />
eroavat toisistaan siten, että esittelyn kohde on useimmiten pöytäkirjan liitteenä kun<br />
taas tilanne on kirjattuna varsinaiseen pöytäkirjaan.<br />
Ohje syntyy useimmiten siten, että projektissa tehdään virheitä tai projektissa ilmenee<br />
ongelmia ja niiden seurauksena keksitään uusia hyviä toimintatapoja. Ohjeita voi toki
42<br />
syntyä muutenkin projektin työntekijöiden hyvinä ajatuksina. Ohjeita sinänsä ei laadita<br />
projektikokouksissa, mutta niiden sisältöä käsitellään ja niitä hyväksytään näissä kokouksissa.<br />
Siksi ohjeista usein jää kirjauksia pöytäkirjoihin.<br />
Tehdyn tarkastaminen liittyy aina tehtävään. Tehtävästä voidaan tarkistaa joko sen tila<br />
(tehty/tekemättä) tai tulokset, eli kuinka hyvin tehtävä onnistui tai mitä siitä seurasi.<br />
Projektipöytäkirjoissa tätä tietotyyppiä löytyy useimmiten kohdasta, jossa on käsitelty<br />
edellisen palaverin pöytäkirjaa.<br />
Taulukossa 7 on esitetty kootusti edellä olleiden tietotyyppien mahdolliset ominaisuudet.<br />
Kaikilla tietotyypeillä ei siis välttämättä ole kaikkia taulukossa esitettyjä ominaisuuksia.<br />
Taulukko 7. Tietotyypit ja niiden ominaisuudet<br />
Tietotyyppi Ominaisuudet<br />
päätös<br />
vastuuhenkilö tai -osasto, laite tai projektin alue, perustelu<br />
tehtävä<br />
vastuuhenkilö tai -osasto, aikataulu, laite tai projektin alue, tila<br />
aikataulu<br />
projektin alue<br />
suunnitelma aikataulu, laite tai projektin alue<br />
selvitettävä asia vastuuhenkilö tai -osasto, aikataulu, laite tai projektin alue<br />
tilanne<br />
projektin alue, osasto<br />
hankinta<br />
vastuuhenkilö tai -osasto, aikataulu, laite tai projektin alue<br />
valitus<br />
vastuuhenkilö tai -osasto, laite tai projektin alue, syy, toiminta<br />
muutos<br />
vastuuhenkilö tai -osasto, laite tai projektin alue, syy<br />
tiedotus<br />
kohderyhmä, kohde<br />
yhteystiedot kohderyhmä, kohde<br />
esittely<br />
projektin alue<br />
ohje<br />
osasto, laite tai projektin alue<br />
tehdyn tarkastaminen kohde
43<br />
6 ÄLYKKÄÄN PÖYTÄKIRJAN ESIMERKKITOTEUTUS<br />
6.1 Toteutuksen taustaa<br />
Projektien pöytäkirjat ovat nykyisessä muodossaan täysin järjestämättömiä tekstidokumentteja,<br />
joiden sisällöstä tietokoneet eivät voi päätellä mitään. Tietyn pöytäkirjassa<br />
olevan lauseen, kappaleen tai muun kokonaisuuden sisällöstä ei myöskään voida sanoa<br />
mitään lukematta sitä.<br />
Seuraavassa esiteltävä älykkään projektipöytäkirjan esimerkkitoteutus koostuu kolmesta<br />
osasta: rakenteinen pöytäkirjamalli, dokumentin rakennekuvaus (Document Type<br />
Definition, DTD) ja hakuohjelma. Rakenteinen pöytäkirjamalli on laadittu pöytäkirjoista<br />
tehdyn dokumenttianalyysin perusteella. Dokumentin rakennekuvaus taas noudattaa tätä<br />
rakenteista mallia. Työssä tehty hakuohjelma noudattaa myös laadittua rakenteista mallia,<br />
mutta soveltuu minkä tahansa tämän perusteella tehdyn DTD:n analysoinnin välineeksi.<br />
Toteutuksen lähtökohtana on ollut kohdassa 2.3 määritelty tarveanalyysi. Pohdittaessa<br />
toteutukseen liittyviä ratkaisuja, tarveanalyysin tuloksena saadut tarpeet on pyritty huomioimaan<br />
mahdollisimman monipuolisesti. Käytännössä tämä tarkoittaa sellaisen<br />
rakenteisen mallin luomista, että kaikki tarpeisiin liittyvät tärkeimmät tavoitteet pystytään<br />
mallin avulla toteuttamaan. Tarveanalyysin lisäksi on otettu huomioon projektiorganisaation<br />
rakenne eri kokoustyyppien muodossa ja erityisesti Jaakko Pöyry Oy:n<br />
osastojen, laitteiden ja projektien luokittelustandardit.<br />
6.2 Rakenteinen pöytäkirjamalli<br />
Kuvissa 17a ja 17b on esitetty kaksi vaihtoehtoista tapaa järjestää projektikokouksen<br />
pöytäkirja rakenteiseen muotoon. Kuvassa 17a dokumentit on järjestetty dokumenttityypin<br />
mukaisesti kun taas kuvassa 17b järjestämisen kriteerinä on projektin numero tai<br />
nimi. Mikäli kuitenkin halutaan kehittää järjestelmä, jossa on muitakin<br />
dokumenttityyppejä kuin pöytäkirjoja, ei dokumentteja voida luokitella projektien<br />
mukaisesti. Tämä johtuu pääasiassa siitä, että esimerkiksi ohje on dokumentti, jota<br />
käytetään useissa projekteissa eikä sitä siten voida sijoittaa minkään tietyn projektin alle.<br />
Esimerkkitoteutuksessa käytetään siis kuvan 17a mukaista mallia.<br />
Rakenteinen pöytäkirjamalli noudattelee XML:n (eXtensible Markup Language) rakennetta,<br />
joka koostuu elementeistä ja niille annettavista ominaisuuksista eli attribuuteista.<br />
Jokainen pöytäkirjan kokonaisuus, esimerkiksi lause tai kappale, edustaa jotakin<br />
tietotyyppiä, jotka tässä on määritelty elementeiksi. Tämän lisäksi jokaiselle elementille<br />
voidaan määritellä haluttu määrä ominaisuuksia eli attribuutteja, jotka toimivat hakuohjelman<br />
hakukriteereinä.<br />
Tarkastellaan kuvan 17a mukaista mallia tarkemmin taso kerrallaan. Pöytäkirja tarkoittaa<br />
sitä, että dokumentti on tyyppiä pöytäkirja. Muita dokumenttityyppejä ovat esimerkiksi
44<br />
ohje tai sopimus. Seuraavalla tasolla on projekti, jotka luokitellaan joko numeron tai<br />
nimen mukaisesti. Pöytäkirjoja toki syntyy muuallakin kuin projekteissa. Nämä pöytäkirjat<br />
on kuitenkin rajattu tämän työn ulkopuolelle. Kolmannella tasolla on kokoustyyppi,<br />
jossa pöytäkirja on syntynyt. Kokoustyypit määriteltiin kohdassa 5.2. Kokoustyyppi<br />
sinänsä ei muuten ole välttämätön taso, mutta se saattaa tarjota arvokasta lisätietoa<br />
kokouksen asialistasta, osanottajista sekä kokouksen valtuuksista. Neljännellä tasolla ovat<br />
tietotyypit, jotka määriteltiin kohdassa 5.4. Tietotyypeillä on edelleen ominaisuuksia,<br />
jotka sijoittuvat viidennelle sekä mahdollisesti tästä eteenpäin oleville tasoille.<br />
a<br />
Kuva 17. Rakenteinen projektipöytäkirjamalli a) dokumenttityypin mukaan<br />
luokiteltuna b) projektitunnisteen mukaan luokiteltuna<br />
b<br />
Kuvassa 18 on esitetty vielä yksi vaihtoehtoinen tapa järjestää pöytäkirja rakenteisesti.<br />
Rakenteen etu on, että sitä käyttämällä voitaisiin hakukriteerinä käyttää esimerkiksi<br />
tiettyä laitetta, osastoa tai muuta ominaisuutta, joka on tiedon kohdistamisessa usein<br />
tärkeämpi kriteeri kuin tietotyyppi. Tietotyyppi pelkästään kertoo sisällöstä hyvin vähän,<br />
kun taas tieto siitä, että jokin asia liittyy esimerkiksi venttiileihin, on paljon havainnollisempaa.<br />
Käytännössä kuitenkin näitä ominaisuuksia on niin paljon, että käyttämällä<br />
kuvan 18 mukaista rakennetta pelkkien tietotyyppien, esimerkiksi kaikkien tehtävien,<br />
haku olisi tehdyssä esimerkkitoteutuksessa hankalaa. Hakuja varten pitäisi silloin tietää<br />
kaikki ominaisuudet, joista jokaisesta erikseen haettaisiin esimerkiksi tehtävät.<br />
Hakuohjelman käyttöperiaatteet esitellään tarkemmin kohdassa 6.4.
45<br />
Kuva 18. Vaihtoehtoinen rakenteinen malli projektipöytäkirjalle<br />
Vaikka kuvan 18 mukainen malli ei sovellukaan tässä työssä tehtyyn esimerkkitoteutukseen,<br />
sen käyttöä kannattaa harkita mahdollisessa jatkokehityksessä. Käyttäjille saattaa<br />
nimittäin olla luontevampaa tehdä hakuja ominaisuuksien kuin tietotyyppien perusteella.<br />
6.3 DTD<br />
Jaakko Pöyry Oy:n tarpeisiin soveltuvan DTD:n laadinnassa on käytetty kohdassa 6.2<br />
(kuva 17a) esitettyä rakenteista pöytäkirjamallia sekä kohdassa 5.4 esiteltyjä tietotyyppejä.<br />
Käytännössä kaikkia määriteltyjä tietotyyppejä ei kuitenkaan tarvita eikä niitä<br />
ole järkevää ottaa toteutukseen mukaan, jotta se säilyisi tarpeeksi yksinkertaisena.<br />
Tehdyssä DTD:ssä käytetyt tietotyypit ominaisuuksineen on esitetty taulukossa 8.<br />
Taulukko 8. DTD:ssä käytetyt tietotyypit ja niiden ominaisuudet<br />
Tietotyyppi Ominaisuudet<br />
päätös alue, laitenumero, vastuuhenkilö tai osasto, perustelu<br />
tehtävä alue, laitenumero, vastuuhenkilö tai osasto, määräaika, tila<br />
tilanne alue, osasto<br />
valitus alue, laitenumero, kohde, syy, toiminta<br />
muutos alue, laitenumero, kohde, syy<br />
tiedotus alue, laitenumero, kohderyhmä<br />
yhteystiedot osapuoli<br />
esittely alue, laitenumero, kohde
46<br />
Kohdassa 5.4 esitellyistä tietotyypeistä on tehdyssä DTD:ssä jätetty pois aikataulu,<br />
suunnitelma, selvitettävä asia, hankinta, ohje ja tehdyn tarkastaminen. Aikataulua ei<br />
tarvita, koska se voidaan aina esittää tilanteena. Suunnitelma voidaan esittää joko esittelynä,<br />
tehtävänä tai tilanteena. Selvitettävä asia voidaan esittää tehtävänä, hankinta on<br />
päätös tai tehtävä ja tehdyn tarkastaminen on tilanne tai tehtävään liittyvä tila-ominaisuus.<br />
Ohjeita pöytäkirjoissa esiintyy hyvin vähän ja lisäksi ne useimmiten voidaan ilmaista<br />
valituksista seuraavina toimintoina. Myöskään kaikkia kohdassa 5.4 määriteltyjä<br />
ominaisuuksia ei ole mukana tehdyssä DTD:ssä. Mukaan on otettu ne ominaisuudet, jotka<br />
ovat oleellisia Jaakko Pöyry Oy:n kannalta.<br />
Tehty DTD on esitetty liitteessä 1. Taulukossa 9 on esitetty DTD:n elementit selityksineen.<br />
Liitteessä 2 on esitetty esimerkki XML-muotoisesta pöytäkirjasta, joka käyttää tätä<br />
DTD:tä. Pöytäkirja on todellisen projektikokouksen pöytäkirja, jota on hieman muunneltu<br />
tunnistamisen välttämiseksi.<br />
Taulukko 9. DTD:n elementit ja ominaisuudet<br />
Elementti Attribuutti Selitys<br />
announcement<br />
(tiedotus)<br />
area valinnainen Kustannusalue. Jaakko Pöyry Oy:ssä<br />
projektit jaetaan kustannusalueisiin.<br />
Kustannusalueet näkyvät tehdyssä<br />
DTD:ssä (liite 1).<br />
change<br />
(muutos)<br />
claim<br />
(valitus)<br />
partnumber valinnainen Osanumero. Kaikki projektin laitteet tai<br />
osat saavat tietyn osanumeron, jonka<br />
perusteella ne voidaan tunnistaa.<br />
target_group valinnainen Tiedotuksen kohderyhmä. Tyypillisiä<br />
kohderyhmiä ovat koko projekti,<br />
yksittäinen osasto tai henkilö.<br />
area valinnainen Kustannusalue<br />
partnumber valinnainen Osanumero<br />
target valinnainen Muutoksen kohde. Mikäli muutosta ei<br />
voida kohdistaa kustannusalueelle tai<br />
osalle, vaan se koskee esimerkiksi<br />
projektiorganisaatiota tai standardeja,<br />
käytetään target-attribuuttia.<br />
reason pakollinen Muutoksen syy. Muutoksen syy pitää<br />
aina kirjata, jotta muutoksia voidaan<br />
myöhemmin analysoida.<br />
action pakollinen Valituksesta seuraava toiminta.<br />
area valinnainen Kustannusalue<br />
partnumber valinnainen Osanumero<br />
target valinnainen Kohde<br />
reason pakollinen Valituksen syy
47<br />
contact_info<br />
(yhteystiedot)<br />
party pakollinen Osapuoli, jonka yhteystiedot ovat<br />
kyseessä.<br />
decision area valinnainen Kustannusalue<br />
(päätös) partnumber valinnainen Osanumero<br />
responsible valinnainen Päätöksestä vastaava henkilö tai osasto.<br />
reason valinnainen Päätöksen syy. Jos päätökseen liittyy<br />
selkeä syy tai perustelu, voidaan se<br />
kirjata attribuutiksi.<br />
introduction area valinnainen Kustannusalue<br />
(esittely) partnumber valinnainen Osanumero<br />
target valinnainen Muu kohde kuin alue tai osanumero<br />
meeting_minutes date pakollinen Kokouspäivämäärä<br />
(dokumentin place pakollinen Kokouspaikka<br />
tyyppi, present pakollinen Kokouksen osaanottajat<br />
juurielementti) distribution pakollinen Pöytäkirjan jakelu<br />
appendices valinnainen Liitteet. Liitteet ovat yleensä irrallinen<br />
osa itse pöytäkirjasta. Linkitystä tai<br />
muuta sijainnin ilmaisua varten ne<br />
voidaan ilmaista omalla attribuutilla.<br />
meeting_type<br />
(kokoustyyppi)<br />
type<br />
parties<br />
pakollinen<br />
pakollinen<br />
Kokoustyyppi. Kokoustyypit esiteltiin<br />
luvussa 5.2.<br />
Kokouksen osapuolet, eli siihen<br />
osallistuneiden yritysten nimet.<br />
project number pakollinen Jaakko Pöyry Oy:ssä jokaisella<br />
projektilla on numero, jolla projekti<br />
voidaan tunnistaa.<br />
status<br />
area valinnainen Kustannusalue<br />
(tilanne) department valinnainen Osasto tai muu vastuualue.<br />
task<br />
area valinnainen Kustannusalue<br />
deadline valinnainen Tehtävän määräaika<br />
partnumber valinnainen Osanumero<br />
responsible pakollinen Tehtävän vastuuhenkilö tai -osasto<br />
status pakollinen Tehtävän tila (tehty/ tekemättä)<br />
6.4 Hakuohjelma<br />
Tätä työtä varten tehty rakenteisille projektipöytäkirjoille tarkoitettu hakuohjelma on<br />
toteutettu Java-ohjelmointikielellä. Ohjelman UML (Unified Modelling Language)-<br />
luokkakaavio on esitetty kuvassa 19. Hakuohjelma tätä työtä varten on toteutettu itse<br />
kahdesta syystä. Ensinnäkin tällä hetkellä tarjolla olevat hakumahdollisuudet XMLdokumenteille<br />
eivät ole erityisen joustavia eikä niistä löytynyt tähän työhön soveltuvaa
48<br />
ratkaisua. Toiseksi nyt tehtyä hakuohjelmaa voidaan kehittää eteenpäin tai sillä voidaan<br />
myöhemmin tutkia muita mahdollisia rakenteita pienin muutoksin.<br />
Kuva 19. Hakuohjelman UML- luokkakaavio<br />
Ohjelma toimii siten, että MMinutesMain-luokka etsii hakemiston, jossa rakenteiset,<br />
XML-muotoiset, pöytäkirjadokumentit sijaitsevat. Hakemisto määritellään erilliseen<br />
tekstitiedostoon, josta sitä on helppo muuttaa tarvittaessa. Samaan tekstitiedostoon<br />
määritellään myös käytettävän DTD:n sijainti. MMinutesSearchEngine, joka on ohjelman<br />
tärkein luokka, kysyy tämän hakemiston polun ja jäsentää kaikki kyseisessä hakemistossa<br />
olevat XML-dokumentit. Jäsennyksessä käytetään sekä omia sisäisiä luokkia että<br />
Apachen Crimson-jäsennintä. Sisäisistä luokista MMinute edustaa yhtä yksittäistä pöytä-
49<br />
kirjaa. Yksi MMinute sisältää vaihtelevan määrän Element-olioita, jotka kuvaavat pöytäkirjan<br />
elementtejä.<br />
Työssä käytetty Crimson on Java XML-jäsennin, joka tukee XML v. 1.0:aa. Tällä hetkellä<br />
Crimson on yksi yleisimmin käytetyistä XML-jäsentimistä, joiden lähdekoodi on<br />
avoin. Crimson-jäsennin toteuttaa SAX 2.0 (Simple API for XML)-rajapinnat. SAX 2.0<br />
määrittää joukon rajapintoja, jotka määrittävät tapahtumapohjaisen XML-jäsentimen,<br />
tässä tapauksessa Crimson-jäsentimen, toiminnan. SAX 2.0 tukee myös muita ohjelmointikieliä<br />
kuin Javaa, esimerkiksi Perl- ja C++ -kieliä.<br />
MMinutesSearchEngine käynnistää SAX-jäsentimen ja jää kuuntelemaan sen lähettämiä<br />
tapahtumia. Jäsennin lähettää tapahtuman aina, kun se löytää jäsennettävästä dokumentista<br />
elementin tai attribuutin. Saadessaan SAX-jäsentimeltä tapahtuman, että juurielementti<br />
on löytynyt, MMinutesSearchEngine luo uuden MMinute-olion. Vastaavasti<br />
muista elementeistä luodaan Element-olioita. Luodut Element-oliot tallennetaan<br />
MMinute-luokan elements-vektoriin. Attribuutit tallennetaan Element-luokan attr-hajautustaulukkoon<br />
(hashtable) ja elementtien sisältö, eli haettava tieto, content-merkkijonoon<br />
(string). MyErrorHandler toteuttaa SAX- rajapintojen määrittämät pakolliset virheiden<br />
käsittelymetodit.<br />
MMinutesUI määrittää hakuohjelman käyttöliittymän. Ohjelman käyttöliittymä on esitetty<br />
kuvassa 20.<br />
Kuva 20. Esimerkkitoteutusta varten tehdyn ohjelman käyttöliittymä<br />
MMinutesUI kutsuu MMinutesSearchEngine-luokan search-metodia. Tämä metodi<br />
suorittaa määritellyt haut jäsennetyistä XML-dokumenteista ja palauttaa jokaisesta<br />
löydetystä hakutuloksesta MMinutesSearchEngineResult-olion. Nämä oliot sisältävät<br />
jokaisesta hakutuloksesta käyttöliittymässä määritellyt tiedot, eli kokouspäivämäärän,
50<br />
kokoustyypin, haetun elementin sisällön sekä tiedoston, josta kyseinen elementti löytyy.<br />
MMinutesUI myös määrittää käyttöliittymään sallitut elementit ja niiden attribuutit.<br />
Nämä on määritelty erillisessä, DTD:stä muodostetussa, XML-tiedostossa. Ohjelmalle<br />
voidaan siis antaa mikä tahansa DTD, josta on tehty XML-tiedosto. Esimerkki tällaisesta<br />
XML-tiedostosta on esitetty liitteessä 3. Kyseessä on kohdassa 6.3 esitellystä DTD:stä<br />
muodostettu XML-tiedosto.<br />
Ohjelmaa käytetään siten, että käyttäjä määrittää aluksi, mitä tietotyyppiä (elementti) hän<br />
tahtoo hakea. Tämän jälkeen käyttäjä valitsee tietotyypin ominaisuuden (attribuutti) ja<br />
kirjoittaa tekstikenttään ominaisuuden halutun hakuarvon. Ohjelman näyttämä hakutulos<br />
on esitetty kuvassa 21. Esimerkissä on haettu tehtäviä, joiden suorittamisesta vastaa<br />
Jaakko Pöyry Oy.<br />
Kuva 21. Esimerkkihaun tulos
Ohjelmalla voidaan myös hakea kaikkia tiettyyn elementtiin liittyviä attribuutteja<br />
valitsemalla attribuutin paikalle ALL. Tällöin hakutulokseksi saadaan esimerkiksi kaikki<br />
tehtävät. Lisäksi voidaan hakea kokouksia niiden päivämäärän, paikan tai läsnäolijoiden<br />
perusteella sekä muitakin elementtejä kuin tietotyyppejä sallitun DTD:n (taulukko 9)<br />
mukaisesti. Koska tehdyissä XML-dokumenteissa ainoastaan neljännen tason elementeillä<br />
(tietotyypit, kuva 17a) on varsinaista sisältöä, muunlaisista kuin tietotyyppeihin<br />
kohdistuvista hauista ei tulostu content-kenttään mitään. Sisältöhakuja ohjelma ei tee.<br />
51
52<br />
7 PROJEKTIPÖYTÄKIRJOJEN HYÖDYNTÄMINEN<br />
7.1 Yleistä<br />
Seuraavassa esitetään analyysi työssä laaditun tietorakenteen (kohta 6.2) soveltumisesta<br />
projektinhallinnan apuvälineeksi tehdyn esimerkkitoteutuksen avulla. Analyysi pohjautuu<br />
tarveanalyysin tuloksena määriteltyjen tarpeiden mukaisten käyttöskenaarioiden<br />
testaamiseen älykkään pöytäkirjan mahdollisilla käyttäjillä. Tutkimusmenetelmät on<br />
esitelty tarkemmin luvuissa 2.3 ja 2.4.<br />
Jokaisen tarpeen osalta esitellään ongelma, ratkaisu ongelmaan ja tulokset luvun 2.4<br />
mukaisista käyttäjätesteistä. Lisäksi jokaisen tarpeen kohdalla pohditaan muita<br />
mahdollisia käyttötarkoituksia tehdylle esimerkkisovelluksen mukaiselle rakenteiselle<br />
projektipöytäkirjadokumentille sekä sen pohjalle rakennettaville paremmille järjestelmille.<br />
7.2 Tiedon kohdistaminen<br />
7.2.1 Ongelma<br />
Nykyisissä Jaakko Pöyry Oy:n pöytäkirjojen arkistointikäytännöissä pöytäkirjat on<br />
jaoteltu kahden kriteerin, kokoustyypin ja kokouspäivämäärän, mukaisesti. Vaikka nämä<br />
ovat hyviä ja myös välttämättömiä kriteereitä, luokittelusta seuraa joukko ongelmia<br />
silloin, kun halutaan hakea tietoa useista pöytäkirjoista. Tarkastellaan esimerkkiä, jossa<br />
asiakas projektin loppupuolella tekee valituksen siitä, että paperikoneen venttiilit on<br />
säädetty väärin. Mikäli asia todella olisi näin ja säädöt täytyisi korjata, aiheutuisi tästä<br />
kenties suurtakin taloudellista vahinkoa, esimerkiksi työvoimakustannuksia. Jos asiasta<br />
tehtyjä päätöksiä joudutaan etsimään projektikokousten pöytäkirjoista, nykyisen<br />
arkistointikäytännön mukaan täytyy tietää kokoustyypit, joissa venttiilien säätöjä on<br />
käsitelty sekä ajankohta, jolloin kyseistä keskustelua on käyty. On myös mahdollista, että<br />
venttiilien säädöistä on keskusteltu useissa kokouksissa ja niistä on mahdollisesti tehty<br />
useita, toisilleen ristikkäisiä päätöksiä. Asiasta on myös mahdollisesti päätetty<br />
kokouksessa, jonka osallistujilla ei ollut kyseisiin päätöksiin edes valtuuksia ja<br />
mahdollisesti osa pöytäkirjoista löytyy ainoastaan kokousten osallistujilta, ei keskitetysti<br />
projektin sihteeriltä. Käytännössä tällaisessa tapauksessa jouduttaisiin siis käymään läpi<br />
kaikki projektin pöytäkirjat, joita voi projektin loppupuolella olla tuhansia. Olisi siis<br />
tärkeää saada helposti esille kaikki venttiilien säätöihin liittyvät päätökset, jotta valituksen<br />
aiheellisuus voidaan selvittää. Annetuilla kriteereillä se ei kuitenkaan ole mahdollista.<br />
Tiedon kohdistamismahdollisuuden puuttuminen on suurin ongelma, joka nykyisissä<br />
pöytäkirjakäytännöissä on. Jaakko Pöyry Oy:n asiakasprojektit ovat pääasiallisesti hyvin<br />
suuria projekteja, jotka kestävät usean vuoden ja joissa on hyvin paljon erilaisia<br />
sidosryhmiä. Tällaisen projektin aikana pidetään tuhansia kokouksia ja tehdään tuhansia<br />
pöytäkirjoja. Pöytäkirja dokumenttina on yksi tärkeimmistä tiedon välityksen kanavista.
53<br />
Projektin elinkaaren aikana myöhemmin mukaan tuleva osapuoli ei kuitenkaan välttämättä<br />
ole kiinnostunut kaikista pöytäkirjoista, vaan ainoastaan esimerkiksi venttiileihin<br />
liittyvistä asioista. Kuitenkin saadakseen kaiken venttiileihin liittyvän informaation,<br />
joutuu kyseinen osapuoli, kuten edellisessäkin esimerkissä, ainakin selaamaan läpi kaikki<br />
mahdolliset pöytäkirjat ja koska suurin osa informaatiosta luultavasti on hänen kannaltaan<br />
epäolennaista, saattaa myös olennainen informaatio jäädä huomiotta.<br />
Vastaavia esimerkkejä ongelmista voidaan löytää paljonkin. Kaikki tapaukset, joissa<br />
yksittäisistä tai pienestä joukosta pöytäkirjoja pitäisi löytää tarkkaan määriteltyä tietoa,<br />
kuuluvat tähän ryhmään.<br />
7.2.2 Ratkaisu ja tulokset<br />
Projektipöytäkirjojen rakenteisessa esimerkkitoteutuksessa tietoa haetaan nimenomaan<br />
kohdistamalla sitä tuloksena haluttuun tietotyyppiin (elementti) ja ominaisuuteen<br />
(attribuutti). Tilanteessa, jossa henkilö tarvitsee kaikki tietylle venttiilille kohdistuneet<br />
päätökset, hän valitsee elementiksi päätöksen ja attribuutiksi osanumeron, jonka jälkeen<br />
tekstikenttään voi syöttää haluamansa numeron tai osan siitä. Haku toimii vastaavalla<br />
tavalla muillakin tietotyypeillä.<br />
Hakuskenaarioina tiedon kohdistamista tutkittaessa käytettiin:<br />
• paperikoneeseen liittyvien päätösten haku,<br />
• kaikkien projektin osapuolten yhteystietojen haku ja<br />
• edellisessä kokouksissa läsnä olleiden henkilöiden selvittäminen.<br />
Testihenkilöt olivat yksimielisiä ja kokivat tehdyn ratkaisun "erittäin hyväksi". Mitään<br />
vastaavaa mahdollisuutta ei tällä hetkellä ole olemassa ja tiedon kohdistamismahdollisuuden<br />
koettiin olevan erittäin hyödyllinen projektinhallinnan työvälineenä.<br />
Hakutuloksena saatu tieto oli käyttäjien mielestä hyödyllistä ja oikeanlaista. Tiedon<br />
kohdistamistarkoitukseen tehty rakenne ei ollut liian yksityiskohtainen eikä liian<br />
yksinkertainen, vaan sillä voitiin hakea haluttuja asioita riittävällä tarkkuudella.<br />
Parannusehdotuksena käyttäjät toivoivat mahdollisuutta seurata tapahtumaketjuja. Esimerkkiratkaisussa<br />
ei ole mahdollista tutkia, onko esimerkiksi toimittajan tekemästä esittelystä<br />
seurannut hankintapäätös. Päätös (decision)- elementin syy (reason)- attribuuttia<br />
ehdotettiin siksi pakolliseksi. Lisäksi lopullista toteutusta varten toivottiin mahdollisuutta<br />
linkkien kautta seurata näitä tapahtumaketjuja.<br />
7.2.3 Muut mahdollisuudet<br />
Tiedon kohdistaminen on projektipöytäkirjan käyttömahdollisuus, jonka käyttöä voi harkita<br />
kaikissa projektin hallintaprosesseissa alkaen projektin eheyden ja laajuuden hallinnasta<br />
ja päättyen riskien ja muutosten hallintaan. Alla on esitetty muutamia esimerkkejä<br />
mahdollisuuksista niihin projektin hallintaprosesseihin liittyen, joita ei tarkastella<br />
erikseen.
54<br />
• Eheyden hallinta: Projektisuunnitelman laadinnassa voidaan käyttää edellisten<br />
projektien pöytäkirjoja ja hakea niistä projektisuunnitelman kohtiin liittyvää<br />
tietoa. Esimerkki tällaisesta käytöstä on aikaisemman projektiorganisaation<br />
esittelyn haku tai edellisen projektin tilanteiden yhdistäminen yhdeksi kokonaisuudeksi<br />
aikataulujen laatimista varten.<br />
• Laajuuden hallinta: Projektin tuotteeseen projektin aikana tulevat muutokset<br />
kirjataan aina pöytäkirjoihin. Laajuuden hallinnassa voidaan sopivia hakuja<br />
tekemällä selvittää muutosten aiheellisuus esimerkiksi hakemalla muutoksen<br />
kohteesta aikaisemmin sovittuja asioita, kuten päätöksiä ja tehtäviä.<br />
• Aikataulujen hallinta: Projektin pääaikataulu koostuu useista pienemmistä<br />
aikatauluista. Jos rakenteisesta pöytäkirjasta hakee tilanteita tai tehtyjä tehtäviä,<br />
niitä voidaan verrata projektin aikatauluihin ja käyttää apuna aikataulujen<br />
hallinnassa.<br />
• Kustannusten hallinta: Pöytäkirjoista voidaan hakea tehtäviä tai päätöksiä, jotka<br />
liittyvät hankintoihin. Lisäksi voidaan hakea toimittajien tekemiä esittelyjä. Myös<br />
aikatauluihin liittyvät haut koskevat läheisesti kustannusten hallintaa.<br />
• Laadun hallinta: Koska laadun hallinta on prosessi, joka ulottuu kaikkeen<br />
projektin työhön ja kaikkiin projektin hallintaprosesseihin, voidaan minkä tahansa<br />
haun, joka helpottaa projektin läpivientiä, ajatella olevan osa laadun hallintaa.<br />
• Hankintojen ja laitteistoresurssien hallinta: Projektikokouksissa käsitellään<br />
projektissa käytettäviä laitteita. Näiden hankinnoista ja ylläpidosta päätettäessä<br />
voidaan tutkia, mitä niistä on aikaisemmin päätetty.<br />
Projektipöytäkirjaa voidaan myös käyttää projektin hallinnan lisäksi esimerkiksi sen<br />
seuraamiseen tai siitä raportointiin. Esimerkiksi voidaan kohdistaa hakuja eri päivämäärille,<br />
jolloin projektipöytäkirjaa voidaan ajatella käytettävän projektin elinkaaren<br />
seuraamisen välineenä.<br />
7.3 Henkilöstön ja tehtävien hallinta<br />
7.3.1 Ongelma<br />
Projektikokouksissa tehtyjen päätösten seurauksena syntyy tehtäviä. Pöytäkirjat toimivat<br />
näiden tehtävien jakelukanavina. Usein kokouksissa päätetään myös tehtävistä sellaisille<br />
henkilöille, jotka eivät itse ole läsnä kokouksessa. Osa kokouksissa päätetyistä tehtävistä<br />
jää toisinaan ilman vastuuhenkilöä, joko erehdyksen vuoksi tai sen vuoksi, ettei tehtävää<br />
pystytä kokouksessa kohdistamaan kellekään henkilölle työtilanneinformaation puuttuessa.<br />
Jaakko Pöyry Oy:n nykyiseen pöytäkirjakäytäntöön kuuluu merkitä erilliseen sarakkeeseen<br />
pöytäkirjan oikeaan reunaan tehtävien vastuuhenkilöiden nimikirjaimet. Näin<br />
pyritään siihen, että vilkaisemalla pöytäkirjaa nopeasti, voi saada yleiskuvan siitä, onko<br />
omalle kohdalle merkitty tehtäviä. Ratkaisu ei kuitenkaan toimi silloin, kun vastuuhenkilö
55<br />
on jätetty merkitsemättä. Monesti myös vastuuhenkilön tilalle merkitään ainoastaan<br />
vastuuyrityksen nimi, jolloin tehtävien koordinointi jää sitä hoitavan henkilön, tyypillisesti<br />
projektipäällikön, vastuulle. Ongelmatilanne syntyy myös, jos vastuu on annettu<br />
henkilölle, joka ei ollut kokouksessa ja joka ei siis automaattisesti jakelun mukaan saa<br />
pöytäkirjaa. Tehtävä voi siis jäädä hoitamatta, jos kokouksessa tai muiden käytäntöjen<br />
mukaan ei ole määritelty, kenen pitää tehtävistä tiedottaa.<br />
Tehtävien hallinnassa on niiden jakamisen lisäksi toinen ongelma. Luettaessa tehtäviä<br />
vanhasta pöytäkirjasta ei voida tietää, onko tehtävä tehty tai mahdollisesti tekemättä.<br />
Käytännössä edelliseen pöytäkirjaan kirjattujen tehtävien tila tarkistetaan seuraavassa<br />
kokouksessa kohdassa edellinen pöytäkirja, mutta tämän jälkeen niihin ei enää palata<br />
riippumatta siitä, oliko tehtävä tehty. Asiakkaan valittaessa esimerkiksi, että sovittuihin<br />
muutoksiin liittyviä töitä ei ole tehty, voidaan kyllä tarkistaa onko kyseisistä tehtävistä<br />
sovittu, mutta ei sitä, onko niitä todella tehty.<br />
7.3.2 Ratkaisu ja tulokset<br />
Rakenteisessa projektipöytäkirjassa tehtävällä on oma elementti (task). Tällä elementille<br />
voidaan antaa attribuutit vastuuhenkilö, määräaika, osanumero, kustannusalue ja tila.<br />
Näistä pakollisia ovat vastuuhenkilö (tai osasto, yritys) sekä tila. Pöytäkirjaa laadittaessa<br />
kaikkien tehtävien tila on oletusarvoisesti tekemättä. Jälkeenpäin tila korjataan tehdyksi.<br />
Esimerkkisovelluksessa korjaus täytyy tehdä manuaalisesti XML-tiedostoihin, mutta<br />
lopullisessa järjestelmässä korjaaminen voidaan automatisoida esimerkiksi sähkö-postilla<br />
tehtäväksi automaattiseksi toiminnoksi.<br />
Skenaarioina henkilöstöresurssien ja tehtävien hallintaa analysoitaessa käytettiin seuraavia<br />
hakuja:<br />
• kaikkien tehtävien hakua, joista testihenkilö itse oli tai oli ollut vastuussa,<br />
• kaikkien tekemättömien tehtävien hakua,<br />
• kaikkien paperikoneeseen liittyvien tehtävien hakua ja<br />
• kaikkien niiden tehtävien hakua, joille ei ollut määritetty vastuuhenkilöä.<br />
Testihenkilöt kokivat yksimielisesti tehdyn ratkaisun "melko hyödylliseksi". Tulos<br />
selittyy osittain sillä, että tehtävien hallintaan on jo olemassa oma pöytäkirjakäytäntönsä,<br />
joka puutteistaan huolimatta on ollut käytössä toimiva. "Erittäin hyödylliseksi" koettiin<br />
mahdollisuus hakea tekemättömiä tehtäviä. Viimeisen skenaarion toteuttaminen oli<br />
hankalampaa, sillä esimerkkisovelluksella ei voi hakea siten, että se hakisi elementtejä,<br />
joilta puuttuu tietty attribuutti. Skenaarion toteutus hoidettiin siten, että haettiin aluksi<br />
kaikki tehtävät ja sen jälkeen haettiin kaikki tehtävät, joilla oli responsible-attribuutti.<br />
Näitä kahta listaa vertaamalla saatiin kaikki tehtävät, joilla ei ollut vastuuhenkilöä.<br />
Parannusehdotuksena testihenkilöt toivoivat mahdollisuutta nähdä tehtävistä myös päivämäärän,<br />
jolloin se oli tehty. Esimerkkisovellus ei sisällä tällaista tietoa. Myös tehtävien
56<br />
kohdalle kaivattiin tapahtumaketjuja. Esimerkiksi haluttiin tietää, mistä päätöksestä jokin<br />
tehtävä oli seurannut.<br />
7.3.3 Muut mahdollisuudet<br />
Tehtävien hallintaa varten rakenteisesta pöytäkirjasta voidaan muodostaa tehtävälistoja,<br />
joita projektipäälliköt tai muut tehtävien koordinoinnista vastaavat henkilöt voisivat<br />
käyttää apuna projektin seuraavaa ajanjaksoa suunniteltaessa. Listoista nähtäisiin kunkin<br />
projektityöntekijän tehtäväkuormitus sekä se, millaisia tehtäviä kullekin työntekijälle on<br />
annettu. Lisäksi tehtävien suoritusajoista voidaan saada apua aikataulujen laatimiseen, jos<br />
suorituspäivämäärä on kirjattu ylös.<br />
Samanlaisia tehtävälistoja voi jokainen työntekijä laatia itselleen. Lista voisi esimerkiksi<br />
olla standardoitu sen muotoiseksi, että siinä on nappi, jota painamalla lähtee tieto järjestelmälle,<br />
että tehtävä on tehty. Järjestelmä osaisi tämän perusteella muuttaa tehtävän<br />
tilaksi tehty ja kirjata suorituspäivämäärän.<br />
Tehtävien merkitsemisestä tehdyiksi seuraa kuitenkin yksi ongelma. Pöytäkirja on dokumentti,<br />
jota ei sen hyväksymisen jälkeen saisi muuttaa. Joko kokousosapuolten on sovittava<br />
siitä, että tehtävien tiloja saa muuttaa myös pöytäkirjan hyväksymisenkin jälkeen tai<br />
tehtävän tilan hallinta on toteutettava jollain muulla tapaa. Yksi vaihtoehto tähän on<br />
kaikkien avoimien tehtävien kuljettaminen mukana pöytäkirjoissa niin kauan, kunnes ne<br />
on tehty. Kaikille tehtäville olisi myös hyvä määrittää jokin yksiselitteinen tunniste,<br />
esimerkiksi tehtävänumero, jotta voitaisiin paremmin nähdä, liittyykö johonkin tehtävään<br />
useita päätöksiä tai työmääräyksiä. Kaksi eri henkilöä voivat kirjoittaa tehtävän ylös niin<br />
eri tavoin, etteivät kaikki ymmärrä kyseessä olevan sama tehtävä. Tunnisteen avulla<br />
pystyttäisiin aina tietämään varmasti, mikä tehtävä on kyseessä.<br />
Tehtävien jakamisongelmaan voidaan ottaa avuksi sähköposti. Järjestelmä voisi olla<br />
sellainen, että se automaattisesti osaisi yhdistää tehtävän saaneen henkilön ja tämän<br />
sähköpostiosoitteen. Kun henkilölle määrätään tehtävä, järjestelmä lähettää automaattisesti<br />
sähköpostia tehtävän saaneelle henkilölle. Vaihtoehtoisesti sähköpostijärjestelmä voi<br />
olla vapaaehtoinen siten, että sen käyttäjäksi voivat rekisteröityä sellaiset henkilöt, jotka<br />
eivät halua itse hakea heille määrättyjä tehtäviä joka kokouksen jälkeen. Ne taas, jotka<br />
eivät halua sähköpostia, voivat käyttää hakukonetta.<br />
7.4 Projekteista oppiminen<br />
7.4.1 Ongelma<br />
Projekteissa tehdään paljon virheitä ja niitä sekä korjaavia toimenpiteitä käsitellään<br />
projektikokouksissa. Tällöin syntyy usein paljon hyviä ideoita virheiden ennaltaehkäisemistä<br />
ajatellen, jotka kuitenkaan eivät ole millään tavoin muiden projektien<br />
käytettävissä. Käytännössä siis kaikissa projekteissa saatetaan tehdä samat virheet, koska
57<br />
vaatisi melkoisesti aktiivisuutta muutenkin kiireiseltä projektipäälliköltä tutkia muiden<br />
projektien pöytäkirjoja oppimismielessä.<br />
Myös kaikki projektin laajuuteen liittyvät muutokset kuuluvat sellaiseen informaatioon,<br />
jota tarvittaisiin projektin jälkeen. Suuri osa näistä muutoksista toki kirjataan muuallekin<br />
kuin pöytäkirjoihin, mutta esimerkiksi muutosten todelliset syyt saattavat jäädä huomiotta,<br />
jos pöytäkirjoissa oleva informaatio ei ole käytettävissä. Muutosten hallintaan liittyviin<br />
asioihin palataan kohdassa 7.6.<br />
Valitukset, sekä aiheelliset että aiheettomat, ovat informaatiota, jota tarvitaan projektin<br />
jälkeen. Valituksiin liittyvät virheet tai muut syyt pyritään seuraavissa projekteissa ennaltaehkäisemään.<br />
Suurin osa valituksista käsitellään projektikokouksissa ja myös niihin<br />
liittyvistä toiminnoista ja tehtävistä sovitaan. Muiden projektien riskien hallintaa ajatellen<br />
tällainen informaatio olisi erittäin tärkeää.<br />
Projekteista voidaan oppia muutenkin kuin virheistä ja valituksista. Kaikki projekteissa<br />
tehdyt ratkaisut ja päätökset vaikuttavat projektin kulkuun. Projektin jälkeen voidaan<br />
esimerkiksi tarkistaa kuinka venttiilit oli säädetty ja kun muistetaan, että kyseessä oli<br />
onnistunut projekti, tietoa voidaan käyttää seuraavassakin projektissa. Iso osa projekteissa<br />
tehtävistä päätöksistä onkin juuri sellaisia, jotka ovat sellaisenaan sovellettavissa kaikissa<br />
vastaavissa projekteissa ja käytännössä samoista asioista on aivan turhaa päättää useaan<br />
kertaan. Tällaiset päätökset ovat usein hiljaista tietoa kokeneella projektiorganisaatiolla,<br />
mutta uusilla projektityöntekijöillä tätä tietämystä ei vielä ole. Jos kuitenkin tämä informaatio<br />
on helposti saatavilla, voidaan kokousten asialistat jo laatia siten, että niissä on<br />
liitteenä ehdotus, joka vastaa edellisessä projektissa käsiteltyjä vastaavia asioita, mikä<br />
taas tehostaa myös kokouskäytäntöjä.<br />
7.4.2 Ratkaisu ja tulokset<br />
Projekteista oppimista varten tehdyt ratkaisut ovat osittain samoja kuin kohdassa 7.2.2<br />
esitellyt tiedon kohdistamisratkaisut. Päätöksillä on oma elementti (decision), jolle voi<br />
määrittää attribuutiksi kustannusalueen, osanumeron, vastaavan tahon sekä syyn. Erityisesti<br />
syy (reason)- attribuutti on projekteista oppimisen kannalta tärkeä. Esimerkiksi jos<br />
paperitehtaan seinät on maalattu siniseksi, voi tähän olla syynä viranomaisten rakennuslupamääräys<br />
tai se, että asiakas ei pidä vihreästä. Projektista oppimisen kannalta on<br />
tärkeää tietää kummasta on kyse, jotta tiedetään, oliko se projekti- tai asiakaskohtainen<br />
ratkaisu vai ratkaisu, jota täytyy soveltaa tulevaisuudessakin kyseiselle alueelle rakennettaessa.<br />
Valituksista ja muutoksista oppimista varten on omat valitus (claim)- ja muutos (change)-<br />
attribuutit. Näille syy- attribuutti on pakollinen. Lisäksi valitukseen liittyy toiminta<br />
(action)- attribuutti. Myös tämä on pakollinen, joten käytännössä sen arvoksi on kirjattava<br />
ainakin, ettei tehty mitään, mikä on oppimisen kannalta myös arvokas tieto. Mikäli
58<br />
osapuolet suostuvat siihen, että pöytäkirjoja muutetaan jälkeenpäin, sen arvoa voi käydä<br />
muuttamassa, kun jotain tehdään.<br />
Skenaarioina projekteista oppimista tutkittaessa käytettiin:<br />
• kaikkien projektista tehtyjen valitusten hakua,<br />
• kaikkien paperikoneesta päätettyjen asioiden hakua ja niiden syiden selvittämistä<br />
sekä<br />
• kaikkien projektiorganisaatioon liittyvien muutosten hakua.<br />
Testihenkilöt kokivat ratkaisun antamien tulosten olevan "erittäin hyödyllisiä". Erityisesti<br />
mahdollisuus katsoa syitä päätösten, valitusten ja muutosten taustalla koettiin hyväksi.<br />
Esimerkkitoteutuksessa syyt käytännössä piti etsiä hakuohjelman ilmoittamista tiedostoista,<br />
sillä ohjelmassa ei ole toiminnallisuutta, joka tulostaisi syyt näkyviin. Lopulliseen<br />
järjestelmään voidaan kuitenkin rakentaa mahdollisuus myös syiden tulostamiseen. Tämä<br />
oli myös testihenkilöiden ehdottama parannusidea.<br />
7.4.3 Muut mahdollisuudet<br />
Jos käytössä on usean projektin rakenteiset pöytäkirjat, järjestelmän avulla on helppoa<br />
koota tilastoa projekteissa esiintyneistä valituksista. Näitä tilastoja voidaan kohdistaa eri<br />
tuotteille, toiminnoille tai osastoille ja käyttää kokonaisten prosessien parantamiseen.<br />
Tilastojen avulla voidaan siis selvittää projektien selkeitä ongelmakohtia ja käyttää siten<br />
projektien laadun parantamisessa ja laadunvalvonnassa.<br />
Myös projektien valituksista ja muutoksista rakennetut tilastolliset jakaumat ovat<br />
projektin riskinhallinnan kannalta hyödyllisiä. Tulevissa projekteissa niitä voidaan<br />
käyttää riskien tunnistamiseen ja ennaltaehkäisyyn. Kohdassa 7.6 on käsitelty enemmän<br />
muutosten hallintaan liittyvää pöytäkirjojen käyttöä.<br />
Tavallisia päätöksiä projekteista oppimistarkoitukseen voi käyttää esimerkiksi laatimalla<br />
kaikista useimmissa projekteissa olevista tavallisista osista omia elinkaaria ja käyttää<br />
näitä seuraavien projektien kokouksissa pohjatietona. Tällaisia elinkaaria, jotka sisältävät<br />
siis kaikki kyseiseen osaan liittyvät päätökset ja muut oleelliset tietotyypit, voidaan myös<br />
käyttää projektiohjeiden laatimisen ja parantamisen perustana. Esimerkiksi jos paperikoneen<br />
elinkaaren aikana siitä tehdään muutamia tarjousesittelyjä, hankintapäätös, tuhat<br />
tavallista päätöstä ja valmistumispäätös, saadaan kyseiset päätökset lukemalla varsin<br />
selkeä kuva paperikoneen rakentamisen elinkaaresta. Lisäksi voidaan liittää elinkaareen<br />
kaikki paperikoneeseen liittyvät tehtävät.<br />
Koska pitkät merkkijonot tai jopa lauseet tietoelementtien attribuutteina heikentävät itse<br />
dokumentin luettavuutta, syy- ja toiminta-attribuuteille voitaisiin myös määrittää jonkinlaiset<br />
numero- tai nimitunnisteet. Tällöin ei tarvitsisi kirjoittaa koko syytä tai toimintaa<br />
itse dokumenttiin. Esimerkiksi syy voitaisiin kirjoittaa erilliseen tekstitiedostoon, jonka<br />
nimi annetaan syy-attribuutiksi. Järjestelmän tehtävänä olisi tällöin hakea tiedoston sisältö
59<br />
niin haluttaessa. Tämä on kuitenkin lähinnä ulkonäköseikka, jolla ei käytännössä ole<br />
oleellista merkitystä. Tarkoituksena ei nimittäin ole, että kukaan järjestelmän käyttäjä<br />
lukisi XML-dokumentteja sellaisinaan.<br />
7.5 Projektin tilanteen seuraaminen<br />
7.5.1 Ongelma<br />
Projektikokoukset ovat pääasiallinen kanava projektin tilanteesta raportoimiseksi ulkoisille<br />
tahoille, esimerkiksi asiakkaalle. Tätä tarkoitusta varten projektin seurantakokousten<br />
asialistoissa on erikseen kohta, jossa käsitellään projektin sen hetkistä tilannetta.<br />
Samoissa kokouksissa käsitellään kuitenkin myös projektin pienempien osien tilanteita,<br />
joita kuitenkaan ei kirjata mitenkään keskitetysti mihinkään, vaan informaatiota näistä<br />
tilanteista löytyy useista paikoista. Myös eri osapuolien kanssa käsitellään erilaista<br />
tilanneinformaatiota.<br />
Projekteissa täytyy kuitenkin laatia tilanneraportteja esimerkiksi yrityksen ylimmälle<br />
johdolle sekä myös asiakkaalle. Informaatio näitä raportteja varten kerätään useista<br />
kokouksista, esimerkiksi työryhmien viikkopalavereista ja jopa työmaapalavereista.<br />
Käytäntö on ongelmallinen, koska se vaatii monien pöytäkirjojen lukemista tilanneraporttia<br />
laadittaessa, tilannetietojen kohdistamista oikealla projektin osalle sekä oletusta siitä,<br />
että kaikki informaatio löytyy pöytäkirjoista.<br />
7.5.2 Ratkaisu ja tulokset<br />
Rakenteisessa pöytäkirjassa tilanteella on oma elementti (status). Koska tilanneraportit<br />
laaditaan pääasiallisesti kustannusalueittain tai osastoittain, tilanne-elementin attribuuttina<br />
ovat juuri kustannusalue (area) ja osasto (department). Käytännössä osastoksi voidaan<br />
myös määritellä koko projekti, jolloin saadaan koko projektia koskevat tilannetiedot.<br />
Kaikki tilannetiedot taas saadaan määrittämällä attribuutiksi ALL.<br />
Testihenkilöille annettiin kaksi skenaariota, jotka olivat<br />
• projektin tilanteen tämänhetkinen selvittäminen sekä<br />
• jonkin kustannusalueen tämänhetkisen tilanteen selvittäminen<br />
Oletuksena skenaarioissa oli lisäksi, että kyseinen projekti oli vielä käynnissä ja pöytäkirja,<br />
jossa oli uusin päivämäärä, oli tämänhetkinen tilanne.<br />
Testihenkilöt kokivat saadun tiedon "jonkin verran hyödylliseksi". Tulokseen vaikutti<br />
suuresti se, että käytetyissä pöytäkirjoissa oli melko vähän muuta tilannetietoa kuin koko<br />
projektiin liittyvää. Toinen tulokseen vaikuttava seikka oli, että testihenkilöt ovat<br />
tottuneet selaamaan tilannetietoa etsiessään pöytäkirjoja, koska se kuitenkin on ollut<br />
esitettynä selkeästi omassa kohdassaan. Lisäksi tilannetieto pelkästään koettiin melko<br />
irralliseksi. Esimerkiksi lause "75 % of piles has been driven, casting of slab proceeding<br />
in 3 fronts" liitteessä 2, jonka saa siis hakutuloksena valitsemalla elementiksi tilanteen ja<br />
osastoksi koko projektin, irroitettuna asiakokonaisuudesta koettiin hyvin mitäänsanomat-
60<br />
tomana. Asiakokonaisuudella tarkoitetaan tässä koko pöytäkirjaa ja siinä erityisesti<br />
kohtaa projektin tilanne.<br />
Tilanteisiin liittyvien hakujen kohdalla täytyykin siis miettiä hakutulosten esittämismuotoa.<br />
Nykyinen ohjelma tulostaa päivämäärän, johon tilanne liittyy, mutta pelkkä<br />
päivämäärä ei tehtyjen testien mukaan riittänyt. Tulokseen voitaisiin harkita tulostettavan<br />
esimerkiksi kokouksen osapuolet tai muuta tietoa, joka auttaisi ohjelman käyttäjää hahmottamaan<br />
kokonaisuuden paremmin. Toinen asia, joka käyttäjätesteissä tuli ilmi, oli<br />
tilannetietojen huono esitysmuoto projektipöytäkirjoissa. Tämä asia ei varsinaisesti liity<br />
tämän työn aiheeseen, mutta käyttäjät ilmaisivat toivomuksensa pöytäkirjoja laativille<br />
henkilöille, että tilannetieto kirjattaisiin dokumentteihin hiukan yksityiskohtaisemmin.<br />
Parempi kirjaamistapa saattaisi myös auttaa edellä esitetyn hahmottamisongelman ratkaisemiseen.<br />
7.5.3 Muut mahdollisuudet<br />
Mikäli pöytäkirjoihin kirjoitettaisiin yksityiskohtaisempaa tilannetietoa, tilanneraporttien<br />
laatiminen voitaisiin osittain automatisoida. Laatiminen voisi silloin tapahtua hakemalla<br />
kaikki tilannetieto raportin aiheen mukaisilla attribuuteilla ja ohjelma voisi tulostaa<br />
valmiin pohjan mukaisen raportin. Tähän automaattiseen raporttiin voisi sitten lisätä<br />
kohtia tai siitä voitaisiin poistaa niitä halutulla tavalla. Tällainen automaattinen tilanneraporttien<br />
laatiminen vaatisi kuitenkin, että pöytäkirjoihin osattaisiin kirjata asiat oikeassa<br />
muodossa.<br />
Toinen mahdollinen käyttö on tilanteiden vertaaminen projektin aikatauluihin ja budjettiin.<br />
Pöytäkirjaan on kyllä useimmiten kirjattu, jos projektin jokin osa on myöhässä, mutta<br />
ei esimerkiksi sitä, jos se on etuajassa ja koko projektin suorittamista voitaisiinkin<br />
nopeuttaa. Hakemalla pöytäkirjoista tilannetietoa, voidaan tätä verrata projektin aikatauluun<br />
ja budjettiin ja siten pöytäkirjaa voidaan käyttää apuna projektinhallintaan liittyvien<br />
tunnuslukujen laskemisessa. Tällaisia tunnuslukuja ovat esimerkiksi tuloksen arvo<br />
(earned value), aikatauluero (schedule variance) tai tuloksen kustannukset (actual cost for<br />
work performed). Lisätietoa näistä projektin kustannusten hallintaan liittyvistä tunnusluvuista<br />
löytyy esimerkiksi lähteistä /26, 30/.<br />
7.6 Muutosten hallinta<br />
7.6.1 Ongelma<br />
Muutosten hallinnan ongelmat liittyvät osittain luvussa 7.4 esittyihin projektista<br />
oppimisen ongelmiin. Muutokset ovat kuitenkin ongelmallisia jo projektin aikana. Aivan<br />
projektin alussa tehdyt muutokset eivät ole yhtä ongelmallisia kuin projektin elinkaaren<br />
myöhemmissä vaiheissa tehdyt ovat. Muutokset projektin laajuuteen voivat seurata<br />
esimerkiksi virheellisestä työstä tai suunnittelusta, mutta myös asiakkaan tarpeiden<br />
muuttumisesta tai siitä, että huomataan tietynlaisen toteutuksen olevan mahdoton tai
61<br />
huono. Koska muutokset usein seuraavat valituksista, myös valitukset liittyvät muutosten<br />
hallintaan.<br />
Mikäli asiakas vaatii muutosta valituksen seurauksena, projektipöytäkirjoja tarvitaan<br />
siihen, että etsitään valituksen aiheellisuuden syytä. Kuten jo kohdassa 7.2.1 todettiin,<br />
näitä pöytäkirjoja voi olla tuhansia ja käytännössä ne kaikki joudutaan silloin ainakin<br />
selaamaan läpi. Myös tehdyt muutokset ovat ongelma: jos tehty muutos ei tuotakaan<br />
haluttua tulosta, saattaa seurauksena olla, että muutettu asia joudutaan muuttamaan<br />
takaisin ja kustannukset tästä pitäisi pyrkiä kohdistamaan sille osapuolelle, joka muutosta<br />
on vaatinut. Jos tätä ei ole missään virallisessa sopimuksessa määritelty, seuraava lähde,<br />
mistä asiaa tutkitaan, ovat projektin pöytäkirjat.<br />
Muutokset projektin laajuudessa vaikuttavat myös suuresti projektin aikatauluun ja<br />
budjettiin. Projektin aikana näitä vaikutuksia on kuitenkin vaikeaa tutkia, sillä käytössä ei<br />
varsinaisesti ole mitään systeemiä, versionumeroinnin lisäksi, jolla tietty laajuuden<br />
muutos voitaisiin yhdistää tiettyihin aikataulu- tai budjettimuutoksiin. Sama pätee myös<br />
muihin suuntiin.<br />
7.6.2 Ratkaisu ja tulokset<br />
Esimerkkitoteutuksessa muutoksella on oma change-elementti. Lisäksi valituksella on<br />
elementti claim. Näillä molemmilla on pakolliset syy-attribuutit, jonka lisäksi ne voidaan<br />
kohdistaa muillekin ominaisuuksille (taulukot 8 ja 9). Valituksen toiminta-attribuutin<br />
arvoksi voidaan antaa sama, kuin siitä seuraavan muutoksen syyksi. Tällöin voidaan<br />
yhdistää toisiinsa valitus ja muutos. Myös muutos-elementin sisältö voidaan antaa<br />
valituksen toiminta-attribuutin arvoksi.<br />
Käytetyt hakuskenaariot olivat<br />
• kaikkien paperikonetta koskevien muutosten haku ja syiden selvittäminen sekä<br />
• valituksista seuranneiden muutosten hakeminen<br />
Ensimmäisestä skenaariosta saadut tulokset koettiin "erittäin hyödyllisiksi". Toisen skenaarion<br />
toteuttaminen oli kommenttien mukaan hiukan hankalampaa: aluksi piti hakea<br />
valituksia ja niiden toiminta-attribuuttien arvojen perusteella muutoksia. Saatuja tuloksia<br />
pidettiin myös "erittäin hyödyllisinä" ja niiden katsottiin olevan hyvä apuväline projektin<br />
budjetin, aikataulun ja laajuuden yhdistämisessä siten, että valituksen päivämäärää ja<br />
muutoksen päivämäärää voidaan verrata aikatauluihin ja budjettiin ja niissä tehtyjen<br />
muutospäivämäärien avulla selvittää yhteys. Hakumenetelmää tosin toivottiin kehitettävän<br />
paremmaksi.<br />
7.6.3 Muut mahdollisuudet<br />
Projektin aikataulun, budjetin ja laajuuden yhdistäminen paremmin projekteissa tapahtuviin<br />
muutoksiin on projektipöytäkirjan käyttämistä muutosten hallinnan apuvälineenä<br />
ajatellen oleellinen asia. Muutoksen attribuutiksi voidaan esimerkiksi lisätä linkki siihen
62<br />
liittyvään aikatauluun ja versioon, johon muutos on vaikuttanut. Tämä tosin edellyttää<br />
myös aikataulujen ja muiden vastaavien projektinhallinnan välineiden siirtämistä<br />
sellaiseen paikkaan, että ne ovat järjestelmän käytettävissä.<br />
7.7 Rakenteisesta tiedonhallinnasta seuraavat ongelmat<br />
Rakenteinen projektipöytäkirjan hallinta ratkaisee monia projektinhallintaan liittyviä<br />
ongelmia, mutta sen mukana tulee myös uusia ongelmia tai asioita, joihin toteutettaessa<br />
älykästä projektipöytäkirjaa, täytyy ottaa kantaa. Seuraavaksi esitellään muutamia<br />
tärkeimpiä ongelmia, joiden ratkaisuja täytyy pohtia esimerkkisovelluksen pohjalta<br />
rakennettavaa järjestelmää kehitettäessä.<br />
Yksi tietoelementti voi edustaa useaa eri tietotyyppiä. Kokouksessa voidaan esimerkiksi<br />
päättää, että tehtaan seinien väri pitää muuttaa vihreästä siniseksi. Tämä on silloin sekä<br />
päätös, tehtävä että muutos. Esimerkkitoteutuksessa on ajateltu, että muutos on tehtävän<br />
erikoistapaus ja tehtävä on päätöksen erikoistapaus. Tällöin kyseinen tietoele-mentti<br />
voidaan luokitella muutokseksi. Vastaavia ongelmia kuitenkin varmasti ilmenee myös<br />
muunlaisia, jolloin jokaiseen tulee etsiä erikseen ratkaisu. Ei myöskään ole itsestäänselvyys,<br />
että pöytäkirjaa laativa henkilö ratkaisee vastaavat tilanteet samalla tavalla,<br />
kuin joku muu, joka tietoa tarvitsee.<br />
Hyvin samanlainen ongelma syntyy tapahtumaketjuista. Tällainen on esimerkiksi valituksesta<br />
seuraava päätös, josta seuraa muutos, josta seuraa tehtävä, josta seuraa taas uusi<br />
valitus jne. Tällaisia tapahtumaketjuja tosin ei pystytä hallitsemaan nytkään, mutta<br />
tapahtumaketjujen hallinta on yksi asia, jonka toteutustapa tulevaa sovellusta<br />
rakennettaessa pitää ratkaista.<br />
Liian tarkka tietoelementtien luokittelu tekee rakenteisen dokumentin hyvin jäykäksi.<br />
Tällöin, jos halutaan tehdä haku suuremmasta kokonaisuudesta, esimerkiksi paperikoneesta,<br />
saatetaan joutua hakemaan monta kertaa, mikä vähentää rakenteisen pöytäkirjan<br />
käyttöarvoa. Toisaalta liian löysä luokittelu johtaa taas siihen, että pieniä tietokokonaisuuksia<br />
on vaikeaa löytää. Esimerkkitoteutuksessa ollutta rakennetta pidettiin<br />
yleisesti ottaen hyvänä, mutta toisaalta vertailukohdetta ei ole. Samaten attribuuttien<br />
tarkkuutta pitää harkita. Toisaalta on hyvä, että voidaan hakea paperikoneen millä tahansa<br />
pikkuosalla, toisaalta taas saatetaan hakea pelkällä paperikoneella. Tämän ongelman tosin<br />
voi ratkaista siten, että hakemalla pelkällä osanumeron alkuosalla saadaan isompi<br />
kokonaisuus ja tarkalla numerolla tietty yksittäinen osa. Jaakko Pöyry Oy:ssä osanumerot<br />
on standardoitu siten, että numeron tietty osa tarkoittaa tiettyä asiaa.<br />
Jos jokin tietotyyppi kohdistuu usealle osalle tai alueelle, se pitää luultavasti luokitella<br />
niiden kaikkien mukaan, jotta se tarvittaessa löytyisi. Tällöin pitää standardoida muoto,<br />
jossa osat syötetään, esimerkiksi "osa1, osa2, osa3" tai "osa1; osa2; osa3". Tämä tosin<br />
riippuu pöytäkirjan syöttämiseen käytetyistä työkaluista siten, että se voidaan myös<br />
muuttaa toiminnaksi, jonka ohjelma hoitaa itse. Tällöin käyttäjien ei tarvitsisi miettiä
63<br />
asiaa pöytäkirjoja laatiessa. Standardointiin liittyy myös joukko muita ongelmia, esimerkiksi<br />
se, kuinka kaikki attribuuttien mahdolliset arvot saadaan standardoiduksi siten, että<br />
hakukone varmasti löytää kaikki mahdolliset tulokset.<br />
7.8 Johtopäätökset<br />
Käyttäjätutkimuksen päätarkoitus oli selvittää tehdyn tietorakennemallin (kuva 17a)<br />
soveltumista projektihallinnan apuvälineeksi. Tehty tietorakenne osoittautui hyväksi. Se<br />
ei ollut liian yksityiskohtainen mutta ei myöskään liian löysä. Ainoastaan tilanne (status)-<br />
elementin sisältämä tieto oli sellaista, että sen esitysmuotoon tai sisältöön toivottiin<br />
parannusta.<br />
Muutamia esimerkkisovelluksen puutteita lukuunottamatta älykkään projektipöytäkirjan<br />
esimerkkitoteutus koettiin erittäin hyödylliseksi. Myös ajatusta älykkäästä projektipöytäkirjasta<br />
projektihallinnan apuvälineenä pidettiin hyvänä. Johtopäätöksenä tuloksista<br />
voidaan sanoa, että älykkään projektipöytäkirjan kaltainen apuväline on erittäin hyvä ja<br />
tarpeellinen. Se tarjoaa mahdollisuuksia hyödyntää projektien pöytäkirjoja aivan uusilla<br />
tavoilla, niin koko projektin hallinnan kuin yksittäisen projektityöntekijän kannalta.<br />
Käytön mahdollisuudet riippuvat pitkälti siitä, kuinka älykäs pöytäkirja toteutetaan.<br />
Esimerkkitoteutuksen käyttöä vaikeutti lähinnä sen käyttöliittymän rajoittuneisuus.<br />
Läheskään kaikkea haluttua ja myös tarjolla olevaa informaatiota ei saanut helposti<br />
käyttöön, mikä testihenkilöiden mukaan varmasti rajoittaisi ihmisten halua käyttää sitä.<br />
Jatkokehityksessä täytyykin ottaa huomioon, että kaikki rakenteisen pöytäkirjadokumentin<br />
sisältö olisi helposti hyödynnettävissä. Ei ole kenenkään kannalta<br />
mielekästä syöttää dokumentteihin suurta määrää tietoa, jota ei sitten helposti voi käyttää.<br />
Tässä työssä ei kuitenkaan ollut tarkoitus kehittää täydellistä hakuohjelmaa vaan tehdyn<br />
sovelluksen tarkoituksena oli tutkia älykkään pöytäkirjan rakenteen järkevyyttä. Tähän<br />
tarkoitukseen sovellus koettiin riittävän hyväksi.<br />
Käyttöliittymän lisäksi parannus- ja jatkokehitysajatuksina toivottiin eniten mahdollisuutta<br />
seurata pöytäkirjoissa olevia tapahtumaketjuja. Tehty tietorakenne ei tällaisenaan<br />
tarjoa siihen kuin melko alkeellisia mahdollisuuksia. Näitä ovat esimerkiksi päätöksen<br />
syy-attribuutti ja muutoksen tai valituksen syy- ja toiminta-attribuutit.<br />
Kaikkien tässä luvussa esitettyjen tulosten luotettavuutta heikentää jonkin verran se, että<br />
kyseessä on täysin uusi pöytäkirjan käyttömuoto, eikä vertailukohdetta siis ole.<br />
Testihenkilöitä pyydettiin vertaamaan hakujen tuloksia niihin käytäntöihin, joilla he<br />
nykyisin hoitavat kyseessä olevaa tehtävää. Voidaan kuitenkin vain todeta, että testattu<br />
tietorakenne tarjoaa hyödyllistä tai hyödytöntä informaatiota, ei sitä, tarjoaisiko jokin<br />
muu rakenne parempaa tai huonompaa informaatiota.<br />
Toinen luotettavuutta hieman heikentävä seikka on käytetyn pöytäkirjamateriaalin<br />
pienehkö määrä (30 kpl). Pöytäkirjat oli valittu siten, että kaikki tietotyypit kaikkine<br />
ominaisuuksineen olivat edustettuina, mutta toisaalta tämä valinta myös saattoi jalostaa
64<br />
hakujen tuottaman informaation sellaiseksi, että se väistämättä oli hyödyllistä. Myös<br />
skenaariot on valittu siten, että ne tuottavat ainakin kohtuullisen määrän järkevää<br />
informaatiota. Toisaalta testikäyttäjät saivat myös tehdä vapaita hakuja, joten ei voida<br />
väittää skenaarioiden kovin pahasti rajoittavan saatuja tuloksia. Se, että käytetyt<br />
pöytäkirjat olivat todellisesta projektista ja sisälsivät siis informaatiota, jota oikeasti on<br />
käsitelty, lisää tulosten luotettavuutta siltä osin, että voidaan todeta rakenteen ja hakujen<br />
soveltuvan oikeiden pöytäkirjojen käsittelyyn.<br />
Kaikki testikäyttäjät olivat kiinnostuneita järjestelmästä, jolla voitaisiin hallita projektien<br />
pöytäkirjoja. Muutosvastarinnan vaikutusta tulevan järjestelmän mahdolliseen käyttöön ei<br />
siis tässä työssä ole huomioitu.
65<br />
8 JATKOKEHITYS<br />
8.1 Tietoelementit ja -attribuutit<br />
Pöytäkirjojen hallintajärjestelmän jatkokehitys voidaan jakaa kahteen osaan: tietoelementtien<br />
ja -attribuuttien valinta ja standardointi sekä tarvittavista tekniikoista ja työkaluista<br />
päättäminen. Ajatuksia jatkokehityksessä tehtävistä lisätoiminnallisuuksista tuli<br />
esille tehdyissä käyttäjätesteissä ja niitä esiteltiin luvussa 7.<br />
Älykkään projektipöytäkirjan esimerkkitoteutus tarjoaa yhden ehdotuksen valittavista<br />
tietoelementeistä. Tämä rakenne myös todettiin käyttäjätesteissä hyväksi. Sovelluksesta<br />
hieman riippuen kuvan 18 mukaista rakennetta voi harkita. Käytännössä tämä ei kuitenkaan<br />
vaikuta itse tietoelementtien valintaan, vaan ainoastaan niiden järjestämiseen. Sovelluksesta<br />
voidaan myös tehdä sellainen, että hakuja ei rajoita taustalla oleva tietorakenne,<br />
vaan haut voidaan tehdä joko tietotyypin tai sen ominaisuuden perusteella riippumatta<br />
siitä käytetäänkö kuvan 17a vai kuvan 18 mukaista rakennetta. Tärkeää on ainoastaan<br />
käyttää kaikille pöytäkirjoille samaa rakennetta.<br />
Attribuuttien valinta riippuu älykästä pöytäkirjaa käyttävän organisaation käytännöistä.<br />
Kohdassa 6.2 esitelty DTD soveltuu Jaakko Pöyry Oy:n käyttöön sekä sellaisille<br />
yrityksille, joissa esimerkiksi osat tai osastot luokitellaan vastaavalla tavalla. Käytännössä<br />
kuitenkin jokaiselle organisaatiolle on luotava oma DTD. Attribuuttien sallitut arvot on<br />
syytä myös standardoida mahdollisimman pitkälle. Tämä lisää tehtävien hakujen<br />
luotettavuutta huomattavasti. Jos esimerkiksi osat voidaan yksiselitteisesti luokitella<br />
numerotunnisteen perusteella, sitä kannattaa käyttää mieluummin kuin osan nimeä.<br />
Nimen käyttämisessä ongelma on aina se, että eri ihmiset saattavat käyttää eri nimeä ja<br />
esimerkiksi kirjoitusvirheet aiheuttavat sen, että osaa ei löydykään. Numerotunnistetta<br />
käytettäessä järjestelmä voi tarkistaa, että kyseinen osanumero on olemassa, mikä osittain<br />
vähentää kirjoitusvirheiden aiheuttamia ongelmatilanteita. Lisäksi järjestelmässä voisi<br />
olla toiminnallisuus, joka osaa yhdistää osanumeron sen nimeen, jolloin haun voi tehdä<br />
myös nimellä, jos tietää osan virallisen ja standardoidun nimen.<br />
Attribuuttien sallituille arvoille pitää myös standardoida kieli. Käytännössä Jaakko Pöyry<br />
Oy:ssä kaikki suurten projektien pöytäkirjat ovat englanniksi, jolloin luonnollinen kielivalinta<br />
on englanti. Kieltä ei automaattisesti voi valita sen mukaisesti, millä kielellä itse<br />
pöytäkirja on, sillä suuressa projektissa saatetaan pitää kokouksia useilla kielillä. Siksi<br />
kieleksi pitää valita koko projektin virallinen kieli ja lisäksi sellainen, jota ainakin valtaosa<br />
projektin työntekijöistä ymmärtää.<br />
8.2 Tekniikat ja työkalut<br />
Älykästä pöytäkirjajärjestelmää kehitettäessä voidaan pohjaksi ottaa nykyinen esimerkkisovellus<br />
ja lisätä siihen toiminnallisuutta. Käytännössä tämä ei kuitenkaan olisi paras<br />
mahdollinen ratkaisu, sillä projektissa pöytäkirjoja voi olla useita tuhansia, eikä toteutus-
66<br />
tapa, jossa jäsennetään ja käydään läpi joukko XML-dokumentteja ole erityisen nopea. Se<br />
soveltui hyvin muutamien kymmenien dokumenttien läpikäymiseen, mutta jos pöytäkirjoja<br />
on esimerkiksi 10 000 kappaletta, haku on melko hidas. Erilaiset pöytäkirjat voidaan<br />
tietysti tallettaa eri hakemistoihin. Tämä nopeuttaa hakua, mutta saattaa aiheuttaa tilanteita,<br />
joissa jokin pöytäkirja on tallennettu väärään paikkaan ja siksi siinä ollut informaatio<br />
jää haussa löytämättä. Niin kauan kuin pöytäkirjojen määrä on pienehkö, esimerkiksi<br />
muutamia satoja, ratkaisu, jossa haut tehdään suoraan jäsennetyistä dokumenteista<br />
on yksinkertaisin ja selkein.<br />
Toinen, ja käytännössä parempi, vaihtoehto on tallentaa pöytäkirjat tietokantoihin. Relaatiotietokannassa<br />
jokainen tietoelementti esitetään omana relaatiotaulunaan, kun taas<br />
oliotietokannassa yksi olio edustaa yhtä tietoelementtiä /17/. Kumpaa tahansa voidaan<br />
käyttää ja molemmilla on hyvät ja huonot puolensa. Kuvissa 23 ja 24 on esitetty päätöselementin<br />
relaatiotaulu ja päätös-elementistä luotu olio.<br />
Kuva 23. Päätös-elementin relaatiotaulu<br />
Kuva 24. Päätös-elementti olio<br />
Relaatiokannassa tietoelementtien yhdistäminen toisiinsa tapahtuu tunnisteen eli Idkentän<br />
mukaisesti. Oliokannassa taas yhdistäminen tapahtuu viittausten avulla. Käytännössä<br />
oliokanta-ajattelu on lähempänä rakenteisen dokumentin mallia ja siksi se voisi olla<br />
parempi ratkaisu älykkään dokumentin tallennustavaksi. Relaatiokannan etu oliokantaan<br />
nähden on se, että se on perinteisempi ja enemmän käytetty ratkaisu. /17/
67<br />
Hakutulosten esitysmuoto on yksi jatkokehityksen kohteista. Yksi vaihtoehto on laatia<br />
XSL (eXtensible Stylesheet Language)- kielellä erilaisia tyylisivuja, joiden avulla hakutuloksista<br />
voidaan muokata erilaisia raportteja, tehtävälistoja tai aivan perinteisen pöytäkirjan<br />
näköinen dokumentti.<br />
Iso kysymys on myös käytettävien työkalujen valinta. Pöytäkirjojen syöttäminen XMLeditorilla<br />
tuskin tulee kysymykseen, ellei editori ole hyvin helppokäyttöinen. Käytännössä<br />
ongelma on, että helpoimmassakin XML-editorissa syöttäjällä täytyy olla perustiedot<br />
XML:n rakenteesta. Syöttäminen tavallisella tekstinkäsittelyohjelmalla, esimerkiksi MS<br />
Word:llä, olisi tavallisen käyttäjän kannalta helpoin ratkaisu. Taustalla voisi olla ohjelma,<br />
jolle kerrotaan, mistä tietoelementistä on kyse ja joka osaisi sitten kysyä arvoja attribuuteille.<br />
Yksi vaihtoehto on myös laatia valmis lomake, jota voisi käyttää tavallisilla<br />
Internet-selaimilla. Lomakkeessa olisi tekstikenttiä ja niihin liittyviä elementti- ja<br />
attribuuttikenttiä, joihin voisi valita sallittuja elementtejä ja attribuutteja valikosta.
68<br />
9 YHTEENVETO<br />
Työssä käsiteltiin viestintää projekteissa ja yhtä viestinnän erikoistapausta: projektikokouksia.<br />
Projektissa, jossa on useita osapuolia, projektikokoukset ovat pääasiallinen<br />
viestintäkanava projektin osapuolten välillä. Projektikokouksissa päätetään lähes kaikki<br />
projektiin liittyvät asiat, niissä raportoidaan projektin kulusta ja keskustellaan projektin<br />
läpiviemisen strategioista.<br />
Suuret projektit voivat kestää useita vuosia. Näin pitkällä aikavälillä kokouksia ehditään<br />
pitää tuhansia. Vastaavasti myös kokouspöytäkirjoja tehdään tuhansia. Kokouspöytäkirjat<br />
projekteissa ovat tärkeitä dokumentteja, joihin kirjatut päätökset ovat osapuolten välisen<br />
sopimuksen mukaan laillisesti sitovia. Siksi niihin kirjatut asiat tulisi olla helposti tarkistettavissa.<br />
Nykyisin projektien pöytäkirjat ovat tallennettuina vaihteleviin paikkoihin eikä<br />
niille ole toteutettu minkäänlaista hakumahdollisuutta. Käytännössä kaikki tarkistukset<br />
pitää siis tehdä manuaalisesti pöytäkirjoja selaamalla, mikä on muutenkin kiireisessä<br />
projektissa liikaa aikaa vievä prosessi.<br />
Tässä työssä tutkittiin mahdollisuutta järjestää kokouspöytäkirjat älykkääseen muotoon.<br />
Älykäs dokumentti on sellainen, että siihen on lisätty tietoa sen sisällöstä ja se voidaan<br />
muuntaa moniin eri tarkoituksiin sopiviin muotoihin. Työssä kartoitettiin dokumenttianalyysin<br />
avulla projektikokouksissa syntyvä tieto ja luotiin rakenteinen malli projektikokouksen<br />
pöytäkirjalle. Saatua mallia testattiin työssä tehdyn esimerkkisovelluksen<br />
avulla siten, että projektinhallintaa työkseen tekevät henkilöt käyttivät sovellusta ja<br />
arvioivat rakenteen hyödyllisyyttä. Mallin suunnittelussa ja käyttäjätesteissä lähtökohtana<br />
pidettiin käyttäjien tarpeita, jotka kartoitettiin ennen suunnittelutyön aloittamista. Tällä<br />
tavoin pyrittiin ratkaisuun, joka olisi sellainen, että käyttäjät kokisivat saavansa siitä<br />
todellista hyötyä projektinhallinnan apuvälineenä. Kartoitettuja ja testattuja tarpeita oli<br />
yhteensä viisi. Jokaiseen liittyen annettiin käyttäjille hakuskenaarioita, joiden tuloksia<br />
käyttäjät arvioivat. Lisäksi pohdittiin muita käyttömahdollisuuksia jokaiseen tarpeeseen<br />
liittyen.<br />
Käyttäjät kokivat mallin ja hakusovelluksen tuottaman informaation pääosin<br />
hyödylliseksi jokapäiväiseenkin käyttöön. Myös ajatus hakutoiminnosta pöytäkirjoille<br />
koettiin hyväksi. Tuloksena saatiin myös joukko parannusehdotuksia ja -ideoita.<br />
Testien tuloksia voidaan pitää luotettavina. Käytetty materiaali oli peräisin oikeasta<br />
projektista, sitä oli paljon ja se oli monipuolista. Kaikki työssä kartoitetut tietoelementit<br />
attribuutteineen olivat edustettuina. Luotettavuutta hiukan heikentää se, että testeissä ei<br />
ollut mahdollisuutta käyttää kovin suurta määrää pöytäkirjoja, joten suuresta joukosta<br />
jouduttiin valitsemaan sellaisia, joissa oli mahdollisimman erityylistä tietoa. Tämä saattoi<br />
jonkin verran jalostaa hakujen tuloksia. Toinen luotettavuutta hiukan heikentävä seikka<br />
oli, että testihenkilöt olivat kaikki innostuneita ajatuksesta, että pöytäkirjat olisivat<br />
älykkäässä muodossa, joten muutosvastarinnan vaikutuksesta ei voida tämän tutkimuksen
69<br />
perusteella esittää johtopäätöksiä. Koska tehdylle tietorakenteelle ei ollut minkäänlaista<br />
vertailukohdetta, ei myöskään voida sanoa rakenteen olevan paras mahdollinen,<br />
ainoastaan, että se toimi hyvin.<br />
Työn lopussa tarkasteltiin vielä lyhyesti ratkaisuja, joita täytyy tehdä kehitettäessä oikeaa<br />
järjestelmää älykkäille pöytäkirjoille. Työssä tehty esimerkkisovellus ei ole soveltuva<br />
laajamittaisempaan käyttöön.
70<br />
LÄHDELUETTELO<br />
/1/ Andersen, E. S., Grude, K. V., Haug, T. Goal Directed Project Management. Kogan<br />
Page, Lontoo 1998. 192 s.<br />
/2/ Artto, K. Managing Business by Projects - the Basics of Project Management from a<br />
new perspective, Teknillinen korkeakoulu, Tuotantotalouden osasto. Helsinki 2000. 265 s.<br />
/3/ Beyer, H., Holtzblatt, K. Contextual Design : A Customer-Centered Approach to<br />
Systems Designs. Morgan Kaufmann, San Fransisco 1997. 350 s.<br />
/4/ Blessing, D., Goerk, M., Bach, V. Management of Customer and Project Knowledge:<br />
Solutions and Experience at SAP. Knowledge and Process Management 8(2001)2, s 75 –<br />
90.<br />
/5/ Choo, C. W. The Knowing Organization.How Organizations Use Information to<br />
Construct Meaning, Create Knowledge and Make Decisions. Oxford University Press,<br />
New York 1998, 320 s.<br />
/6/ Damm, D., Schindler, M. Security issues of a knowledge medium for distributed<br />
project work. International Journal of Project Management 20(2002)1. s. 37-47.<br />
/7/ Dias, C. Corporate portals: a literature review of a new concept in Information<br />
Management. International Journal of Information Management 21(2001)4. s. 269 –287.<br />
/8/ Eloranta, E., Hameri, A-P., Lahti, M. Improved project management through<br />
improved document management. Computers in Industry 45(2001)3. s. 224–231.<br />
/9/ Feigenbaum, E., McCorduck, P. Viides sukupolvi: Japanin haaste. Kirjayhtymä.<br />
Helsinki 1985, 275 s.<br />
/10/ Galliers, R. D. In search of a paradigm for information systems research. In:<br />
Mumford, E., Hirschheim, R., Fitzgerald, G., Wood-Harper, T.(toim.). Research methods<br />
in information systems. Amsterdam 1985. Elsevier Science Publishers B.V. s. 281-290.<br />
/11/ Holtshorne, D. Ten Knowledge Domains: Model of a Knowledge-Driven Company<br />
Knowledge and Process Management 6(1999)1. s. 3-8.<br />
/12/ Huuskonen, P. Model-based explanation of plant knowledge. Valtion teknillinen<br />
tutkimuskeskus, Espoo 1997, 232 s.<br />
/13/ ISO 10006. Quality management - Guidelines to quality in project management. The<br />
International Organization for Standardization, 1997. 23 s.
71<br />
/14/ Jaakko Pöyry Oy. Project Management Procedure Manual. Jaakko Pöyry Oy,<br />
Vantaa 1998.<br />
/15/ Johannessen, J-A., Olaisen, J., Olsen, B. Mismanagement of tacit knowledge: the<br />
importance of tacit knowledge, the danger of information technology, and what to do<br />
about it. International Journal on Information Management 21(2001)1, s. 3-20.<br />
/16/ Kaarela, K., Huuskonen, P., Leiviskä, K. The role of design knowledge in<br />
industrial plant projects. In: Proceedings of the 4 th International Conference on Cognitive<br />
and Computer Sciences for Organizations, Montreal 1993, s. 173-183.<br />
/17/ Karjalainen, A. M. Etäoppimateriaalin rakenteistaminen. Jyväskylän yliopisto,<br />
Tietojenkäsittelytieteiden laitos. Jyväskylä 1997. 106 s.<br />
/18/ Koulopoulos, T. M., Frappaolo, C. Electronic Document Management Systems. A<br />
Portable Consultant. McGraw-Hill Inc. USA 1995. 313 s.<br />
/19/ Maler, E., El Andaloussi, J., Developing SGML DTDs. From text to model to<br />
markup. Prentice Hall. New Jersey 1996. 532 s.<br />
/20/ Niiniluoto, I. Tieto, Informaatio ja Yhteiskunta. Hallinnon kehittämiskeskus.<br />
Helsinki 1997. 136 s.<br />
/21/ Nissen, H-E. Acquiring Knowledge of Information Systems - Research in a<br />
Methodological Quagmire. In: Mumford, E., Hirschheim, R., Fitzgerald, G., Wood-<br />
Harper, T.(toim.), Research methods in information systems, Amsterdam 1985, Elsevier<br />
Science Publishers B.V., s. 39-51.<br />
/22/ Nonaka, I. The knowledge-creating company: how Japanese companies create the<br />
dynamics of innovation. Oxford University Press, New York 1995. 284 s.<br />
/23/ Nyman, G. Henkisten voimavarojen hallinta verkottuneessa liiketoiminnassa, Luento<br />
31.5.2001. Professori. Helsingin yliopisto, Psykologian laitos.<br />
/24/ Oakland, J. S. Statistical process control. Butterworth-Heinemann. Oxford 1999.<br />
425 s.<br />
/25/ Oittinen, P. AS-75.100 Mediatekniikka, Luentokalvoja. Teknillinen korkeakoulu,<br />
Viestintätekniikan laboratorio. Espoo 2000. 194 s.<br />
/26/ Pelin, R. Projektihallinnan käsikirja, Gummerus Kirjapaino Oy. Jyväskylä 1999.<br />
438 s.
72<br />
/27/ Pitkänen, S. S. Haastattelu 17.9.2001. Projektipäällikkö. Stora Enso Oyj,<br />
Kanavaranta 1, 00101 Helsinki, Finland.<br />
/28/ Project Management Institute. Guide to the Project Management Body of<br />
Knowledge 2000 edition. USA 2000. 176 s.<br />
/29/ Robertson, S. Requirements trawling: techniques for discovering<br />
requirements. International Journal on Human-Computer Studies 55(2001)4. s. 405-421.<br />
/30/ Turner, R. The Handbook of Project-based Management. McGraw-Hill. Cambrigde<br />
1999. 529 s.<br />
/31/ Wiio, O. A., Johdatus viestintään. Weilin+Göös. Porvoo 1994. 271 s.
LIITE 1. PÖYTÄKIRJOJEN HALLINNASSA KÄYTETTY<br />
DTD<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
LIITE 2. ESIMERKKI XML-MUOTOISESTA<br />
PÖYTÄKIRJASTA<br />
<br />
<br />
<br />
<br />
<br />
<br />
75 % of piles has been driven, casting of slab<br />
proceeding in 3 fronts <br />
Wire silo level will be lowered by 100<br />
mm<br />
Customer presented document delivery time<br />
schedule, no critical items.<br />
Stainless steel piping to be used for condensate<br />
lines after the condensate pump if pump is stainless steel material.<br />
<br />
Approach Flow System: Butterfly type valve to<br />
be used as shut-off valve before machine screens. Valve will be located into<br />
pipe between the flanges.<br />
Approach<br />
Flow System: Correct flow balance for dilution headbox.<br />
Approach Flow System: Drains after machine<br />
screens duplicated in Supplier flow sheet, second one to be<br />
removed.<br />
Approach flow system: Wire silo might be in<br />
unbalanced situation. To guarantee constant level is silo, recirculation with<br />
level control valve to be arranged.<br />
Approach<br />
flow system: Supplier to give outline dimensioning for hydraulic curve<br />
before headbox.<br />
Vacuum system: Flow measurement from wet<br />
suction box not required<br />
Vacuum system: Level control valve of 1st<br />
suction box filtrate in Supplier scope, to be indicated in flowsheet<br />
accordingly.<br />
Vacuum system: Bleed for high vacuum box<br />
will be taken from Nash channel and located physically close to vacuum<br />
pumps.
Shower water system: No potable water will be<br />
used, Supplier to correct flowsheet. Condensate for Duo Cleaners need to be<br />
cooled down to 55 C. The cooled condensate will be taken from trim squirt<br />
heat exchanger.<br />
Shower water system: Chemical/hot water<br />
showers to be located above the collector tray in press section to avoid water<br />
drops on paper.<br />
Shower water system: Tray water from couch to<br />
be led into white water tank (ww2) with individual line. Water from wire<br />
basin is led into press water tank.<br />
Shower water<br />
system: Supplier to confirm if 4 bar water is enough for size press showers.<br />
In flowsheet 5 bar is indicated.<br />
Steam and condensate system: Steam condersers<br />
for pre and after dryers will be located into operating floor.<br />
Steam and condensate system: Steam headers<br />
were rearranged to release more space for other piping. The main header<br />
remain in operating floor and additional consumer headers are located into<br />
mezzanine level.<br />
Steam and<br />
condensate system: Total steam flow to PM 2 will be measured.<br />
Steam and condensate system: Steam flow for<br />
drying will be measured, that means one orifice before predryer, one orifice<br />
before after dryer, one orifice before hood supply units (in mezzanine floor)<br />
and one orifice for steam flow box.<br />
Steam and condensate system: Secondary<br />
consumers to be measured are process water heating and white water<br />
heating.<br />
Dryer fabric is used for conveyor.<br />
Trim squirt nozzles will be rubin<br />
type.<br />
Next meeting to be agreed with<br />
Supplier and Customer representative<br />
<br />
<br />
LIITE 3. HAKUOHJELMAN KÄYTTÄMÄ XML-TIEDOSTO<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />