टीमों में ओवरलैपिंग भूमिकाओं का प्रबंधन

परिचय

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

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

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

अस्पष्ट जिम्मेदारियों की लागत

• अगला कदम दर्द बिंदुओं की पहचान करना है। टीम से पिछले महीने की उन परिस्थितियों को याद करने के लिए कहें जहाँ इस बारे में भ्रम पैदा हुआ कि कौन जिम्मेदार था। ऐसे मामलों की संख्या आमतौर पर प्रारंभिक अपेक्षाओं से अधिक होती है।

RACI मैट्रिक्स

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

RACI का अर्थ है:

• Responsible (निष्पादक): वह व्यक्ति जो काम अपने हाथ से करता है, और किसी एक काम में यह भूमिका कई लोगों की हो सकती है।
• Accountable (स्वामी): वह व्यक्ति जो नतीजे का जवाब देता है और मुख्य फ़ैसले लेता है, और ध्यान रहे कि हर काम का Accountable व्यक्ति सिर्फ़ एक ही होना चाहिए।
• Consulted (सलाहकार): वे लोग जिनकी राय पर विचार करना ज़रूरी है, आम तौर पर पड़ोसी क्षेत्रों के विशेषज्ञ।
• Informed (पर्यवेक्षक): वे लोग जिन्हें खबर रहनी चाहिए, पर फ़ैसले के लिए जिनकी राय ज़रूरी नहीं होती।

व्यावहारिक दृष्टिकोण: शुरुआत किसी एक ठोस प्रक्रिया के लिए RACI मैट्रिक्स बनाकर करें, जैसे नए कर्मचारी की भर्ती या उत्पाद की किसी नई सुविधा का लॉन्च। जब टीम एक असली उदाहरण पर तरीका समझ ले, तब इसे बाकी प्रक्रियाओं तक फैलाया जा सकता है।

लागू उदाहरण: किसी नई सुविधा के लॉन्च में Responsible डेवलपर हो सकता है, Accountable उत्पाद प्रबंधक, Consulted डिज़ाइनर और विश्लेषक, और Informed प्रबंधन तथा ग्राहक सहायता टीम।

मुख्य बाधा: हर काम का Accountable व्यक्ति ठीक एक होना चाहिए। अगर दो लोगों को मालिक बना दिया जाए, तो असल में जवाबदेही किसी की नहीं रह जाती।

साप्ताहिक सिंक्रनाइज़ेशन

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

साप्ताहिक सिंक का कारगर प्रारूप:

• मैं क्या योजना बना रहा हूँ (प्रति व्यक्ति 3 मिनट): इस हफ़्ते के मुख्य कामों का छोटा-सा ब्योरा
• मुझे कहाँ मदद की आवश्यकता है (प्रति व्यक्ति 2 मिनट): किसी सहारे या सलाह के लिए साफ़-साफ़ अनुरोध
• संभावित ओवरलैप (समूह के लिए 5 मिनट): उन कामों पर बात जिनका असर साथियों के काम पर पड़ सकता है

इस प्रारूप में 15-20 मिनट लगते हैं और यह कई घंटों के दोहराए गए काम को बचा लेता है, जो संगठन छोटा हो या बड़ा, हर हाल में फ़ायदे का सौदा है।

योग्यता मैट्रिक्स

हर टीम में कुछ अनौपचारिक विशेषज्ञ होते हैं, जिनके पास लोग किसी खास विषय पर सलाह लेने जाते हैं। जब इस विशेषज्ञता को खुलकर और औपचारिक रूप से दर्ज कर दिया जाता है, तो यह उलझन कम हो जाती है कि किससे पूछना है और विवाद की हालत में फ़ैसला किसका होगा।

योग्यता मैट्रिक्स में तीन स्तर होते हैं:

• विशेषज्ञ: इस क्षेत्र में आखिरी फ़ैसला लेता है, साथियों को सलाह देता है और टीम में इस विषय की समझ बढ़ाने की जिम्मेदारी उसी की होती है
• अभ्यासी: सामान्य काम खुद निपटा लेता है और ज़रूरत पड़ने पर विशेषज्ञ का हाथ बँटा सकता है
• नवीन: इस क्षेत्र में अभी सीख रहा है और विशेषज्ञ या अभ्यासी की देखरेख में काम करता है

ऐसी मैट्रिक्स से फ़ौरन पता चल जाता है कि सवाल लेकर किसके पास जाना है और उलझी स्थिति कौन सुलझाएगा। कोई व्यक्ति एक क्षेत्र में विशेषज्ञ और दूसरे में नवीन हो सकता है, जो ढाँचे के लिहाज़ से बिल्कुल सामान्य है और रोज़ के काम में उपयोगी भी (और पढ़ें: कंपनी प्रबंधन)।

प्रक्रिया पारदर्शिता

सही तरह से सेट किए गए परियोजना प्रबंधन उपकरण यह उलझन कम कर देते हैं कि कौन क्या कर रहा है, और संभावित ओवरलैप को टकराव या दोहरी मेहनत में बदलने से पहले ही सामने ले आते हैं, बशर्ते ये मुख्य सिद्धांत माने जाएँ:

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

अगर टीम में समस्याओं पर खुलकर बात करने का माहौल न हो, तो सबसे सोची-समझी प्रक्रियाएँ भी ज़्यादा कुछ नहीं दे पातीं। लोगों को यह मानने में झिझक नहीं होनी चाहिए कि उन्हें अपनी जिम्मेदारियों को लेकर पक्का नहीं पता, और यह भरोसा ढाँचागत उपकरणों के काम शुरू करने से पहले बनना चाहिए।

संबंधित लेख:

लचीली परियोजना प्रबंधन विधियों के बारे में पढ़ें एजाइल परियोजना प्रबंधन: प्रभावी परियोजनाएँ।

संरचित प्रक्रियाएँ काम की रफ़्तार कैसे बढ़ाती हैं, यह समझने के लिए पढ़ें PM कार्यप्रवाह: परियोजना सफलता को सुव्यवस्थित करने के चरण।

दूर-दूर बैठी टीमों को व्यवस्थित करने के तरीकों के लिए पढ़ें दीर्घकालिक रिमोट कार्य के लिए एक टीम को कैसे व्यवस्थित करें।

निष्कर्ष

टीमें बढ़ती हैं और परियोजनाएँ पेचीदा होती जाती हैं, इसलिए जिम्मेदारियों की सीमाओं को समय-समय पर दोबारा देखना और तालमेल की प्रक्रियाओं को लगातार सुधारते रहना पड़ता है। मकसद ऐसी व्यवस्था बनाना नहीं है जिसमें एक भी ओवरलैप न हो। मकसद यह है कि हर ओवरलैप सोच-समझकर हो, सँभाला जा सके और साझा नतीजों की ओर ले जाए, और वह धुंधले ढाँचे या आपस में बिना तालमेल लिए गए निजी फ़ैसलों की उपज न बने।