जटिल सॉफ्टवेयर के बिना एक साथ कई प्रोजेक्ट्स को कैसे ट्रैक करें

उन निर्णयों से शुरुआत करें जो आपको लेने हैं

कोई फॉर्मेट चुनने से पहले, वे प्रश्न लिख लें जिनका उत्तर आप ओवरव्यू से चाहते हैं। उदाहरण के लिए: कौन से प्रोजेक्ट अपने अगले माइलस्टोन के लिए सही रास्ते पर हैं? इस सप्ताह किन पर ध्यान देने की आवश्यकता है? क्या कोई व्यक्ति किसी अन्य प्रोजेक्ट की प्रतीक्षा कर रहा है? मुझे किस चीज़ पर निर्णय लेने की आवश्यकता है?

ये प्रश्न ओवरव्यू को केंद्रित रखते हैं। यदि आप हर कार्य, नोट और बातचीत को जोड़ते हैं, तो क्रॉस-प्रोजेक्ट की मुख्य तस्वीर छिप जाती है। विस्तृत टास्क लिस्ट वहीं रखें जहां काम पहले से हो रहा है; विभिन्न प्रोजेक्ट्स के बीच समन्वय में मदद करने वाले कुछ महत्वपूर्ण तथ्यों को दिखाने के लिए ओवरव्यू का उपयोग करें।

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

एक पन्ने का प्रोजेक्ट ओवरव्यू तैयार करें

प्रत्येक प्रोजेक्ट के लिए एक पंक्ति (row) या कार्ड बनाएं। शुरुआती बिंदु के रूप में निम्नलिखित फ़ील्ड्स का उपयोग करें:

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

एक माइलस्टोन ऐसा होना चाहिए जिसे कोई अन्य व्यक्ति पूर्ण के रूप में पहचान सके, जैसे कि "समीक्षकों के साथ ड्राफ्ट साझा किया गया" या "इवेंट स्थल की पुष्टि की गई।" "प्रगति करना" कोई चेकपॉइंट नहीं है। ऐसे माइलस्टोन चुनें जो प्रोजेक्ट के अगले निर्णय या डिलीवरी के लिए मायने रखते हों; छोटे-मोटे कार्यों की लंबी सूची ओवरव्यू को पढ़ना कठिन बना देती है।

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

ऐसे स्टेटस लेबल का उपयोग करें जिन्हें लोग लगातार लागू कर सकें

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

ट्रैक पर (On track): अगला माइलस्टोन अपनी लक्षित तिथि तक पूरा होने की उम्मीद है, और कोई भी अनसुलझा मुद्दा वर्तमान में इसके लिए खतरा नहीं है।

निगरानी में (Watch): एक विशिष्ट चिंता है जो माइलस्टोन को प्रभावित कर सकती है, लेकिन एक अगला कदम निर्धारित कर लिया गया है।

अवरुद्ध (Blocked): जब तक कोई निर्दिष्ट समस्या, निर्णय या निर्भरता हल नहीं हो जाती, तब तक प्रगति जारी नहीं रह सकती।

ये लेबल काम करने की सुझाई गई परंपराएं हैं, कोई आधिकारिक मानक नहीं। उन लोगों के साथ इन पर सहमति बनाएं जो ओवरव्यू को अपडेट करेंगे या इसका उपयोग करेंगे। यदि किसी प्रोजेक्ट को "निगरानी में" (watch) चिह्नित किया गया है, तो उसका कारण और वह कदम शामिल करें जो इसे "ट्रैक पर" वापस लाएगा। यदि यह "अवरुद्ध" (blocked) है, तो आवश्यक मदद और फॉलो-अप करने वाले व्यक्ति का नाम बताएं। बिना स्पष्टीकरण के एक लेबल गंभीर समस्या को भी एक छोटी अनिश्चितता जैसा दिखा सकता है।

बहुत अलग-अलग तरह के प्रोजेक्ट्स में प्रतिशत पूर्णता (percentage complete) को मुख्य संकेत मानने से बचें। एक डिज़ाइन, एक इवेंट और एक शोध कार्य के लिए "80% पूर्ण" का अर्थ काफी भिन्न हो सकता है। एक तारीख वाला चेकपॉइंट और साथ में दिखने वाला प्रमाण पाठकों को समझने के लिए कुछ अधिक ठोस आधार देता है। यह तुलना का एक व्यावहारिक विकल्प है, न कि यह दावा कि प्रतिशत कभी उपयोगी नहीं होते; वे किसी प्रोजेक्ट के भीतर तब मदद कर सकते हैं जब काम को लगातार मापा जा सके।

एक हल्का-फुल्का अपडेट रूटीन निर्धारित करें

एक ओवरव्यू केवल तभी काम करता है जब लोग यह जान सकें कि उसकी जानकारी अद्यतित (current) है या नहीं। एक ऐसा अपडेट रिदम चुनें जो प्रोजेक्ट्स के बदलने की गति से मेल खाता हो। कई छोटे समूहों के लिए साप्ताहिक समीक्षा एक उचित शुरुआती बिंदु है, लेकिन धीमी गति से चलने वाले काम के लिए कम बार अपडेट की आवश्यकता हो सकती है, जबकि तेजी से बदलते प्रोजेक्ट को अधिक बार अपडेट की आवश्यकता हो सकती है। एटलासियन भी अपनी स्टेटस रिपोर्ट गाइड में प्रोजेक्ट की जटिलता और हितधारकों की जरूरतों के अनुसार स्टेटस-रिपोर्ट की आवृत्ति चुनने की सलाह देता है।

प्रत्येक अपडेट पर, प्रत्येक प्रोजेक्ट ओनर से चार बातों की जांच करने के लिए कहें:

1. क्या अगला माइलस्टोन, लक्षित तिथि या प्रभारी बदला?

2. पिछली जांच के बाद से कौन सा ठोस काम पूरा हुआ?

3. क्या कोई बाधा, नई निर्भरता, या निर्णय की आवश्यकता है?

4. अगला कदम क्या है, और इसकी दोबारा जांच कब की जाएगी?

अपडेट की तारीख दर्ज करें। यदि किसी पंक्ति को हाल ही में नहीं जांचा गया है, तो उसे "अपडेट नहीं किया गया" चिह्नित करें या स्थिति को वर्तमान मानने से पहले उसके ओनर से पूछें। यह पुराने "ट्रैक पर" लेबल को नया मूल्यांकन दिखने से रोकता है। जब कोई तारीख बदलती है, तो उस कारण या निर्णय को एक छोटे नोट में रखें जिसने इसे बदला; अन्यथा, बार-बार तारीख बदलना समझना कठिन हो जाता है।

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

प्रोजेक्ट्स के बीच की निर्भरताओं (dependencies) को पहचानें

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

फिर साझा किए गए लोगों और तारीखों के लिए ओवरव्यू को स्कैन करें। यदि एक ही व्यक्ति के पास एक ही समय में कई अगले कदम पूरे करने की ज़िम्मेदारी है, या एक प्रोजेक्ट का विलंबित निर्णय दूसरे प्रोजेक्ट के माइलस्टोन को आगे खिसका देगा, तो टकराव को स्पष्ट करें और प्राथमिकता या संशोधित योजना पर सहमत हों। यही वह जगह है जहां अलग-अलग प्रोजेक्ट अपडेट की तुलना में एक अकेला ओवरव्यू अधिक उपयोगी होता है: यह आपको एक ही स्थान पर प्रतिबद्धताओं और निर्भरताओं की तुलना करने देता है। प्रोजेक्ट मैनेजमेंट इंस्टीट्यूट (PMI) की पोर्टफोलियो प्रक्रिया भी अपने क्रॉस-प्रोजेक्ट इन्वेंट्री को हर कार्य से भरने के बजाय उच्च-स्तरीय माइलस्टोन, स्थिति और प्रोजेक्ट की आपसी निर्भरताओं को रिकॉर्ड करती है; यहाँ दिया गया संक्षिप्त संस्करण एक छोटे समूह के लिए संपादकीय अनुकूलन है।

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

सबसे सरल फॉर्मेट चुनें जो उपयोगी बना रहे

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

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

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

एक व्यावहारिक उदाहरण

मान लीजिए कि एक समन्वयक तीन प्रोजेक्ट्स को फॉलो कर रहा है: एक सामुदायिक कार्यक्रम (कम्युनिटी इवेंट), एक वेबसाइट रीफ्रेश, और एक मासिक न्यूज़लेटर। उनका ओवरव्यू कुछ ऐसा दिख सकता है:

उदाहरण: कम्युनिटी इवेंट 'निगरानी में' (Watch) है क्योंकि दो संभावित स्थान अभी भी बुक नहीं हुए हैं; इसका ओनर 12 मई के स्थल माइलस्टोन के लिए 8 मई तक उपलब्धता की तुलना करेगा। वेबसाइट रीफ्रेश 'ट्रैक पर' (On track) है क्योंकि ड्राफ्ट पेज समीक्षकों तक पहुंच चुके हैं; 15 मई की समीक्षा के लिए 10 मई तक टिप्पणियाँ अपेक्षित हैं। मासिक न्यूज़लेटर 'अवरुद्ध' (Blocked) है क्योंकि अंतिम कॉपी के लिए पुष्टि किए गए इवेंट विवरण की आवश्यकता है; इसका ओनर 9 मई के कॉपी माइलस्टोन से पहले 7 मई तक इसके लिए अनुरोध करेगा।

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

जब इस दृष्टिकोण को अधिक संरचना की आवश्यकता हो

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

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

इस विषय को आगे पढ़ें