haaste, johon törmäämme usein työskennellessämme uusien asiakkaiden kanssa, on projektin laajuuden määritteleminen melko yksityiskohtaisella tasolla. Usein organisaatiot tietävät, mitä he haluavat kannalta korkean tason projektien tuloksia, mutta eivät ole päässeet alas pikkujuttuja – mutta sitä varten olemme täällä!
hankkeen laajuus on se osa projektisuunnittelua, johon kuuluu luettelon määrittäminen ja dokumentointi hankkeen erityistavoitteista, tuotoksista, ominaisuuksista, toiminnoista, tehtävistä, määräajoista ja viime kädessä kustannuksista. Toisin sanoen se on se, mikä on saavutettava ja mitä työtä on tehtävä hankkeen toteuttamiseksi.
on tärkeää määrittää hankkeen soveltamisala varhaisessa vaiheessa, koska se voi vaikuttaa merkittävästi hankkeen aikatauluun tai kustannuksiin (tai molempiin).
alla on katsaus joihinkin keskeisiin prosesseihin, joita on noudatettava, jotta soveltamisala voidaan määritellä oikein.
Määrittele tuotevaatimukset
ennen kuin päätämme, mikä on projektin laajuus, sinun on oltava hyvin selvillä siitä, mitkä ovat tuotevaatimukset, jotka tunnetaan myös nimellä tuotteen laajuus. Toisin sanoen, mitä toimintoja ja ominaisuuksia tarvitaan verkkosivuilla, sovellus ja/tai mittatilaustyönä ohjelmistoratkaisu kehitetään? Onko mitään erityistä, joka on sisällytettävä suunnitteluun? Onko sen noudatettava tiettyjä brändäysohjeita? Lista jatkuu.
Määrittele Prosessivaatimukset
Prosessivaatimukset kuvaa, miten ihmiset ovat vuorovaikutuksessa tuotteen kanssa ja miten tuote on vuorovaikutuksessa muiden (usein olemassa olevien) liiketoimintaprosessien kanssa. Kun keskustellaan siitä, miten data siirtyy ja miten liiketoimet kulkevat pisteestä toiseen, kuvataan prosessivaatimuksia. Esimerkiksi verkkosivuston laskutustapahtumia koskevat vaatimukset, miten tällaiset tapahtumat linkittyvät laskutukseen ja tileihin ja missä vaiheessa henkilökunta voi tarkastella ja muuttaa tilausten tilaa, on esitettävä yksityiskohtaisesti.
mukaan otetaan oikeat sidosryhmät
on tietenkin sanomattakin selvää, että hankkeen onnistuminen edellyttää, että hankkeen toimeksiantajan organisaation oikeat sidosryhmät otetaan tiiviisti mukaan hankkeen laajuuden eri vaiheisiin. Kun näin ei tapahdu, aletaan tehdä oletuksia (jotka ovat yleensä subjektiivisia) ja sidosryhmille voi syntyä sekaannusta hankkeen edetessä.
Määrittele rajoitukset
ehkä vielä tärkeämpää kuin se, mikä on hankkeen soveltamisalan ulkopuolella, on se, mikä on hankkeen soveltamisalan ulkopuolella. Usein on ratkaisevaa dokumentoida, mitä ei tehdä, varsinkin kun on kyse ohjelmistokehityksestä-muuten ihmiset olettavat, että on toteutettava tiettyjä asioita, joita ei ole budjetoitu tai sisällytetty projektin aikatauluun.
muutosjohtaminen
on luonnollista, että osa mistä tahansa suuresta projektista muuttuu matkan varrella. Vaikka on aina parasta välttää scope creep (tilanne, jossa yksi tai useampi osa hankkeen päätyy vaatii enemmän työtä), joskus se on väistämätöntä, koska muuttuva luonne liiketoimintaa. Jotta kaikki sidosryhmät, sekä asiakas-että virastopuolella, eivät aiheuttaisi erimielisyyksiä ja muuttaisi hankkeen laajuutta, on parasta, että käytössä on tiukat muutosjohtamisprosessit. Kun soveltamisala on määritelty, sitä ei saa muuttaa ilman asianmukaisia muutoksenhallintatoimintoja, jolloin voidaan ryhtyä asianmukaisiin toimiin hankkeen muuttuvien vaatimusten korjaamiseksi.
joten siinä se on! Yksinkertainen opas saada projekti pois oikealle alkuun oikein määrittelemällä projektin laajuus. Tehokas soveltamisalan hallinta edellyttää hyvää viestintää sen varmistamiseksi, että kaikki ymmärtävät hankkeen vaatimukset ja sopivat tarkasti, miten hankkeen tavoitteet saavutetaan. Kun olet tämän sängyn alas, sinulla on perusta aloittaa ja toivottavasti onnistuneesti loppuun projekti.