Introduction

Projects are often the means to operationalize strategic plans of a organization. Suunnitelmissa on kehittää tuotteita ja palveluita sekä tehostaa toimintaa. Bisnes on yhä projektisoituneempaa ja globaalit menot projekteihin ovat useiden miljardien dollarien luokkaa vuosittain (Williams, 2005). Syyt ovat ilmeiset. Projektit tarjoavat mahdollisuuden hyödyntää resurssien tehokasta ja tuloksellista käyttöä edistäviä projektinhallintakäytäntöjä. Huolimatta edistysaskeleista projektinhallinnan kurinalaisuudessa ja ammatissa, yhteinen kokemus viittaa kuitenkin siihen, että monet hankkeet epäonnistuvat (Williams, 2005), mikä korostaa projektinhallinnan prosessien ja suorituskyvyn tärkeyttä ja tarvetta parantaa niitä.

yleensä organisaatiot pyrkivät toteuttamaan PMI—standardeihin perustuvia perinteisen projektinhallinnan parhaita käytäntöjä projektin tavoitteiden saavuttamiseksi ja asiakkaan odotusten täyttämiseksi. Kaikki Projektinjohtoelimen (PMBOK® Guide) suositellut prosessit ja käytännöt eivät kuitenkaan välttämättä ole merkityksellisiä kaikissa hankkeissa. Usein valikoiva lähestymistapa on järkevä, kun projektinhallintaprosesseja ja-käytäntöjä otetaan käyttöön hankkeen erityistarpeisiin sen koon, tyypin, monimutkaisuuden ja toimialan mukaan, jolla hanke toteutetaan. Tällainen tarve toisenlaiseen lähestymistapaan IT-projektien johtamisessa on hyvin dokumentoitu projektinhallintakirjallisuudessa.

Ohjelmistokehitysprojektit kohtaavat usein ristiriitaisia haasteita kehittäessään ohjelmistotuotteita kiihtyvään tahtiin ja kehittäessään niitä niin, että ne ovat luotettavia (Boehm, 2002). Tietotekniikkahankkeet, joiden tavoitteena on pysyä nopeasti muuttuvan teknologian kehityksen tahdissa, muuttuvat usein suunnittelu-ja toteutusvaiheessa. Siksi IT-hankkeilla on haasteita, jotka poikkeavat perinteisistä hankkeista. IT-projekteissa kehitetään ja harjoitellaan useita mukautuksia ja muutoksia perinteisiin projektinhallintakäytäntöihin, jolloin otetaan käyttöön uusia projektinhallintamenetelmiä, kuten ketterä Projektinhallinta.

ketterässä projektinhallintamenetelmässä-joka soveltuu paremmin usein muuttuviin toiminta-aloihin-käytetään iteratiivista tai vaiheittaista suunnittelua ja jatkuvaa integraatiota. Keskeisenä periaatteena on pitää projektin laajuus pehmeänä. Menetelmä edistää yhteistyötä ja lisää asiakastyytyväisyyttä. Agile ei kuitenkaan ole täydellinen ratkaisu kehittää ohjelmistoja nopeaan tahtiin ja samalla täyttää asiakkaan vaatimukset kestävyydestä ja luotettavuudesta. Tässä yhteydessä Boehm (2002) suositteli perinteisen projektinhallinnan ja ketterän ohjelmistokehitysmenetelmän yhdistelmää, joka on toteuttamiskelpoinen ja edullinen. Täydentävänä lähestymistapana olisi kehittää riskiperusteinen lähestymistapa, joka on räätälöity säilyttämään sekä ketterien että suunnitelmalähtöisten menetelmien hyödyt ja samalla lieventämään monia niiden heikkouksia (Boehm & Turner, 2003).

tämän tutkimuspaperin tarkoituksena on tutkia edellä mainittuja väitteitä (Boehm, 2002; Boehm & Turner, 2003), jotka koskevat yhdistettyä lähestymistapaa IT-konsultointiprojektien hallintaan, jotka poikkeavat IT-hankkeista. IT-konsultointihankkeet on suunniteltu hallinnoimaan ja antamaan projektitukea IT-hankkeille. Ne aloitetaan usein julkisella sektorilla. IT-konsultointiprojektit eivät ole ohjelmistokehityshankkeita, vaan ne antavat PROJEKTITUKEA IT-hankkeille.

tässä tutkimuksessa pyrimme kehittämään ymmärrystä siitä, miten ketterät projektinhallintakäytännöt ovat merkityksellisiä IT-konsultointiprojekteissa. Opinnäytetyön tavoitteena on tunnistaa ketterän projektinhallinnan hyödyt, soveltuvuus ja se, mitä asioita perinteisestä projektinhallinnasta voidaan yhdistää ketterään projektinhallintaan it-konsultointiprojekteissa projektin suorituskyvyn parantamiseksi. Seuraavassa osassa, laajassa agile project management methodology-kirjallisuuskatsauksessa, olemme tunnistaneet agile method-menetelmän keskeiset piirteet ja sen ainutlaatuisen lähestymistavan projektinhallintaan verrattuna perinteiseen projektinhallintaan. Kirjallisuuskatsaus on auttanut kehittämään ymmärrystä ketterän ohjelmistokehityksen keskeisistä käsitteistä ja hyödyistä. Lisäksi kirjallisuuskatsauksen tulosten pohjalta olemme kehittäneet ja esittäneet strukturoidun kyselylomakkeen avulla tutkimusmenetelmän, jonka avulla voimme kehittää ymmärrystä IT-konsultointiprojekteista. Myöhemmin esitelty Data-analyysi ja-keskustelu tarjoavat tärkeitä oivalluksia ja tutkimustuloksia. Päätämme paperin TUTKIMUSTULOKSIIMME ja IT-konsultointihankkeita koskeviin suosituksiimme.

kirjallisuuskatsaus

perinteisiä projektinhallintakäytäntöjä, joiden taustalla on kokonaisvaltainen suunnittelu, voidaan käyttää, kun projektimääritykset on määritelty selkeästi. Toisaalta, kun eritelmät muuttuvat usein hankkeen elinkaaren aikana, perinteinen lähestymistapa hankkeiden hallintaan ei välttämättä toimi tehokkaasti. Ohjelmistokehitysprojekteissa noudatetaan usein vähimmäisvaatimuksia, mikä aiheuttaa usein muutoksia näihin eritelmiin projektin toteutuksen aikana. Lisäksi ohjelmistoprojektien kehitysajat ovat lyhyitä. Ketterät menetelmät, verrattuna perinteisiin projektinhallintatekniikoihin, soveltuvat ohjelmistokehitysprojekteihin, koska nämä projektit ovat lyhytkestoisia (Hanakawa & Okura, 2004).

yleisesti ottaen erilaiset ohjelmistokehitysmenetelmät, kuten ketterä Projektinhallinta, lupaavat parempaa asiakastyytyväisyyttä, alhaisempia vikojen määriä, nopeampia kehitysaikoja, ja ne toimivat ratkaisuna nopeasti muuttuviin projektivaatimuksiin (Boehm & Turner, 2003). Toisin kuin ketterässä projektinhallinnassa, stage-gate-mallissa käytetään työprosessia konseptiideasta tuotteeseen, joka lopulta toimitetaan. Tässä mallissa kehitetään projektinhallinnan elinkaarivaiheita, jotka perustuvat tuotekehityksen eri vaiheisiin projektinhallintaa varten. Tärkeä ero stage-gate-mallin ja ketterän projektinhallinnan välillä on se, että ensin mainitussa pyritään minimoimaan vaatimusten muutokset niin, että tuote valmistuu ajoissa (Karistroom & Runeson, 2005). Toinen tapa kehittää ohjelmistoja on SCRUM, joka on joukko projektinhallinnan periaatteita, joissa käytetään pieniä poikkitoiminnallisia ja itseohjautuvia tiimejä (Schatz & Abdelshafi, 2005). SCRUM edellyttää, että jokainen tiimin jäsen ja tuoteomistaja työskentelevät yhdessä jokaisen tuotekehityksen alussa ja menetelmä toimii kääreenä olemassa olevien kehitysprosessien ympärille. Tämän vuoksi Schatz ja Abdelshafi väittivät, että SCRUMILLA ei ole perussuunnitelmaa hankkeen onnistumisen mittaamiseksi. Ketterä Projektinhallinta otetaan kuitenkin tässä tutkimuksessa huomioon, koska se on joustavampaa ja mukautuvampaa ohjelmistokehitysprojekteihin.

edellä mainittujen hyötyjen lisäksi ketteriä menetelmiä voidaan soveltaa turbulenttisiin ja jatkuvasti muuttuviin ympäristöihin (Highsmith & Cockburn, 2001). Lisäksi ketterä menetelmä korostaa mukautuvuutta markkinoihin, teknologiaan ja prosesseihin (Mellor, 2005). Agile methodology on lähestymistapa, jossa keskitytään ensin tärkeisiin ominaisuuksiin, ja sen tuloksena etsitään varhaista palautetta ominaisuuksista (Karistrom & Runeson, 2005). Kun tärkeät ominaisuudet on tunnistettu, projektipäällikkö varmistaa, ettei viivästyksiä tule. Karistromin ja Runesonin mukaan ketterä prosessi välttäisi resurssien ahtamisen, kiinteät suunnitelmat ja pitkän aikavälin suunnitelmien tukemisen.

ketterä menetelmä ei kuitenkaan sovellu kaikkiin ohjelmistokehitysprojekteihin. Agile Methodin Kehittäjä Scott Ambler Boehm (2002) suositteli perinteisiä, suunnitelmalähtöisiä projektinhallintamenetelmiä varmennusohjelmistoille, kuten elämänkriittisille järjestelmille.

ketterä menetelmä tarvitsee vaativan, kaaoksen ja epävarmuuden leimaaman projektiympäristön vuoksi lahjakkaista ihmisistä koostuvia projektitiimejä vastaamaan haastaviin tarpeisiin ja vaatimuksiin. Viitaten tutkimukseen Constantine (2001), Boehm (2002) ehdotti, että ketterä menetelmät vaativat erittäin kyvykkäitä ihmisiä. Agile ei myöskään sovellu isompiin tiimeihin (Highsmith & Cockburn, 2001), sillä menestyminen vaatii tiivistä tiimityötä, ja yli 15 tai 20 kehittäjän tiimit lisäävät projektin hallinnan vaikeutta (Constantine, 2001).

on ilmeistä, että ketterä menetelmä työllistää koherentteja tiimejä (Karistroom & Runeson, 2005). Karistrom ja Runeson tunnistivat ketteriä lisäominaisuuksia, kuten pieniä ja hallittavia tehtäviä, jatkuvaa integraatiota ja automaattista testausta. Ketterille projektitiimeille onkin ominaista hyvä sisäinen kommunikaatio, laadukkaampi toiminta ja kontrollin tunne (Karistroom & Runeson). He kuitenkin visioivat ketterän joukkueen mahdollista eristäytymistä.

viestinnän, asiakirjapohjaisen edistyksen hallinnan ja laadunvalvonnan osalta perinteinen projektinhallinnan käytäntö ei sovi yhteen ketterän ohjelmistokehitysmenetelmän kanssa (Hanakawa & Okura, 2004). Ketterissä menetelmissä suositaan yleensä kasvokkaista vuorovaikutusta kehitystavoitteiden jatkuvassa uudelleensuuntaamisessa (Melnik & Mauer, 2004). Korostaen perinteisten ja ketterien menetelmien eroa Melnik ja Mauer ehdottivat, että ohjelmistokehityksessä suositaan lyhyttä tiedonsiirtoa sekä suoraa viestintää ja yhteistyötä, toisin kuin perinteisissä projektinhallintakäytännöissä, joissa käytetään pitkiä tiedonsiirtoketjuja, jotka ovat usein alttiita vääristymiselle ja tiedon katoamiselle.

yksi merkittävistä eroista suunnitelmalähtöisten perinteisten projektinhallintakäytäntöjen ja ketterien menetelmien välillä on se, että ketterät menetelmät hyödyntävät ketteryyttä projektiryhmän hiljaisesta tiedosta eivätkä eksplisiittisestä tiedosta, jota käytetään usein dokumenttien ja suunnitelmien muodossa perinteisessä projektinhallinnassa (Boehm, 2002).

toinen ero on hankkeita varten luodun dokumentaation määrä ja tyyppi. Suunnitelmavetoinen perinteinen Projektinhallinta korostaa yksityiskohtaista suunnittelua, seurantaa ja dokumenttien hallintaa. Suunnittelun perusteet, perustelut ja perustelut, luodaan pitkälle automatisoidulla menettelyllä ja nämä suunnittelun perusteet toimivat ketteränä dokumentaationa (Sauer, 2003).

Coram ja Bohner (2005) ovat tunnistaneet ketterän menetelmän yhteisiä piirteitä: yhteistyö, pienet tiimit, lyhyet julkaisuaikataulut, aikanyrkkeily ja jatkuva testaus. Projektipäällikön vastuulla on varmistaa tiivis yhteistyöympäristö. Tätä varten ketterä menetelmä kannustaa pieniä tiimejä ja muutamia alaryhmiä projektia kohden edistämään yhteistyötä. Tämän seurauksena ketterä menetelmä vaatii todennäköisesti vähemmän prosessia ja suunnittelua tiimitoiminnan koordinoimiseksi. Ketterä menetelmä käyttää myös lyhyitä julkaisuaikatauluja, jotka voivat vaihdella kahdesta viikosta kuuteen kuukauteen. Time boxing on käsite, joka asettaa kiinteän keston vapauttamaan projektin suoritteet, mikä auttaa vähentämään kultausta ja laajuus hiipiä. Jatkuva testaus takaa tuotteiden laadun ja integraation. Lisäksi Coram ja Bohner ehdottivat, että projektipäälliköiden on seurattava edistymistä ja tehtävä liiketoimintapäätöksiä, joissa painotetaan muutokseen vastaamista tietyn suunnitelman sijaan.

Aikanyrkkeily johtaa arvaamattomaan suunnitteluun parhaan arvauksen mukaan ja määrätyt päivämäärät voivat tuoda yllättäviä yllätyksiä kehitysvaiheessa (Patton, 2003). Toinen lopputulos tässä iteratiivisessa projektisuunnitteluprosessissa on se, että ketterä menetelmä ei voi seurata edistymistä prosenttilukujen perusteella (Patton, 2003).

pienten alaryhmien osallistuminen suunnitteluun johtaa motivoituneisiin ohjelmistokehitysinsinööreihin; tekniset kysymykset nousevat esiin projektin alkuvaiheessa, eikä toteutuksessa ole juurikaan vastustusta (Karistroom & Runeson, 2005). Lisäksi hankkeen laajuuden määrittäminen ketterällä lähestymistavalla johtaisi kustannusten vähenemiseen (Mcgovern, 2002). Ketterä menetelmä käyttää vaatimuspohjaista suunnittelua ja antaa meille myös mahdollisuuden hallita laajuutta (McGovern).

käyttäen kaikkia viittauksia ja keskusteluja tähän mennessä ja muita (Little Greene, Phillips, Pilger & Poldervaart, 2004; Little, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004), taulukossa 1 esitetään yhteenveto perinteisten ja ketterien projektinhallintakäytäntöjen vertailusta.

Taulukko 1: Ketterän ja perinteisen projektinhallinnan vertailu

Hankevaihe	perinteinen	Ketterä
vireillepano	virallistettu hanke valmius laatu ennakoitavissa olevat kehitysvaatimukset muodolliset viestintäpolitiikat hyvä varmuus ja vakaus	Priorisoidut epäviralliset tarinat testitapaukset ennalta arvaamaton nopea muutos epäviralliset, kasvokkain viestintä radikaali muutos ja nopea arvomalli
suunnittelu	dokumentoitu eksplisiittinen dokumentoitu tietämys muodollinen suunnitelma kattava lähestymistapa hyvin määritelty soveltamisala hidas muutos soveltamisalassa (hyväksytty) ennustettavuus optimointi Suunnitelmalähtöinen resurssien kohdentaminen pieni riski suunnitelmien vuoksi Joustamaton suunnitelma ja soveltamisala laadunvalvonnan ja työkalujen laaja käyttö suunnitelma-ja yrityslähtöiset hanke Suunnitelmavetoinen aikataulu	vähemmän dokumentoitu ajettu joustava suunnitelma Hiljainen ihmissuhdetuntemus iteratiivinen suunnitelma Vaatimuslähtöinen lähestymistapa muuttuva soveltamisala usein tapahtuvat, radikaalit muutokset arvaamaton Vaatimuslähtöinen, felxible tarveperusteinen resurssien kohdentaminen suuri riski, ennakoimaton joustava suunnitelma ja soveltamisala ei laatutyökalujen käyttöä soveltamisalan muutosten vuoksi yritys-ja tarvelähtöinen hanke ajallinen schedule
Execution	Extensive design Longer increments Detailed execution plan Comprehensive scope change control Contractual and scope-based procurement Integration during integration Large teams for execution	Simple design Short increments Iterative and reactive execution plan Easy refactoring Requirement-based procurement Continuous integration pienet joukkueet teloitettaviksi
seuranta ja valvonta	kvantitatiivinen valvonta dokumentoidut testaussuunnitelmat ja-menettelyt seurantahankkeen kustannusten Ansaittu arvo viikoittain ja kuukausittain	kvalitatiivinen kontrolli suoritettavat testitapaukset määrittelevät testauksen usein muuttuvat lähtötilanteet yksinkertaiset graafiset raportointityökalut
Sulje	systemaattinen lähestymistapa sopimusten sulkemiseen Helppo kaapata opetukset Eksplisiittinen ja hiljainen-pohjainen opetukset	Puute suuntaviivojen (ehdot ja ehdot) Vaikea vangita opetukset Tacit-knowledge intensive opetukset

Yhteenveto kirjallisuuskatsaus

Ketterä projektinhallinta menetelmää käytetään yleisesti ohjelmistojen kehityshankkeita. Se on enemmän sopeutumiskykyä usein muuttuvat soveltamisalaan. Tämän seurauksena ketterä Projektinhallinta käyttää iteratiivista tai vaiheittaista suunnittelua ja jatkuvaa integraatiota koko projektin keston ajan. Keskeinen periaate ketterä projektinhallinta on pitää hankkeen laajuus pehmeä. Ketterä projektinhallinnan menetelmä on erilainen kuin perinteinen projektinhallinta-menetelmää antamalla tärkeitä tekijöitä, jotka ovat perinteisesti pidetään merkityksetön. Ketterä määrittää suhteellisesti suurempi merkitys:

• henkilöt ja vuorovaikutukset prosesseissa ja työkaluissa
• projektin läpivienti kattavassa dokumentaatiossa
• asiakasyhteistyö sopimusneuvotteluissa
• muutosvastarinta projektisuunnitelmassa

ketterä menetelmä korostaa joustavuutta projektin tarpeiden täyttämiseksi. Lisäksi se perustuu asiakaspalautteeseen hankesuunnitelman muutosten käynnistämiseksi. Menetelmässä käytetään soveltuvien loppukäyttäjien ja heidän tavoitteidensa tunnistamiseen perustuvaa lähestymistapaa hankkeen tuotosten muotoilussa ja liiketoimintaprosessien suorittavien tarpeiden täyttämisessä. Ketterän menetelmän etuja ovat asiakastyytyväisyyden paraneminen, matalammat vikamäärät ja nopeammat kehitysajat. Lisäksi ketterä menetelmä on vastaus nopeasti muuttuviin vaatimuksiin, sillä siinä hyödynnetään varhaista palautetta projektien tuotosten teknisistä ominaisuuksista. Ketterä menetelmä varmistaa, ettei vaatimuksia ole ahdettu täyteen. Agile-menetelmän keskeisiä ominaisuuksia ovat tehokas viestintä projektiryhmän sisällä ja sen ulkopuolella, ja se on osoittanut joustavuutta vaatimusten lisäämisessä.

nämä edut auttaisivat organisaatioita tarjoamaan parempaa asiakaspalvelua. Lisäksi ne ovat merkityksellisiä nykyisessä taloudessa, jossa globalisaatio ja vapaa markkinointifilosofia vaikuttavat asiakkaiden käsityksiin lisätä odotuksia toimittaa tuotteita ja/tai palveluja nopeammin, halvemmalla ja paremmin.

ketterä menetelmä ei kuitenkaan ole vailla puutteita, kuten taulukosta 1 käy ilmi. Usein muuttuvat soveltamisalat vaikeuttavat hankkeiden edistymisen seurantaa. Ei ole myöskään helppoa kaapata hiljaista tietoa opittujen opetusten muodossa. Scope change control, dokumentointi, kattava suunnitelma, laadunhallinta ja riskienhallinta ovat tärkeitä perinteisen projektinhallinnan etuja, jotka voimme menettää käyttäessämme agile Methodia.

tutkimusmenetelmät

aineistojen keräämiseen käytettiin sekä henkilöhaastatteluja että kyselylomakkeita. Laadimme jäsennellyn kyselylomakkeen, joka koostui kahdesta osasta. Ensimmäinen osio oli suunniteltu kuvaamaan yksityiskohtia hankkeesta ja sen ominaisuuksista. Tämä osio sisältää 13 kysymystä, jotka liittyvät projektin väestötietoihin ja projektinhallintakäytäntöihin. Heille esitettiin tutkimukseen osallistuneille mahdollisuus antaa tarvittaessa avoimia vastauksia.

toisessa osiossa keskityttiin projektinhallinnan käytännön lausuntoihin, ja osallistujia pyydettiin vastaamaan näihin lausuntoihin viisikohtaisella asteikolla 1 ilmaisulla ”vahvasti eri mieltä” ja 5 ilmaisulla ”vahvasti samaa mieltä.”Seuraavissa lausunnoissa käsiteltiin tärkeitä yhteisiä opinkappaleita projektinhallinnan käytännöistä sekä pyrittiin asettamaan vastakkain perinteiset ja ketterät projektinhallinnan käytännöt.

• hankkeen onnistumisen mittauskriteerit perustuvat hankkeen tavoitteisiin ja päämääriin.
• projektia ohjaavat vaatimukset.
• projekti on muutoskelpoinen.
• mielestänne projektinhallintatoimet, joilla saavutettiin odotettuja tuloksia
• Kasvokkaiset vuorovaikutukset ja lyhyemmät viestintäketjut, ovat tärkeämpiä kuin prosessit ja työkalut.
• tiimi keskittyy projektin toteuttamiseen kattavan dokumentaation avulla.
• asiakasyhteistyö sopimusneuvotteluissa toimii tiimisi kannalta paremmin.
• hankkeella on tarkoin määritelty projektin laajuus.
• Projektinhallintakäytännöt noudattavat PMBOK® Guide-projektin elinkaarta.
• projektissa noudatetaan iteratiivista tai vaiheittaista hankesuunnittelua.
• projektissa on dokumentointivaatimuksia, kuten standardien kuten ISO9000, OMB 300 noudattaminen.
• User Acceptance Testing (UAT) – menettelyjä noudatetaan koko projektin ajan.
• projektipäälliköllä on valtuudet tehdä projektiin liittyviä päätöksiä ilman asiakkaan väliintuloa.

vastaukset näihin väittämiin analysoidaan yhdessä 13 kysymyksen ensimmäisen joukon sopivien kysymysten kanssa. Molempiin osioihin annetuissa vastauksissa annettiin yksityiskohtaista tietoa hankkeesta mielekkään analyysin tekemiseksi.

tutkimustulokset

kyselylomake jäsennettiin keräämään tietoja 20 IT-konsultointiprojektista, jotka olivat tutkimuksen tekohetkellä käynnissä. Hankkeista 65 prosenttia on aika-ja materiaalisopimustyyppisiä hankkeita ja loput kiinteähintaisia (firm fixed price, FFP). Aika-ja materiaalihankkeista 55% on yli kahden vuoden mittaisia.

suurin osa projektiryhmistä on pieniä: vain 15 prosentissa on vähintään 10 jäsentä. Projektiryhmän jäsenten välisen viestinnän osalta 60% vastaajista on käyttänyt vain muodollista viestintää projektin tarpeisiin. ; 30 prosenttia käytti sekä muodollista että epävirallista viestintää, ja loput 10 prosenttia turvautui pelkkiin epävirallisiin menetelmiin.

joka toinen vastaaja ilmoitti, että heidän hankkeissaan on käytetty hankesuunnitelmaa. Tähän liittyvässä kysymyksessä niistä hankkeista, joilla ei ollut hankesuunnitelmaa, 80 prosenttia ei myöskään käyttänyt iteratiivista suunnittelua.

soveltamisalan muutos on tärkeä osa tätä tutkimusta. Hankkeista 70 prosenttia on kokenut soveltamisalan muutoksen vähintään kerran. Niistä, jotka kokivat projektin laajuuden muutoksen, 60% koki sen useammin kuin kahdesti. Kun asiakas päättää soveltamisalan muutoksesta, konsultti voi asiakkaan suostumuksella sisällyttää laadunvalvontasuunnitelman projektinhallintasuunnitelmaan. Kun heiltä kysyttiin, onko heillä laadunvalvontasuunnitelma hankkeelleen, 65 prosenttia vastaajista ilmoitti, ettei käytä laadunvalvontasuunnitelmaa.

Tuloskeskustelu ja analyysi

tutkimustulokset analysoitiin tutkimalla huolellisesti kysymyksen ja kaikkien muiden kysymysten välisiä yhteyksiä ensin tulosten validoimiseksi ja toiseksi tehokkaiden hallintastrategioiden kehittämiseksi. Lisäksi tuloksia analysoitiin, jotta voitiin selvittää, mitä ketteriä ja perinteisiä projektinhallintakäytäntöjä voidaan käyttää yhdessä vahvan projektinhallintatavan kehittämiseksi IT-konsultointiprojekteihin.

hankkeen Onnistumiskriteerit, jotka perustuvat sen tavoitteisiin

hanketta pidetään onnistuneena, kun se täyttää sille asetetut tavoitteet ja tavoitteet. Vain 60 prosenttia vastaajista oli samaa mieltä. ”hankkeen onnistumisen mittauskriteerit perustuvat hankkeen tavoitteisiin ja päämääriin. Eri mieltä oli noin 30 prosenttia vastaajista. Tarkemmissa analyyseissä on selvinnyt, että erimielisyyden syynä oli se, että nämä projektit kokivat jatkuvasti muuttuvia olosuhteita ja vaatimuksia tai että asiakas ei ollut selvillä hankkeesta. Viime kädessä näiden hankkeiden soveltamisala muuttui usein. Yhdessä tapauksessa projektin tavoitteet ja tavoitteet muuttuivat.

on mielenkiintoista huomata, että hankkeen onnistumiskriteerit johtuvat sen tavoitteista ja laajuuden muutoksesta, projektityypistä ja hankesuunnitelman olemassaolosta. Toisin sanoen hankkeen kriteerien johtaminen organisaation strategisesta suunnitelmasta ei vaikuta laajuuden muutokseen eikä siihen, onko hankkeella suunnitelmaa.

hankkeen vaatimukset

yleensä yksityiskohtainen projektisuunnitelma laaditaan sen jälkeen, kun hankkeen rahoittajan vaatimukset on selkeästi yksilöity. Hankesuunnitelman laatimisen ja sen toteuttamisen tulisi lähtökohtaisesti perustua näihin vaatimuksiin. Siksi voisi olettaa, että projektipäälliköt olisivat samaa mieltä toteamuksesta: ”hanketta ohjaavat vaatimukset.”Tutkimustulokset osoittavat, että vain 60% vastaajista sanoi, että heidän hankkeitaan ohjaavat vaatimukset. Lausunnosta eri mieltä olleista vastaajista noin 20 prosenttia ilmoitti, että heidän hankkeensa toteutetaan ilman hankesuunnitelmaa.

noin 20% kyselyyn neutraalisti vastanneista on sellaisia projektipäälliköitä, jotka eivät kokeneet projekteissaan mitään soveltamisalan muutosta. Kaikki muut vastaajat, jotka olivat samaa mieltä tai eri mieltä kannanotosta, ovat kokeneet soveltamisalan muutoksen ainakin kerran nykyisissä hankkeissaan.

yleisesti ottaen, jos hanketta ei toteuteta sen suunnitelman mukaisesti, voidaan olettaa, että vaatimuksia ei ole yksilöity tai että projektin vaatimusten odotetaan muuttuvan toteutuksen aikana. Tässä tutkimuksessa ei kuitenkaan voida muodostaa tällaista yhteyttä ”hankkeen toteuttaminen ilman hankesuunnitelmaa” ja ”hanke ei ole vaatimusten ohjaama” välille, koska vain 50% toisen lausunnon hyväksyneistä on myös johtanut hankkeita ilman suunnitelmaa.

sopeutumiskyky muutokseen

kahdeksantoista 20 hankkeesta on vastannut hankkeessa tapahtuneisiin muutoksiin onnistuneesti. Sopeutumiskykyä muutokseen pidetään ensisijaisena ominaisuutena sille, että hanke on ehdolla käyttämään ketteriä projektinhallintamenetelmiä. Tässä tutkimuksessa edustetut IT-konsultointihankkeet ovat osoittaneet, että ne ovat sopeutumiskykyisiä käsittelemään soveltamisalan muutoksia.

projektinhallinnassa saavutetut odotetut tulokset

tulokset viittaavat siihen, että asiakas on tyytyväinen lopputulokseen useimmissa hankkeissa (70%). Nämä vastaukset eivät kuitenkaan liittyneet muihin tärkeisiin kyselykysymyksiin projektin etenemisestä ja projektipäällikön näkökulmasta kehitetystä tuotteesta. Syyt ovat ilmeiset. Hankkeet kokivat vielä aikaa ja kustannusylityksiä. Vaikka lopputulos ohjelmistotuotteen toimittamisessa on tyydyttävä, projektinhallintaprosesseja ei toteutettu onnistuneesti. Johtopäätöksenä voisi olla, että perinteisten projektinhallintakäytäntöjen, kuten virstanpylväiden, seurannan ja valvonnan, käyttöönotto olisi auttanut projektin onnistunutta hallintaa.

Kasvokkaisen viestinnän merkitys verrattuna prosesseihin

viestintä on avain hankkeisiin liittyvien roolien, vastuiden, politiikkojen ja menettelyjen ymmärtämiseen ja yhteistyön edistämiseen. Viime kädessä viestintä johtaa yhtenäiseen projektiryhmään ja kannustaa tiimin jäseniä yhteistyöhön ja päätöksentekoon. Seitsemän kymmenestä tutkimukseen osallistuneesta projektipäälliköstä oli sitä mieltä, että kasvokkain tapahtuvalle vuorovaikutukselle ja lyhyemmille viestintäketjuille annettiin enemmän merkitystä kuin prosesseille ja työkaluille.

tulokset osoittavat, että kasvokkaisen viestinnän merkitys ja viestintävälineet liittyvät vahvasti toisiinsa projektiryhmän jäsenten keskuudessa. Ne, jotka olivat eri mieltä siitä, että kasvokkainen viestintä on tärkeämpää kuin projektiprosessit, ovat käyttäneet epävirallista viestintää projektiryhmän jäsenten keskuudessa, kun taas ne, jotka pitivät kasvokkaista viestintää tärkeämpänä, ovat käyttäneet sekä virallista että epävirallista viestintää.

projektin toteutukseen keskittyminen dokumentaation sijaan

projektidokumentaatio jää usein huomiotta, minkä vuoksi organisaatioilta viedään tärkeitä kokemuksia projektisuunnittelusta ja toteutuksesta. Ottaen huomioon, että kaikki tässä tutkimuksessa edustettuina olevat hankkeet ovat liittohallituksen hankkeita, on mielenkiintoista huomata, että 70% vastanneista projektipäälliköistä oli samaa mieltä siitä, että heidän tiiminsä keskittyivät projektin toteuttamiseen verrattuna kattavan dokumentaation luomiseen. Muutamissa tapauksissa, joissa projektipäälliköt ovat pitäneet dokumentointia tärkeämpänä kuin projektin toteuttamista, lisätutkimuksissa kävi ilmi, että asiakas oli kaikissa tapauksissa epävarma hankkeesta.

asiakasyhteistyö yli sopimusneuvottelujen

sopimusneuvottelut ovat olennainen osa ulkopuolisia projekteja. Neuvotteluissa molemmat osapuolet keskittyisivät oman etunsa suojelemiseen. Sopimusneuvottelut voivat tapahtua projektin eri vaiheissa. On toivottavaa, että näitä kysymyksiä käsitellään yhteistyössä erityisesti hankkeen toteuttamisen aikana; muuten se johtaa ongelmiin, kuten sopimuksen jatkamiseen. Koska kaikki tässä tutkimuksessa edustetut hankkeet ovat sopimuksia, on rohkaisevaa huomata, että yli puolet vastanneista projektipäälliköistä (60%) pitää asiakasyhteistyötä tärkeämpänä kuin sopimusneuvotteluja. He ehdottivat, että yhteistyö toimii paremmin projektitiimeissä.

jos oli erimielisyyttä, mikä viittaa siihen, että yhteistyö ei ole yhtä tärkeää kuin neuvottelut, näihin hankkeisiin liittyi kaksi mielenkiintoista seikkaa. Kaikissa muissa hankkeissa käytettiin suoraa kontaktia kommunikaation välineenä hankkeen sidosryhmien kanssa, mutta näissä hankkeissa käytettiin komentoketjuista viestintää ja asiakas oli myös epävarma hankkeesta. Molemmat tekijät merkitsevät vaikeita yhteistyöedellytyksiä.

hankkeeseen ja tarkkaan määriteltyyn hankkeen laajuuteen

hankkeisiin liittyy yleensä epävarmuuksia ja tuntemattomia tekijöitä, jotka johtavat epäselvyyteen. Tämän vuoksi hankkeen alkuvaiheessa ei voida laatia yksityiskohtaisia soveltamisaloja ja eritelmiä. Hankkeen laajuus muuttuu jatkuvasti koko hankkeen ajan. Joskus myös hankkeen alkuperäiset tavoitteet voivat muuttua. Tutkituista hankkeista 40 prosentilla on hyvin määritelty soveltamisala, kun taas 45 prosentilla ei.

80% hankkeista koki kuitenkin soveltamisalan muutoksen ainakin kerran,mikä vahvistaa aiemmin esitetyt väitteet.

Projektinhallintakäytännöt ja PMBOK® Guide projektin elinkaari

PMBOK® Guide on kehittänyt yksityiskohtaisen projektinhallinnan elinkaariprosessin; se on kattava ja kattava. PMBOK® Guide-projektinhallinnan elinkaaren jokaista prosessia ei kuitenkaan tarvitse soveltaa jokaiseen projektiin. Sen hyväksymisen olisi oltava hankekohtaista. Odotetusti 45% projektipäälliköistä noudatti PMBOK® Guide-hankkeen elinkaaren projektinhallintakäytäntöjä ja 45% ei noudattanut.

iteratiivinen tai vaiheittainen hankesuunnittelu

soveltamisalan määrittely ja projektinhallintasuunnitelma ovat osa hankesuunnitelmaa. Kuten aiemmin todettiin, soveltamisalan ja eritelmien yksityiskohtaista kehittämistä ei voida kehittää hankkeen alkuvaiheessa. Näin ollen hankkeen laajuus muuttuu jatkuvasti koko hankkeen ajan, mikä korostaa iteratiivisen tai vaiheittaisen hankesuunnittelun merkitystä, mikä on ketterän menetelmän tärkeä ominaisuus. Kun kysyttiin, noudatetaanko hankkeessa iteratiivista vai vaiheittaista hankesuunnittelua vai ei, puolet vastaajista vastasi Kyllä ja vain 15 prosenttia ei noudattanut iteratiivista hankesuunnittelua. On mielenkiintoista huomata, että kaikilla iteratiivisesta hankesuunnittelusta eri mieltä olleilla ei ollut hankesuunnitelmaa.

dokumentointi ja standardien noudattaminen

projektidokumentaatio toimii referenssinä historiatietojen analysoinnissa ja auttaa organisaatioita jatkuvasti parantamaan projektinhallintaprosesseja ja kehittämään standardeja. Dokumentaatio auttaa myös tunnistamaan saadut kokemukset ja muuttamaan projektinhallintajärjestelmiä, jotka johtavat projektinhallinnan kypsyyteen. OMB300 ja ISO9000 toimivat oppaina projektidokumentointijärjestelmien suunnittelussa. Erityisesti monien hallituksen hankkeiden on noudatettava OMB300-suuntaviivoja. Vastaajista 80% kertoi, että heidän HALLINNOIMISSAAN IT-projekteissa oli dokumentointivaatimuksia, kuten ISO9000: n ja OMB300: n kaltaisten standardien noudattaminen. Näitä IT-konsultointihankkeita koskevia vaatimuksia sovelletaan kuitenkin rajoitetusti.

käyttäjien Hyväksymistestit

asiakastyytyväisyys on projektin tuotettavien tuotteiden laadun ja menestyksen ensisijainen mittari. Siksi käyttäjien hyväksymistestausmenettelyjä pidetään tärkeinä. Myös vähemmän konkreettisissa projektituotteissa, kuten palveluissa, projektin onnistumisen taustalla on asiakastyytyväisyys. Se on kuitenkin subjektiivista. Vain 30 prosenttia vastaajista kertoi noudattaneensa käyttäjien hyväksymistestejä koko projektin ajan ja 45 prosenttia ei.

valtuutus tehdä projektiin liittyviä päätöksiä

yleisesti ottaen projektipäälliköille tulisi antaa vapaat kädet tehdä projektiin liittyviä päätöksiä ilman asiakkaan väliintuloa, jos näillä päätöksillä ei ole merkittävää vaikutusta projektin laajuuteen tai projektin tuotoksiin. Vain 15 prosenttia oli samaa mieltä siitä, että projektipäälliköllä on valtuudet tehdä projektiin liittyviä päätöksiä ilman asiakkaan puuttumista asiaan. Noin 40 prosenttia pysyi neutraalina ja loput 45 prosenttia sanoivat, ettei projektipäälliköllä ollut tätä valtaa. Koska nämä hankkeet ovat ulkoisia ja hallituksen hankkeita, nämä tulokset ovat järkeviä.

johtopäätös

tutkimustuloksemme osoittavat, että suurin osa hankkeista perustuu vaatimuksiin. Lähes kaikki tässä tutkimuksessa esitetyt hankkeet osoittivat, että ne ovat sopeutumiskykyisiä muutoksiin. Epävirallista viestintää pidetään tärkeämpänä kuin virallisia prosesseja ja järjestelmiä. Ottaen huomioon, että tutkimuksen projektit liittyvät hallituksen työhön, tulokset osoittavat projektiryhmän keskittyneen projektin toteuttamiseen kattavan dokumentaation kautta. Lisäksi asiakasyhteistyö yli sopimusneuvottelujen toimii paremmin projektitiimeissä. Usein tapahtuva projektin laajuuden muutos merkitsee iteratiivisen tai vaiheittaisen hankesuunnittelun merkitystä; ketterän projektinhallinnan tärkeä ominaisuus. Koska kaikki tässä tutkimuksessa edustetut IT-konsultointiprojektit ovat sopimuksia, tutkimustulokset kannustavat ottamaan muodollisesti käyttöön ketteriä menetelmiä IT-konsultointiprojekteissa ja yhdistämään ne perinteisiin projektinhallintakäytäntöihin, kuten suunnitelmalähtöiseen virstanpylväiden kehittämiseen ja seurantaan, käyttäjien hyväksymismenettelyihin ja laadunhallintakäytäntöihin.

ketterän menetelmän soveltuvuus hankkeisiin on sopimusvelvoite, joka liittyy projektisuunnittelua, seurantaa ja valvontaa koskeviin asiakirjoihin. Liittohallitukseen liittyvillä hankkeilla on yleensä merkittäviä dokumentointivaatimuksia, kuten ISO9000: n ja OMB300: n kaltaisten standardien noudattaminen; meidän tulisi noudattaa varovaisuutta ketterän menetelmän muuttamisessa tällaisissa hankkeissa.

haasteena on säilyttää ketteryys, nopea reagointi muutoksiin, joustavat ja yksinkertaiset suunnitelmat, jatkuva integraatio ja muut ketterän menetelmän edut samalla kun siihen sisällytetään joitakin perinteisten projektinhallintakäytäntöjen kattavia prosesseja.