Metlivi ब्लॉग

जब काम की डेडलाइन पहले आ जाए: अपने सप्ताह की फिर से योजना कैसे बनाएं और सहकर्मियों को सूचित कैसे करें

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

30 सितंबर 20266 min readपढ़ना, कला और संस्कृतिलेखक: Metlivi Editorial Team
खंड 1

1. नई डेडलाइन और क्या डिलीवर किया जाना चाहिए, इसकी पुष्टि करें

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

यह कदम इसलिए मायने रखता है क्योंकि तारीख के बदलाव को काम के दायरे (स्कोप) में बदलाव समझने की गलती हो सकती है। केवल एक छोटा शेड्यूल आपको यह नहीं बताता कि मांगे गए काम के किन हिस्सों को कम किया जा सकता है या टाला जा सकता है। प्रोजेक्ट प्लानिंग मार्गदर्शन काम को शेड्यूल करने से पहले स्कोप, डिलीवरेबल्स, टास्क सीक्वेंस और अनुमानों को अलग-अलग चीजों के रूप में स्पष्ट करने में अंतर करता है। यदि अनुरोधकर्ता ने मांगे गए आउटपुट में बदलाव नहीं किया है, तो चुपचाप यह न मान लें कि कम पूर्ण संस्करण स्वीकार कर लिया जाएगा; पूछें कि यदि पूरा काम अब संभव नहीं है तो वे क्या समझौता (ट्रेड-ऑफ) चाहते हैं। PMI, “The critical steps to managing small projects”

खंड 2

2. उस काम को ट्रैक करें जो डिलीवरेबल पर निर्भर करता है

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

अनिवार्य हैंडऑफ़ को पसंदीदा अनुक्रम (सीक्वेंसिंग) से अलग करें। कुछ काम वास्तव में तब तक शुरू नहीं हो सकते जब तक कि कोई पिछला काम पूरा न हो जाए; अन्य हिस्से किसी सहमत ड्राफ्ट या आंशिक इनपुट का उपयोग करके समानांतर रूप से आगे बढ़ सकते हैं। PMI का शेड्यूलिंग मार्गदर्शन यह जांचने का सुझाव देता है कि सूचीबद्ध निर्भरताएं अनिवार्य हैं या वैकल्पिक, और वैकल्पिक अनुक्रम पर विचार करने का सुझाव देता है जहाँ यह दर्शाता हो कि काम वास्तव में कैसे आगे बढ़ सकता है। केवल कैलेंडर को व्यावहारिक दिखाने के लिए किसी डिपेंडेंसी को न हटाएं: आउटपुट पर निर्भर लोगों के साथ पुष्टि करें कि क्या पहले या आंशिक हैंडऑफ़ का उपयोग किया जा सकता है। PMI, “Four Ways Project Schedules Are Limited and What To Do About It”

खंड 3

3. उपलब्ध समय और जिम्मेदार व्यक्तियों के आधार पर योजना को फिर से बनाएं

अब से नई डेडलाइन के बीच के कार्य समय की गणना करें, फिर इसकी तुलना बचे हुए काम से करें। ऐसे यथार्थवादी अनुमानों का उपयोग करें जो हैंडऑफ़ और समीक्षा को ध्यान में रखते हों; प्रत्येक शेष घंटे को निर्बाध प्रोजेक्ट समय न मानें। कार्यों को निर्भरता क्रम में रखें और उन मदों की पहचान करें जो वास्तव में एक ही समय में आगे बढ़ सकते हैं। डिलीवरेबल्स को छोटे कार्यों में विभाजित करने से प्रयास का अनुमान लगाना आसान हो जाता है, जबकि निर्भर काम की सबसे लंबी श्रृंखला जल्द से जल्द व्यावहारिक समाप्ति को सीमित करती है। PMI, “The critical steps to managing small projects”

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

एक संक्षिप्त कार्य तालिका निर्णयों को तुरंत सामने ला सकती है:

कार्य मद: ड्राफ्ट को अंतिम रूप देना; जिम्मेदार व्यक्ति: आप; पहले क्या चाहिए: पुष्ट संक्षिप्त विवरण (ब्रीफ); संशोधित लक्ष्य: मंगलवार दोपहर; आवश्यक निर्णय या इनपुट: कोई नहीं

कार्य मद: मुख्य आंकड़ों की समीक्षा करना; जिम्मेदार व्यक्ति: प्रिया; पहले क्या चाहिए: ड्राफ्ट आंकड़े; संशोधित लक्ष्य: मंगलवार दोपहर 3 बजे; आवश्यक निर्णय या इनपुट: क्या आंशिक ड्राफ्ट की समीक्षा कर सकते हैं?

कार्य मद: अंतिम संस्करण को स्वीकृत करना; जिम्मेदार व्यक्ति: जॉर्डन; पहले क्या चाहिए: समीक्षित ड्राफ्ट; संशोधित लक्ष्य: बुधवार सुबह 10 बजे; आवश्यक निर्णय या इनपुट: उपलब्धता की पुष्टि करें

कार्य मद: टीम हैंडऑफ़ तैयार करना; जिम्मेदार व्यक्ति: ली; पहले क्या चाहिए: स्वीकृत संस्करण; संशोधित लक्ष्य: बुधवार दोपहर; आवश्यक निर्णय या इनपुट: नए डिलीवरी समय की पुष्टि करें

ये उदाहरण मात्र प्रविष्टियां हैं, कोई अनुशंसित अवधि या मापा गया अनुमान नहीं। इन्हें अपने काम के वास्तविक कार्यों, नामों, प्रयास और समय से बदलें। एक वर्तमान शेड्यूल को संदर्भ बिंदु के रूप में रखें; यदि आप एक साझा टाइमलाइन का उपयोग करते हैं, तो कार्य के जिम्मेदार व्यक्तियों, तारीखों और निर्भरताओं को एक साथ अपडेट करें। एक शेड्यूल दृश्य टकरावों (कॉन्फ्लिक्ट्स) को दृश्यमान बना सकता है, लेकिन जिम्मेदार लोगों को अभी भी काम और समय की पुष्टि करने की आवश्यकता है। Asana Help Center, “Managing tasks and dependencies with timeline”

खंड 4

4. प्रभावित सहकर्मियों को स्पष्ट मांग के साथ सूचित करें

उन लोगों को तुरंत अपडेट भेजें जिनके कार्य, निर्णय या योजनाएं प्रभावित हुई हैं। इसमें पुष्टि की गई नई डेडलाइन, क्या बदला है, वर्तमान प्रस्तावित अनुक्रम, प्रत्येक अगले कदम का मालिक कौन है, और प्रत्येक व्यक्ति से आपको क्या विशिष्ट प्रतिक्रिया चाहिए, शामिल करें। योगदानकर्ताओं को विस्तृत कार्य परिवर्तनों की आवश्यकता हो सकती है; जो लोग केवल अंतिम परिणाम पर निर्भर करते हैं उन्हें नए हैंडऑफ़ समय और उनके काम पर इसके प्रभाव की आवश्यकता हो सकती है। Atlassian का संचार मार्गदर्शन यह पहचानने की सलाह देता है कि किसे किस जानकारी की आवश्यकता है, किस चैनल के माध्यम से और कब, और संचार के लिए एक जिम्मेदार व्यक्ति नियुक्त करना चाहिए। Atlassian, “Stakeholder Project Communication Plan”

उदाहरण के लिए: “डिलीवरी की डेडलाइन शुक्रवार से बदलकर बुधवार दोपहर कर दी गई है; मैंने पुष्टि की है कि मांगा गया स्कोप अपरिवर्तित है। मेरा प्रस्ताव है कि मंगलवार दोपहर तक ड्राफ्ट पूरा कर लिया जाए, दोपहर 3 बजे तक समीक्षा के लिए प्रिया को आंकड़े भेज दिए जाएं, और बुधवार सुबह 10 बजे तक जॉर्डन की मंजूरी ले ली जाए। ली, इससे आपका हैंडऑफ़ बुधवार दोपहर को चला जाता है। प्रिया और जॉर्डन, क्या आप आज उन समीक्षा विंडो की पुष्टि कर सकते हैं? यदि वे उपयुक्त नहीं हैं, तो कृपया ऐसा समय सुझाएं जब आप मिल सकें ताकि हम अनुरोधकर्ता के साथ एक छोटी पहली डिलीवरी या बाद के हैंडऑफ़ पर सहमति बना सकें।”

तत्काल सूचना के लिए टीम के स्थापित चैनल का उपयोग करें, फिर साझा कार्य सूची, दस्तावेज़, या प्रोजेक्ट टाइमलाइन को अपडेट करें ताकि सहमत योजना को खोजना आसान हो। केवल एक संदेश कार्य रिकॉर्ड में पुरानी तारीखें छोड़ सकता है; संदर्भ के बिना बदला हुआ शेड्यूल सहकर्मियों को भ्रमित कर सकता है कि तारीखें क्यों बदलीं। अपडेट की गई योजना का लिंक दें या उसका संकेत दें, और प्राप्तकर्ताओं से टकरावों या छूटी हुई निर्भरताओं को इंगित करने के लिए कहें। Asana, “How to manage and change project plans with Asana Timeline”

खंड 5

5. निर्णयों की पुष्टि करें, प्रभावित काम को संशोधित करें, और दोबारा जांचें

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

जब कोई डिपेंडेंसी हैंडऑफ़ की जाए और अगले महत्वपूर्ण पड़ाव (माइलस्टोन) के बाद फॉलो अप करें। एक संक्षिप्त स्टेटस नोट यह बता सकता है कि क्या पूरा हो गया है, क्या बाकी है, अगली कार्रवाई का मालिक कौन है, और क्या सहमत स्कोप के तहत डेडलाइन अभी भी प्राप्त करने योग्य है। जब हैंडऑफ़ का समय बदलता है, तो आगे के सहकर्मियों को सूचित करें, भले ही वे पहली पुनर्निर्मित योजना (रीप्लानिंग) की चर्चा में शामिल न रहे हों; डिपेंडेंसी मार्गदर्शन यह मानने के विरुद्ध चेतावनी देता है कि हर कोई जानता है कि संबंधित काम कब शुरू हो सकता है। Atlassian, “Project dependencies”

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

संबंधित लेख

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