RACI, DACI या RAPID: आपकी टीम को असल में किसकी ज़रूरत है
ज़िम्मेदारी के तीन ढाँचे, तीन अलग समस्याएँ। हर एक किस नाकामी के खिलाफ़ बनाया गया, हर एक कहाँ नाकाम होता है, और चुनने के लिए एक छोटी-सी परीक्षा।
गोरखा टीम11 मिनट का पठन
RACI मैट्रिक्स बिल्डर → हर कार्य के लिए तय करें कि कौन करेगा, कौन जवाबदेह है, किससे परामर्श होगा और किसे सूचित किया जाएगा, और खाली जगहें पकड़ें।
एक खास किस्म की बैठक होती है जो बता देती है कि टीम में निर्णय-अधिकार की समस्या है। फ़ैसला छह हफ़्ते पहले हो चुका था। कोई, जो उस कमरे में नहीं था, तब से आपत्ति उठा चुका है, और अब वही फ़ैसला दोबारा लिया जा रहा है, दूसरे समूह के साथ, शुरू से। कोई भी अनुचित व्यवहार नहीं कर रहा। बस यह तय ही नहीं हुआ था कि फ़ैसला करने का हक़ किसका है।
इस बैठक को रोकने के लिए तीन ढाँचे मौजूद हैं: RACI, DACI और RAPID। ये एक-दूसरे की जगह लेने लायक लगते हैं (चार या पाँच अक्षर, लोगों को भूमिकाओं से जोड़ना) और टीमें इनमें से लगभग बेतरतीब ढंग से चुन लेती हैं, आम तौर पर वही जो पिछली कंपनी में चलता था। ये अदल-बदल लायक नहीं हैं। हर एक किसी अलग नाकामी के खिलाफ़ बना है, और गलत वाला इस्तेमाल करने से ऐसा दस्तावेज़ बनता है जो अच्छे-से-अच्छे हाल में भी बस व्यस्तता भर है।
तीन नाकामियाँ
यह नाम देना मददगार है कि हर ढाँचा किस नाकामी के खिलाफ़ बनाया गया, क्योंकि असल में उन्हें यही अलग करता है।
RACI चलते रहने वाले, बँटे हुए काम के लिए है। इसकी नाकामी है बहुत सारे कार्यों में मालिकी का धुँधला पड़ जाना, वह परियोजना जिसमें बीस चीज़ें चल रही हैं और देर से पता चलता है कि कई किसी की भी नहीं थीं।
DACI एक अकेले फ़ैसले के लिए है। इसकी नाकामी है वह फ़ैसला जो कभी बंद नहीं होता, वह चुनाव जो खुला रहता है क्योंकि पहले से कोई तय नहीं हुआ था कि इसे कौन निपटाएगा।
RAPID बड़ी संस्था में किसी महत्वपूर्ण, विभागों के आर-पार जाने वाले फ़ैसले के लिए है। इसकी नाकामी है वह फ़ैसला जो हुआ और फिर पलट गया, वह जिसमें असली वीटो रखने वाले को सलाहकार की तरह बरता गया, उसे नतीजा बाद में पता चला, और उसने मामला फिर खोल दिया।
अगर आप बता सकते हैं कि आपकी टीम में इन तीनों में से कौन-सी हो रही है, तो आपने अपना ढाँचा चुन ही लिया है।
RACI: चलते काम का नक़्शा
RACI हर कार्य को चार भूमिकाएँ देती है: Responsible (काम करता है), Accountable (उसका जवाब देता है, ठीक एक व्यक्ति), Consulted (काम पूरा होने से पहले पूछा जाता है) और Informed (बाद में बताया जाता है)। Project Management Institute, RACI चार्ट को responsibility assignment matrix का एक उदाहरण मानता है, ग्रिडों का वह सामान्य परिवार जो लोगों को वर्क पैकेज से जोड़ता है।
इसका आकार ही बता देता है कि यह किसलिए है: एक ग्रिड, बहुत पंक्तियाँ, बहुत स्तंभ। यह समय के साथ फैले काम के पिंड का वर्णन करती है, किसी एक क्षण का नहीं। एक सॉफ़्टवेयर रिलीज़, एक माइग्रेशन, निर्माण का एक चरण, एक ऑडिट।
जहाँ यह काम करती है। जब भी सवाल यह हो कि "इस सब में कौन क्या कर रहा है?" मैट्रिक्स का रूप दो चीज़ें दिखा देता है जो गद्य नहीं दिखा सकता: वह पंक्ति जिसका कोई जवाबदेह मालिक नहीं, और वह स्तंभ जिसमें हर पंक्ति पर जवाबदेही है, वही अड़चन जिसकी शिकायत सब करते हैं और जिसकी तरफ़ कोई उँगली नहीं उठा पाता।
जहाँ यह नाकाम होती है। RACI में कब की कोई धारणा नहीं है। यह कहती है कि QA लीड जाँच के लिए responsible है; यह नहीं कहती कि जाँच मंज़ूरी से पहले होगी या बाद में। बारीकी के साथ यह बुरी तरह बिगड़ती भी है: अलग-अलग गतिविधियों की चालीस पंक्तियों पर यह ऐसा दस्तावेज़ बन जाती है जिसे कोई सँभालता नहीं, और बिना सँभाली मैट्रिक्स किसी मैट्रिक्स न होने से भी बुरी है, क्योंकि लोग उस पर भरोसा कर लेते हैं।
और अकेले फ़ैसलों के लिए यह सचमुच कमज़ोर है। आप ज़बरदस्ती एक बना सकते हैं (एक पंक्ति, उस पर अक्षर) लेकिन शब्दावली गलत है। "Consulted" उस व्यक्ति में, जिसकी राय का स्वागत है, और उस व्यक्ति में, जो आपको रोक सकता है, कोई फ़र्क नहीं करता।
DACI: एक फ़ैसला, बंद किया हुआ
DACI अक्षरों की जगह एक चुनाव पर टिकी चार भूमिकाएँ रखता है: Driver (निर्णय-प्रक्रिया का समन्वय करता है और उसे चलाता रहता है), Approver (फ़ैसला करता है, एक व्यक्ति), Contributors (विशेषज्ञता और विश्लेषण देते हैं) और Informed (नतीजा बताया जाता है)। Atlassian इसे अपने Team Playbook में एक प्ले के रूप में प्रकाशित करता है और भीतर इस्तेमाल करता है।
अहम कदम है Driver को Approver से अलग करना। RACI में अक्सर मान लिया जाता है कि जवाबदेह व्यक्ति ही प्रक्रिया को हाँक रहा है। DACI कहता है कि ये अलग काम हैं, और असली फ़ैसले में अक्सर होते भी हैं: प्रोडक्ट मैनेजर प्रक्रिया चलाता है, निदेशक फ़ैसला करता है।
जहाँ यह काम करता है। कोई भी फ़ैसला जिसकी समय-सीमा हो और जिस पर तीन से ज़्यादा लोगों की राय हो। विक्रेता चुनना। दो आर्किटेक्चर में से एक तय करना। लॉन्च की तारीख़ पर सहमत होना। नतीजा एक पन्ने का दस्तावेज़ होता है, ग्रिड नहीं, और वह लिखे हुए फ़ैसले और एक तारीख़ पर ख़त्म होता है।
जहाँ यह नाकाम होता है। DACI के पास वीटो के लिए कोई शब्द नहीं है। जो Approver नहीं है, वह Contributor है, चाहे वह मददगार इंजीनियर हो या कानूनी विभाग का प्रमुख जो पूरा मामला रोक सकता है। छोटी संस्था में यह भेद अनौपचारिक रह सकता है। बड़ी में यही बाद में फटता है।
चलते काम के लिए भी यह अनुपयुक्त है। हर फ़ैसले का एक DACI ठीक है; किसी परियोजना का वर्णन करने वाले चालीस DACI योजना नहीं हैं।
RAPID: बड़ी संस्था में निर्णय-अधिकार
RAPID®, जिसे Bain and Company ने विकसित किया और जो 2006 के Harvard Business Review लेख "Who Has the D?" (पॉल रॉजर्स और मार्सिया ब्लेंको) से लोकप्रिय हुआ, पाँच भूमिकाएँ देता है: Recommend (विश्लेषण करता है और प्रस्ताव देता है), Agree (सहमति देना ज़रूरी है, असली वीटो), Perform (फ़ैसले को अमल में लाता है), Input (परामर्श लिया जाता है, वीटो नहीं) और Decide (वह एक व्यक्ति जो संस्था को प्रतिबद्ध करता है)।
दो बातें इसे अलग बनाती हैं, और दोनों उन्हीं संस्थाओं से आती हैं जिनके लिए यह बना।
पहली, Agree को Input से अलग किया गया है। यही पूरी बात है। ज़्यादातर ढाँचों में "जिनसे हम पूछते हैं" के लिए एक ही डिब्बा होता है। RAPID उसे दो में बाँट देता है (जिनकी सहमति अनिवार्य है और जिनकी राय वांछित है) और आपको पहले से बताने पर मजबूर करता है कि कौन कौन है। यही वह नियंत्रण है जो फ़ैसलों को पलटने से रोकता है।
दूसरी, Perform खुद फ़ैसले के भीतर नामित भूमिका है। जिन लोगों को इस चुनाव के साथ जीना है, उनकी पहचान फ़ैसला होते समय ही हो जाती है, और इससे चुनाव आम तौर पर बेहतर होता है।
जहाँ यह काम करता है। उतनी बड़ी संस्थाओं में महत्वपूर्ण, विभागों के आर-पार जाने वाले फ़ैसले जहाँ विभागों के पास असली वीटो का बल हो, मूल्य-निर्धारण, किसी बाज़ार में उतरना, किसी प्लैटफ़ॉर्म पर प्रतिबद्धता। तीनों में यह सबसे सटीक है।
जहाँ यह नाकाम होता है। यह भारी है। जिस फ़ैसले को एक व्यक्ति दस मिनट में ले सकता था, उस पर RAPID चलाना एक कर है, और जो टीमें इसे हर जगह अपनाती हैं, वे जल्दी ही कहीं भी इस्तेमाल करना छोड़ देती हैं। बारह लोगों की कंपनी में Agree की भूमिका आम तौर पर Decide में ही समा जाती है, और तब आप दो अक्षरों की स्थिति के लिए पाँच अक्षरों का ढाँचा सँभाल रहे होते हैं।
आमने-सामने
| RACI | DACI | RAPID | |
|---|---|---|---|
| किसके लिए बना | चलता काम | एक फ़ैसला | एक महत्वपूर्ण फ़ैसला |
| रूप | बहुत कार्यों की ग्रिड | एक पन्ने का दस्तावेज़ | एक पन्ने का दस्तावेज़ |
| एकमात्र मालिक | Accountable | Approver | Decide |
| वीटो स्पष्ट है | नहीं | नहीं | हाँ (Agree) |
| काम कौन करता है | Responsible | तय नहीं | Perform |
| प्रक्रिया का मालिक नामित | नहीं | हाँ (Driver) | व्यवहार में Recommend |
| आम आकार | 6 से 20 पंक्तियाँ | 1 फ़ैसला | 1 फ़ैसला |
| कमज़ोरी | अकेले फ़ैसले, क्रम | वीटो के अधिकार, चलता काम | छोटी टीमें, छोटे फ़ैसले |
चुनाव, तीन सवालों में
1. यह काम का पिंड है या एक चुनाव? काम का पिंड यानी RACI। एक चुनाव यानी DACI या RAPID। यही एक सवाल ज़्यादातर मामले तय कर देता है, और टीमें हैरान करने वाली बारंबारता से गलती करती हैं, आम तौर पर उस चीज़ के लिए RACI बनाकर जो परियोजना के भेस में एक फ़ैसला था।
2. कमरे के बाहर कोई इसे रोक सकता है? अगर हाँ, और आप उससे सीधे फ़ैसला करने को नहीं कह सकते, तो आपको RAPID चाहिए, क्योंकि आपको Agree भूमिका चाहिए। अगर नहीं, तो DACI हल्का है और सचमुच इस्तेमाल होगा।
3. तीन महीने बाद इसे कोई पढ़ेगा? अगर नहीं, तो इनमें से कोई न बनाएँ। एक वाक्य में लिख दें कि फ़ैसला कौन करता है, उसी दस्तावेज़ में जहाँ काम रहता है। ये ढाँचे तब के लिए हैं जब जवाब को उन लोगों से टकराकर भी टिकना है जो वहाँ मौजूद नहीं थे।
जो इनमें से कोई ठीक नहीं करता
इस पर साफ़ कहना ज़रूरी है, क्योंकि ये ढाँचे उन समस्याओं के इलाज के रूप में बेचे जाते हैं जिन्हें ये छूते भी नहीं।
ये अधिकार नहीं बनाते। किसी का नाम Accountable, Approver या Decide के नीचे लिख देने से उसे फ़ैसला करने की ताक़त नहीं मिल जाती। अगर वह मना नहीं कर सकता और उसे टिका नहीं सकता, तो दस्तावेज़ एक ऐसी संस्था का वर्णन कर रहा है जो मौजूद नहीं है। सही प्रतिक्रिया यह है कि खाने में उस व्यक्ति का नाम डालें जो मना कर सकता है, चाहे यह राजनीतिक रूप से असुविधाजनक हो। वह असुविधा ही जानकारी है।
ये फ़ैसले की जगह नहीं लेते। पूरी भरी हुई मैट्रिक्स फ़ैसला नहीं है; यह इस पर सहमति है कि फ़ैसला कौन करेगा। कभी-कभी टीमें ढाँचा पूरा करती हैं, प्रगति का अहसास पाती हैं, और फ़ैसला कभी नहीं करतीं।
और ये उपेक्षा सहकर नहीं टिकते। तीनों एक-एक तस्वीर हैं। इन्हें उस दस्तावेज़ से जोड़ें जिसे ये नियंत्रित करते हैं, और जब उस दस्तावेज़ की समीक्षा हो तब इनकी भी करें। नाकामी कभी नाटकीय नहीं होती, कोई घोषणा नहीं करता कि मैट्रिक्स अब गलत है। वह चुपचाप हक़ीक़त से मेल खाना बंद कर देती है, और फिर कोई उस पर भरोसा कर लेता है।
इन्हें इस्तेमाल करना
चारों रूप (RACI, RASCI, DACI और RAPID) एक ही दस्तावेज़ के मोड हैं RACI मैट्रिक्स बिल्डर में। मोड बदलने पर आपकी पंक्तियाँ बनी रहती हैं और अक्षरों के नाम बदल जाते हैं, इसलिए किसी फ़ैसले को पहले DACI और फिर RAPID के रूप में देखकर यह परखने में कुछ नहीं लगता कि असल में जो हो रहा है, उस पर कौन सी शब्दावली बैठती है।
अगर आप अपनी पहली मैट्रिक्स बना रहे हैं, तो तरीक़ा यहाँ है: RACI मैट्रिक्स कैसे बनाएँ, उस क्रम वाली तरकीब सहित जो बहसें आख़िर में नहीं, शुरू में सामने लाती है।
स्रोत
- Who Has the D? How Clear Decision Roles Enhance Organizational Performance, Harvard Business Review, पॉल रॉजर्स और मार्सिया ब्लेंको, जनवरी 2006
- RAPID: Bain’s decision-making tool, Bain and Company
- DACI: a framework for group decisions, Atlassian Team Playbook
- Stakeholder management and the RACI matrix, Project Management Institute