प्रोजेक्ट टीम के टकराव को कैसे प्रबंधित करें: विरोधी पक्षों से निकलकर फिर से समस्या-समाधान की ओर बढ़ना
जब किसी प्रोजेक्ट टीम में इस बात पर बहस हो कि क्या पूरा किया जा सकता है, तो किसी से भी समझौता करने को कहने से पहले मौजूदा सहमति की ओर लौटें। वादा किए गए परिणाम, तारीख, उपलब्ध लोगों और विवादित अनुमान के पीछे के साक्ष्यों की पहचान करें। फिर उस प्रश्न में अंतर करें जिसकी जांच की जानी बाकी है और उस विकल्प में अंतर करें जिसके लिए किसी अधिकृत निर्णय की आवश्यकता है। केवल "बेहतर ढंग से मिलकर काम करने" का आग्रह करने से कमी वाली क्षमता नहीं बढ़ाई जा सकती।\n\nयह दृष्टिकोण तब उपयोगी होता है जब असहमति किसी वास्तविक प्रोजेक्ट प्रतिबद्धता को प्रभावित करती है। यह उस काम पर ध्यान देता है जिसे बदलने की आवश्यकता है, न कि किसी व्यक्ति के चरित्र पर। इसका परिणाम एक संशोधित स्कोप, काम का एक अलग क्रम या किसी असमर्थित बदलाव का स्पष्ट इनकार हो सकता है; यह ज़रूरी नहीं कि दो शुरुआती मांगों के बीच का कोई मध्य मार्ग ही हो।
विवादित बदलाव की मौजूदा प्रतिबद्धता से तुलना करें
कल्पना कीजिए कि एक छोटी टीम किसी आंतरिक कार्यशाला (वर्कशॉप) के लिए प्रदर्शन (डेमो) तैयार कर रही है। सहमति के अनुसार प्रदर्शन में तीन कार्य (फ़ंक्शन्स) शामिल हैं। अब कोई चौथे कार्य का अनुरोध करता है, जबकि इसे तैयार करने वाला व्यक्ति कहता है कि इससे मौजूदा समीक्षा (रिव्यू) का समय खत्म हो जाएगा। यह एक उदाहरणात्मक स्थिति है। दृष्टिकोणों पर चर्चा करने से पहले, वर्तमान स्कोप और स्वीकृत कार्यशाला की तारीख देखें। जांचें कि क्या नए कार्य का वादा पहले ही किया गया था या यह वास्तव में एक नया अनुरोध है।
इस अंतर को सरल भाषा में दर्ज करें: एक अतिरिक्त कार्य, इसके लिए आवश्यक प्रतीत होने वाला काम और समीक्षा की वह गतिविधि जिस पर इसका असर पड़ सकता है। किसी असत्यापित अनुमान को तथ्य के रूप में प्रस्तुत न करें। यदि दो लोग स्कोप के अलग-अलग संस्करणों का उपयोग कर रहे हैं, तो किसी समाधान पर बातचीत करने से पहले यह तय करें कि कौन सा संस्करण वर्तमान में मान्य है। अन्यथा वे वास्तव में अलग-अलग डिलिवरेबल्स की योजना बनाते हुए भी ऐसा लग सकते हैं कि वे केवल लगने वाले समय या प्रयास (एफ़र्ट) पर असहमत हैं।
पूछें कि प्रत्येक पक्ष प्रोजेक्ट की किस शर्त की रक्षा कर रहा है
“इसे अभी शामिल करें” शायद कार्यशाला के किसी उद्देश्य की रक्षा कर रहा हो; “इसे बाहर रखें” शायद किसी ज़रूरी समीक्षा की रक्षा कर रहा हो। पूछें कि प्रतिभागियों को क्या देखने या करने में सक्षम होना चाहिए, और किन जांचों की अभी भी आवश्यकता है। अधिक प्रभावशाली प्रदर्शन की चाहत, प्रतिभागियों की किसी प्रमाणित आवश्यकता से अलग होती है। किसी चीज़ में बहुत अधिक समय लगने का एक सामान्य डर, पहचाने गए कार्यों पर आधारित अनुमान से अलग होता है।
हार्वर्ड का प्रोग्राम ऑन नेगोशिएशन (PON) अंतर्निहित हितों और व्यक्त किए गए पक्षों के बीच अंतर करता है तथा वस्तुनिष्ठ मानकों के उपयोग की सिफारिश करता है। यहाँ, उस सिद्धांत को प्रोजेक्ट के अपने सहमत परिणाम और साक्ष्य पर लागू करें। किसी के मंतव्य का अनुमान न लगाएं और न ही उनकी ओर से किसी साझा लक्ष्य की घोषणा करें। उनसे इस बात की पुष्टि करने को कहें कि क्या आपका विवरण उसी स्थिति को दर्शाता है जिसे वे सुरक्षित रखने की कोशिश कर रहे हैं।
तकनीकी अनिश्चितता को स्कोप के निर्णय से अलग करें
यदि विवादित प्रश्न यह है कि क्या कोई मौजूदा घटक अतिरिक्त कार्य का समर्थन कर सकता है, तो किसी नामित व्यक्ति, एक निर्धारित समय और एक अवलोकन योग्य परिणाम के साथ सीमित जांच पर सहमति बनाएं। उदाहरण के लिए, पूरे प्रस्तावित फ़ीचर को बनाने के बजाय केवल संबंधित घटक का सत्यापन करें। पहले ही तय कर लें कि किस निष्कर्ष से यह विकल्प व्यावहारिक माना जाएगा और इसके बाद क्या अनिश्चितता बनी रहेगी।
यदि सभी पहले से ही जानते हैं कि अतिरिक्त काम उपलब्ध समय से अधिक है, तो अधिक तकनीकी चर्चा से कुछ भी हल नहीं हो सकता है। यह चयन स्कोप, समय या क्षमता से संबंधित है। इसी तरह, एक सफल छोटी जांच अपने आप अतिरिक्त काम को मंजूरी नहीं देती है। यह केवल प्रोजेक्ट के निर्णय के लिए जिम्मेदार व्यक्ति को साक्ष्य प्रदान करती है।
यही अंतर तब भी लागू होता है जब किसी ने कुछ अतिरिक्त जोड़ने का अनुरोध न किया हो। मान लीजिए कि टीम के दो सदस्य पहले से सहमत परिणाम को प्राप्त करने के लिए अलग-अलग तरीकों की सिफारिश करते हैं। समान इनपुट, संचालन स्थितियों और स्वीकृति मानदंडों के बारे में उनके अनुमानों की तुलना करें। प्रत्येक व्यक्ति से एक ऐसे अवलोकन की पहचान करने को कहें जो उनके पसंदीदा दृष्टिकोण का खंडन कर सकता हो। एक सीमित तुलना से यह सामने आ सकता है कि किसी एक अनुमान में किसी निर्भरता को छोड़ दिया गया था या किसी अलग स्थिति का उपयोग किया गया था। जो जांचा गया था और जो अज्ञात रह गया है उसे दर्ज करें; किसी दृष्टिकोण को केवल इसलिए न चुनें क्योंकि उसका समर्थन करने वाला व्यक्ति अधिक वरिष्ठ है।
पूरे प्रोजेक्ट पर पड़ने वाले परिणामों की तुलना करें
उन विकल्पों पर विचार करें जो वास्तव में उपलब्ध हैं: मूल प्रदर्शन को बनाए रखें, यदि स्वामी (ओनर) अनुमति दे तो किसी एक सहमत कार्य को अनुरोधित कार्य से बदल दें, या अतिरिक्त काम को बाद के सत्र में ले जाएं। प्रत्येक विकल्प के लिए, प्रभावित तैयारी, समीक्षा, सामग्री और लोगों की पहचान करें। बाहर से छोटा दिखने वाला बदलाव बैठक से बाहर के किसी व्यक्ति के लिए काम बढ़ा सकता है, इसलिए उनकी ओर से वादा करने से पहले उस व्यक्ति से पूछें।
एटलसियन का प्रोजेक्ट ट्रेड-ऑफ विश्लेषण स्कोप, समय, लागत, गुणवत्ता और जोखिम जैसे चरों की जांच करता है, और पूछता है कि कौन से अधिक लचीले हैं। यह नई जानकारी सामने आने पर प्राथमिकताओं पर फिर से विचार करने की भी सिफारिश करता है। आप पूरे कार्यशाला प्रारूप को अपनाए बिना भी उन प्रश्नों का उपयोग कर सकते हैं। कोई आवश्यक जांच केवल इसलिए वैकल्पिक नहीं हो जाती क्योंकि किसी अन्य चर को बदलना कठिन है।
लागू करने योग्य निर्णय के साथ असहमति को समाप्त करें
मौजूदा निर्णय अधिकार का उपयोग करें। वर्तमान प्रतिबद्धता, सत्यापित निष्कर्ष, अनसुलझे अनुमान और व्यावहारिक विकल्पों के परिणाम प्रस्तुत करें। यदि टीम कार्यशाला की तारीख नहीं बदल सकती या किसी अन्य व्यक्ति को नहीं सौंप सकती, तो ऐसा स्पष्ट कहें। चयनित व्यवस्था को दर्ज करें, यह भी तय करें कि बदले गए प्रत्येक कार्य को कौन पूरा करेगा और यह किस पिछले निर्देश की जगह लेगा। पुष्टि करें कि प्रभावित सहयोगी नई व्यवस्था के अनुसार काम कर सकते हैं।
बातचीत करने वाली टीमों पर PON की एक चर्चा कार्य से जुड़ी असहमतियों को व्यक्तिगत हमलों से अलग करती है; इसकी रूपरेखा यह स्थापित नहीं करती कि टकराव से प्रोजेक्ट में हमेशा सुधार ही होता है। बहस को इसी प्रतिबद्धता पर केंद्रित रखें। अगली प्रासंगिक जांच के बाद, देखें कि क्या चुनी गई व्यवस्था ने आवश्यक परिणाम को बनाए रखा और क्या कोई अनुमान गलत साबित हुआ। किसी पहले की बातचीत को किसी व्यक्ति की विश्वसनीयता पर स्थायी निर्णय मानने के बजाय, यदि आवश्यक हो तो विशिष्ट निर्णय पर फिर से विचार करें।