Projektien hallinta: perinteinen, toistuva vai hybridi?

Kuten useimmat projektipäälliköt ja organisaatiot, sinäkin todennäköisesti kamppailet sen kanssa, mikä toteutustapa olisi paras. Useimmat meistä tunnistavat, että perinteiset lähestymistavat eivät takaa onnistunutta toimitusta, ja etsimme aina parempaa tapaa.

Ketterät tai iteratiiviset kehitystekniikat ovat saaneet viime vuosina paljon erittäin positiivista näkyvyyttä merkittävänä parannuksena, mikä on parantanut projektin onnistunutta toimitusta. Siksi, kuten useimmat tämän päivän organisaatiot, myös sinun organisaatiosi pohtii todennäköisesti, missä ja miten näitä ketteriä tai iteratiivisia kehitystekniikoita voidaan parhaiten käyttää toimitusaikataulun ja projektien onnistumisen parantamiseen.

Lyhyesti sanottuna iteratiivisissa kehitystekniikoissa projektin toiminnallisuus suunnitellaan, kehitetään ja otetaan käyttöön pienissä osissa tai iteraatioissa. Onnistuneen iteratiivisen toimituksen avain on se, että jokainen pieni osa toimii käytännössä pienempänä alaprojektina kokonaisprojektin puitteissa. Tämän ansiosta jokaisen alaprojektin iteraation työmäärä voidaan arvioida paremmin kahden viikon iteraatiota varten kuin kahden vuoden suunnitelmassa. Lisäksi, koska suunnittelemme kahden viikon jaksoissa, voimme helposti mukauttaa seuraavien kahden viikon suunnitelmaa havaittuihin muutoksiin.

Ketterä ja perinteinen tapaustutkimus

Haluan pysähtyä hetkeksi kuvaamaan ei-teknistä tilannetta, jossa saatiin parempi tulos käyttämällä ketterää lähestymistapaa kuin perinteistä suunnitelmaa.

Käytetään esimerkkinä koko päivän toimien suunnittelua – se on projekti. Kuten suuressa projektissa, tähän liittyy paljon epävarmuutta ja riskejä. Emme tiedä, mitä lounaan jälkeen tapahtuu ja mikä voi vaikuttaa suunnitelmaamme. Perinteisesti kuitenkin laadimme kattavan suunnitelman siitä, mitä aiomme tehdä joka tunti päivässä, kun heräämme kello kuusi ja menemme nukkumaan kello yksitoista.

Kello yhdeksään mennessä olemme aikataulusta myöhässä, koska liikenne viivästytti työpaikalle pääsyä. Kello kymmeneltä meidät kutsutaan hätäkokoukseen. Puoleenpäivään mennessä ainoa päivän tehtävä, joka on saatu valmiiksi, on toimistolle pääsy, ja sekin on myöhässä.

Nyt käsitellään tätä ketteränä projektina, jossa suunnittelemme vain seuraavan iteraation: valmistaudutaan lähtemään kotoa. Tarinat ovat siis suihku, aamiainen ja lasten vieminen kouluun. Kaikki tämä toimitettiin onnistuneesti ajallaan ja budjetissa.

Siksi suunnittelemme luottavaisina seuraavan iteraation, joka on pääsy toimistolle. Siihen kuuluvat ajo parkkipaikalle, lähijunan ottaminen asemalle ja sitten kaupunkibussilla toimistolle.

Tämä ei toteudu kovin hyvin: ensimmäisessä tarinassa, ajo parkkipaikalle, on liikenteeseen liittyviä ongelmia, joten muutamme käyttäjätarinan muotoon ajo toimistolle ja sovimme, että kaksi muuta tarinaa voidaan poistaa iteraatiosuunnitelmasta. Saapumisen jälkeen suunnittelemme seuraavan iteraation. Mutta suunnittelusyklin puolivälissä lisätään uusi tarina, hätäkokous, ja se vie koko seuraavan iteraation.

Lopulta lounaan jälkeen asiat rauhoittuvat, ja voimme tarkastella tarinajonoa ja aloittaa korkean prioriteetin tehtävistä. Saamme valmiiksi onnistuneesti kaksi iteraatiota, joissa käsitellään iltapäivällä korkeimman prioriteetin kohteet.

Jos olisimme pysyneet perinteisessä suunnitelmassa, emme olisi koskaan saaneet näitä korkeimman prioriteetin kohteita valmiiksi, koska ne siirrettiin seuraavalle päivälle suunnitelman viivästymisen vuoksi, jonka työmatka toimistolle aiheutti.

Mikä on paras lähestymistapa – ketterä, perinteinen vai hybridi?

Juuri tämä joustavuus mukautua muuttuviin liiketoimintatarpeisiin on ketterien tai iteratiivisten menetelmien vahvuus, ja siksi monet organisaatiot ottavat niitä käyttöön. MUTTA onko organisaatiosi todella valmis siirtymään täysin ketterään toimintatapaan? Kokemukseni mukaan täyteen ketterään malliin siirtymistä estää usein monia asioita, erityisesti vakiintuneet organisaation käytännöt, jotka ovat usein vain osittain yhteensopivia ketterien lähestymistapojen kanssa.

Käytännöt, kuten se, että ennen projektin hyväksymistä tarvitaan tarkka budjetti, hyötyjen toteutumista kuvaava selvitys ja tavoitepäivä, ovat tärkeitä, mutta eivät oikeastaan ketteriä. Vastaavasti organisaation toteutuskäytäntöjen noudattaminen sen varmistamiseksi, ettei olemassa oleviin toimintoihin kohdistu vaikutuksia, on kriittistä, mutta se ei todellakaan ole ketterää.

Tämän vuoksi monet organisaatiot kamppailevat sen kanssa, miten säilyttää joitakin keskeisiä perinteisiä prosesseja ja samalla mukautua iteratiivisiin menetelmiin. Vastaus on hybridi toimitusmalli. Projektin osia voidaan toimittaa perinteisillä hallintamenetelmillä, ja toiset osat voivat olla iteratiivisia.

Hybriditoimitusmalli

Yleisin hybridimalli, johon olen törmännyt, tukee perinteistä projektin käynnistystä ja suunnittelua. Sen jälkeen tulee sarja iteraatioita, joiden välissä on taukoja perinteisille toteutustoimille julkaisuja varten. Tämän jälkeen seuraa taas uusi sarja iteraatioita ja perinteistä toteutusta.

Tässä mallissa laadin perinteisen toimituspohjaisen työn jakautumisen rakenteen eli WBS:n, joka määrittää organisaatiossa projektin hyväksymiseen tarvittavat keskeiset toimitukset, kuten projektin määritelmän, projektinhallintasuunnitelman ja projektin budjetin.

Näitä alussa tehtäviä toimituksia voidaan kehittää ja hallita perinteisillä menetelmillä, jotta johto näkee, että tämä projekti on sopiva ja hyvä kohde resurssien sijoittamiselle.

Kun projekti on hyväksytty, se voi siirtyä iteratiiviseen toimintatapaan, jossa ylläpidetään tarinajonoa ja korkean prioriteetin tarinat valitaan ja toteutetaan kokonaan seuraavassa iteraatiossa. Projektin näkymä muuttuu perinteisestä Gantt-kaaviosta vuorovaikutteiseksi vedä ja pudota -taulukoksi, joka mahdollistaa tarinoiden dynaamisen kohdistamisen iteraatioihin.

Tuoteomistaja voi milloin tahansa, usein päivittäin, lisätä, poistaa ja muuttaa tarinoita tarinajonossa, jotta ne vastaavat muuttuvia liiketoimintatarpeita.

Jokaisen iteraation lopussa pysähdymme tekemään retrospektiivisen arvion onnistumisista ja epäonnistumisista ja teemme muutokset tarvittavien parannusten toteuttamiseksi. Seuraavaksi, ja mikä tärkeintä, käymme läpi tuotteen tarinajonon ja valitsemme tärkeimmät tarinat seuraavan iteraation ehdokkaiksi. Tämä lähestymistapa varmistaa, että projektissa tehdään aina tarkoituksenmukaisinta ja arvokkainta työtä.

Kunkin iteraation aikana tiimi voi käyttää ketteriä periaatteita, kuten päivittäistä pikakokousta, ja keskustella nykyiseen iteraatioon ajoitettujen tarinoiden tilasta. Näin tiimillä on täysi hallinta iteraation aikana tehtävään työhön, ja samalla varmistetaan, että koko projekti pysyy ajan tasalla ja käytettävissä yritystason raportointiin resurssikapasiteetin sekä portfolio- ja ohjelmatilan osalta.

Ketterien periaatteiden avain on kyky toteuttaa lopullinen ratkaisu pieninä julkaisuina. Tämän etuna on, että alustavaa toiminnallisuutta voidaan käyttää joidenkin odotettujen liiketoimintahyötyjen saavuttamiseen mahdollisimman nopeasti.

Lisäksi ratkaisu voidaan validoida varhaisessa vaiheessa, joten mahdolliset muutokset voidaan helposti huomioida tuotteen tarinajonon jäljellä olevissa tarinoissa. Siksi heti, kun riittävä määrä korkean prioriteetin tarinoita on saatu valmiiksi iteraatioissa, projekti siirtyisi takaisin perinteiseen vaiheeseen ja toteuttaisi organisaation vaatimat tavanomaiset käyttöönottotehtävät.

Kokeile Microsoft Projectia maksutta

Kokeile Microsoft Projectia kuukauden ajan maksutta

Tutustu

Nämä julkaisu- ja käyttöönottotoimet suunnitellaan ja ohjataan perinteisillä lähestymistavoilla, ja ne varmistavat, että määritettyjä prosesseja noudatetaan, jotta uudet projektit voidaan ottaa käyttöön ilman vaikutuksia olemassa oleviin toimintoihin.

Kun ensimmäinen julkaisu on valmis, projekti palaa ketteriin lähestymistapoihin ja alkaa käydä läpi uuden iteraatiosarjan, jotta jäljellä olevien tarinoiden kehitys voi jatkua.

Vaikka tämä vaiheittainen tapa yhdistää ketteriä ja perinteisiä lähestymistapoja on yleisin, lähestymistapoja voi yhdistää myös tiettyjen projektitoimitusvaatimusten tukemiseksi. Esimerkiksi johdin projektia, jossa uuden tuotteen käyttöönotto erittäin säännellyllä toimialalla edellytti poikkeuksellisen korkeaa vaatimustenmukaisuuden ja validoinnin tasoa. Siksi suurin osa projektistani suunniteltiin ja ohjattiin perinteisillä menetelmillä.

Projektissa oli kuitenkin liiketoimintatiedon osuus, jossa yritykseni analysoi järjestelmän tuottamaa valtavaa suorituskykytietojen määrää. Tätä osuutta tuettiin parhaiten ketterällä lähestymistavalla. Projektin BI-osiossa, joka eteni rinnakkain perinteisen työn kanssa, valitsimme korkeimman prioriteetin tarinat – ne, jotka voitaisiin saada valmiiksi kolmen viikon sprintissä – ja toteuttaisimme yhden iteraation.

Koska monet näistä tarinoista olivat luonteeltaan tutkivia, loisimme usein uusia tarinoita joko lisäselvitystä tai tiettyjen suorituskykyraporttien luomista varten. Nämä lisättiin yksinkertaisesti käsiteltävien tehtävien luetteloon seuraavaa sprinttiä varten.

Tällä lähestymistavalla minulla oli yksi projektiaikataulu, joka varmisti, että sain kaikki raportointi- ja sääntelyvaiheet tehtyä, mutta joka samalla antoi hyvin joustavan tavan kehittää projektin sääntelemätöntä liiketoimintaraportoinnin osaa.

Kun kaikki työ oli yhdessä aikataulussa, saimme yhden näkymän kaikkeen, mitä projektissa tapahtui:

Tarvittava tieto resurssien kohdistamiseen sopivimpiin tehtäviin, oli ne sitten perinteisiä tai ketteriä, oli heti käytettävissä

Mahdollisuus luoda vaikuttavia viikko- ja kuukausiraportteja oli käytettävissä

Ketterä toimintamalli on erittäin tehokas projektitoimitustapa, jonka pitäisi tarjota merkittäviä hyötyjä organisaatiosi koko projektitoimituksen työkalupakkiin. Sitä voi käyttää itsenäisenä ratkaisuna, osana vaiheittaista toimitustapaa tai integroituna hybridirakenteeseen.

Tärkeintä on ottaa käyttöön ketterät periaatteet, jotka auttavat organisaatiotasi onnistumaan toimituksissa, samalla kun noudatat perinteisiä prosesseja, joiden avulla organisaatiosi on tähän asti menestynyt.

Steve Caseleyllä on yli 35 vuoden kokemus Microsoft Projectista, ja hän on käyttänyt Microsoft Projectia aktiivisesti sen ensimmäisestä julkaisusta lähtien. Hän on useiden Microsoft Projectiin ja projektinhallinnan parhaisiin käytäntöihin liittyvien kirjojen toimittaja. Hän on pääkonsultti Sensei Project Solutionsissa, jossa hän auttaa suuria organisaatioita saavuttamaan erinomaisia tuloksia projektitoimituksissa Microsoft Project Portfolio Managementin (PPM) työkalujen avulla.

AIHEESEEN LIITTYVÄT TUOTTEET
Office 365

Microsoft 365:n käytön aloittaminen

Tuttu Office ja yhteistyötä helpottavat työkalut, joilla työnteko on helpompaa sekä tehokkaampaa missä ja milloin vain.

Osta nyt

Aiheeseen liittyvä sisältö

Liiketoiminnan hallinta

Miksi johto inhoaa projektipäälliköitä?

Lue lisää

Liiketoiminnan tiedot ja ideat -palveluun ei sisälly ammattimaista vero- eikä rahoitusneuvontaa. Ota yhteys omaan vero- tai rahoitusneuvojaasi, jos haluat keskustella tilanteestasi.