Kui olete projekti eest vastutav, teate tavaliselt väga hästi, mida teie meeskond peab tegema, et täita projekti nõudeid. Aga mis siis, kui teie klient tuleb välja uue funktsiooniga, olgu see kui tahes väike, millega te peaksite hakkama tegelema lisaks olemasolevale projekti ulatusele?
Mida te tänu sellele artiklile saate teada:
Projektijuhina olete tõenäoliselt tuttav selle stsenaariumiga, sest projektid muutuvad sageli kasutajate tagasiside või dünaamiliste turutingimuste tõttu. See on loomulik ja võib viia väga positiivsete tulemusteni (näiteks parema kvaliteediga lõpptoode). Kuid asi on selles, et need ootamatud muudatused võivad põhjustada ulatuse kerkimist nii, et teil on väga vähe kontrolli projekti edenemise üle.
Vaatleme lähemalt projekti ulatuse muutumist ja arutame, kuidas sellega oma projektijuhtimise karjääris toime tulla.
Esiteks, milline on projekti ulatus? Projektijuhtimises mõistetakse ulatuse all kõiki projekti ülesandeid, protsesse, tegevusi, nõudeid ja tulemusi. Lihtsamalt öeldes on see kogu töö, mida nõutakse projekti lõpuleviimiseks.
Projekti ulatus on osa projekti planeerimisest. Projektijuhtimise elutsükli selle etapi tulemus on projekti ulatuse aruanne. See on projekti ulatuse dokumentatsioon (mida nimetatakse ka "ulatusdeklaratsiooniks" või "lähteülesandeks"), mis sisaldab kehtestatud kontrollnimekirja täpsete
Kui projekti ulatus on kindlaks määratud, on aeg alustada faasi, mida nimetatakse projekti ulatuse juhtimise plaaniks. Selles kirjeldatakse kogu projekti elluviimisega seotud protsessid ja see on suunis, et hoida projekti määratletud ootuste ja piiride piires.
Kõige lihtsam viis kirjeldada scope creep'i on öelda, et see on lisades funktsioone ja nõudeid, mis ületavad kokkulepitud projekti ulatust. Selle määratluse mõlemad osad on olulised, sest projekti ulatuse muutmine või laiendamine ei ole tingimata sama, mis ulatuse muutumine.
Vastupidi, muutused on projektijuhtimises täiesti normaalne asi. Ulatus hiilib, kui muudatustes ei ole kokku lepitud, ja projekti nõuete suurenemine on kontrollimatu.
PMBOK® Guide'i (5. väljaanne) definitsioonis on öeldud, et scope creep on toote või projekti ulatuse kontrollimatu laiendamine ilma aja, kulude ja ressursside kohandamiseta. Selles kirjelduses rõhutatakse üht olulist tegurit, mis peaks aitama teil ette kujutada võimalikke tagajärgi, mis võivad tekkida, kui töö ulatus on vähenenud. Ma räägin sellest, kuidas need projekti ulatuse uusi funktsioone ei kohandata ajakava, ressursside või eelarvega. See tähendab sisuliselt, et mis tahes (või kõik) neist muutujatest võivad minna väga valesti ja teie projekt uppuda.
Nüüd, kui me oleme defineerinud scope creepi, arutame selle peamisi põhjusi.
Ulatuse vähenemine on tõenäoliselt tingitud järgmiste tegurite kombinatsioonist:
Kehv projekti ulatus. See on tavaliselt peamine tegur, mis aitab kaasa ulatuse muutumisele. Kui teie projekti ulatus on ebamäärane või olematu, kuidas saate seda kontrollida? Selge ulatusdeklaratsioon ei ole aga selle probleemi lõplik lahendus. Teil tuleb ulatus kinnitada ja allkirjastada see koos kõigi projekti sidusrühmadega.
Veel üks probleem võib tekkida siis, kui te ei konsulteeri oma meeskonna õigete inimestega nõuete üle. Näiteks võib selguda, et mõned nõuded ei ole tehniliselt teostatavad, isegi kui teie ulatus on selge ja teie klient on andnud selleks loa. Seepärast on oluline, et te:
Tahad selle protsessi kohta rohkem teada saada? Vaadake meie projekti ulatuse juhtimise juhend. See aitab teil edukalt hallata reguleerimisala.
Ulatuse suurenemine on tõenäoline ka siis, kui teil ei ole kehtestatud menetlusi muudatuste taotluste käsitlemiseks. Või olete kehtestanud mõned muudatuste kontrollimise eeskirjad, kuid sidusrühmad ei ole neist teadlikud. Selle blogipostituse järgmises osas räägime veidi rohkem muudatuste haldamisest, et need ei viiks teie projekti rööbastelt kõrvale.
Üks vähem oodatud põhjuseid, miks ulatus on suurenenud, on see, kui klient mõjutab teie meeskonnaliikmeid otseselt uue funktsiooni lisamisel või olemasoleva laiendamisel. Sellist välist survet võib projektijuhtidel olla raske märgata, eriti kui meeskonnaliikmed ei anna sellest läbipaistvalt teada.
Veel üks võimalik oht on see, kui sidusrühmad osalevad projektis erinevalt. Kujutage ette olukorda, kus teie klient ei pööra nõuete kogumise etapis projekti ulatusele kuigi palju tähelepanu. Võib-olla on nad muude asjadega hõivatud või lihtsalt ei ole projektiga tegelikult seotud. Kui nad aga näevad teie töö esimesi tulemusi, hakkavad nad äkki rohkem osalema ja hakkavad välja mõtlema uusi funktsioone või määratlema projekti eesmärke ümber. Võite ette kujutada, kuidas see võib kergesti viia mahu suurenemiseni.
Lõpuks peame mainima välismõjusid, mis on sageli teie kontrolli alt väljas. Ootamatuteks stsenaariumideks on raske valmistuda, kuid projektijuhina peaks teil olema valmis mõned situatsiooniplaanid. Need aitavad teil muudatustega toime tulla isegi siis, kui need teid ootamatult tabavad.
Nagu näete, on palju võimalikke põhjusi, mis võivad põhjustada mahu suurenemist - meie loetelu ei ole kindlasti ammendav. Peate meeles pidama, et scope creep toimub ka erinevate tegurite kombinatsiooni tõttu. Seetõttu on kasulik teada, kuidas saate potentsiaalselt üldse vältida scope creep'i.
Alustuseks olgu öeldud, et reguleerimisala muutmine ei ole midagi, mida peaksite iga hinna eest vältima. Kui te töötate agiilses keskkonnas, siis ilmselt ootate, et muudatusi tuleb ette. Mida te soovite leevendada, on teie ulatuse kontrollimatu kasvu tulemus. Vaatame läbi mõned strateegiad, kuidas vältida scope creep'i:
Mõned projektijuhid võivad arvata, et "selge projekti ulatuse loomine" on sageli kergemini öeldud kui tehtud - ja neil on õigus. Paljude projektide puhul, eriti uuenduslike ettevõtmiste puhul, ei pruugi te 100% kindel olla, milline lõpptoode välja näeb. Nii on see paljude tarkvaraarendusprojektide puhul, kus muudatusi tehakse sageli kasutajate tagasiside ja testide põhjal. Projektimeeskonnad seisavad silmitsi veel ühe väljakutsega, kui nad otsustavad kasutada tipptasemel tehnoloogiat või eksperimentaalseid lahendusi.
See ei tähenda siiski, et sellistes stsenaariumides on ulatusest väljumine paratamatu. Saate siiski suurendada oma võimalusi mõistliku ulatuse loomiseks, alustades nn projekti avastusfaasist. See on periood, mille jooksul saate testida hüpoteese, vaidlustada eeldusi või luua prototüüpe. Kõik selleks, et oma ideid valideerida ja kontrollida, kas pakutud lahendused on elujõulised.
Me arutasime äsja mitmeid parimaid tavasid, kuidas vältida scope creep'i, kuid mis siis, kui te juba kogete seda? Võib-olla sai see alguse näiliselt väikestest muudatuste taotlustest või ehk on sidusrühmad oodanud lisafunktsioone alates projekti algusest. Ulatuse vähenemise ohjamine on võimalik ja siin on teile paar võimalust.
Kõigepealt võib reguleerimisala vähenemine tunduda masendav, kuid praegu ei ole aeg passiivseks ja lüüasaamiseks. Projektid, mille ulatus on vähenenud, võivad ikkagi hästi välja tulla.
Vaadake kindlasti kõiki muutmistaotlusi lähemalt ja analüüsige hoolikalt nende tagajärgi. Hinnake, kuidas muudatused mõjutavad teie projekti eelarvet ja ajakava. Isegi kui teie meeskond on konkreetse muudatuse juba ellu viinud, on siiski väärtuslik uurida selle võimalikku mõju teie projekti ülejäänud osale.
Samuti on hea aeg pöörata tähelepanu sellele, et ressursside prognoosimine. Muudatuste taotlused võisid mõjutada ka seda projekti aspekti. Kas teil on selle projekti elluviimiseks piisavalt olemasolevaid meeskonnaliikmeid? Kas teil on vaja mõnda inimest palgata/välja osta? Võtke töötajate kättesaadavus ja meeskonna töökoormus arvesse (loe töökoormuse juhtimine). Te ei taha oma meeskonnaliikmeid üle koormata ja potentsiaalselt neid isegi läbi põletada, sest nende töömaht on liiga laialivalguv.
Teine strateegia ulatuse muutumise vastu võitlemiseks on mõnede esialgsete nõuete vähendamine. Kui teie projekti tagavaraportfell on prioritiseeritud, peaksite olema võimeline tuvastama elemendid, mida saaks vahetada uute lisandunud elementidega. Selle tulemusena võite võita projekti elluviimiseks veidi lisaaega ja -kulusid.
Kuna muutmistaotlusi laekub pidevalt, võib teie meeskond olla projekti ootuste osas veidi segaduses. See omakorda võib viia kuldse töö tegemiseni ja teatud ülesannetele veelgi rohkem aega kulutada. Te peaksite veel kord kontrollima, et iga meeskonnakaaslane mõistab uusi projektinõudeid.
Ärge unustage vaadata oma projekti suurt pilti. Ka scope creep mõjutab seda. Võib-olla on teil ja projekti sidusrühmadel nüüd mõttekas arutada alamprojekti(de) loomist või MVP käivitamist? Üks ulatuse hiilimise varjukülgi on see, et meeskonnad kaotavad hoogu ja projektid võtavad oodatust kauem aega. Osa projekti ulatusest eraldi versioonina välja andmine võib aidata seda hoogu taastada ja panna teie meeskonda tundma, et olete rohkem saavutanud. Sellisel lähenemisviisil on ka ärilist kasu: MVP (minimaalselt elujõuline toode) varajane vabastamine võib aidata teie kliendil toodet testida ja saavutada varakult edu klientide seas.
Lõpuks, isegi kui teil on ulatusest kõrvalekaldumine, peaksite ikkagi regulaarselt jälgima oma projekti seisukorda. Projektiaruanded aitab teil hinnata meeskonna tulemuslikkust ja arvutada kasvava ulatuse mõju.
Ulatuse suurenemine ei ole haruldane nähtus. Projektijuhina puutute sellega peaaegu kindlasti mingil hetkel oma karjääri jooksul kokku. Pooled Project Management Institute'i poolt 2018. aasta uuringus küsitletud vastanutest Kutsekoja küsitlus "Pulse of the Profession on viimase 12 kuu jooksul kogenud ulatuse vähenemist. Aastal 2020, käesoleva aruande uuem väljaanne näitas, et võimekuselt küpsemad ettevõtted on vähem mõjutatud scope creep'ist kui madala küpsusega organisatsioonid (30% kuni 47%).
Need arusaamad ei ole üllatavad, sest kuigi ulatus on potentsiaalselt hukatuslik, on see hallatav, eriti kui tegemist on asjatundlike projektijuhtide ja juhtidega. Loodame, et see blogipostitus on aidanud teil avastada võimalusi, kuidas hallata ulatuse hiilimist oma meeskonna kasuks.
Tahad rohkem teada saada projektijuhtimisest? Miks mitte vaadata teisi meie poolt avaldatud ressursse projektijuhtidele:
[/vc_column_text][/vc_column][/vc_row][/vc_row]
Ressursikalender (või projektijuhtimise kalender või projektiplaneerimise kalender, ressursside planeerimise tarkvara) võimaldab teil planeerida ja hallata ning jaotada ressursse tõhusamalt ja tulemuslikumalt - eriti kui Microsoft Excelil oli juhtiv roll teie...
Mis on projektijuhtide lõppeesmärk? Oma projektide edukas elluviimine. PM-id ise tunnistavad, et seda ei juhtu väga tihti: viimase Pulse of the Profession uuringu kohaselt viiakse vähem kui 60% projektidest lõpule kas...
Tootmisvõimsuse juhtimine on strateegia, mida ettevõtted kasutavad selleks, et kasutada tootmise tõhusust võimalikult hästi ära seoses nõudlusega teenuse või toote järele. Tootmisvõimsuse juhtimise lõppeesmärk on: tuvastada ja...