Projektinhallinta eli hankehallinta tarkoittaa resurssien (kuten työvoiman) organisointia ja hallintaa sellaisella tavalla, että projekti voidaan päättää suunnitellun sisältöisenä ja laatuisena, aikataulun sekä budjetin mukaisesti. Käytettäviin resursseihin luetaan esimerkiksi raha, työvoima, raaka-aineet, energia, tila ja palkat. Resurssien lisäksi huomioidaan esimerkiksi viestintä, laatu ja riskit.
Lyhyt projektinhallinnan historia
Projektinhallinnan isänä pidetään Henry Ganttia, joka kehitti projektin suunnittelu- ja seurantatekniikoita, mm. Gantt-kaavion. Gantt-kaavio kuvaa tehtäviä aikajanalla niiden ajoitusta osoittavien pylväiden avulla. Ganttia pidetään myös työnosituksen () kehittäjänä. Työnosituksessa projekti jaetaan pieniin osiin, joiden pohjalta työn kulkua on helpompi hallita ja tehtävät voidaan jakaa eri vastuuhenkilöille.
Seuraava kehitysvaihe oli PERT-malli () ja kriittisen polun menetelmä, jotka perustuivat matemaattisiin malleihin.
USA:ssa perustettiin vuonna 1969 Project Management Institute (PMI), joka palvelee projektinhallinnasta kiinnostuneita. PMI julkaisi 1981 kirjan A Guide to the Project Management Body of Knowledge (PMBOK), joka sisältää projektinhallinnassa yleisesti käytettyjä standardeja ja ohjeita. Euroopassa perustettiin 1967 International Project Management Association (IPMA), joka myös perusti IPMA Project Baseline:n. Organisaatiot tekevät parhaillaan yhteistyötä luodakseen kansainvälisen projektinhallinnan standardin.
Projektipäällikkö
Projektinhallinta on useimmiten projektipäällikön tehtävä. Projektipäällikkö ei useimmiten osallistu projektin muiden tehtävien tekemiseen, vaan lähinnä keskittyy projektin etenemisen varmistamiseen ja eri osapuolten yhteistyön varmistamiseen siten, että projektin riskit pienenevät. Projektipäällikkö toimii usein asiakkaan edustajana, ja siksi määrittelee ja toteuttaa asiakkaan tarpeet. Projektipäällikön tehtävänä on löytää paras mahdollinen kompromissi kolmen projektien resurssimuuttujan kesken: aika, kustannukset ja laatu. Jos jotain muuttujista muutetaan, se vaikuttaa automaattisesti kahteen muuhun: jos tavoitellaan parempaa laatua, projektin kustannukset tavallisesti nousevat ja kesto pitenee. Kommunikointi eri sidosryhmien kanssa on myös projektipäällikön tärkeimpiä tehtäviä.
Projektipäällikkö tekee projektin osituksen, tyypillisesti yhteistyössä muiden kokeneiden projektinjäsenten kanssa. Projektipäällikkö myös jakaa projektin tehtävät eri työntekijöille.
Projektinhallinnan tehtäviä
Projektin määrittely Työn ja tavoitteiden suunnittelu Tavoitteiden analysointi Riskien hallinta (analysointi ja seuranta) Projektin laajuuden hallinta Resurssien arviointi Resurssien jako Projektiorganisaation muodostus Työn organisointi Resurssien hankinta Tehtävien jako Projektin etenemisen seuranta ja hallinta Tulosten analysointi Laadun hallinta Virheiden ehkäiseminen Projektin päättäminen Sidosryhmien ja heidän tarpeidensa analysointi Sidosryhmien kanssa kommunikointi
Projektinhallinnan tuotoksia
Menestyneiden projektien täytyy dokumentoida tavoitteet ja tuotokset riittävän hyvin. Nämä dokumentit toimivat projektin sponsorin, asiakkaiden ja projektin jäsenten odotusten linjaamiseksi.
Projektin asetus Projektin liiketoimintasuunnitelma/kannattavuusselvitys (ks. liiketoimintatarkastelu) Projektisuunnitelma WBS Muutostenhallinta/konfiguraationhallintasuunnitelma Riskien hallintasuunnitelma Viestintäsuunnitelma Asialista Tehtävälista Resurssinhallintasuunnitelma (ks. riskianalyysi) Projektin aikataulu Projektiraportti (ks. esim edistymisraportti ja loppuraportti) Vastuunjako Sidosryhmien analysointi Opitut kokemukset
Nämä dokumentit tallennetaan yleensä paikkaan, johon projektin sidosryhmillä on vapaa pääsy, esimerkiksi Intranetiin.
Projektinhallinnan suuntauksia
Projektinhallinnan suuntauksiin voidaan lukea erilaisia ketteriä, interaktiivisia, inkrementaalisia ja vaiheistettuja suuntauksia.
Perinteinen suuntaus
Perinteisesti projektihallinnassa on tiettyjä vaiheita, jotka tehdään yleensä samassa järjestyksessä: projektin asettaminen projektin suunnittelu projektin toteutus projektin seuranta projektin päättäminen
Erityisesti suunnittelu-, toteutus- ja seurantavaiheet saattavat toistua useamman kerran. Esimerkiksi seurantavaiheessa saattaa nousta esiin ongelmia, jotka vaativat korjausta ja joskus myös projektisuunnitelmaa täytyy muuttaa näiden ongelmien poistamiseksi. Näistä vaiheista on erilaisia muunnelmia eri teollisuuden aloilla. Ohjelmiston kehittämisessä monet organisaatiot noudattavat Rational Unified Process (RUP) tai tuotekehitykselle tyypillistä vaiheistettua (kuten Cooper: stage-gate model) mallia.
Päättämiseen kuuluu postmortem (myös nimellä retrospective), jossa arvioidaan miten projekti sujui. Tarkoitus on antaa ryhmälle tilaisuus arvioida, mikä sujui hyvin ja mitä voi parantaa seuraavalla kerralla. Post-mortem voidaan suorittaa koko projektin lopussa, mutta se voi olla hyödyllinen myös jokaisen vaiheen jälkeen monivaiheisessa projektissa.
RUP (Rational Unified Process)
Aloitus: Projektin sisältö määritetään, samoin mahdollinen järjestelmän arkkitehtuuri, ja haetaan projektille rahoitus ja sidosryhmien hyväksyntä. Kehitys: Järjestelmän arkkitehtuuri varmennetaan. Rakentaminen: Rakennetaan toimiva ohjelmisto säännöllisten pienten lisäysten avulla. Siirtyminen: Varmennetaan ja otetaan käyttöön järjestelmä sille suunnitellussa ympäristössä.
Kriittinen ketju
Kriittinen ketju () on kriittisen polun ja TOC-teorian pohjalle rakennettu projektinhallintamenetelmä.
Ketterät suuntaukset
Perinteiset projektinhallinnan menetelmät, joissa projektin sisältö pyritään suunnitteluvaiheessa lukitsemaan, soveltuvat parhaiten kertaluonteisille projekteille, joissa on vain pieni tai kohtalainen määrä etukäteen tuntemattomia muuttujia. Koska varsinkin nykyaikaiseen tuote- ja ohjelmistokehitykseen sisältyy usein enemmän etukäteen tuntemattomia kuin tunnettuja muuttujia, sekä peräkkäisiä tuotejulkaisuja, on kehitetty tällaisille projekteille paremmin soveltuvia malleja, kuten ketterä ohjelmistokehitys (), Extreme Programming ja Scrum. Ketterien mallien ajatellaan joskus soveltuvan vain pieniin projekteihin, mutta itse asiassa Apollo-avaruusohjelman menestys perustui osittain iteratiiviseen kehitysmalliin, jossa suunnitelmia, määrityksiä ja toteutusta tarkennettiin ajan myötä, kun toleranssit ja muut etukäteen tuntemattomat muuttujat opittiin tuntemaan paremmin.
Prosessipohjainen hallinta
Projektinhallintaan on liitetty usein prosessipohjainen asioiden hallinta, esimerkkinä tästä mainittakoon kypsyysmallit kuten CMMI () ja ISO/IEC 15504 (SPICE – ).
Projektin menestys vs. tehokkuus Ihmiset helposti sekoittavat projektin menestyksen projektinhallinnan menestykseen. Projektin menestyksellä on kaksi näkökulmaa: Prosessin näkökulma, eli tehokkaiden tulosten varmistaminen; tätä kutsutaan yleensä projektinhallinnan tehokkuudeksi tai projektin suorituskyvyksi. Tulosten näkökulma, eli hyödyllisten lopputulosten saavuttaminen; tätä kutsutaan yleensä projektin tehokkuudeksi (joskus yksinkertaisesti projektin menestykseksi).
Onnistuneen projektin toteutus vaatii paitsi suunnittelua myös kurinalaista toimeenpanoa. Projektinhallinnan menestyskriteerit poikkeavat itse projektin menestyskriteereistä. Projektinhallintaa pidetään onnistuneena, jos kyseinen projekti valmistuu sovitussa ajassa, vastaa sovittua työn laajuutta ja mahtuu sovittuun budjettiin. Kolmoisrajoituksen jälkeen on tarkasteltu moninaisia rajoitteita projektin onnistumisen varmistamiseksi. Kuitenkin kolmois- tai monirajoitus osoittaa vain projektin suorituskykymittareita, jotka pohjimmiltaan ovat projektinhallinnan menestyskriteereitä koko projektin elinkaaren ajan.
Projektin tuloksia voi tarkastella a priori ja a posteriori -näkökulmista. A priori -kriteerit rajaavat pois tärkeämmät projektin jälkeiset tulokset, jotka käsittävät neljä tasoa: tuotteen menestys, tuloksen menestys ja vaikutuksen menestys tuotteen elinkaaren aikana. Nämä a posteriori -menestyskriteerit osoittavat tuotteen, palvelun tai projektin tuloksen suorituskykymittarit projektin päättymisen ja luovutuksen jälkeen. Tämä kattava monitasoinen rakenne projektien, ohjelmien ja portfolion menestykselle kehitettiin Paul Bannermanin toimesta vuonna 2008. Toisin sanoen projekti on onnistunut, kun se saavuttaa odotetun liiketoimintatavoitteen, joka tulee olla selkeästi määritelty ja muotoiltu projektin käynnistys- ja valintavaiheessa ennen kehitysvaiheen aloittamista. Tämä monitasoinen menestysrakenne vastaa projektia muutoksena, esitettynä syöte–prosessi/toiminta–tuotos–tulos–vaikutus -ketjuna, jonka tarkoituksena on luoda haluttua arvoa. Emanuel Camilleri luokitteli vuonna 2011 kaikki kriittiset menestys- ja epäonnistumistekijät ryhmiin ja sovitti kunkin niistä monitasoisiin menestyskriteereihin liiketoiminta-arvon varmistamiseksi.
Esimerkkinä projektinhallinnan käytössä olevasta suorituskykymittarista on "valmiiden projektien portfolio" tai "projektisalkku".
Lähteet
Kirjallisuutta Risto Pelin: Projektihallinnan käsikirja, 5. uudistettu painos, Projektijohtaminen Oy Risto Pelin, Espoo 2008. Rainer Jansson, Peter Juselius: Projektiopas Ideasta liiketoimintaan, Tekes, Helsinki 2004. Paavo Viirkorpi: Onnistunut projekti - opas kunta-alan projektityöskentelyyn , Suomen Kuntaliitto, Helsinki, 2000. Jess Sutherland, Ken Schwaber, Lare Lekman: Suomenkielinen Scrum Guide, Agile Finland, 2011
Aiheesta muualla
Projektinhallintaluentoja (IT projektit) Projektien hallinta ja ohjaus (TKK:n kurssin sivusto]
* Luokka:Seulonnan keskeiset artikkelit