गैंट चार्ट बेसलाइन: योजना की तुलना वास्तविकता से करें

गैंट चार्ट बेसलाइन प्रोजेक्ट शेड्यूल का सुरक्षित रखा गया संदर्भ संस्करण है, जिसे मौजूदा योजना या वास्तविक प्रगति के साथ दिखाया जाता है। इससे टीम मूल स्वीकृत समय की तुलना अब संभावित लग रही स्थिति और पहले हो चुकी घटनाओं से कर सकती है। बेसलाइन यह वादा नहीं कि अनिश्चितता खत्म हो गई है।

महत्वपूर्ण अंतर बेसलाइन, पूर्वानुमान और वास्तविक स्थिति के बीच है। बेसलाइन सहमत संदर्भ को सुरक्षित रखती है। टीम के सीखने पर पूर्वानुमान बदलता है। वास्तविक तारीखें पूरी हुई घटनाएं दर्ज करती हैं। यदि इन क्षेत्रों को एक साथ बदल दिया जाए, तो चार्ट शेड्यूल में हुए बदलाव की व्याख्या नहीं कर सकता।

यह मार्गदर्शिका व्याख्या और टीम समीक्षा पर है, किसी एक शेड्यूलिंग ऐप के निर्देशों पर नहीं। NextRetro रेट्रोस्पेक्टिव टूल है, गैंट शेड्यूलिंग इंजन नहीं; आधिकारिक शेड्यूल अपने प्रोजेक्ट-योजना सिस्टम में रखें।

शेड्यूल बेसलाइन में क्या होना चाहिए?

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

U.S. GAO Schedule Assessment Guide बेसलाइन बनाए रखने और वास्तविक प्रगति के अनुसार शेड्यूल अपडेट करने को अलग-अलग शेड्यूलिंग अभ्यास मानता है। नीचे की समीक्षा-विधि इस अंतर को छोटी टीम की निर्णय बैठक पर लागू करती है; यह विशेषज्ञ शेड्यूल आश्वासन का विकल्प नहीं है।

बेसलाइन की स्वीकृति-तिथि, दायरा, संस्करण और धारणाएं दर्ज करें। बताएं कि बदलाव कौन मंजूर कर सकता है। अनुबंध या नियमों से जुड़ी प्रतिबद्धताओं वाले प्रोजेक्ट को यहां दिए हल्के उदाहरणों से अधिक नियंत्रण की जरूरत हो सकती है।

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

बेसलाइन, पूर्वानुमान और वास्तविक तारीखें साथ पढ़ें

इस काल्पनिक प्रोजेक्ट अंश पर विचार करें। समझाने के लिए तारीखें और गतिविधियां गढ़ी गई हैं।

मद	बेसलाइन समाप्ति	मौजूदा पूर्वानुमान	वास्तविक समाप्ति	समीक्षा प्रश्न
डेटा मैपिंग पर सहमति	4 नव॰	—	6 नव॰	सहमति में अधिक समय क्यों लगा?
माइग्रेशन रिहर्सल पूरी	11 नव॰	16 नव॰	—	कौन-सी पूर्ववर्ती गतिविधि या क्षमता-बाधा बदली?
संचालन स्वीकृति	18 नव॰	23 नव॰	—	क्या प्राप्तकर्ता टीम संशोधित तैयारी-अवधि स्वीकार करती है?

पूरी हुई गतिविधि के लिए वास्तविक तारीख चाहिए, लगातार खिसकता पूर्वानुमान नहीं। अधूरी गतिविधि के लिए यथार्थवादी पूर्वानुमान चाहिए, न कि पुराने बेसलाइन को मौजूदा-योजना क्षेत्र में नकल करना क्योंकि कोई देरी बताना नहीं चाहता।

बीत चुके समय और कार्य समय में भी अंतर रखें। पांच कैलेंडर दिन और पांच कार्य-दिन अलग तुलना हैं। अंतर की गणना से पहले नियम बताएं, खासकर जब टीमें अलग छुट्टियां या संचालन कैलेंडर अपनाती हों।

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

30 मिनट की अंतर-समीक्षा

मौजूदा शेड्यूल, उसकी बेसलाइन और उन मदों की छोटी सूची साथ लाएं जिनका बदलाव निर्णय बदल सकता है। केवल मौजूद होने के कारण हर बार को देखने से बचें।

पहले पांच मिनट: संदर्भ संस्करण और स्थिति की तारीख पर सहमत हों। पुष्टि करें कि वास्तविक प्रगति अद्यतन है। चार्ट समझने से पहले ज्ञात डेटा-अंतर दर्ज करें।

अगले दस मिनट: काम की एक महत्वपूर्ण श्रृंखला देखें। पूछें कि दायरे, क्रम, उपलब्धता, प्रयास या बाहरी प्रतिबद्धता में क्या बदला। प्रमाण वाले घटनाक्रम और संभावित व्याख्याओं को अलग रखें।

अगले दस मिनट: प्रतिक्रियाओं की तुलना करें। क्या टीम अनावश्यक प्रतीक्षा हटा सकती है, क्रम सुरक्षित रूप से बदल सकती है, निर्णय हासिल कर सकती है या स्वीकृत दायरा घटा सकती है? तेजी लाने से कौन-सी लागत या जोखिम होगा? अधिक लोगों या ओवरटाइम के परिणाम होते हैं; वे अपने आप सुधार नहीं हैं।

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

ये समय सुविधा के लिए सुझाए गए हैं। जटिल कार्यक्रम को छोटी बैठक के बजाय गहरी शेड्यूल-जोखिम समीक्षा चाहिए हो सकती है।

उदाहरण: देर हुई गतिविधि ही पूरा कारण नहीं थी

एक काल्पनिक सॉफ्टवेयर माइग्रेशन में रिहर्सल बेसलाइन से चार कार्य-दिन बाद पूरी होती है। पहली व्याख्या है, “परीक्षण में ज्यादा समय लगा।” टीम समय वापस पाने के लिए अगली परीक्षण अवधि घटाने वाली है।

समीक्षा प्रमाण के आधार पर पीछे जाती है। परीक्षण चलाने में नियोजित समय ही लगा। काम देर से शुरू हुआ क्योंकि संचालन प्राप्तकर्ता टीम ने उत्पादन-जैसे परीक्षण डेटा को मंजूरी नहीं दी थी और नामित अनुमोदक उपलब्ध नहीं था।

परीक्षण अवधि घटाने से कारण नहीं सुलझेगा और तैयारी के प्रमाण कमजोर हो सकते हैं। इसके बजाय टीम अगली रिहर्सल के लिए पहले स्वीकृति-जांच पर सहमत होती है और मौजूदा अनुमोदन नियमों के तहत वैकल्पिक निर्णय-स्वामी की पुष्टि करती है।

टीम पूर्वानुमान अपडेट करती है और मूल बेसलाइन को दिखाती रहती है। रेट्रोस्पेक्टिव में दोबारा उपयोगी सीख दर्ज होती है: निर्भरता की योजना बनाते समय अनुमोदनकर्ता की उपलब्धता पहचानें, यह न मानें कि नामित व्यक्ति हमेशा उपलब्ध होगा।

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

टीम को बेसलाइन कब बदलनी चाहिए?

रीबेसलाइन करने से स्वीकृत तुलना-संदर्भ बदलता है। अधिकृत दायरा-परिवर्तन या डिलीवरी प्रतिबद्धता के बड़े पुनर्निर्धारण के बाद यह उचित हो सकता है। प्रतिकूल अंतर पर यह नियमित प्रतिक्रिया नहीं होनी चाहिए।

मूल बेसलाइन संग्रहित रखें, नए स्वीकृत दायरे और तारीखों की पहचान करें और बताएं कि आगे की रिपोर्ट कौन-सी तुलना इस्तेमाल करेंगी। यदि काम का केवल एक पैकेज बदला है, तो असंबंधित इतिहास चुपचाप न बदलें।

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

कार्यकारी पूर्वानुमान को नई स्वीकृत बेसलाइन न समझें। औपचारिक रूप से हर योजना-धारणा पर फिर से बातचीत होने की प्रतीक्षा किए बिना पूर्वानुमान को और यथार्थवादी बनाया जा सकता है और बनाना चाहिए।

शेड्यूल के प्रमाण को उपयोगी रेट्रोस्पेक्टिव में बदलें

अगली रेट्रोस्पेक्टिव में एक बार-बार दिखने वाला पैटर्न चुनें: अनुमोदन की प्रतीक्षा, एकीकरण का कम अनुमान, क्षमता की कमी या आशावादी हस्तांतरण। हर देर हुई गतिविधि के लिए किसी एक व्यक्ति को दोष देने में बैठक न बदलें।

पूछें कि उपलब्ध जानकारी से टीम कौन-सा निर्णय पहले ले सकती थी। फिर एक प्रयोग तय करें—जैसे मील के पत्थर का वादा करने से पहले समीक्षक की उपलब्धता की पुष्टि करना—और जांचें कि क्या बदलाव उसी प्रतीक्षा-पैटर्न को घटाता है।

प्रयोग दर्ज करने के लिए रेट्रोस्पेक्टिव कार्रवाई-मद मार्गदर्शिका और चर्चा तैयार करने के लिए सुविधादाता चेकलिस्ट इस्तेमाल करें। शेड्यूल प्रमाण देता है; रेट्रोस्पेक्टिव सोच-समझकर सीखने का चक्र देती है।

अक्सर पूछे जाने वाले प्रश्न

क्या बेसलाइन और समय-सीमा एक ही हैं?

नहीं। बेसलाइन शेड्यूल का संदर्भ संस्करण है। समय-सीमा एक समय-बाधा या प्रतिबद्धता है। शेड्यूल में कई समय-सीमाएं हो सकती हैं और बेसलाइन यह सुरक्षित रख सकती है कि टीम ने मूल रूप से उन्हें पूरा करने की योजना कैसे बनाई थी।

क्या गतिविधि देर होने पर हमें बेसलाइन अपडेट करनी चाहिए?

वास्तविकता दिखाने के लिए मौजूदा पूर्वानुमान अपडेट करें। स्वीकृत बेसलाइन केवल प्रोजेक्ट के सहमत शासन के तहत बदलें, और पिछला संस्करण तथा कारण सुरक्षित रखें। नियमित रूप से पुराना डेटा बदलना मूल प्रदर्शन समझना कठिन करता है।

क्या गैंट चार्ट साबित कर सकता है कि प्रोजेक्ट देर से क्यों हुआ?

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