RACI मैट्रिक्स कैसे बनाएँ
ज़िम्मेदारी तय करने वाली मैट्रिक्स बनाने का काम करने वाला तरीका: हर अक्षर का असल मतलब, पंक्तियों की ठीक संख्या, वे दो नियम जो इसे उपयोगी बनाते हैं, और वे चार तरीके जिनसे यह आम तौर पर बेकार हो जाती है।
गोरखा टीम9 मिनट का पठन
RACI मैट्रिक्स बिल्डर → हर कार्य के लिए तय करें कि कौन करेगा, कौन जवाबदेह है, किससे परामर्श होगा और किसे सूचित किया जाएगा, और खाली जगहें पकड़ें।
RACI मैट्रिक्स काम के हर हिस्से के लिए एक ही सवाल का जवाब देती है: यह कौन कर रहा है, और जब यह बिगड़े तो जवाब कौन देगा। यह एक ग्रिड है। हर स्तंभ एक व्यक्ति या भूमिका है, हर पंक्ति एक कार्य या एक डिलिवरेबल, और हर खाने में एक अक्षर।
यह प्रारूप पुराना है और बहुत चला हुआ है, Project Management Institute, RACI चार्ट को responsibility assignment matrix का एक उदाहरण बताता है, यानी उस सामान्य श्रेणी का ग्रिड जो लोगों को काम से जोड़ता है। ज़्यादातर टीमें इससे उस स्प्रेडशीट के रूप में मिलती हैं जो किसी ने एक बार बनाई और फिर कोई खोलकर नहीं देखा। वह संस्करण बेकार है। यह गाइड उस संस्करण के बारे में है जो बेकार नहीं है।
चार अक्षरों का मतलब
अक्षर रटना आसान है और गड़बड़ करना भी, क्योंकि इनमें से दो एक ही चीज़ जैसे लगते हैं।
- R: Responsible (करने वाला)। वे लोग जो काम करते हैं। कई हो सकते हैं।
- A: Accountable (जवाबदेह)। वह एक व्यक्ति जो नतीजे के लिए जवाब देता है और उसे मंज़ूरी देने का अधिकार रखता है। ठीक एक।
- C: Consulted (परामर्श लिया गया)। वे लोग जिनकी राय काम पूरा होने से पहले ली जाती है। दोतरफ़ा: उनसे पूछा जाता है और वे जवाब देते हैं।
- I: Informed (सूचित)। वे लोग जिन्हें बाद में बताया जाता है। एकतरफ़ा।
पूरी पद्धति जिस भेद पर टिकी है, वह R और A के बीच है। Responsible मेहनत की बात है। Accountable अधिकार की बात है। अगर जिस व्यक्ति को आपने A लिखा है, वह काम को असल में अस्वीकार नहीं कर सकता, तो आपने गलत व्यक्ति लिखा है, और मैट्रिक्स उस पदानुक्रम का वर्णन कर रही है जो आप चाहते हैं, उसका नहीं जो आपके पास है।
एक ही व्यक्ति दोनों हो सकता है। A/R लिखा खाना छोटी टीमों में सामान्य और आम है: वही व्यक्ति नतीजे का मालिक है और काम भी करता है। जो कभी स्वीकार्य नहीं है, वह है एक ही पंक्ति में दो अलग-अलग लोगों पर A।
दो नियम
इस गाइड में बाकी सब सलाह है। ये दो नियम हैं, और जो मैट्रिक्स इनमें से कोई एक तोड़ती है, वह बाँटने लायक नहीं है।
- हर पंक्ति में ठीक एक A। Accountable का मतलब है निर्णय का एक ही बिंदु। दो जवाबदेह लोगों का मतलब है कि जब वे असहमत होंगे, तो बात ऊपर भेजे बिना तय नहीं होगी, और यही वह नाकामी है जिसे रोकने के लिए RACI बनी है। शून्य जवाबदेह का मतलब है कि कार्य का कोई मालिक नहीं, और वह देर से उसी को पता चलेगा जिसकी किस्मत खराब हो।
- हर पंक्ति में कम से कम एक R। अगर कोई responsible नहीं है, तो कोई काम नहीं कर रहा। ऐसी पंक्तियाँ आम तौर पर वे इच्छाएँ होती हैं जो किसी योजना में टाइप हो गईं।
RACI बिल्डर दोनों की जाँच आपके टाइप करते-करते करता है और उन पंक्तियों को चिह्नित करता है जो इन्हें तोड़ती हैं, क्योंकि अपनी ही बनाई ग्रिड पढ़ते समय ये गलतियाँ ठीक वही हैं जो दिखती नहीं।
एक मैट्रिक्स बनाना, क्रम से
क्रम मायने रखता है। ज़्यादातर खराब मैट्रिक्स इसलिए खराब होती हैं कि उन्हें बाएँ से दाएँ, एक-एक पंक्ति भरते हुए बनाया गया, और यह चुपचाप इसमें बदल जाता है कि काम उसी को दे दिया जाए जो सबसे नज़दीक है।
1. लोगों से पहले पंक्तियाँ लिखें
पहले डिलिवरेबल और निर्णय लिखें, कहीं किसी का नाम नहीं। आप काम का वर्णन कर रहे हैं, टीम का नहीं। अगर आप टीम से शुरू करेंगे, तो ऐसी मैट्रिक्स बनेगी जो मौजूदा बँटवारे की जाँच करने के बजाय उसे जायज़ ठहराएगी।
डिलिवरेबल और निर्णयों के स्तर पर रहें, गतिविधियों के नहीं। "कोड लिखना और समीक्षा करना" एक पंक्ति है। "पुल रिक्वेस्ट खोलना" नहीं। एक उपयोगी जाँच: अगर किसी पंक्ति के अक्षर ऊपर की पंक्ति जैसे ही होंगे, तो वे दोनों एक ही पंक्ति हैं।
असली मैट्रिक्स आम तौर पर छह से बीस पंक्तियों के बीच रहती हैं। तीस के पार कोई पढ़ता नहीं, और उसे चरण के हिसाब से बाँटना बेहतर है।
2. स्तंभ नामों के नहीं, भूमिकाओं के रखें
इंजीनियरिंग लीड लिखें, प्रिया नहीं। भूमिकाएँ लोगों के जाने के बाद भी टिकती हैं, नाम नहीं। जहाँ भूमिका एक ही व्यक्ति के पास है और सब जानते हैं, वहाँ नाम कोष्ठक में जोड़ दें।
3. पहले A भरें, हर पंक्ति में
कुछ और छूने से पहले A वाले स्तंभ को ऊपर से नीचे भरें। यही वह दौर है जो असली बहसें सामने लाता है: वे पंक्तियाँ जहाँ दो लोग मानते हैं कि फ़ैसला वे करते हैं, और वे पंक्तियाँ जहाँ सब एक-दूसरे को देखते हैं। इन्हें अभी सुलझाएँ। आप मैट्रिक्स बना ही इसलिए रहे हैं।
4. फिर R, उसके बाद C और I
Responsible अगला है, क्योंकि जवाबदेही तय होने के बाद यह आम तौर पर साफ़ हो जाता है। फिर परामर्श और सूचना, और यहाँ कंजूस रहें। हर C एक ऐसा व्यक्ति है जो काम रोक सकता है। पाँच C वाली पंक्ति पूरी तैयारी नहीं है; वह ऐसी पंक्ति है जिसमें तीन हफ़्ते लगेंगे।
5. इसे पंक्ति से नहीं, स्तंभ से पढ़ें
अब ग्रिड को नब्बे डिग्री घुमाएँ। जिस स्तंभ में लगभग हर पंक्ति पर A है, वह अड़चन है, और वही व्यक्ति आपकी परियोजना के धीमे होने की वजह है। जिस स्तंभ में सिर्फ़ I है, वह व्यक्ति इस मैट्रिक्स में होने की ज़रूरत नहीं रखता। जिस स्तंभ में एक भी अक्षर नहीं, वह ऐसा सवाल है जिसे ज़ोर से पूछना चाहिए।
एक पूरा उदाहरण
एक सॉफ़्टवेयर रिलीज़ की छह पंक्तियाँ, पाँच भूमिकाओं के साथ:
| कार्य | प्रोडक्ट ओनर | इंजीनियरिंग लीड | डेवलपर | QA लीड | रिलीज़ मैनेजर |
|---|---|---|---|---|---|
| रिलीज़ का दायरा तय करना | A/R | C | I | C | I |
| कोड लिखना और समीक्षा करना | I | A | R | C | I |
| रिलीज़ कैंडिडेट की जाँच | I | A | C | R | I |
| गुणवत्ता पर मंज़ूरी | A | C | I | R | I |
| प्रोडक्शन में तैनाती | I | C | R | I | A |
| रिलीज़ की घोषणा | A/R | I | I | I | C |
A वाला स्तंभ ऊपर से नीचे पढ़िए और टीम की बनावट करीब चार सेकंड में दिख जाती है: प्रोडक्ट ओनर दायरे और संचार का मालिक है, इंजीनियरिंग लीड इस बात का कि यह कैसे बनेगा, और रिलीज़ मैनेजर रिलीज़ करने की क्रिया का। कोई भी सब कुछ का मालिक नहीं है। काम करने वाली मैट्रिक्स ऐसी ही दिखती है।
यही ग्रिड बिल्डर में सॉफ़्टवेयर रिलीज़ टेम्पलेट है, सातों भाषाओं में।
चार तरीके जिनसे यह बिगड़ती है
सबसे परामर्श लिया जाता है। सबसे आम नाकामी, और सबसे महँगी। C का मतलब है किसी का इंतज़ार करने का वादा। अगर आप यह नहीं बता सकते कि उनके जवाब के आधार पर आप क्या अलग करेंगे, तो वे I हैं।
जवाबदेह व्यक्ति के पास अधिकार नहीं है। जिस फ़ैसले को असल में कोई निदेशक ही ले सकता है, उस पर प्रोजेक्ट मैनेजर को A लिख देने से अधिकार हस्तांतरित नहीं होता; पंक्ति बस एक कल्पना बन जाती है। उसे लिखें जो मना कर सकता है।
यह बहुत बारीक है। अलग-अलग गतिविधियों की चालीस पंक्तियों वाली मैट्रिक्स ऐसा दस्तावेज़ है जिसे कोई अद्यतन नहीं रखेगा, यानी एक महीने में वह गलत होगी और दो में भ्रामक।
यह एक बार लिखी जाती है। किकऑफ़ पर बनी और फिर कभी न देखी गई मैट्रिक्स चुपचाप गलत हो जाती है, लोग भूमिकाएँ बदलते हैं, ग्रिड नहीं। इसे उस दस्तावेज़ के साथ जोड़ें जिसका वह वर्णन करती है, और जब उस दस्तावेज़ की समीक्षा हो तब इसकी भी करें। अगर समीक्षा कुछ भी शुरू नहीं कराता, तो समीक्षा कभी नहीं होगी।
कब कुछ और इस्तेमाल करें
RACI चलते रहने वाले काम का वर्णन करती है: कौन क्या करता है, बहुत सारे कार्यों में, समय के साथ। एक बार लिए जाने वाले एक फ़ैसले के लिए यह ठीक नहीं बैठती। उसके लिए खास तौर पर बने विकल्प हैं: DACI (Driver, Approver, Contributor, Informed), जिसे Atlassian अपने Team Playbook में एक प्ले के रूप में प्रकाशित करता है, और RAPID®, जिसे Bain and Company ने विकसित किया और जो 2006 के Harvard Business Review लेख "Who Has the D?" में पॉल रॉजर्स और मार्सिया ब्लेंको ने रखा, यह फ़ैसला लेने वाले को अमल करने वालों से अलग करता है और वीटो के अधिकार को स्पष्ट बनाता है।
दोनों बिल्डर में मोड के रूप में उपलब्ध हैं, और चुनने से पहले अंतर समझ लेना ठीक रहता है: RACI, DACI या RAPID, आपकी टीम को असल में किसकी ज़रूरत है।
इसे वहाँ निर्यात करें जहाँ लोग पढ़ेंगे
मैट्रिक्स तभी काम करती है जब वह वहाँ रहे जहाँ काम रहता है। बिल्डर Excel और Google Sheets, Word, PowerPoint (तस्वीर नहीं, संपादन योग्य तालिका के रूप में), PDF, CSV, Notion के लिए Markdown, और क्लिपबोर्ड HTML में निर्यात करता है, जो OneNote या Google Docs में तालिका सही-सलामत चिपकता है।
व्यावहारिक सलाह: इसे उसी दस्तावेज़ में रखें जिसे यह नियंत्रित करती है (प्रोजेक्ट प्लान, रनबुक, चार्टर) अपनी अलग फ़ाइल में नहीं। अपनी अलग फ़ाइल में पड़ी मैट्रिक्स वह मैट्रिक्स है जिसे कोई नहीं खोलता।
स्रोत
- Stakeholder management and the RACI matrix, Project Management Institute
- DACI: a framework for group decisions, Atlassian Team Playbook
- Who Has the D? How Clear Decision Roles Enhance Organizational Performance, Harvard Business Review, रॉजर्स और ब्लेंको, 2006