Projektimalli organisaation johtamisjärjestelmässä - Projekti-Instituutti
Projektimalli organisaation johtamisjärjestelmässä - Projekti-Instituutti
Projektimalli organisaation johtamisjärjestelmässä - Projekti-Instituutti
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Projekti</strong>toiminnan johtaminen<br />
<strong><strong>Projekti</strong>malli</strong><br />
<strong>organisaation</strong><br />
johtamisjärjestelmässä<br />
Organisaation projektikulttuurin<br />
kehittämisen alueita ovat johdon ja<br />
johtamisjärjestelmien luomat edellytykset,<br />
projektien johtamisprosessit<br />
ja niihin liittyvät työkalut, sekä<br />
henkilöstön projektiosaaminen.<br />
Kirjoituksessa tarkastellaan projektien<br />
johtamisprosesseja ja niiden<br />
ominaisuuksia, jotka helpottavat<br />
käytäntöjen jalkauttamista organisaatioon.<br />
Kirjoittaja, jolla on<br />
laaja kokemus projektinhallinnan<br />
kouluttajana ja kehittäjänä, muistuttaa,<br />
että mikään projektikulttuurin<br />
osa-alueista ei vaativassa<br />
projektiympäristössä yksinään tuo<br />
menestystä.<br />
Matti Haukka<br />
P<strong>Projekti</strong>en johtamisprosessit kuvataan<br />
usein yrityksissä projektimalleilla. Nämä<br />
mallit (projektiohjeet, projektikäsikirjat<br />
tms.) ovat syntyneet <strong>organisaation</strong> itse<br />
tekeminä, konsultin avustuksella tai<br />
hankkimalla valmis kaupallinen malli.<br />
Tänä päivänä useimmissa organisaatioissa<br />
on kehitetty oma projektimalli<br />
yhtenäistämään projektikäytäntöjä.<br />
Todelliset yhtenäistämisen haasteet<br />
tulevat vastaan kun monikulttuurisia<br />
organisaatioita yhdistetään.<br />
Kaupalliset projektimallit ovat usein<br />
ongelmallisia<br />
Kaupallisia projektimalleja ovat muun<br />
muassa Propps, PPS, Prince2 ja ABC<br />
Project Model, joista kolme ensimmäistä<br />
ovat laajalti tunnettuja. Kaikki<br />
nämä mallit ovat periaatteessa geneerisiä<br />
(yleisiä, soveltuvat käytettäviksi<br />
kaiken tyyppisissä projekteissa).<br />
Useimmat niistä ovat alun perin<br />
syntyneet yhden <strong>organisaation</strong> projektimalliksi,<br />
mikä on antanut niille oman<br />
leimansa ja vaikuttanut esimerkiksi käytettyyn<br />
terminologiaan. Niinpä niiden<br />
laaja soveltaminen on monesti tuottanut<br />
vaikeuksia. Lisäksi on olemassa lukuisa<br />
joukko malleja, jotka ovat hyvin vahvasti<br />
sidoksissa johonkin tiettyyn projektiprosessiin<br />
tai projektityyppiin.<br />
<strong><strong>Projekti</strong>malli</strong>lle tyypillisiä ongelmia ja<br />
puutteita ovat:<br />
- Malli ei ole riittävän geneerinen,<br />
eikä siksi ole sovellettavissa<br />
<strong>organisaation</strong> kaikkiin projekteihin,<br />
mikä usein johtaa useisiin<br />
projektimalleihin.<br />
- Malli jää irralliseksi ohjeeksi<br />
projektipäälliköille, eikä siinä ole<br />
selvää kytkentää projektisalkun<br />
hallintaan.<br />
- Mallissa käytetty terminologia<br />
on hyvin omaleimainen, mikä<br />
voi aiheuttaa ongelmia yhteistyöhön<br />
muiden tahojen kanssa.<br />
- Malli ei jousta tarkoituksenmukaisesti<br />
eri vaikeusasteen<br />
projektien tarpeiden mukaan.<br />
Yksinkertainen ja helppo<br />
projekti ei vaadi samaa panosta<br />
projektinhallintaan kuin laaja ja<br />
monimuotoinen projekti.<br />
<strong><strong>Projekti</strong>malli</strong>n tulisi olla geneerinen<br />
Useassa organisaatiossa muodostuu<br />
erilaisia projektimalleja ja käytäntöjä<br />
eri tyyppisiin projekteihin. Tämä on<br />
hyvin luonnollista ja varmasti auttaa<br />
yksittäisiä projekteja. Mutta useita<br />
malleja käytettäessä tulee seuraavia<br />
ongelmia:<br />
- Iso projekti voi sisältää erityyppisiä<br />
osaprojekteja. Ei ole<br />
esimerkiksi pelkkiä IT-projekteja,<br />
vaan kyse on usein laajemmasta<br />
kokonaisuudesta.<br />
- Samat resurssit osallistuvat<br />
usean tyyppisiin projekteihin<br />
ja joutuvat näin opettelemaan<br />
useita käytäntöjä.<br />
- Strategisiin ohjelmiin ja projektisalkkuihin<br />
kuuluu usein eri<br />
tyyppisiä projekteja. Ohjelmien<br />
ja salkkujen johtaminen edellyttää<br />
ainakin jollakin tasolla<br />
yhteneväisyyttä projektien johtamiskäytännöissä.<br />
Sivu 22 <strong>Projekti</strong>toiminta 2/2003
Geneerinen projektimalli edellyttää<br />
aina projektin johtamisprosessin erottamista<br />
selvästi projektin toteutusprosessista.<br />
Tärkeää olisi, että saman johtamisprosessin<br />
mukaan voidaan johtaa<br />
erilaisia toteutusprosesseja (esimerkkejä<br />
toteutusprosesseista ovat esimerkiksi<br />
systeemityömalli, tuotekehitysprosessi<br />
ja tilaus-toimitus −prosessi). Geneerinen<br />
projektimalli kytkee erilaisten projektien<br />
hallinnan osaksi koko <strong>organisaation</strong> johtamisjärjestelmää<br />
(kuva 1).<br />
Jotta geneerisyys toteutuu, ei projektimallia<br />
(johtamisprosessia) saa liian<br />
tiukasti kytkeä projektin toteutuksen<br />
vaiheisiin, jotka ovat erityyppisissä<br />
projekteissa tietenkin erilaiset. Project<br />
Management Instituten julkaisun A<br />
Guide to the Project Management,<br />
Body of Knowledge (PMBOK) ajatusmalli<br />
projektinjohtamisessa on<br />
tässä mielessä erinomainen. <strong>Projekti</strong>n<br />
johtamisprosessit ryhmitellään viiteen<br />
prosessiryhmään (process group):<br />
- Asettaminen (initiation)<br />
- Suunnittelu (planning)<br />
- Toimeenpano (executing)<br />
- Valvonta ja ohjaus (controlling)<br />
- Päättäminen (closing)<br />
Prosessiryhmiin liittyviä johtamistoimenpiteitä<br />
tehdään koko projektin<br />
ajan. Esimerkiksi projektin suunnittelu<br />
jatkuu koko ajan eikä vain joidenkin<br />
tiettyjen päätöksentekopisteiden välillä<br />
(kuva 2). Tärkeää kuitenkin on, että<br />
tietyt keskeiset johtamistoimenpiteet<br />
kytketään selvästi tiettyihin johdon ja<br />
projektisalkun kontrolloimiin päätöksentekopisteisiin<br />
(kuva 3).<br />
Geneerinen projektimalli<br />
edellyttää aina projektin<br />
johtamisprosessin erottamista<br />
selvästi projektin<br />
toteutusprosessista.<br />
<strong><strong>Projekti</strong>malli</strong>n kytkentä projektisalkun<br />
hallintaan<br />
Useimmat projektimallit perustuvat<br />
ns. portti-ajatteluun (gate, tollgate,<br />
decision point). Näiden porttien merkitys<br />
tulisi nähdä vahvemmin johdon<br />
ja projektisalkun johtamisen näkökulmasta<br />
eikä pelkästään ohjausryhmän ja<br />
yksittäisen projektin riskien hallinnan<br />
tarpeista käsin. Näitä porttien välisiä<br />
vaiheita voisi nimittää johtamisvaiheiksi<br />
(management phase) tai salkunhallinnan<br />
vaiheiksi (portfolio phase). Salkunhallinta<br />
edellyttää tietenkin näiden vaiheiden<br />
aikana suoritettavien salkunhallinnan<br />
menettelyjen (kuten projektien vertailu<br />
ja priorisointi) kuvaamista.<br />
Johtamisvaiheen idea perustuu myös<br />
siihen, että erilaiset projektit käyttävät<br />
erilaisia vaihejakomalleja. Ne pitää joka<br />
tapauksessa sovittaa niille yhteiseen<br />
porttimalliin. Kun projekti varsinaisesti<br />
käynnistyy ja projektisuunnitelma<br />
hyväksytään, voivat projektin vaiheet<br />
(project phase) olla hyvin erilaisia ja olisi<br />
hyvä, jos portti-malli ei tästä eteenpäin<br />
”kahlehtisi” erilaisia projekteja. Toisaalta<br />
myös ennen projektisuunnitelman hyväksymistä<br />
eri projektit ovat edenneet<br />
erilaisin esivaihein.<br />
Kuvan 3 G2 ja G3 porttien välillä olevat<br />
tarkistuspisteet olisivat näin ollen<br />
projektityyppi- tai projektikohtaisesti<br />
sovittavia virstanpylväitä (milestone).<br />
Globaali terminologia tarpeen<br />
Terminologiaa käsiteltäessä voidaan perusteokseksi<br />
ottaa edellä mainittu PM-<br />
BOK. Tietyistä puutteellisuuksistaan<br />
huolimatta sen käsitteistö on varmasti<br />
laajimmin levinnyt. Maailmassa, jossa<br />
organisaatiot yhdistyvät ja verkottuvat,<br />
ja projekteja tehdään useiden yritysten<br />
yhteistyönä, on aina helpompi, jos<br />
lähtökohtana on tunnettu käsitteistö.<br />
Kun <strong>organisaation</strong> projektimallia aletaan<br />
kehittää, varsinkin käytäntöjen<br />
yhtenäistämistapauksessa, tulee aina<br />
Strategic level<br />
Operational level<br />
Project Portfolio level<br />
Project Management Level<br />
Project Management Process<br />
Project 1 Process<br />
Project 2 Process<br />
Project 3 Process<br />
Gate Port<br />
Milestone<br />
Kuva 1. <strong>Projekti</strong>salkun hallinta ja projektinhallintamalli osana<br />
<strong>organisaation</strong> johtamisjärjestelmää.<br />
<strong>Projekti</strong>toiminta 2/2003 Sivu 23
ensimmäiseksi sopia käsitteistö, toiseksi<br />
ymmärtää käsitteistö ja sitten vasta<br />
alkaa tehdä muuta.<br />
Vaikeusaste määrittää projektin<br />
prosessin<br />
Panostaminen projektin johtamiseen<br />
tulee olla aina tarkoituksenmukaista ja<br />
oikeaan osuvaa. <strong>Projekti</strong>njohtamisen<br />
tulee olla renki eikä isäntä. Monista<br />
projektimalleista onkin muodostunut<br />
Työn määrä<br />
Asettaminen<br />
Suunnittelu<br />
Toimeenpano ja valvonta<br />
Päättäminen<br />
Kun <strong>organisaation</strong><br />
projektimallia aletaan<br />
kehittää, tulee aina<br />
ensimmäiseksi sopia<br />
käsitteistö, toiseksi<br />
ymmärtää käsitteistö ja<br />
sitten vasta alkaa<br />
tehdä muuta.<br />
byrokraattinen riesa projekteja tekeville<br />
henkilöille. Ehdottoman tärkeää on aina<br />
löytää ne johtamistoimenpiteet (esimerkiksi<br />
dokumentit), joita koko yrityksen<br />
ohjaaminen ja projektisalkunhallinta<br />
edellyttävät. Vain nämä toimenpiteet<br />
ovat pakollisia. <strong>Projekti</strong>nhallinnan<br />
vaatimusten kasvaessa projektimallin<br />
tulee antaa oikeaan osuvia neuvoja ja<br />
menetelmiä projektiryhmälle. Erityisen<br />
Kuva 3. <strong>Projekti</strong>njohtamista ei tulisi kuvata peräkkäisinä vaiheina, eikä kytkeä sitä liiaksi muuhun vaihejavaativat<br />
ja ainutkertaiset projektit tulee<br />
tunnistaa ja kiinnittää niissä erityishuomiota<br />
muun muassa projektipäällikön<br />
kokemukseen ja osaamiseen sekä suunnitella<br />
kuhunkin projektiin soveltuvat<br />
johtamistoimenpiteet. Tässä punnitaan<br />
todellinen projektiosaaminen.<br />
Usein hyväksi koettu ratkaisu on jakaa<br />
projektit kolmeen luokkaan niiden<br />
vaatiman projektinjohtamispanoksen<br />
mukaan.<br />
A. Erityisen haastava ja ainutkertainen<br />
projekti, jossa projektinjohta-<br />
<strong>Projekti</strong> tai projektin vaihe<br />
Kuva 2. Prosessiryhmien ajoitus projektin elinkaarella (PMBOK).<br />
minen on suunniteltava kyseiselle<br />
projektille erikseen. Tällaista vaihetta<br />
voidaan nimittää esim. stratup<br />
prosessiksi (vrt. Morten Fangel:<br />
Planning The Project Management<br />
Effort, Nordnet Kongressi Reykjavik<br />
2002).<br />
B. Tavanomainen projekti, johon<br />
perusprojektimalli yleensä soveltuu<br />
ja on tarkoituksenmukainen.<br />
C. <strong>Projekti</strong>, joissa vaaditaan salkunhallinnan<br />
kannalta minimitoimenpiteet.<br />
Portfolio Management Level<br />
G0 G1<br />
G2 G3<br />
Project Management Level<br />
G4<br />
Charter<br />
Project<br />
Initiation<br />
Planning<br />
Project<br />
Plan<br />
Executing<br />
Controlling<br />
Weekly or monthly<br />
reports<br />
C C C<br />
Closing<br />
Final<br />
Report<br />
Project Implementation Level<br />
Project<br />
Outcome<br />
Project Start<br />
Project Finish<br />
Sivu 24 <strong>Projekti</strong>toiminta 2/2003
Huom! Panostetaan kuitenkin<br />
erityisesti sidosryhmäanalyysiin<br />
Valitaan projektiluokka B<br />
Piirre<br />
A B C<br />
Aikataulun tiukkuus<br />
Sidosryhmien määrä<br />
Osallistujien määrä ja luonne<br />
Uusi teknologia<br />
jne.<br />
jne.<br />
X<br />
X<br />
>30 10X- 30
Change language