# NUPP Parimet Pothuajse Universale të Projekteve [image] Ky është një version i shkarkueshëm i manualit online (https://omimo.org/sq/modules/nupp/), i gjeneruar më 2026‑07‑02. Kontrolloni faqen e internetit për versione më të reja. NUPP vjen nga OMIMO (https://omimo.org/sq/), një familje modulesh të hapura dhe minimaliste. Ky manual mund të përdoret dhe shpërndahet lirisht sipas licencës Creative Commons Attribution 4.0 International. OMIMO bashkëfinancohet nga Bashkimi Evropian. Megjithatë, pikëpamjet dhe opinionet e shprehura janë vetëm ato të OMIMO-s dhe nuk pasqyrojnë domosdoshmërisht ato të Bashkimit Evropian ose të EPOS VZW. As Bashkimi Evropian dhe as autoriteti që ka dhënë financimin nuk mund të mbahen përgjegjës për to. Përkthyer nga : Eldisa Cirogu, Reina Matraxhiu, Ejon Dervishi, Genard Mata. ## Prezantimi NUPP është një koleksion i parimeve pothuajse universale të projekteve: ato që do të bënim mirë t’i ndiqnim në të gjitha projektet, pavarësisht nga metodologjitë dhe qasjet që përdorim, për të maksimizuar suksesin tonë. Secili prej burimeve dhe metodave të disponueshme për ekzekutimin e projekteve mbështetet në disa nga këto NUPP (parime pothuajse universale). Sidoqoftë, pikat e mëposhtme duhet të merren parasysh: - Do të ishte e dobishme që praktikuesit të merrnin parasysh të gjitha NUPP-të në vend të një nëngrupi. - Parimet themelore zakonisht nuk bëhen mjaft të qarta në burime dhe metoda, dhe shumica e praktikuesve janë aq të angazhuar në detaje praktike saqë harrojnë parimet dhe bëjnë gjëra që nuk janë në përputhje me to. NUPP është i pajtueshëm me të gjitha metodat, sistemet, burimet dhe kornizat kryesore si PRINCE2^(®), PMBOK^(®) Guide, P3.express, PM², DSDM^(®), XP dhe Scrum. Megjithatë, mund të mos jetë në përputhje me disa interpretime të këtyre sistemeve, dhe pikërisht këtu NUPP përpiqet të inkurajojë praktikuesit që të rishqyrtojnë interpretimet e tyre. NUPP është një koleksion i NUP-ve të mëposhtëm: - NUP1 — Preferoni rezultatet dhe të vërtetën ndaj përkatësive - NUP2 — PRuani dhe optimizoni energjinë dhe burimet - NUP3 — Jini gjithmonë proaktiv - NUP4 — Mos harroni se një zinxhir është po aq i fortë sa hallka e tij më e dobët - NUP5 — Mos bëni asgjë pa një qëllim të qartë - NUP6 — Përdorni elementë të përsëritshëm ## NUP1 Preferoni rezultatet dhe të vërtetën ndaj përkatësive [image] Të gjithë ne kemi një prirje të natyrshme për t’u përkitur grupeve, një tendencë që shpesh shkon përtej formës bazë, krijon lidhje të forta dhe shkakton probleme. Ne humbasim shumë më tepër sesa fitojmë për shkak të përkatësive. Ne mund të bëhemi ekspertë më profesionistë dhe efektivë nëse nuk e kufizojmë identitetin dhe preferencat tona në grupe të caktuara. ### Shembull: Agile vs waterfall Një grup njerëzish shumë entuziastë, të cilët ishin mjaft të guximshëm për të provuar qasjet adaptive në zhvillimin e TI-së në kohën kur norma ishte përdorimi i qasjeve parashikuese u mblodhën dhe e quajtën qasjen e tyre “Agile”. Kjo ishte një nismë e shkëlqyer për të mos kufizuar zgjedhjet në atë që dukej e nevojshme. Ka ende shumë njerëz entuziastë dhe të orientuar drejt rezultateve në komunitetin Agile, por fatkeqësisht, ka edhe disa njerëz në këtë komunitet që e kthejnë Agile në një kult dhe i konsiderojnë të gjithë të huajt si armiq. Kjo shkakton probleme në shumë mënyra, duke përfshirë sa vijon: - Nuk i lejon ata të mësojnë nga askush jashtë grupit të tyre - I dekurajon të huajt që të mësojnë prej tyre - Kjo e bën përkatësinë në grup më të rëndësishëm se qëllimin e vërtetë, gjë që nga ana tjetër pengon shumë nga anëtarët e tij të mësojnë kuptimin e vërtetë të Agility. Ky problem mund të reduktohet ndjeshëm, nëse nuk eliminohet dot, duke përdorur “Agile” vetëm si një etiketë që i referohet një qasjeje zhvillimi dhe jo si një komunitet me anëtarë; dhe duke pasur njerëz që e konsiderojnë veten krijues, zgjidhës të problemeve dhe udhëheqës, të cilët e shohin Agile thjesht si një nga mundësitë nën brezin e tyre dhe jo si identitetin e tyre. Nuk ka luftë midis Agile dhe Waterfall për profesionistët e vërtetë. ### Shembull: PRINCE2^(®) vs PMBOK^(®) Guide Ka shumë profesionistë në komunitet që ndjekin PRINCE2^(®) ose PMBOK^(®) Guide (zakonisht për shkak të vendndodhjes së tyre gjeografike). Ata mund të njohin njërin por nuk njohin tjetrin. Ne të gjithë mund të kemi preferenca ndaj burimeve të caktuara, por jo si përcaktues i identitetit tonë, dhe më e rëndësishmja, ne duhet t’i njohim të gjitha ato për të zgjeruar perspektivën dhe zgjedhjet tona. Profesionisti i vërtetë është i hapur për të gjitha idetë, duke i kërkuar ato, duke mësuar rreth tyre dhe duke i përdorur ato sipas nevojës dhe kur është e nevojshme, pa përkatësi. ### Shembull: Mësim i vazhdueshëm Përkatësitë e kënaqin personin për shkak të ndjenjës së përkatësisë që ato nxisin, por nuk i shtyjnë ato të mësojnë, madje ndonjëherë i dekurajojnë që të mësojnë nga frika se mos i humbasin ato. Kur je një person i lirë, një ekspert pa përkatësi, duhet të plotësosh boshllëkun me anë të të mësuarit: me mësim të vazhdueshëm. Ajo që ne besojmë sot nuk është e vërteta. Është thjesht ajo që ne arrijmë të kuptojnë më mirë deri më tani, por që duhet të përmirësohet ndërsa ne vazhdojmë përpara. Ka diçka të gabuar nëse idetë e dikujt janë saktësisht të njëjta me ato që ishin disa vite më parë. Ky është edhe rasti i NUPP: nëse ktheheni pas disa vitesh dhe shihni saktësisht të njëjtën gjë, duhet të bëheni dyshues. ### Shembull: Të qënurit i hapur Kur kundërshtoni dikë, sigurohuni që po bazoni kundërshtimin tuaj tek ideja, dhe jo tek personi. Kjo ndihmon në parandalimin e shumë tensioneve. Në të njëjtën mënyrë, kur dikush ju kundërshton, përpiquni të mos e interpretoni atë si një luftë kundër jush, por më tepër si një diskutim të ideve tuaja dhe qëndroni të hapur ndaj tyre. Mos dëgjoni për t’u përgjigjur, dëgjoni për të kuptuar; dhe punoni me personin tjetër për të përmirësuar idenë. Disa njerëz, qëllimisht, mund t’ju synojnë ju në vend të idesë dhe në këtë rast përpara se të vazhdojnë, duhet t’i ndihmoni ata të përqendrohen tek ideja dhe jo tek ju dhe të përpiqeni ta ruani këtë gjë gjatë gjithë bisedës. ## NUP2 PRuani dhe optimizoni energjinë dhe burimet [image] Burimet janë të kufizuara. Burimet në dispozicion të projektit janë të kufizuara, si dhe energjia mendore që keni për të marrë vendime të mira. Ju duhet ta ruani dhe optimizoni këtë burim për veten tuaj dhe për projektin, dhe të ndihmoni anëtarët e tjerë të ekipit të bëjnë të njëjtën gjë. ### Shembull: Rregulli 80/20 Një pjesë e madhe e përfitimeve të mundshme të menaxhimit të projektit mund të arrihet duke shpenzuar një pjesë të vogël të përpjekjes. Në shumicën e rasteve, synimi i 100% të përfitimeve të mundshme është shumë i shtrenjtë dhe i pajustifikueshëm. Ju duhet të merrni parasysh këtë rregull në çdo gjë që bëni dhe të inkurajoni të tjerët të bëjnë të njëjtën gjë. ### Shembull: Lodhje nga vendimet Ne përdorim një burim të vetëm energjie mendore për të marrë të gjitha llojet e vendimeve, si dhe për të shprehur vullnetin. Nëse përdorni shumë nga ky burim për të marrë vendime të panevojshme ose të parëndësishme, do të keni më pak energji për vendimet e rëndësishme, ç’ka mund të çojë në rezultate të dobëta. Kjo është një nga arsyet që duhet të shmangni mikro-menaxhimin (parimi “menaxhoni me përjashtim” të PRINCE2^(®)). Konfliktet që kanë të bëjnë me idetë mund të jenë të dobishme, por ato që kanë të bëjnë me njerëzit zakonisht janë të dëmshme për projektin, dhe një nga pasojat është se shteron energjinë mendore të anëtarëve të grupit. Nëse vëreni një konflikt të tillë, duhet të bëni çmos për të gjetur shkakun rrënjësor dhe për ta zgjidhur atë. ### Shembull: Kujdesuni për veten! Vendimet që merrni dhe vullneti që shprehni, përdorin burimin tuaj të energjisë mendore. Nga ana tjetër, ky burim mbushet me energji kur flini dhe hani siç duhet. Pra, duhet të kujdeseni mirë për veten: sigurohuni që të flini dhe të pushoni mjaftueshëm dhe të hani mirë. Nëse keni zakone të dëmshme ose probleme me gjumin, nuk keni pse të përballeni vetëm me të; ka shumë specialistë që mund t’ju ndihmojnë të zgjidhni probleme të tilla. Aktiviteti fizik mund të ndihmojë gjithashtu me këtë burim energjie, megjithëse studimet nuk janë ende përfundimtare për këtë çështje. Mundohuni të inkurajoni anëtarët e ekipit të bëjnë të njëjtën gjë si ju. Së pari, sigurohuni që ata të punojnë me një ritëm të qëndrueshëm dhe pa shumë punë jashtë orarit. Më pas, nëse keni mundësi të zgjidhni, përpiquni të ofroni ushqime energjike, të shëndetshme, snacks dhe pije gjatë kohës së punës. ### Shembull: Balanca punë-jetë Shumë prej nesh e duan atë që bëjnë, por kjo nuk është gjithçka që duhet të kemi në jetë. Në të njëjtën mënyrë që optimizoni punën tuaj, duhet të planifikoni dhe zbatoni ide në jetën tuaj personale, në mënyra që e bëjnë atë një jetë të gëzueshme dhe të lumtur. Kur jeni më të lumtur, mund të jeni më të suksesshëm edhe në punë. Nëse mundeni, përpiquni të inkurajoni anëtarët e ekipit tuaj të bëjnë të njëjtën gjë. ### Shembull: Motivimi Motivimi është një koncept kompleks. Ka disa burime interesante dhe të dobishme për këtë temë, si dhe shumë të tjera të cilat janë më tepër joshkencore. Sidoqoftë, duhet të mësoni për të dhe ta përdorni vazhdimisht, pasi rrit energjinë mendore të ekipit dhe mundësinë për të arritur rezultate më të mira për projektin. Motivimi mund të jetë aq i thjeshtë sa t’u bësh të ditur njerëzve se e vlerëson punën e tyre të mirë nëpërmjet një buzëqeshje ose një “falenderimi” të thjeshtë. Megjithatë, duhet të jeni të kujdesshëm, sepse shumë nga format e zakonshme të motivimit, si shpërblimet e vogla monetare, kanë një efekt negativ. ### Shembull: Bashkëpunimi dhe puna në grup Njerëzit që bashkëpunojnë ndonjëherë mund të kenë fuqinë për të krijuar rezultate më të mira, por më e rëndësishmja, njerëzit janë socialë dhe kënaqen duke qenë pjesë e një grupi. Nëse mund të hiqni anët negative të punës në grup dhe të krijoni një mjedis të këndshëm, do të ketë anëtarë më të lumtur të ekipit në projekt. Megjithatë, duhet të jeni të kujdesshëm, sepse njerëzit janë të ndryshëm dhe disa kanë nevojë për më shumë kohë të qetë, më të fokusuar dhe të vetmuar se të tjerët; zakonisht është një veprim balancues. ### Shembull: Kultura “një ekip i vetëm” Ekziston një tendencë që aktorë të ndryshëm të krijojnë ose marrin në konsideratë nëngrupe dhe të shkaktojnë tensione me grupet e tjera; për shembull, njerëzit që janë të fokusuar në aspektet e biznesit të projektit kundrejt njerëzve që po ndërtojnë produktin. Ky tension konsumon shumë energji nga të dyja palët, që është një nga arsyet që duhet të përpiqemi të ndërtojmë një kulturë të një ekipi, ku të gjithë të punojnë së bashku drejt të njëjtit qëllim. ### Shembull: Mençuria e turmave Kur një numër i madh njerëzish me diversitete mblidhen dhe punojnë në një mjedis të lehtësuar, ekziston mundësia për të marrë rezultate, ide dhe zgjidhje shumë të mira, që mund të jenë edhe më të mira se ato që vijnë nga ekspertë të vetëm. Nëse e keni atë mundësi, mund ta përdorni rregullisht për t’u kërkuar anëtarëve të ekipit t’ju ndihmojnë të zgjidhni problemet e vështira në projekt. Përveç mundësisë për të marrë rezultate të mira, gjithashtu kjo u lejon anëtarëve të ekipit të dinë se opinionet e tyre vlerësohen dhe se ata luajnë një rol të rëndësishëm në projekt, gjë që rrit nivelin e tyre të energjisë. Aktiviteti E02 i P3.express është një shembull i përdorimit të mençurisë së turmave në projekte. ### Shembull: Chief project facilitator Nëse jeni menaxher projekti, shumica e gjërave që bëni kanë një natyrë lehtësuese (ose të paktën duhet të kenë). Nga ana tjetër, mund të shihni se anëtarët e ekipit kanë pasur përvoja të këqija me menaxherët e projektit në të kaluarën dhe se këto përvoja po ndikojnë në marrëdhënien e tyre me ju: një pjesë e energjisë së tyre shpenzohet në analizimin e sjelljes suaj për kërcënime të mundshme në vend që t’ju besojnë. Në këtë rast, ju mund ta ndryshoni titullin tuaj nga menaxher i projektit në ‘Chief project facilitator’. Në fund të fundit, kjo është ajo që ju bëni vërtet në projekt. ## NUP3 Jini gjithmonë proaktiv [image] Ekziston një tendencë e natyrshme tek ne për të qenë reagues. Kjo mund të na ndihmojë të ruajmë energjinë tonë duke u marrë me çështje të parëndësishme, ose mund të na japë rezultate më të mira kur kemi të bëjmë me diçka për të cilën nuk jemi ekspert. Ato situata janë të ndryshme nga projektet tona dhe këtu mund të marrim rezultate më të mira duke qenë proaktivë. ### Shembull: Planifikimi Nëse dëshironi të shkoni me makinë në një vendodhje të re dhe jeni vonë, mund të filloni menjëherë ti jepni makines për të “kursyer kohë” dhe të perballeni me problemet e mundshme kur ato te lindin. Qasja proaktive është që të merrni pak kohë në fillim dhe të vendosni sistemin tuaj të navigimit që t’ju japë rrugën më të shpejtë bazuar në trafikun, aksidentet dhe bllokimet e mundshme te rruges dhe më pas te filloni ti jepni makines; ky është shpenzimi i kohës përpara ekzekutimit, për të shmangur problemet më vonë dhe për të kursyer kohë në fund. Ndryshe nga ajo që disa njerëz mendojnë për projektet qe kerkojne perkushtim dhe pune, planifikimi është gjithmonë i nevojshëm dhe ka të bëjë vetëm me llojin dhe nivelin e detajeve në plane. Planifikimi përpara ekzekutimit është një qasje proaktive. Mbani mend citimin: më jepni gjashtë orë të pres një pemë dhe unë do t’i kaloj katër të parat duke mprehur sëpatën. Nëse është një projekt proaktive, mund të shpenzosh 4 orë duke mprehur sëpatën, sepse je i sigurt se do të presësh një pemë. Në një projekt “ Agile “ , nuk je i sigurt nëse do të presësh një pemë, do të mbledhësh degë të thyera, do të korrësh barin, do të mbledhesh qymyr ne miniera ose diçka tjetër. Megjithatë, ju duhet të keni ende një përgatitje të përgjithshme për të gjitha këto (të dini se ku është dyqani më i afërt i pajisjeve) dhe të keni një përgatitje specifike (mprehje) kur doni të fokusoheni në një zgjidhje të caktuar; ky eshte planifikimi. ### Shembull: Planifikimi i planifikimit Planifikimi i mënyrës se si do të ekzekutojmë projektin është një qasje proaktive. Ky proaktivitet madje mund të zgjerohet duke planifikuar mënyrën se si do të planifikojmë ekzekutimin; ky është koncepti i planit të menaxhimit të Udhëzuesit PMBOK^(®), strategjitë e menaxhimit të PRINCE2^(®) dhe qasjet në DSDM^(®). ### Shembull: Planifikimi i vazhdueshëm Realiteti rrallë përputhet me atë që kemi planifikuar, dhe kjo është në rregull - por, ne duhet ti përshtatim vazhdimisht planet tona për t’u siguruar që ato të qëndrojnë realiste dhe praktike. Kete pershtatje duhet ta bëjmë sa më shpejt që të nevojitet dhe jo kur hasim probleme. Kjo është një qasje proaktive. ### Shembull: Menaxhimi i riskut I gjithë koncepti i menaxhimit të rrezikut bazohet në proaktivitet: kur përballemi me ngjarje të pasigurta, në vend që të presim të shohim se çfarë ndodh dhe më pas të reagojmë ndaj tyre, ne mendojmë për mundësitë dhe ndikimet, marrim parasysh kunder-përgjigjet dhe ndoshta bëjmë diçka për të përpara se të ndodhë. Vini re se ajo që bëjmë në projekte është serioze; ndonjëherë ka të bëjë me jetët e njerëzve. ### Shembull: Përcaktoni rolet dhe përgjegjësitë Ju mund t’i lini anëtarët e ekipit të projektit të punojnë pa role dhe përgjegjësi të qarta, dhe herët a vonë do të shfaqet një formë rolesh dhe përgjegjësish, por është shumë e shtrenjtë dhe në fund të fundit mund të mos funksionojë mirë. Qasja proaktive është që ato të përcaktohen herët dhe t’i përshtaten sipas nevojës. Kjo e bën punën më të lehtë për të gjithë, dhe secili mund të fokusohet në prodhimin e diçkaje, në vend që të vendosin se kush po bën çfarë. Numri dhe shumëllojshmëria e roleve varet nga lloji dhe madhësia e projektit; mund të jetë një përkufizim i thjeshtë si ai në “ Scrum “, diçka e moderuar si ajo në “ P3.express “, ose diçka gjithëpërfshirëse si ato në “ DSDM^(®) “dhe “ PRINCE2^(®) “. Megjithatë, mos harroni se përshkrimet e roleve në këto metoda kanë të bëjnë vetëm me aktivitetet e menaxhimit dhe se gjithmonë duhet të shtoni përshkrime rolesh edhe për aspektet teknike. ### Shembull: Zgjedhjet ne dispozicion A duhet ta mbyllni projektin para kohe apo të vazhdoni me të? Rrallëherë ka vetëm dy zgjedhje, nëse pyetja nënkupton këtë. Ju duhet të keni një qasje proaktive dhe të merrni parasysh të gjitha zgjedhjet tuaja përpara se të merrni një vendim. Ndoshta ju mund të rishikoni projektin; ndoshta mund ta ndaloni derisa diçka tjetër të bëhet e qartë; ose ndoshta mund të ndryshoni qasjen e projektit etj. ### Shembull: Të menduarit kritik Ne të gjithë kemi shumë pikpamje që na ndihmojnë të mbijetojmë nga njëra anë dhe na mashtrojnë në marrjen e vendimeve të këqija nga ana tjetër. Kur bëhet fjalë për marrjen e vendimeve të rëndësishme në lidhje me projektin, është më mirë të ndalemi për një kohë dhe të shqyrtojmë të gjitha keto pikpamje nga kende te ndryshme që mund të ndikojnë në vendimin tonë përpara se të shkaktojnë probleme. Madje ka metoda vendimmarrëse që mund t’i përdorni për të marrë vendime më të mira: https://en.wikipedia.org/wiki/List_of_cognitive_biases Në fillim, mund të jetë shpërqendruese dhe madje e bezdisshme përdorimi i tyre, por së shpejti mësoheni me to dhe përfitoni prej tyre pa shumë përpjekje . ### Shembull: Transparenca Ne nuk na pëlqen të vonohemi në projekt apo të kemi ndonjë problem tjetër, por kjo nuk do të thotë se duhet ta fshehim. Ju duhet të jeni transparent dhe t’u tregoni palëve të interesuara, sepse disa prej tyre mund të jenë në gjendje t’ju ndihmojnë, dhe për më tepër, ata do të dinë për problemet dhe pasojat e tyre herët a vonë, dhe disa prej tyre mund të kërkojnë veprime të hershme nga ana e tyre (p.sh. , për të pranuar pasojën negative). ### Shembull: Komunikoni në mënyrë efektive Mund të ketë shumë raste në të cilat ju dërgoni raporte palëve të interesuara dhe ata nuk ju japin asnjë reagim. Ju mund të besoni se gjithçka është në rregull vetëm sepse nuk ka reagime negative, megjithëse mund të mos jetë kështu. Duhet të jeni proaktiv dhe të kontrolloni për të parë nëse ata e kanë përdorur vërtet raportin dhe nëse ai i ka shërbyer qëllimit, dhe të përdorni të dhëna për të rregulluar metodën tuaj të komunikimit; përndryshe, ky problem i fshehur mund të shkaktojë probleme serioze më vonë, kur është shumë e vështirë për t’u rregulluar. ### Shembull: Merrni përgjegjësi Është e lehtë të fajësosh të tjerët për rezultate të dobëta. Për shembull, ju mund të dëshironi që organizata juaj t’ju japë autoritet të plotë për të ndryshuar gjithçka në projekt dhe për ta bërë atë në mënyrë të përsosur, por ata nuk e bëjnë, dhe si rezultat, projekti dështon. Kjo nuk është një qasje proaktive. Qasja proaktive është të merrni përgjegjësi dhe të bëni gjithçka që mundeni brenda kufizimeve. Ju nuk mund të prisni që organizata t’ju besojë plotësisht dhe t’ju japë gjithçka me shpresën për të marrë rezultate të mira, veçanërisht kur ata kanë parë kaq shumë projekte të dështuara. Ajo që duhet të bëni është të bëni një përmirësim të vogël brenda kufizimeve që janë vendosur, ta përdorni atë për të fituar pak besim, disa burime më shumë dhe pak më shumë tolerancë për kufizimet, dhe më pas ta përdorni atë për një përmirësim pak më të madh, dhe të mbani kështu derisa të arrini objektivin optimal. ## NUP4 Mos harroni se një zinxhir është po aq i fortë sa hallka e tij më e dobët [image] Ka fusha të ndryshme në projekte dhe të gjitha kanë nevojë për vëmendje; ne duhet të kemi një perspektivë holistike të projektit. Nuk mjafton t’i kushtosh vëmendje vetem nje fushe në dukje e rëndësishëm (p.sh., kohës), sepse të gjitha fushat ndërveprojnë dhe ato nuk funksionojnë siç duhet nëse të gjithë nuk marrin vëmendjen e duhur. ### Shembull: Gjithçka ka të bëjë me afatin! Le të themi se po ndërtoni diçka për Lojërat Olimpike. Ka një afat shumë serioz, gjë që e bën shumë të rëndësishëm menaxhimin e kohës. A është e drejtë, megjithatë? Po sikur cilësia të jetë aq e ulët sa të kërkojë përsëritjen e punës pas një kohe. Kjo do të ndikonte në kohë dhe cilesi. Ju mund të keni një kopsht të zbukuruar të listuar në përkufizimin origjinal të projektit, por ju e dini se nëse nuk ka kohë të mjaftueshme, mund ta anashkaloni dhe thjesht ta mbuloni me bar, për sa kohë që e keni shqyrtuar këtë si mundësi në kohë dhe jeni përgatitur për atë. Pra, menaxhimi i fushëveprimit është gjithashtu i rëndësishëm. Tani ne kemi fushëveprimin, kohën dhe fushat e cilësisë në qendër të vëmendjes sonë. A keni dëgjuar për atë shembullin e famshëm ku presidenti Kenedi takon një pastrues në NASA dhe e pyet atë se çfarë bën, dhe ai përgjigjet: “Unë po ndihmoj për të vendosur një njeri në hënë”? A nuk ndihmon të kesh njerëz të tillë në projekt në përmbushjen e afatit? Ndërsa vazhdoni, vini re se çdo pjese e vetme në projekt kontribuon në menaxhimin e kohës dhe nuk mund ta përmbushni afatin me një nivel të pranueshëm sigurie nëse nuk i kushtoni vëmendje të gjitha pjeseve perberse. ### Shembull: Selektimi Kur njerëzit përballen me metoda të ndryshme, ndonjëherë ata fillojnë të bejne seleksionime dhe krijojnë një përzierje të gjithçkaje që duket interesante nga sisteme të ndryshme. Kjo zakonisht nuk funksionon, sepse elementët nuk funksionojnë të izoluar dhe duhet të jenë të pajtueshëm me njëri-tjetrin. Çdo shtesë ose ndryshim në një sistem duhet të bëhet nga një këndvështrim holistik. Kjo është arsyeja pse ne ndonjëherë shohim elemente kontradiktore në metoda të ndryshme; diçka funksionon mirë në një sistem, dhe e kundërta e saj funksionon mirë në një sistem tjetër. Ky element nuk është i drejtë apo i gabuar në vetvete. Qasja më e sigurt është të zgjidhni një metodologji për projektin, ta përshtatni atë dhe më pas t’i shtoni me kujdes elementë të rinj duke marrë parasysh konsistencën e të gjithë sistemit. ### Shembull: Qasja kundër procesit Një nga gjërat më të mira që kanë bërë metodat “Agile” është tërheqja e vëmendjes ndaj aspekteve njerëzore. Manifesti Agile u jep më shumë vlerë individëve dhe ndërveprimeve në krahasim me proceset dhe mjetet, megjithëse ky mund të mos jetë një krahasim i drejtë. Pothuajse të gjitha metodat thonë se aspektet njerëzore janë të rëndësishme, dhe ndryshimi i vërtetë me metodat Agile është se aspektet njerëzore janë një pjesë e ngulitur e proceseve të tyre, dhe jo një sugjerim i thjeshtë. Pra, nuk bëhet fjalë për një konkurrencë midis aspekteve dhe proceseve njerëzore, por për mënyrën se si aspektet njerëzore shihen në sistem. Nuk ka dyshim se disa njerëz përpiqen të zëvendësojnë aspektet njerëzore duke pasur procese më të sofistikuara, por ky është vetëm një keqpërdorim. Ekziston edhe e kundërta: njerëzit që përpiqen të zëvendësojnë proceset. ### Shembull: Këto janë të gjitha burimet kryesore që ju nevojiten Kur mendoni për burimet kryesore duhet të keni kujdes që të mos humbisni asnjë prej tyre. Çfarë janë ata, megjithatë? Nëse kontrolloni burimet themelore, do të merrni përgjigje të ndryshme; e megjithatë, asnjëra prej tyre nuk është e gjithë e vërteta. Temat e PRINCE2^(®) janë burime, por ato janë vetëm burimet që luajnë një rol kyç në metodologji. Burimet e tjera nënkuptohen . Udhëzuesi PMBOK^(®) nuk është një metodologji dhe mund ta formulojë atë shumë më mirë me dhjetë fushat e njohurive. Sidoqoftë, këto janë interpretime të të gjitha fushave të bazuara në këndvështrimin e udhëzuesit PMBOK^(®) për projektin, në vend të një perspektive neutrale (jo se ekziston domosdoshmërisht një perspektivë neutrale). Për shembull, aspekteve njerëzore nuk u kushtohet shumë vëmendje në Udhëzuesin PMBOK^(®). Një burim i mirë informacioni rreth burime kryesore është ICB. Megjithatë, nuk bëhet fjalë për burime, por për kompetencat që kërkohen në projekt. Nuk ka një marrëdhënie vetem per vetem me burimet, por ndihmon shumë në identifikimin e tyre. Nuk ka asnjë listë të burimeve në NUPP, kryesisht sepse është një meta-sistem dhe jo një sistem, dhe gjithashtu sepse kategorizimi i burimeve varet nga lloji i projektit dhe mjedisi i tij; p.sh., një projekt rutinë ndërtimi mund të ketë nevojë për një këndvështrim të ndryshëm nga një projekt kërkimor krijues. ## NUP5 Mos bëni asgjë pa një qëllim të qartë [image] Ju nuk duhet të bëni asgjë nëse nuk ka një qëllim të qartë. Imagjinoni dy botë paralele ku gjithçka është e njëjtë përveç asaj që po mendoni të bëni: Sa të ndryshme do të ishin ato botë? A ia vlen ndryshimi përpjekja për ta bërë atë gjë? Nëse nuk keni një qëllim të qartë në mendje dhe jeni duke bërë diçka vetëm sepse të gjithë të tjerët po e bëjnë atë, ose të gjithë thonë se është e rëndësishme ta bëni atë, atëherë - mund të mos ketë një përfitim real në rastin tuaj, dhe për këtë arsye ju nuk mund të merrni asgjësaj; ose - mund të ketë ende përfitime të mundshme në rastin tuaj, por sepse ju nuk keni qëllimi në mendje, mënyra juaj për ta bërë atë mund të mos ndihmojë në realizimin e përfitimeve. ### Shembull: Portofole dhe programe Nëse jeni të përfshirë në përzgjedhjen dhe fillimin e projekteve, duhet të siguroheni që të fokusoheni më tepër në përfitimet dhe problemet që kërkohen të zgjidhen sesa produkti që do t’i realizojë ato gjëra. Shembulli klasik është prodhuesi i ashensorëve që merrte më parë ankesat për shpejtësinë e ashensorëve të tyre, dhe kështu kishin kryer projekte të shumta për të rritur shpejtësinë, pa sukses të plotë. Kjo vazhdoi derisa ata vendosën të fokusohen në problemin (mërzia e njerëzve ose siklet) në vend të zgjidhjes “natyrore” (ashensorë më të shpejtë). Rezultati ishte se u shtuan pasqyra ashensorëve dhe e zgjidhi problemin thjesht dhe me çmim të lirë. Mos harroni se menaxhimi i projektit ka të bëjë kryesisht me bërjen e gjërave siç duhet, ndërsa menaxhimi i portofolit ka të bëjë me bërjen e gjërave të duhura. Nuk ka rëndësi sa mirë ju drejtoni projektet tuaja; nuk do të funksionojë mirë nëse po bëni projekte të gabuara. Eshtë gjithçka për të pasur një qëllim. ### Shembull: Projekti në tërësi Fleksibiliteti i produktit ndryshon midis projekteve. Në disa zhvillime IT projekteve, produkti është plotësisht fleksibël, dhe forma e tij përfundimtare varet nga reagimet që do të gjenerohen nga rritjet e produktit gjatë projekt, i cili kërkon një qasje adaptive (Agile). Ky është në aspektin praktik një kombinim i portofolit, programit dhe projektit shtresa, dhe ka nevojë për vëmendje maksimale për qëllimin përfundimtar. Është një ide e mirë për të dokumentuar qëllimin dhe për ta bërë atë të aksesueshëm; është një nga qëllimet e “Vizioni i produktit”, siç përdoret në disa projekte Scrum. Vëmendja ndaj biznesit vlera në projektet Agile është mënyra e tyre për të siguruar përafrimin me qëllimin. Në llojet e tjera të projekteve, ku produkti është relativisht i fiksuar dhe ka mekanizma të tjerë për të siguruar që produkti i identifikuar do të përmbushë qëllimin, është e mundur që anëtarët e ekipit të projektit të zhvendosin një pjesë të madhe të fokusit të tyre nga qëllimi i produktit, por të paktën një vëmendje minimale ndaj qëllimit ende kërkohet për të siguruar që ajo që po ndërtohet do të përmbushë qëllimin, i cili mund të jetë duke krahasuar përfitimet e parashikuara me përfitimet e pritshme (prandaj Parimi i “justifikimit të vazhdueshëm të biznesit” dhe tema e “rasteve të biznesit”. në PRINCE2^(®) ). Kur një projekt drejtohet për një klient të jashtëm, klienti do të kishte të tijin qëllimi për projektin dhe kompania juaj do të kishte një qëllim tjetër. Ju duhet t’i kuptoni dhe t’i përdorni të dyja këto për të pasur sukses. ### Shembull: Monitorimi i projektit Përqendrimi në qëllimin përfundimtar është i nevojshëm, por mund të jetë shumë abstrakt shumë nga përdorimet e përditshme. Kjo është arsyeja pse nevojitet një hierarki drejtuesish e bëjnë atë më praktik. Së pari, arsyetimi dhe përfitimet e projektit përcaktohen bazuar në qëllimin përfundimtar, dhe atëherë do të keni objektiva të qarta dhe të nënkuptuara për projektin variablat (p.sh. koha, kostoja dhe cilësia) për të kënaqur justifikimin, i cili nga ana tjetër do të përmbushë qëllimin përfundimtar. Këto janë qëllime të nivelit më të ulët që janë të dobishëm për shumë nga detyrat tona të përditshme. Për sa i përket monitorimit, do të bëhet monitorimi i nivelit të ulët të projektit duke përdorur nivelin më të ulët të variablave, sepse mund të mos jetë e mundur të gjurmohet qëllimi përfundimtar. Në këtë rast, ju duhet të keni ende qëllimet në mendje: Çfarë është qëllimi i monitorimit? Një përgjigje normale dhe e pranueshme është të shohim nëse jemi në rrugën e duhur, dhe nëse jo, ta bëjmë atë të shkaktojë një reagim të caktuar që do të na kthejë në rrugën e duhur ose do të rregullojë objektivat dhe shikoni nëse ai ende mund të përmbushë qëllimin përfundimtar. Prandaj, matjet tona duhet të jenë në gjendje të ndihmojnë me këtë qëllim të nivelit të ulët, dhe matjet e duhura janë parashikimet për variablat në përfundim; p.sh., kur do të mund ta përfundonim projektin? Sa para do të kishim duhet të përfundojë projekti? Të gjitha matjet e tjera, të tilla si vlerat e planifikuara dhe aktuale deri më sot, janë të drejta vlerat e ndërmjetme që ju nevojiten për të llogaritur parashikimet, jo ato përfundimtare vlerat që përdorni për qëllime menaxheriale. ### Shembull: Dokumentet Pavarësisht se çfarë qasje zhvillimi përdorni në projekt, planifikimi është gjithmonë e nevojshme. Pyetja e rëndësishme është niveli i detajeve në çdo lloj plani. Nëse nuk ka detaje të mjaftueshme në plan, plani nuk do të jetë në gjendje të kontribuojë mjaftueshëm, dhe ekzekutimi i projektit do të bazohet në vendime ad hoc dhe jo të integruara, holistike. Nga ana tjetër, shumë njerëz përpiqen të jenë të kujdesshëm dhe të shtojnë shumë detaje planin e tyre, gjë që e bën shumë të vështirë përgatitjen dhe mirëmbajtjen dhe shumë të ngurtë për të pasiguritë e projektit. Si rezultat, plani bëhet jorealist dhe të padobishme. Mënyra më e mirë për të vendosur për nivelin e detajeve është të kesh një qëllim në mendjeçdo element në plan. Për shembull, nëse po konsideroni shtimin e burimet e planit, ju duhet të keni një qëllim për të: Si do të përdoret? Si do ta ndihmojë projektin? Sa përpjekje do të duhet? dhe a ia vlen? Ndonjëherë ka të bëjë me vendosjen nëse dëshironi të keni një element të caktuar planet tuaja, dhe ndonjëherë për mënyrën se si dëshironi të planifikoni ose përgatitni diçka. Qoftë një rast biznesi, një statut projekti ose një raport: ju duhet të pyesni akoma pse po e përgatisni atë dokument dhe si mund ta ndihmojë projektin. Të kërkosh një “template” është e kundërta e të bërit diçka të bazuar në një qëllim. ### Shembull: Raportimi i statusit Është e zakonshme të kesh raporte vërtet të gjata të statusit në shumë projekte. Bazuar në këtë NUP, duhet të pyesim veten se cili është qëllimi i raportit dhe si mundemi arrini atë qëllim, pavarësisht se çfarë mund të bëjnë shumica e njerëzve të tjerë. Kjo, në shumë raste, mund të na shtyjë të përgatisim raporte shumë të thjeshta me një faqe që palët e interesuara vërtet lexojnë dhe kuptojnë në vend të raporteve të gjata. Kjo është duke i dedikuar vëmendje ndaj qëllimit. Megjithatë, nëse përgatitni raporte me një faqe, disa njerëz mund të kundërshtojnë për ju dhe mendoni se nuk keni një sistem monitorimi “të duhur”. Në praktikë kjo krijon një qëllim të dytë për ju (përveç qëllimit të parë, e cila po ndihmon palët e interesuara të kuptojnë statusin e projektit), dhe të kënaqeni këtë, thjesht mund të krijoni një lloj të dytë raporti që është shumë i gjatë. Sidoqoftë, nuk do ta përzieni atë me raportin e parë, sepse këto dy qëllime nuk janë të njëjta. ### Shembull: Rasti i biznesit dhe statuti i projektit Përgatitja e dokumenteve të tilla si një rast biznesi dhe një statut projekti është zakonisht një domosdoshmëri e mërzitshme, e pafrytshme, burokratike për shumicën e njerëzve, ndërsa këto dokumente të gjitha kanë qëllime të vlefshme që vlejnë për shumicën e projekteve. Nëse përpiqesh të gjesh një “shabllon” dhe ta plotësosh, puna thjesht shkon kot; kurse ju në vend të kësaj mund të kontrolloni qëllimin e vërtetë të atyre dokumenteve, të shihni nëse dhe si ato mund të jenë të dobishme në projektin tuaj dhe më pas përgatitni dokumentin në çfarëdo mënyre ju pëlqen, vetëm për të kënaqur këto qëllime: ky do të jetë dokumenti i duhur. Ndërsa jeni duke menduar për mënyrën se si mund të përgatitni dokumentet për të kënaqur qëllimet e tyre, ju mund të mos mendoni për çdo skenar dhe mund të humbisni diçka.Për të shmangur këtë, ju mund të kontrolloni për të parë se çfarë burimesh të tilla siç sugjerojnë PRINCE2^(®) , PMBOK^(®) Udhëzuesi, P3.express dhe DSDM^(®) dhe më pas vlerësoni ato sugjerime bazuar në qëllimet. ### Shembull: Post-projekt Ndërsa projekti ka një qëllim specifik dhe ne mund ta konsiderojmë atë qëllim gjatë gjithë projektit realizimi i qëllimit vlerësohet kryesisht në bazë mbi parashikimet e bëra gjatë projektit. Sidoqoftë, ne nuk duhet ta harrojmë atë kur të përfundojë projekti. Është e rëndësishme të kontrolloni realizimin e qëllimeve pasi të përfundojë projekti: - sepse ne mund të shohim se si arrihen qëllimet përfundimtare dhe të mësojmë prej tyre për të ardhmen projekte dhe - ndonjëherë qëllimet arrihen vetëm kur realizojmë ndonjë shtesë detyrash pas përfundimit të projektit, dhe të kuptuarit e domosdoshmërisë së ato detyra shtesë kanë nevojë për monitorim. Monitorimi pas projektit është një hap i domosdoshëm për të qenë i drejtuar nga qëllimi. Është kryesisht përgjegjësia e sistemeve të menaxhimit të programit dhe portofolit, dhe për shkak se shumica e kompanive nuk kanë shtresa të tilla të menaxhimit, ky hap është zakonisht i lënë pas dore. Kjo është arsyeja pse metoda të tilla si P3.express dhe DSDM^(®) shtojnë këtë hap në projektin e tyre metodologjitë e menaxhimit. ### Shembull: Thjeshtësia Bota është komplekse dhe kaotike, por modelet tona janë përafërsi abstrakte që pasqyrojnë pjesë të botës, dhe për këtë arsye, ato mund të jenë të thjeshta. Ne tjetren dore, sistemet e thjeshta zakonisht funksionojnë më mirë, sepse ne mund të fokusohemi tek ideja kryesore. Shumë prej nesh përpiqen të marrin rezultate më të mira duke shtuar kompleksitet në sistemet tona, duke shpresuar se do të përputhet me kompleksitetin e botës, edhe pse në praktikë kjo bën që sistemi është i vështirë për t’u punuar dhe zakonisht na pengon të kënaqim qëllimi. ### Shembull: Përshtatja Një pjesë e softuerit për transmetimin e muzikës ka një gjendje shumë të ndryshme nga një që do të përdoret për pajisje në një spital apo në aeroplan ku jetët e njerëzve mund të varet nga ajo, ose nga një pjesë e softuerit që do të përdoret në një satelit ku supozohet të funksionojë për shumë vite pa u përplasur, dhe janë të gjitha ndryshe nga ndërtimi i një vile verore, një stacioni zjarrfikës dhe një impianti përpunimi. Kur të keni në mendje qëllimet, do të kuptoni më mirë se si të përshtatni sistemet dhe artefaktet për projekte të ndryshme. ## NUP6 Përdorni elementë të përsëritshëm [image] Një qasje ad hoc ndaj projektit kërkon shumë energji dhe burime, dhe gjithmonë rrezikon të mungojë disa nga elementët e nevojshëm. Mënyra më e mirë për thjeshtimin e saj është përdorimi i elementeve të përsëritshëm, dhe mundësisht të kthyerit e tyre në cikle të përsëritshme. ### Shembull: Lista e kontrollit të cilësisë Një listë kontrolli është një shembull i thjeshtë i një elementi potencialisht të përsëritshëm që ka shumë njerëzit përdorin në jetën e tyre personale dhe profesionale. Merrni kriteret e cilësisë së dorëzueshme, për shembull: - Së pari, ju mund të krijoni një listë kontrolli të të gjitha kritereve, e cila është një formë planifikimi. - Ajo që rekomandon NUP6 është të përpiqeni ta përgjithësoni atë: a ka të tjera të ngjashme rezultatet në projekt? Në këtë rast, përgatitni një listë kontrolli të përgjithshme të cilësisë për atë kategori produktesh dhe ta përdorin atë për të gjitha. Nëse ka disa variacione, mbani listën e përgjithshme dhe shtoni disa artikuj shtesë për individintë dorëzueshme. Tani keni lista kontrolli të përsëritshme. - Pasi të keni përgatitur lista kontrolli gjenerike për lloje të ndryshme të ofruesve, ju mund të gjeni elemente që përsëriten mes tyre, gjë që sugjeron realizimin e një l kategorie vituale “mëmë”. Në atë rast, në vend që të përsërisni artikujt për të gjithë ato lista kontrolli gjenerike, ju mund t’i nxirrni dhe t’i vendosni në një listë kontrolli. Në fund, ju ndoshta do të keni një listë të vetme kontrolli të përgjithshme për të gjithë projektin. “Përkufizimi i kryer” i Scrum është një shembull i përdorimit në nivel projekti të listave kontrolluese për cilësinë, por edhe për tema të tjera. Cdo deliverable do t’i përkasë një hierarkie kategorish dhe duhet të plotësojë elementër që shfaqen në listat kontrolluese të të gjitha kategorive në zinxhirin e tyre. Duke bërë këtë, një artikull në listën e kontrollit admin do të bëhet i përsëritshëm për të gjithë nën të, gjë që kursen kohë dhe energji në planifikim dhe ekzekutim. Më e rëndësishmja, pasi ta bëni këtë për një projekt, mund ta përshtatni dhe ta përdorni për të të gjitha projektet e ngjashme në të ardhmen, e cila është një formë e përsëritshme e planifikimit pë projekte të shumta. ### Shembull: Proceset dhe rrjedhat e punës Disa rezultate, ose qëllime të lidhura me to, kanë nevojë për hapa të caktuar që mund të bëhen të standardizuara dhe të përsëritshme. Për shembull, nëse produktet duhet të jenë projektuar individualisht dhe miratuar, ju mund të përgatitni një rrjedhë të thjeshtë pune që i bën të qarta të gjithë hapat, njerëzit e përfshirë dhe kohëzgjatjet e përafërta, kështu duke shmangur shumë vështirësi. Sidoqoftë, duhet të jeni të kujdesshëm që të mos bëni procedurat dhe proceset punës shumë të komplikuara ose tepër intensive në dokumentacion, pasi do të ketë një pasojë negative. Të gjithë njerëzit e përfshirë në projekt duhet të shohin rrjedhat e punës dhe proceset si diçka që mbështet punën e tyre dhe e bën gjithçka më të lehtë për të ato, dhe jo si dokumentacion burokratik që bllokon punën e tyre reale. Projektet Agile kanë elementë të përsëritshëm në qasjen e tyre të zhvillimit përsëritës, ku lloje të caktuara të aktiviteteve të zhvillimit përsëriten për çdo veçori; p.sh.rutina e zakonshme e përditshme në XP (Programimi eXtreme): zgjidh një artikull, dizenjoni atë në një tabelë të bardhë, ndërtoni skriptet dhe kodin e testimit, integroni kodin,etj. Përveç flukseve të punës të përsëritshme që mund të përdoren për aktivitete teknike, ju mund të keni elemente të përsëritshëme dhe për aktivitetet e menaxhimit të projektit.Të përpunon në PMBOK^(®) Udhëzuesin, PRINCE2^(®) dhe DSDM^(®), aktivitetet në P3.express dhe ngjarjet në Scrum janë shembuj të këtij koncepti. ### Shembull: Ciklet Pasja e elementeve të përsëritshme për menaxhimin e projektit është e dobishme. Kjo mund të jetë bëhet edhe më e lehtë duke i vendosur ato në cikle të përsëritshme. Këto cikle thjeshtojnë ndjeshëm aktivitetet e përditshme të njerëzve të përfshirë në menaxhimin dhe udhëheqjen e projektit. Ciklet e grupeve të procesit në udhëzuesin PMBOK^(®) kur përdoren në një projekt me faza të shumta, faza në PRINCE2^(®) , cikle ditore, javore dhe mujore në P3.express, përsëritjet dhe kutitë kohore në DSDM^(®) dhe Sprints në Scrum janë të gjitha shembuj të këtij koncepti. Ciklet më të shkurtra janë më të lehta për t’u kuptuar dhe përdorur sesa ato më të gjata; p.sh., Sprintet në Scrum në kontrast me fazat sipas Udhëzuesit PMBOK^(®). Megjithatë, ciklet që janë shumë të shkurtra mund të mos jenë të mjaftueshme për të mbështetur disa lloje të projekteve dhe zgjidhja mund të jetë përdorimi i cikleve të shumta, të tilla si DSDM^(®) i cili përdor cikleve të shkurtra kohore së bashku me ciklet më të gjata të përsëritjes, ose përdorimi i P3.express të cikleve ditore, javore dhe mujore. ### Shembull: Metodat Përdorimi i një metodologjie ose një kornize për drejtimin e një projekti është një përdorim tjetër i elemente të përsëritshme. Ky mund të jetë një sistem ekzistues si PRINCE2^(®) ,P3.express, DSDM^(®) ose Scrum, ose një që e keni personalizuar ose ndërtuar vetë. Sidoqoftë, normalisht është një ide më e mirë të filloni me një nga metodat ekzistuese dhe përshtateni me nevojat tuaja sesa ta ndërtoni nga e para. Çdo element i përsëritshëm është abstrakt dhe ka nevojë për personalizim për ta përshtatur atë me botën reale. Ka një spektër abstraksioni dhe nevojë për personalizim, megjithatë: listat kontrolluese të cilësisë së vogël, relativisht konkrete janë në njërën anë spektër me sasinë më të vogël të abstraksionit dhe nevojës për përshtatje, ndërsa metodologjitë janë në anën tjetër, me nevojën më të madhe për pëershtatje. Ju duhet të analizoni gjithmonë nevojën për përshtatje, përndryshe, elementët e përsëritshëm nuk do të përputhen me nevojat tuaja.