Onko projekti vaatimusten täyttämistä vai lisäarvon tuottamista?

Perinteinen projektinhallintanäkemys lähtee siitä, että asiakkaalla on tietty joukko vaatimuksia, jotka toimittajan on täytettävä. Projektin alkuun nämä vaatimukset on analysoitava (kaikki vaatimukset), ja sitten suunniteltava sellainen projekti, joka täyttää nämä vaatimukset. Projektinhallinnan tehtävä on sitten varmistaa, että kaikki nämä alkuperäiset vaatimukset tulevat täytetyiksi ja että alunperin arvatut budjettiraamit pitävät. Projektin seuranta koostuu siitä, kuinka projektille määritellyt tehtävät tulevat kukin vuorollaan tehdyksi kunnes lopulta kukin tehtävä on tehty ja voidaan siirtyä testausvaiheeseen.

Ketterä kehitys ottaa täysin erilaisen lähtökohdan: asiakkaalla on joitain tiettyjä tavoitteita, ja projektin tehtävä on tuottaa asiakkaalle lisäarvoa siten, että alkuperäiset tavoitteet täyttyvät. Tässä mallissa ei ole mielekästä seurata alunperin arvattuja vaatimuksia vaan sitä, saako asiakas investointiaan vastaavan määrän lisäarvoa. Asiaa voisi ajatella vertauskuvallisesti: sijoittamalla euron projektiin, projekti tuottaa kaksi euroa. Jos tämä toteutui, kannattanee ehdottomasti sijoittaa toinen euro. Jos sekin tuotti kaksi euroa, se oli hyvä sijoitus ja sijoittamista kannattaa jatkaa.

Näinpä projektin alussa ei ole välttämättä mielekästä rajata, kuinka monta euroa projektiin tullaan sijoittamaan: sijoittamista kannattaa jatkaa pienissä paloissa niin kauan, kun sijoituksella saadaan voittoa.

Seuraavassa taulukossa on esitetty muutama keskeinen projektin osa-alue, ja vertailtu vesiputousmallin ja ketterän kehityksen ideologista suhtautumista näihin osa-alueisiin:

Vesiputousmallin ja ketterän kehityksen asenteelliset eroavaisuudet
Osa-alue Vesiputousmalli Ketterä kehitys
Suunnittelu ja muutosprosessi Projektisuunnittelu ja tekninen suunnittelu ovat tärkeimmät aktiviteetit koko projektissa. Nämä on tehtävä heti projektin alussa ja projektin aikana seurattava suunnitelmien toteutumista sekä pidettävä muutosten määrä minimissä. Muutoksia tapahtuu aina, itse asiassa niihin kannattaa rohkaista. Suunnittelua jatketaan koko projektin ajan, eikä lopeteta toteutusvaiheen alettua. Tämän vuoksi projektin alussa kannattaa suunnitella vain sen verran, että projektin riskit tulevat tietoon ja seuraava inkrementti saadaan toteutettua.
Edistymisen mittari Tehtävien valmistuminen. Koska kaikki tarvittavat tehtävät ja niiden vaatima työmäärä on tiedossa etukäteen, voidaan projektin valmiusastetta mitata yksinkertaisesti laskemalla käytettyjen tuntien määrää ja alunperin suunniteltujen tehtävien valmiusastetta. Edistymiseksi lasketaan vain toimivat ominaisuudet, joista on asiakkaalle lisäarvoa. Yksittäisten tehtävien valmistuminen ei edistä projektia, vain nähtävissä ja käytettävissä olevat toiminnallisuudet.
Laadun määritelmä Määritysten ja suunnitelmien noudattaminen. Tämän vuoksi määrittelyt on oltava mahdollisimman hyvät heti alussa. Asiakkaan saama lisäarvo. Asiakkaan käsitys lisäarvosta voi muuttua projektin aikana. Voi olla, että asiakas ei osaa tarkoin kertoa, mitä haluaa ennenkuin on nähnyt jotain toimivaa. Tämän vuoksi, järjestelmiä on kehitettävä siten, että niitä voidaan helposti muuttaa erilaiseksi, eikä kaikkia yksityiskohtia kannata määritellä ennen kuin on pakko.
 Epävarmuuden hyväksyminen Kaikki tehtävät voidaan tunnistaa ja arvioida etukäteen, eikä epävarmuutta tarvitse hyväksyä. Epävarmuus kuuluu oleellisena osana kaikkiin projekteihin. Ennustettavuuden saavuttamiseksi on pyrittävä vähentämään epävarmuustekijöitä, mutta huomioitava, ettei niitä koskaan voida täysin poistaa.
 Projektin aikaiset välitulokset Dokumentit, mallit ja tilanneraportit ovat välttämättömiä, jotta projekti voidaan suunnitella ja jakaa tehtäviin. Vain niiden avulla voidaan seurata projektin etenemistä. Projektin aikaisten dokumenttien ainut tehtävä on vähentää epävarmuustekijöitä ja tehostaa kommunikaatiota. Muutoin ne ovat turhia.
 Projektin sujuvuuden varmistaminen Projektin lopputuotokset määräytyvät täysin aika-, resurssi-, ominaisuus- ja laaturajoitteiden mukaan. Jos jotain näistä muutetaan, on muutettava kaikkia muitakin. Vahdi pienintäkin muutosta tarkoin, ettei hallitsemattomia muutoksia pääse lipsahtamaan projektiin. Projektin rajoitteet voivat liittyä aikaan, resursseihin, ominaisuuksiin tai laatuun, mutta yhtä hyvin ne voivat liittyä muihinkin tekijöihin. Näihin keskittymisen sijaan kannattaa identifioida suurimmat projektin sujuvuutta hidastavat esteet ja poistaa ne. Ja seuraavaksi identifioida seuraavaksi pahimmat hidasteet. Tätä tehostamista on jatkettava koko ajan.
Luottamukseen suhtautuminen Ihmisiä on tarkkailtava ja verrattava heidän suoritustaan standardeihin ja määriteltyihin prosesseihin. Johdon kannattaa asettaa tulokseen pohjautuvia tulospalkkioita, joilla yksilöitä kannustetaan noudattamaan suunnitelmia. Ylpeys omasta työstä ja tiimityö ovat parempia motivaattoreita kuin henkilökohtaiset bonukset. Rehellinen läpinäkyvyys, jossa kukin tiimin jäsen näkee koko tiimin todellisen tilanteen, toimii paremmin kuin johdon asettamat tulospalkkiot.

 Luonnollisesti nämä ovat äärimmäisiä kärjistyksiä ja käytännössä usein projektin toimintapa on jossain näiden ääripäiden välillä. Kunkin projektin kohdalla olisi kuitenkin syytä miettiä, millaisella prosessilla juuri tämä projekti kannattaa viedä läpi. Tätä asiaa on käsitelty tarkemmin artikkelissa Menetelmä per projekti.