Projektinhallinnan aakkoset: M niin kuin MOSCOW

Projektin tavoitteiden tehokas priorisointi MOSCOW-menetelmällä

Mikä on MOSCOW-menetelmä?

MOSCOW-menetelmän kehitti 1990-luvulla Oraclen konsultti Dai Clegg. Se kehitettiin RAD-menetelmän (Rapid Application Development) yhteydessä, ja sen tarkoituksena oli tukea tarpeiden tunnistamista ja priorisointia nopeissa kehitysjaksoissa. Käyttöönoton jälkeen MOSCOW-menetelmä on vakiintunut eri toimialoilla, ja sitä käytetään usein ketterissä projektinhallintakehikoissa, kuten SCRUMissa ja DSDM:ssä (Dynamic Systems Development Method), joissa se auttaa projektipäälliköitä keskittymään kaikkein tärkeimpiin tehtäviin tai tavoitteisiin ja varmistamaan selkeän priorisoinnin. Tämä parantaa ajan ja resurssien käyttöä, koska olennaiset vaatimukset käsitellään ensin. Menetelmä helpottaa myös viestintää sidosryhmien kanssa, koska on selvää, mitkä vaatimukset ovat kriittisiä ja mitkä voidaan lykätä. Tämä edistää realistisia odotuksia ja parempaa suunnittelua.
Nimi ”Moscow” on lyhenne, joka kuvaa neljää tärkeintä vaatimusluokkaa: Täytyy olla (Must-Have, M), pitäisi olla (Should-Have, S), voisi olla (Could-Have, C) ja ei saa olla (Won’t-Have, W) – O-kirjaimet on lisätty vain kätevämmän lyhenteen luomiseksi, eikä niillä ole merkitystä.

MOSCOW-menetelmän luokat

Täytyy (Must – M)

Must-vaatimukset ovat välttämättömiä, ja niiden on toteuduttava, jotta projekti onnistuisi. Niistä ei voida neuvotella, sillä projektin katsotaan epäonnistuneen, jos nämä kohdat eivät täyty.

Esimerkkejä:

• Tuotteen keskeiset toiminnot, joita ilman pääasiallista tarkoitusta ei voida täyttää.
• Turvallisuustoiminnot, jotka ovat välttämättömiä lainsäädännön noudattamiseksi.
• Järjestelmän suorituskykyä tai saatavuutta koskevat vähimmäisvaatimukset.

Pitäisi (Should – S)

Tavoitevaatimukset ovat myös tärkeitä, ja ne tulisi toteuttaa aina kun se on mahdollista. Niiden puuttuminen heikentää projektin tuloksen laatua tai hyötyä. Projektin voidaan kuitenkin katsoa valmistuneen tietyin rajoituksin, jos ne eivät täyty. Tavoitevaatimusten tärkeysjärjestys on heti pakollisten vaatimusten jälkeen. Tämä tarkoittaa, että pahimmassa tapauksessa nämä vaatimukset voidaan siirtää seuraavaan projektiin, jos pakollisten vaatimusten täyttämiseen tarvitaan kaikki aika ja resurssit.

Esimerkkejä:

• Tuotteen lisätoiminnot, jotka lisäävät kilpailuetua mutta eivät ole kriittisiä.
• Ohjelmiston parannetut käyttöliittymät, jotka parantavat käyttäjäkokemusta.
• Tehokkuuden parannukset, jotka eivät ole välttämättömiä.

Voisi (Could – C)

Voi olla -vaatimukset ovat toivottavia, koska ne tarjoavat projektille suurempia hyötyjä tai lisäävät esimerkiksi mukavuutta. Nämä vaatimukset pyritään täyttämään, mutta ne eivät ole kriittisiä projektin onnistumisen kannalta, joten ne toteutetaan vain, jos aikaa ja resursseja on vielä käytettävissä sen jälkeen, kun pakolliset ja tarpeelliset vaatimukset on täytetty. Jos resurssiristiriitoja ilmenee, ”voi tehdä” -vaatimuksia ei toteuteta tai ne siirretään myöhempään projektiin.
Näillä vaatimuksilla on usein suuri merkitys eri sidosryhmien tyytyväisyyteen. Siksi on tärkeää pitää niitä silmällä ja listata ne. Tällä tavoin niitä voidaan tarkastella lähemmin ja selvittää, voidaanko ne toteuttaa ilman suurta lisävaivaa.

Esimerkkejä:

• Lisävaihtoehdot tai -asetukset, joita käytetään harvoin.
• Ohjelmiston käyttöliittymän kosmeettiset parannukset.
• Ohjelmiston parannukset, jotka helpottavat ylläpitoa tai lisäävät skaalautuvuutta, mutta joita ei tällä hetkellä tarvita.

Ei pidä (Won’t – W)

W voidaan tulkita eri tavoin:

• Won’t viittaa vaatimuksiin, joita ei ole toteutettu.
• Would tarkoittaa vaatimuksia, jotka olisivat mukavia, mutta joita ei voida toteuttaa tässä projektissa.
• Want sisältää vaatimuksia, jotka halutaan, mutta joita ei toteuteta tässä projektissa, vaan myöhemmissä projekteissa.

Yhteistä kaikille näille tulkinnoille on se, että näitä vaatimuksia ei toteuteta nykyisen projektin aikana. Ne on kuitenkin lueteltu väärinkäsitysten välttämiseksi ja niiden tietoisen lykkäämisen tai huomioon ottamisen mahdollistamiseksi tulevissa projekteissa. Tämä kategoria auttaa siten hallitsemaan projektin laajuutta ja pitämään silmällä vaatimuksia, jotka voivat olla tärkeitä myöhemmässä yhteistyössä asiakkaan kanssa.

Esimerkkejä:

• Toiminnot, jotka ovat mielenkiintoisia mutta eivät ole tällä hetkellä relevantteja.
• Vaatimukset, jotka voivat olla merkityksellisiä vasta tuotteen myöhemmissä versioissa.
• Parannukset, joita ei voida toteuttaa resurssien tai ajan puutteen vuoksi.

Miten kategoriat tulisi jakaa?

Kategorioiden jakamisen tulisi olla projektissa tasapainoista ja realistista, jotta voidaan varmistaa projektin onnistuminen ilman, että tiimi kuormittuu liikaa tai että tärkeitä näkökohtia jätetään huomiotta. Jos jaotteluun ei kiinnitetä huomiota, voi käydä niin, että kaikki vaatimukset päätyvät ”täytyy”-luokkaan, eikä silloin taas voida tehdä priorisointia. Nyrkkisäännön mukaan enintään 60-70 prosenttia kaikista vaatimuksista voi olla kriittisiä ja ne voidaan siksi luokitella ”must”-vaatimuksiksi. Näin taataan, että pääpaino on aidosti projektin kannalta olennaisissa vaatimuksissa. 20-25 prosenttia kaikista vaatimuksista on tärkeitä ja vaikuttavat merkittävästi hankkeen laatuun ja hyötyihin, joten ne luokitellaan ”pitäisi”-luokkaan. 5-10 prosenttia vaatimuksista voi kuulua luokkaan ”voisi”, ja vain 0-5 prosenttia tulisi sijoittaa viimeiseen luokkaan.

MOSCOW-menetelmän edut

• Selkeä priorisointi: Vahva painotus ensin must-have- ja sitten should-have-vaatimuksiin auttaa varmistamaan, että projektin tavoitteet saavutetaan. Samalla projektiryhmää eivät häiritse vähemmän tärkeät tarpeet.Anforderungen abgelenkt.
• Resurssien tehokas käyttö: Koska tärkeimmät vaatimukset käsitellään ensin, voidaan varmistaa, että projektin keskeiset tavoitteet saavutetaan käytettävissä olevilla resursseilla. Samalla menetelmä mahdollistaa vähemmän tärkeiden vaatimusten tarkastelun (could-have), jos käytettävissä on lisäresursseja.
• Parempi viestintä: Selkeä luokittelu helpottaa sidosryhmien ja tiimin jäsenten kanssa käytävää viestintää prioriteeteista ja projektin tavoitteista ja auttaa siten tekemään avoimia päätöksiä. Samalla kategorisointi varmistaa, että sidosryhmät ymmärtävät paremmin, mitä he voivat odottaa, mitkä vaatimukset ovat realistisesti saavutettavissa ja mitkä lykätään.
• Joustavuus ja sopeutumiskyky: Tämä menetelmä soveltuu joustavasti muuttuviin vaatimuksiin ja puitteisiin. Se on erityisen hyödyllistä ketterissä hankkeissa. Se mahdollistaa iteratiivisen lähestymistavan projektin tavoitteisiin, jolloin prioriteetteja voidaan jatkuvasti tarkistaa ja mukauttaa.

MOSCOW-menetelmän haasteet ja puttee

Monista eduistaan huolimatta MOSCOW-menetelmää käytettäessä on otettava huomioon myös joitakin mahdollisia ongelmia ja epäkohtia:

• Priorisoinnin subjektiivisuus: Eri sidosryhmillä voi olla erilaiset näkemykset siitä, mitkä vaatimukset ovat välttämättömiä ja mitkä eivät, mikä voi johtaa ristiriitoihin. Yksimielisyyden saavuttaminen priorisoinnista voi kestää kauan, erityisesti suurissa tai hajanaisissa tiimeissä.
• Pakollisten vaatimusten luokan ylikuormittuminen: On olemassa vaara, että liian monet vaatimukset luokitellaan must-have-luokkaan, mikä heikentää priorisoinnin tehokkuutta. Samalla liian suuri määrä must-have-vaatimuksia voi kuormittaa tiimiä ja vaarantaa projektin onnistumisen.
• Riippuvuuksien huomioimatta jättäminen: Menetelmä ei ota automaattisesti huomioon vaatimusten välisiä riippuvuuksia, mikä voi johtaa suunnitteluongelmiin erityisesti monimutkaisissa hankkeissa.
• Staattinen priorisointi: Erityisesti ketterissä hankkeissa prioriteetit voivat muuttua, ja niitä on mukautettava uusiin tuloksiin. Tällaisissa tapauksissa prioriteettiluettelo ei saisi olla tiukka, vaan sitä tulisi tarkistaa säännöllisesti, vaikka se merkitsisikin lisätyötä.

Yhteenveto

MOSCOW-menetelmä tarjoaa järjestelmällisen ja tehokkaan tavan priorisoida tarpeita projektinhallinnassa. Selkeän luokittelun avulla projektiryhmä voi varmistaa, että tärkeimmät tavoitteet saavutetaan ensimmäisinä ilman resurssien haaskaamista tai painopisteen menettämistä. Joistakin haasteista, kuten priorisoinnin mahdollisesta subjektiivisuudesta ja säännöllisen mukauttamisen tarpeesta, huolimatta MOSCOW-menetelmä mahdollistaa läpinäkyvän ja joustavan projektisuunnittelun, joka parantaa sekä tehokkuutta että viestintää tiimin sisällä ja sidosryhmien kanssa.

Lisätietoja myPARM-projekti- ja portfolionhallintaohjelmistosta:

Haluaisitko tutustua myPARMiin demoesityksessä? Siinä tapauksessa voit varata ajan tapaamiseen vaikka samantien!