Onko sinulla kokemusta IT-projektista, joka meni maaliin ajallaan ja budjetissa? Onnittelut! Olet ollut mukana projektissa, jossa projektin laajuuden hallinta on ollut kunnossa.
Nuo kolme projektinhallinnan kulmakiveä, eli aika, raha ja projektin laajuus, ovat keskenään sidoksissa niin, ettei yhtä voi kasvattaa ilman toista. Silti tuntuu olevan enemmän sääntö kuin poikkeus, että projektin laajuus lähtee salakavalasti kasvamaan projektin aikana – ja kah – siinä on se pirullinen Scope Creep!
Asiakkaalle Scope Creep tarkoittaa joko venyvää aikataulua tai kasvavaa budjettia – yleensä molempia näistä. Kun kehitystyötä suunnitellaan, lähdetään liikkeelle keskimääräisistä arvioista ajan ja työmäärän suhteen. Toimittaja haluaa tehdä tarjouksen, joka on houkutteleva, mutta riittävän kokoinen toimivan järjestelmän toteuttamiseen. Ja vaikka kokemusta olisi kuinka paljon, ovat arviot silti aina arvioita, ei lupauksia tulevaisuudesta.
Toimittajalle siten pienikin Scope Creep aiheuttaa paineita pysyä aikataulussa ja budjetissa sekä projektipäällikölle harmaita hiuksia tämän estämiseen. Helposti lähdetään karsimaan “näkymättömästä työstä”, eli testaamisesta ja parhaiden käytäntöjen noudattamisesta versionhallinnan suhteen.
Tämä aiheuttaa väistämättä laadun heikkenemistä ja saa toimittajan näyttäytymään epäammattimaisena.
Vaikka suomen kielestä kovin nautinkin, ei Scope Creepille löydy sopivaa suomennosta. Suonette anteeksi temin käytön tästä eteenpäin.
Kun projektit vain paisuvat ja paisuvat
Syitä Scope Creepille on monia. Projektin koosta ja luonteesta riippuen voi olla hyvin vaikeaa arvioida etukäteen projektin kokonaiskustannuksia tai vaadittavaa aikaa maaliviivan ylittämiseen.
Monesti projekteille on kuitenkin määritelty reunaehtoja, kuten maksimibudjetti tai deadline. Oli toimitusmalli mikä hyvänsä, vesiputous tai ketterät menetelmät, pätevät niissä samat lainalaisuudet laajuuden hallinnan suhteen. Yksinkertaisuuden vuoksi käytän tässä ketterän menetelmän työkaluja ja termistöä.
Laajuuden hallinta lähtee projektin tavoitteiden määrittelystä.
Mitä tällä projektilla halutaan saavuttaa? Mihin lopputuotoksen pitäisi pystyä? Mitä toimintoja loppukäyttäjällä pitää olla käytettävissä? Mikä on riittävä taso toiminnallisuuksien automaatiotasolle tai käyttäjien käyttökokemukselle?
Näiden kysymysten vastaukset antavat pohjan työmääräarvioille. Nykyisin IT-projektien laajuutta arvioitaessa osataan jo ottaa melko hyvin huomioon kaikenlaiset projektin aikana vastaan tulevat yllätykset sekä myös testaukseen, tuotantoon viemiseen ja dokumentointiin tarvittava aika. Siitä huolimatta on vaikeaa vetää tiukkaa raja siihen, kuinka laaja projektin tulisi olla. Erityisen hankalia arvioitavia ovat integraatiot järjestelmien välillä.
Ketteryys ei tarkoita suunnitelmallisuuden puuttumista
Ketterässä toimitusmallissa ei monien ennakkoluuloista huolimatta heitetä suunnitelmilla vesilintua. Päinvastoin, jatkuva arviointi ja yksinkertainen matematiikka pitävät huolen siitä, että kokonaisuus pysyy hallussa.
Ketterän kehityksen perustyökaluihin kuuluvat backlog ja käyttäjätarinat. Backlog on työtehtävien lista, joka pitää sisällään kaikki projektiin kuuluvat tehtävät ja toiveet. Tehtävät on kirjoitettu käyttäjätarinan muodossa, jonka formaatti on muotoa <Kuka> tarvitsee <mitä> ja <miksi>. Käyttäjätarina on nimensä mukaisesti käyttäjän silmin kuvaama liiketoiminnallinen tarve, ei tekninen selostus tai tehtävä luoda nappi x paikkaan y.
Backlogilta poimitaan prioirisoinnin mukaisesti käyttäjätarinoita toteutettavaksi sprintille. Sprintti on ajanjakso, jonka aikana toimittajatiimi kehittää valitut tehtävät, jotka ovat sprintin päätteeksi valmiit siirrettäväksi tuotantoon. Sprintin pituus voidaan määritellä projektin tai kehitysmallin perusteella. Yleinen pituus on kaksi viikkoa, mutta se voi olla mitä tahansa viikon tai kuukauden välillä.
Käytit sitten apuna projektinhallintaohjelmistoa tai taulukkolaskentaa, oleellista on, että backlogin käyttäjätarinat on arvioitu työmäärän suhteen ja priorisointia tehdään jokaisen sprintin yhteydessä. Näin repsahtavaan laajuuteen ehditään puuttumaan ajoissa.
Käyttäjätarinan kuvauksessa tulee käydä ilmi valmiin määritelmä. Kun kyseinen käyttäjätarina saa hyväksyntätestauksessa vihreää valoa, se suljetaan ja toiminnallisuus siirretään sprintin päätteeksi tuotantoon. Kuulostaa yksinkertaiselta, eikö? Olisikin niin!
Valmiin määritelmä on aina tulkitsijasta kiinni, eikä pelkkä tekninen toiminta takaa asiakkaan tyytyväisyyttä. Kömpelö käyttäjäkokemus voi olla teknisesti periaatteessa toimiva, mutta niin vaikea käyttää, että se laskee käyttöastetta ja siten asiakkaan saamaa arvoa.
Vaikeissa tapauksissa onkin hyvä laskea käytettävyyden hiomiseen käytetty aika pelkän teknisen toteutuksen lisäksi. Kun pitää mielessä asiakkaan liiketoiminnallisen tavoitteen osana projektin ydintä, on helpompi tehdä oikeita valintoja laajuuden hallinnan suhteen.
Läpinäkyvyys hyödyttää kaikkia
Läpinäkyvyys projektin suunnittelun ja toimituksen osalta poistaa painetta toimittajapuolelta laajuuden hallinnassa.
Asiakkaan on helpompi ymmärtää kokonaiskuva ja riippuvaisuudet osien välillä, kun niistä viestitään avoimesti ja säännöllisesti. Ylimääräiset pyynnöt ja toiveet vähenevät, kun koko toteutus on laskettu auki lukujen valossa.
Asiakkaankin on helppo nähdä, ettei uusia toiminnallisuuksia ehditä tekemään annetussa ajassa, kun kaikki työtehtävät on arvioitu etukäteen.
Mikään määrä ruotimista käyttäjätarinoiden osalta ei riitä, jos projektin omistaja ei osaa tai halua tehdä kipeitä valintoja. Koska sitä onnistuminen toden totta vaatii. Yhden asian priorisoimista toisen edelle.
Kun pannaan kova kovaa vastaan, kaikki käyttäjätarinat eivät ole samanarvoisia. Tarpeet voivat myös muuttua projektin aikana; siksi priorisoinnin tulee olla jatkuvaa.
Toimituspuolella voit olla titteliltäsi Scrum Master tai Projektipäällikkö. Siihen ei kuitenkaan kuulu käyttäjätarinoiden priorisointia. Se on puhtaasti asiakkaan tehtävä, oli projektin sisällä titteli mikä hyvänsä. Olen todennut hyväksi välineeksi hintalapun käyttämisen, kun asiakas haluaa venyttää käyttäjätarinan sisältöä.
Asiakas: “Muuten hyvä tää toiminnallisuus mut saisko tohon jokaiselle ruudulle meidän logon kivasti vilkkuvaloilla höystettynä?”
Minä: “Saa. Karkea arvio sille on kaksi päivää. Jätetäänkö jotain pois tulevalta sprintiltä vai nostetaanko budjettia x eurolla?”
Yhtäkkiä lisäpyynnöt vähenevät kummasti, kun pienemmällekin asialle annetaan kaksi konkreettista vaihtoehtoa, joilla on seurauksia.
Konsultin tai koodarin työstä tulee käsinkosketeltavaa, eikä iso projekti ole enää vain epämääräinen musta aukko, joka imee rahaa. Olemme yhtä tiimiä, joilla on sama tavoite: saattaa projekti maaliin annetussa ajassa ja budjetissa. Ilman Scope Creepiä.