प्रोजेक्ट प्रबंधन में सामान्य गलतियाँ: संकीर्ण मामले जिनका उल्लेख करना महत्वपूर्ण है

प्रोजेक्ट प्रबंधन में सामान्य गलतियाँ: संकीर्ण मामले जिनका उल्लेख करना महत्वपूर्ण है

प्रोजेक्ट प्रबंधन की गलतियाँ हमेशा नाटकीय नहीं लगतीं। एक छूटी हुई निर्णय, एक अस्पष्ट हस्तांतरण, एक “हम बाद में ठीक कर देंगे” नोट एक प्रोजेक्ट में 3 सप्ताह तक लहरें पैदा कर सकता है और किसी को भी यह सुनिश्चित नहीं होता कि किसने क्या बदला। यही कारण है कि प्रोजेक्ट प्रबंधन में सामान्य गलतियों का विश्लेषण करना संकीर्ण मामलों में महत्वपूर्ण है, केवल सिद्धांत के रूप में नहीं।

एक नया प्रबंधक एक अधूरे प्रोजेक्ट को विरासत में ले सकता है, फ़ोल्डर खोल सकता है, और बिना तारीखों के 14 फ़ाइलें देख सकता है। पिछले लीड ने छोड़ दिया है, दो फ्रीलांसर इंतज़ार कर रहे हैं, और ग्राहक शुक्रवार तक एक अपडेट की उम्मीद कर रहा है। पहली गलती अक्सर तकनीकी नहीं होती। यह विश्वास करना है कि प्रोजेक्ट अभी भी अपने आप में बोलता है।

1. एक नया प्रबंधक एक अधूरे प्रोजेक्ट को संभाल रहा है

एक अधिग्रहण एक स्मृति परीक्षण है। यदि प्रोजेक्ट में कोई नोट्स नहीं हैं, कोई निर्णय लॉग नहीं है, और प्रत्येक कार्य के लिए कोई नामित मालिक नहीं है, तो नया प्रबंधक पहले दिन अनुमान लगाने में बिताता है। यह अनुमान महंगा है क्योंकि छिपे हुए पूर्वधारणाएँ आमतौर पर पुराने अनुमोदनों के अंदर होती हैं, स्पष्ट दस्तावेज़ों में नहीं।

3 चीज़ों के लिए पूछने से शुरू करें: अंतिम अनुमोदित दायरा, अंतिम ग्राहक संदेश, और खुले अवरोधकों की सूची। यदि ये 3 आइटम मेल नहीं खाते, तो प्रोजेक्ट पहले से ही दो संस्करणों में विभाजित है। एक संस्करण ग्राहक के दिमाग में है। दूसरा फ़ाइल पेड़ में है।

यहां सामान्य गलतियाँ परियोजना प्रबंधन में चुप्पी के रूप में प्रकट होती हैं। एक प्रबंधक मानता है कि "कोई समाचार नहीं" का मतलब कोई समस्या नहीं है, फिर पता चलता है कि एक डिज़ाइनर एक गायब संपत्ति के लिए 5 दिन तक इंतज़ार करता है। एक डेवलपर ने एक उचित विकल्प बनाया हो सकता है, लेकिन यदि वह विकल्प कभी दर्ज नहीं किया गया, तो अगला व्यक्ति इसे एक आश्चर्य के रूप में लेगा।

एक संक्षिप्त हैंडओवर कॉल और एक लिखित पुनर्कथन का उपयोग करें। नाम, तिथियों और निर्णयों के लिए पंद्रह मिनट पर्याप्त है। लंबे बैठकें अक्सर स्पष्टता की तुलना में अधिक धुंधलापन पैदा करती हैं।

2. परियोजना शुरू होने के बाद हितधारकों की प्राथमिकताओं को गलत समझना

हितधारकों की प्राथमिकताएँ अक्सर बदलती हैं, जितना लोग स्वीकार करते हैं। योजना अभी भी मौजूद हो सकती है, लेकिन असली लक्ष्य "जल्दी लॉन्च" से "समर्थन मुद्दों को कम करना" या "सुंदर डिज़ाइन" से "सरल चेकआउट" में बदल गया है। यदि कोई इसे ज़ोर से नहीं कहता, तो टीम गलत चीज़ को अनुकूलित करती रहती है।

एक व्यावहारिक संकेत यह है कि बार-बार दी गई प्रतिक्रिया असंगत लगती है। ग्राहक सोमवार को गति की मांग करता है और बुधवार को अतिरिक्त विवरण। यह हमेशा भ्रम नहीं होता। कभी-कभी प्राथमिकता बदल जाती है और प्रबंधक ने संकेत को चूक दिया क्योंकि परियोजना का संक्षिप्त विवरण स्थिर रहा जबकि व्यावसायिक दबाव बढ़ गया।

एक उपयोगी आदत है कि हर समीक्षा में शीर्ष लक्ष्य को फिर से व्यक्त करें। कार्य सूची नहीं। शीर्ष लक्ष्य। एक टीम केवल तभी 8 कार्यों को एक साथ संभाल सकती है जब उसे पता हो कि व्यापारिक समझौतों के समय कौन सा सबसे महत्वपूर्ण है।

यदि आपको तुलना बिंदु की आवश्यकता है, तो देखें एक फ्रीलांसर को सुरक्षित रूप से कैसे भर्ती करें, जहाँ प्रारंभिक संरेखण कार्य शुरू होने से पहले महत्वपूर्ण होता है। वही तर्क किकऑफ के बाद भी लागू होता है, क्योंकि देर से संरेखण भी संरेखण है, बस यह अधिक महंगा होता है।

3. अनुभवी योगदानकर्ताओं का अधिक प्रबंधन करना

कुशल फ्रीलांसरों को हर 4 घंटे में स्थिति की जानकारी की आवश्यकता नहीं होती। उन्हें एक स्पष्ट लक्ष्य, एक सीमा, और काम करने की जगह चाहिए। उनका अधिक प्रबंधन आमतौर पर अच्छे इरादों से शुरू होता है और अनावश्यक अनुमोदन चक्रों के साथ समाप्त होता है जो परियोजना को 2 दिन या उससे अधिक समय तक धीमा कर देते हैं।

नियंत्रण और दृश्यता के बीच एक अंतर है। नियंत्रण कहता है, “जारी रखने से पहले मुझे हर ड्राफ्ट दिखाओ।” दृश्यता कहती है, “मुझे बताओ जब परिणाम योजना को बदल देगा।” पहला विशेषज्ञों को क्लर्क में बदल देता है। दूसरा परियोजना को आगे बढ़ाए रखता है।

परियोजना प्रबंधन में एक सामान्य गलती यह है कि वरिष्ठ योगदानकर्ताओं को इंटर्न की तरह व्यवहार किया जाता है। यह गलती विशेष रूप से अनुभवी डिजाइनरों, डेवलपर्स, या संपादकों के साथ स्पष्ट होती है जो पहले से ही मानक जांच जानते हैं। उन्हें अपने प्रक्रिया को लाइन दर लाइन फिर से लिखने के लिए एक प्रबंधक की आवश्यकता नहीं होती। उन्हें एक प्रबंधक की आवश्यकता होती है जो फिनिश लाइन का नाम दे सके।

यदि टीम में विशेषज्ञ शामिल हैं, तो याद रखें कि डिजाइनरों के लिए फ्रीलांस अक्सर परिभाषित आउटपुट के साथ सबसे अच्छा काम करता है, न कि निरंतर निगरानी के साथ। अन्य विशेषज्ञ भूमिकाओं के लिए भी यही पैटर्न लागू होता है। मील के पत्थर के लिए पूछें, न कि प्रति घंटे की आश्वासन के लिए।

4. दायरे में बदलावों को “छोटे favors” के रूप में मानना

“क्या आप बस एक चीज़ जोड़ सकते हैं?” ने किसी भी नाटकीय विफलता की तुलना में अधिक परियोजना बजट को तोड़ा है। एक छोटा एहसान हानिरहित लगता है क्योंकि यह केवल 1 अतिरिक्त स्क्रीन, 1 अतिरिक्त पैराग्राफ, या 1 अतिरिक्त डेटा फ़ील्ड है। फिर भी प्रत्येक छोटा एहसान परीक्षण, समीक्षा समय, और डिलीवरी की तारीख को बदल सकता है।

गलती परिवर्तन को स्वीकार न करना है। गलती अनौपचारिक रूप से परिवर्तन को स्वीकार करना है। यदि एक अनुरोध को लॉग नहीं किया गया, आंका नहीं गया, और जानबूझकर स्वीकार नहीं किया गया, तो यह अदृश्य कार्य बन जाता है। अदृश्य कार्य हमेशा बाद में देरी, बिलिंग विवाद, या एक थके हुए टीम सदस्य के रूप में लौटता है जो चुपचाप संदेशों को मिस करना शुरू कर देता है।

एक सरल नियम रखें: हर दायरा परिवर्तन के लिए 3 प्रश्न होते हैं। क्या बदलता है? क्या इस पर निर्भर करता है? कौन इसे मंजूरी देता है? यह 5 मिनट से कम समय लेता है और अक्सर 2 घंटे की बहस को रोकता है।

यह 24freelance.pro साइट के नियमों को याद रखने के लिए एक अच्छा स्थान है। फ्रीलांस परियोजनाएँ स्पष्टता पर निर्भर करती हैं, और जब अनुरोध चैट थ्रेड में छिपे नहीं होते हैं तो स्पष्टता आसान होती है। यहां तक कि एक छोटा एहसान भी एक ट्रेस करने योग्य निर्णय का हकदार है।

5. समानांतर कार्यों के बीच निर्भरता जोखिमों की अनदेखी करना

समानांतर कार्य प्रभावी लगते हैं जब तक एक कार्य 4 अन्य कार्यों को अवरुद्ध नहीं करता। एक डेवलपर टेक्स्ट का इंतजार करता है। एक डिज़ाइनर उत्पाद विशिष्टताओं का इंतजार करता है। एक समीक्षक कानूनी नोट का इंतजार करता है। परियोजना व्यस्त लगती है, लेकिन अनुक्रम गलत है। यह एक निर्भरता समस्या है, प्रेरणा समस्या नहीं।

प्रबंधक अक्सर इसे चूक जाते हैं क्योंकि हर कार्य सक्रिय प्रतीत होता है। एक कार्य सक्रिय हो सकता है और फिर भी निरर्थक हो सकता है यदि इसकी पूर्वापेक्षा पूरी नहीं हुई है। बर्बाद किया गया समय चुपचाप जमा होता है। अंत में, सभी ने मेहनत की है और परियोजना अभी भी 1 सप्ताह पीछे है।

क्रम को वास्तविक नामों के साथ मानचित्रित करें, जैसे “सामग्री” या “डेव” जैसे लेबल नहीं। लिखें कि किसे क्या चाहिए और किस तारीख तक। यदि एक कार्य दूसरे के बिना शुरू नहीं हो सकता, तो योजना में स्पष्ट रूप से ऐसा कहें। एक स्प्रेडशीट में छिपी हुई निर्भरता अभी भी एक निर्भरता है।

उन टीमों के लिए जो सिस्टम या होस्टेड टूल के बीच काम करती हैं, क्लाउड सेटअप एक और देरी का बिंदु जोड़ सकता है। लेख पर क्लाउड कंप्यूटिंग तकनीकयहां प्रासंगिक है क्योंकि बुनियादी ढांचे में परिवर्तन अक्सर “शुरू करने के लिए तैयार” और “वास्तव में उपयोगी” के बीच होते हैं।

6. एक मील का पत्थर के अंत में केवल प्रगति की समीक्षा करना

एक मील का पत्थर की समीक्षा उपयोगी होती है। केवल अंत में एक मील का पत्थर की समीक्षा खतरनाक होती है। यदि समस्या एक टूटी हुई धारणा है, तो अंतिम दिन तक इंतजार करना इसका समाधान नहीं होता; यह फिर से काम बन जाता है। फिर से काम करने में समय दो बार लगता है।

केवल अंत में समीक्षा करने की आदतें आमतौर पर आशावाद से आती हैं। प्रबंधक टीम पर भरोसा करता है, टीम योजना पर भरोसा करती है, और सभी को विश्वास होता है कि अगला चेकपॉइंट समस्याओं को पकड़ लेगा। फिर चेकपॉइंट आता है और एक गायब संपत्ति, एक गलत प्रारूप, या गलत ब्रीफ के खिलाफ किया गया कार्य प्रकट करता है।

2 सरल क्षणों के साथ पहले जांचें: एक प्रारंभिक नमूना और एक मध्य-बिंदु समीक्षा। नमूना दिशा दिखाता है। मध्य-बिंदु समीक्षा खराब निर्णयों को पकड़ती है जब वे अभी भी सस्ते होते हैं। यदि काम पाठ है, तो एक पृष्ठ 20 पृष्ठ लिखे जाने से पहले एक स्वर समस्या को उजागर कर सकता है।

यह आदत बाहरी मदद वाले परियोजनाओं पर और भी महत्वपूर्ण है, क्योंकि फ्रीलांसर की समीक्षाएँ अक्सर यह दर्शाते हैं कि क्या प्रतिक्रिया समय पर आई थी ताकि दिशा को सही किया जा सके। देर से मिली प्रतिक्रिया देर से सुधार करती है। यह पैटर्न सरल है, और यह महंगा है।

7. हर परियोजना प्रकार के लिए एक ही प्रक्रिया का उपयोग करना

एक 2-व्यक्ति लैंडिंग पृष्ठ और एक 12-व्यक्ति उत्पाद लॉन्च को एक ही प्रक्रिया की आवश्यकता नहीं होती। फिर भी टीमें वही चेकलिस्ट दोबारा उपयोग करती हैं क्योंकि यह प्रभावी लगती है। परिणाम या तो छोटे काम के लिए बहुत अधिक समारोह होता है या बड़े काम के लिए बहुत कम संरचना होती है।

एक परियोजना को 10-मिनट की चेक-इन और एक साझा फ़ोल्डर की आवश्यकता हो सकती है। दूसरी को एक परिवर्तन लॉग, एक साइन-ऑफ चरण, और एक साप्ताहिक समीक्षा की आवश्यकता हो सकती है। यदि आप दोनों पर एक ही विधि को लागू करते हैं, तो आप एक मामले में घर्षण और दूसरे में अंतराल उत्पन्न करते हैं। प्रक्रिया को काम के आकार के अनुसार होना चाहिए, न कि प्रबंधक की आदत के अनुसार।

यह परियोजना प्रबंधन में एक सामान्य गलती है जो वर्षों तक जीवित रहती है क्योंकि यह अनुशासित लगती है। कैलेंडर भरा हुआ है, बोर्ड साफ है, और टीम सोचती है कि प्रक्रिया 'मानक' है। मानक उपयुक्त के समान नहीं है।

यदि आपकी परियोजना में सामुदायिक सामग्री या संदर्भ सामग्री भी शामिल है, तो यहां तक कि एक विकी साइट बनाना यह दिखा सकता है कि प्रक्रिया कैसे दायरे के साथ बदलती है: एक संपादक, 1 समीक्षा पथ, और एक ग्राहक अभियान से बहुत अलग गति।

8. उस क्षण को चूकना जब एक परियोजना को रोकने या रीसेट करने की आवश्यकता होती है

कुछ परियोजनाओं को अधिक धक्का नहीं देना चाहिए। उन्हें रोका जाना चाहिए। यदि ग्राहक ने 3 बार दिशा बदली है, बजट प्रभावित हुआ है, और टीम वही डिलीवरबल फिर से बना रही है, तो आगे बढ़ना एक भ्रांति हो सकती है। ऑटोपायलट पर जारी रहना दृढ़ता नहीं है। यह बहाव है।

एक रीसेट अपने आप में असफलता नहीं है। कभी-कभी यह एकमात्र साफ़ कदम होता है। मुख्य संकेत सरल हैं: बार-बार रुकावटें, अस्पष्ट स्वामित्व, और निर्णय जो बार-बार पलटे जाते हैं। जब ये संकेत एक साथ प्रकट होते हैं, तो प्रबंधक को पूछना चाहिए कि क्या वर्तमान दायरा अभी भी समझ में आता है।

एक छोटा रीसेट मीटिंग एक परियोजना को बचा सकता है। यह बताएं कि क्या पूरा हुआ है, क्या नहीं हुआ है, और क्या छोड़ना है। यदि कोई कार्य लक्ष्य का समर्थन नहीं करता है, तो उसे हटा दें। यदि लक्ष्य स्वयं बदल गया है, तो योजना को फिर से लिखें। यदि बजट या समय अब उपयुक्त नहीं है, तो इसे स्पष्ट रूप से कहें, भले ही उत्तर असहज हो।

यही वह जगह है जहाँ परियोजना प्रबंधन की अनुशासन इच्छाशक्ति से अलग होती है। एक परियोजना को रद्द किया जा सकता है, फिर से परिभाषित किया जा सकता है, या पुनः सौंपा जा सकता है। कुछ टीमों के लिए, यह बातचीत बहुत देर से होती है क्योंकि वे गति को प्रगति के साथ भ्रमित करते हैं।

ये गलतियाँ चूकना आसान क्यों हैं

इन मामलों में एक विशेषता साझा होती है: प्रत्येक गलती उस क्षण में उचित लग सकती है। एक प्रबंधक जल्दी से कार्यभार संभालता है, विशेषज्ञों को अतिरिक्त शोर से बचाता है, एक छोटी सी कृपा स्वीकार करता है, या मील का पत्थर समीक्षा के लिए इंतजार करता है। इनमें से कोई भी विकल्प अपने आप में लापरवाह नहीं लगता। नुकसान केवल तब दिखाई देता है जब इनमें से 2 या 3 एक साथ जुड़ जाते हैं।

यही कारण है कि सबसे अच्छे परियोजना प्रबंधन की आदतें नाटकीय नहीं होती हैं। वे एक अच्छे तरीके से उबाऊ होती हैं। वे निर्णयों को रिकॉर्ड करती हैं, निर्भरताओं का नाम देती हैं, और दायरे में बदलाव को खुलकर लाती हैं। एक टीम को 20 नियमों की आवश्यकता नहीं होती। इसे सही 5 की लगातार आवश्यकता होती है।

पाठक जो साइट विकल्पों के व्यापक सेट को देखना चाहते हैं, वे स्कैन कर सकते हैं फ्रीलांस मार्केटप्लेस पर सभी टैग और देख सकते हैं कि ये मुद्दे भर्ती, डिलीवरी, और समीक्षा में कितनी बार क्रॉस करते हैं। श्रेणियाँ बदलती हैं। गलतियाँ ज्यादा नहीं बदलती।

और हाँ, “परियोजना प्रबंधन में सामान्य गलतियाँ” वाक्यांश व्यापक लगता है जब तक आप इसे एक वास्तविक परियोजना में नहीं देखते जिसमें एक छूटी हुई हैंडऑफ, एक मौन निर्भरता, और एक निर्णय है जिसे किसी ने नहीं लिखा। तब यह बहुत जल्दी ठोस हो जाता है।