Kun olet vastuussa projektista, tiedät yleensä hyvin, mitä tiimisi on tehtävä täyttääkseen projektin vaatimukset. Mutta entä jos asiakkaasi keksii uuden, vaikka kuinka pienen ominaisuuden, jota sinun pitäisi alkaa työstää olemassa olevan projektin laajuuden lisäksi?
Mitä opit tämän artikkelin ansiosta:
Projektipäällikkönä tämä skenaario on varmasti sinulle tuttu, sillä projektit muuttuvat usein käyttäjien palautteen tai dynaamisten markkinaolosuhteiden vuoksi. Tämä on luonnollista, ja se voi johtaa hyvin myönteisiin tuloksiin (esimerkiksi laadukkaampaan lopputuotteeseen). On kuitenkin niin, että nämä odottamattomat muutokset voivat johtaa siihen, että projektin laajuus kasvaa niin paljon, että sinulla on hyvin vähän valtaa hallita projektin etenemistä.
Tarkastellaan tarkemmin projektin laajuuden hiipumista ja keskustellaan siitä, miten voit käsitellä sitä projektinhallintaurallasi.
Ensinnäkin, mikä on hankkeen laajuus? Projektinhallinnassa laajuudella tarkoitetaan kaikkia projektin tehtäviä, prosesseja, toimintoja, vaatimuksia ja tuotoksia. Yksinkertaisesti sanottuna se on kaikki se työ, jota vaaditaan projektin loppuun saattamiseksi.
Hankkeen laajuus on osa hankesuunnittelua. Projektinhallinnan elinkaaren tämän vaiheen tuloksena syntyy projektin laajuusselvitys. Se on dokumentaatio projektin laajuudesta (jota kutsutaan myös "laajuuslausumaksi" tai "tehtävänmäärittelyksi"), joka sisältää tarkan tarkistuslistan, joka sisältää tarkat
Kun hankkeen laajuus on määritelty, on aika siirtyä vaiheeseen, jota kutsutaan hankkeen laajuuden hallintasuunnitelmaksi. Siinä hahmotellaan koko hankkeen toteuttamiseen liittyvät prosessit, ja se toimii ohjeena, jonka avulla hanke pysyy määritellyissä odotuksissa ja rajoissa.
Helpoin tapa kuvata laajuuden hiipumista on sanoa, että se on lisäämällä ominaisuuksia ja vaatimuksia, jotka ovat sovitun projektin laajuuden ulkopuolella. Määritelmän molemmat osat ovat tärkeitä, koska projektin laajuuden muuttaminen tai laajentaminen ei välttämättä ole sama asia kuin laajuuden hiipiminen.
Päinvastoin, muutos on täysin normaali asia projektinhallinnassa. Laajuus hiipii, kun muutoksista ei sovita, ja projektin vaatimusten kasvu on hallitsematonta.
PMBOK® Guide -oppaan (5. painos) määritelmän mukaan "scope creep" on seuraavaa tuotteen tai projektin laajuuden hallitsematon laajentaminen ilman, että aikaa, kustannuksia ja resursseja mukautetaan. Tässä kuvauksessa korostetaan ratkaisevaa tekijää, jonka pitäisi auttaa sinua hahmottamaan laajuuden hiipumisen mahdollisia seurauksia. Tarkoitan sitä, miten nämä projektin laajuuteen sisältyviä uusia ominaisuuksia ei ole sovitettu aikatauluun, resursseihin tai budjetteihin. Se tarkoittaa lähinnä sitä, että mikä tahansa (tai kaikki) näistä muuttujista voi mennä pahasti pieleen ja upottaa projektisi.
Nyt kun olemme määritelleet laajuuden hiipumisen, keskustellaan sen tärkeimmistä syistä.
Scope creep johtuu todennäköisesti seuraavien tekijöiden yhdistelmästä:
Huono hankkeen laajuus. Tämä on yleensä tärkein tekijä, joka aiheuttaa laajuuden karkaamista. Kun projektin laajuus on epämääräinen tai olematon, miten voit hallita sitä? Selkeä laajuusselvitys ei kuitenkaan ole lopullinen ratkaisu tähän haasteeseen. Sinun on validoitava laajuus ja allekirjoitettava se kaikkien projektin sidosryhmien kanssa.
Toinen ongelma voi syntyä, kun et neuvottele vaatimuksista tiimisi oikeiden henkilöiden kanssa. Jotkin vaatimukset voivat esimerkiksi osoittautua teknisesti toteuttamiskelvottomiksi, vaikka niiden laajuus olisi selvä ja asiakas olisi antanut niille luvan. Siksi on tärkeää, että:
Haluatko oppia lisää tästä prosessista? Tutustu opas projektin laajuuden hallintaan. Se auttaa sinua hallitsemaan laajuutta onnistuneesti.
Laajuusriippuvuus on todennäköistä myös silloin, kun sinulla ei ole vakiintuneita menettelyjä muutospyyntöjen käsittelemiseksi. Tai ehkä olet asettanut joitakin muutoksenhallintasääntöjä, mutta sidosryhmät eivät ole niistä tietoisia. Tämän blogikirjoituksen seuraavassa osassa puhumme hieman enemmän muutosten hallinnasta, jotta ne eivät suista projektia raiteiltaan.
Yksi vähemmän odotettu syy laajuuden hiipimiseen on se, että asiakas vaikuttaa suoraan tiimisi jäseniin, jotta he lisäisivät uuden ominaisuuden tai laajentaisivat olemassa olevaa ominaisuutta. Tällaista ulkoista painostusta voi olla vaikea huomata projektipäälliköiden, varsinkin jos tiimin jäsenet eivät kerro siitä avoimesti.
Toinen mahdollinen vaara on se, että sidosryhmät osallistuvat hankkeeseen vaihtelevasti. Kuvittele tilanne, jossa asiakkaasi ei kiinnitä kovinkaan paljon huomiota hankkeen laajuuteen vaatimusten keruuvaiheessa. Ehkä heillä on kiireitä muiden asioiden kanssa tai he eivät yksinkertaisesti ole oikeasti sitoutuneet projektiin. Kun hän kuitenkin näkee työsi ensimmäiset tulokset, hän yhtäkkiä osallistuu enemmän ja alkaa keksiä uusia ominaisuuksia tai määritellä uudelleen projektin tavoitteita. Voit kuvitella, miten tämä voi helposti johtaa laajuuden kasvuun.
Lopuksi on mainittava ulkoiset tekijät, joihin et useinkaan voi vaikuttaa. Odottamattomiin skenaarioihin on vaikea varautua, mutta projektipäällikkönä sinulla pitäisi olla valmiita varasuunnitelmia. Ne auttavat sinua hallitsemaan muutoksia, vaikka ne yllättäisivätkin sinut.
Kuten huomaat, on monia mahdollisia syitä laajuuden hiipumiseen - luettelomme ei todellakaan ole tyhjentävä. Sinun on pidettävä mielessäsi, että laajuuden karkaaminen johtuu myös eri tekijöiden yhdistelmästä. Siksi on hyödyllistä tietää, miten voit mahdollisesti välttää scope creepin kokonaan.
Aluksi todettakoon, että soveltamisalan muutoksia ei kannata välttää kaikin keinoin. Jos työskentelet ketterässä ympäristössä, odotat luultavasti, että muutoksia tapahtuu. Se, mitä haluat lieventää, on laajuutesi hallitsemattoman kasvun seuraukset. Käydään läpi joitakin strategioita, joilla voidaan estää laajuuden hiipiminen:
Joidenkin projektipäälliköiden mielestä "selkeän projektin laajuuden luominen" on usein helpommin sanottu kuin tehty - ja he ovat oikeassa. Monissa hankkeissa, erityisesti innovatiivisissa hankkeissa, ei välttämättä ole 100% varmuutta siitä, miltä lopputuote näyttää. Näin on monissa ohjelmistokehityshankkeissa, joissa muutoksia tehdään usein käyttäjäpalautteen ja testien perusteella. Projektiryhmät kohtaavat vielä yhden haasteen, kun ne päättävät käyttää huipputekniikkaa tai kokeellisia ratkaisuja.
Tämä ei kuitenkaan tarkoita sitä, että laajuuden kasvaminen olisi välttämätöntä näissä tilanteissa. Voit silti lisätä mahdollisuuksiasi kohtuullisen laajuuden luomiseen aloittamalla niin sanotusta projektin selvitysvaiheesta. Se on vaihe, jonka aikana voit testata hypoteeseja, kyseenalaistaa oletuksia tai rakentaa prototyyppejä. Näin voit validoida ideasi ja tarkistaa, ovatko ehdotetut ratkaisut toteuttamiskelpoisia.
Olemme juuri keskustelleet useista parhaista käytännöistä, joilla voidaan välttää laajuuden hiipuminen, mutta entä jos se on jo tapahtunut? Ehkä se on alkanut näennäisesti pienistä muutospyynnöistä, tai ehkä sidosryhmät ovat odottaneet lisäominaisuuksia projektin käynnistämisestä lähtien. Laajuuden hiipumisen hallinta on mahdollista, ja tässä on pari vaihtoehtoa.
Ensinnäkin laajuuden hiipuminen voi tuntua lannistavalta, mutta nyt ei ole aika jäädä passiiviseksi ja lyödyksi. Hankkeet, jotka kärsivät laajuuden hiipimisestä, voivat silti onnistua hyvin.
Tutustu tarkemmin kaikkiin muutospyyntöihin ja analysoi niiden seuraukset huolellisesti. Arvioi, miten muutokset vaikuttavat projektin budjettiin ja aikatauluun. Vaikka tiimisi olisikin jo toteuttanut tietyn muutoksen, on silti arvokasta tutkia sen mahdollisia vaikutuksia muuhun projektiin.
Se on myös hyvä aika kiinnittää hieman huomiota resurssien ennustaminen. Muutospyynnöt ovat saattaneet vaikuttaa myös tähän hankkeen osa-alueeseen. Onko teillä riittävästi käytettävissä olevia tiimin jäseniä tämän hankkeen toteuttamiseen? Onko sinun palkattava/ulkoistettava joitakin henkilöitä? Ota huomioon työntekijöiden saatavuus ja ryhmän työmäärä huomioon (lue lisää työmäärän hallinta). Et halua ylikäyttää tiimisi jäseniä ja mahdollisesti jopa polttaa heitä loppuun laajuuden kasvun vuoksi.
Toinen strategia, jolla voidaan puuttua laajuuden hiipumiseen, on joidenkin alkuperäisten vaatimusten rajauksen purkaminen. Jos projektin taustatietosi on priorisoitu, sinun pitäisi pystyä tunnistamaan elementit, jotka voidaan vaihtaa uusiin lisättyihin elementteihin. Tämän seurauksena voit ostaa lisää aikaa ja kustannuksia projektin toteuttamiseen.
Kun muutospyyntöjä tulee jatkuvasti, tiimisi saattaa olla hieman hämmentynyt projektin odotuksista. Tämä puolestaan voi johtaa siihen, että kullataan ja käytetään entistä enemmän aikaa tiettyihin tehtäviin. Kannattaa tarkistaa kahdesti, että jokainen tiimikaveri ymmärtää projektin uudet vaatimukset.
Älä unohda katsoa projektin kokonaiskuvaa. Laajuus vaikuttaa myös siihen. Ehkä sinun ja projektin sidosryhmien on nyt järkevää keskustella osaprojektin (osaprojektien) luomisesta tai MVP:n käynnistämisestä? Yksi laajuuden hiipumisen varjopuolista on, että tiimit menettävät vauhtia ja projektit kestävät odotettua kauemmin. Osan projektin laajuudesta toimittaminen erillisenä julkaisuna voi auttaa saamaan vauhdin takaisin ja saada tiimisi tuntemaan, että olet saavuttanut enemmän. Tästä lähestymistavasta on myös liiketoiminnallista hyötyä: MVP:n (minimum viable product) julkaiseminen varhaisessa vaiheessa voi auttaa asiakastasi testaamaan tuotetta ja saamaan asiakkaita jo varhaisessa vaiheessa.
Lopuksi, vaikka projekti olisi joudutkin hiipumaan, sinun on silti seurattava säännöllisesti projektin tilaa. Hankeraportit auttaa sinua arvioida ryhmän suorituskykyä ja laskea kasvavan soveltamisalan vaikutukset.
Scope creep ei ole harvinainen ilmiö. Projektipäällikkönä joudut lähes varmasti kohtaamaan sen jossain vaiheessa urasi aikana. Puolet Project Management Instituten vuoden 2018 kyselyyn vastanneista oli Pulse of the Profession -tutkimus ovat kokeneet laajuuden hiipumista viimeisten 12 kuukauden aikana. Vuonna 2020, tämän kertomuksen uudempi painos osoitti, että kyvyiltään kypsemmät yritykset kärsivät vähemmän "scope creepistä" kuin kypsyysasteeltaan heikot organisaatiot (30%-47%).
Nämä oivallukset eivät ole yllättäviä, sillä vaikka laajuuden hiipuminen on potentiaalisesti tuhoisaa, se on hallittavissa, erityisesti hyvin perehtyneillä projektipäälliköillä ja johtajilla. Toivomme, että tämä blogikirjoitus on auttanut sinua löytämään keinoja, joilla voit hallita laajuuden hiipumista tiimisi eduksi.
Haluatko oppia lisää projektinhallinnasta? Tutustu muihin julkaisemiimme projektipäälliköille suunnattuihin resursseihin:
[/vc_column_text][/vc_column][/vc_row][/vc_row]
Resurssikalenterin (tai projektinhallintakalenterin, projektisuunnittelukalenterin, resurssisuunnitteluohjelmiston) avulla voit suunnitella, hallita ja jakaa resursseja tehokkaammin ja tuloksellisemmin - varsinkin jos Microsoft Excelillä oli johtava rooli...
Mikä on projektipäälliköiden perimmäinen tavoite? Toimittaa projektinsa menestyksekkäästi. PM:t itse myöntävät, että näin ei tapahdu kovin usein: viimeisimmän Pulse of the Profession -tutkimuksen mukaan alle 60% projekteista saadaan päätökseen joko...
Kapasiteetinhallinta on strategia, jolla yritykset pyrkivät hyödyntämään tuotannon tehokkuutta parhaalla mahdollisella tavalla suhteessa palvelun tai tuotteen kysyntään. Kapasiteetinhallinnan lopullisena tavoitteena on: Tunnistaa ja...