बेसलाइन प्रोग्राम बनाएं

कीमत लगे BOQ और स्कोप को देखें और काम को उस स्तर की गतिविधि सूची में बदलें जिसे आप वाकई मैनेज करेंगे: एक मंजिल की ब्लॉकवर्क, एक ड्रेनेज रन, किसी विंग का फर्स्ट फिक्स, न कि हर BOQ आइटम की एक लाइन और न ही एक सिंगल सारांश बार।

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

हर गतिविधि को मात्राओं और आप जो क्रू चलाने की योजना बना रहे हैं उससे एक वास्तविक अवधि दें, फिर गतिविधियों को उस क्रम में लिंक करें जिसमें उन्हें होना चाहिए, ताकि एक को खिसकाने से उस पर निर्भर वाली भी खिसकें।

क्यों: बिना लिंक की अवधियां आपको इच्छा सूची देती हैं, प्रोग्राम नहीं। गतिविधियों के बीच का लॉजिक ही शेड्यूल को यह दिखाने देता है कि एक देरी वाकई नीचे के काम को कितना नुकसान पहुंचाती है।

महत्वपूर्ण तय तारीखें चिह्नित करें, साइट पर शुरुआत, सेक्शनल हैंडओवर, प्रैक्टिकल कंप्लीशन, और कार्य कैलेंडर तय करें जो छुट्टियों, शिफ्ट पैटर्न और उन मौसम खिड़कियों का सम्मान करें जिन्हें ट्रेड्स हरा नहीं सकते।

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

फिनिश डेट तय करने वाली गतिविधियों की श्रृंखला का पालन करें और इसे सामान्य समझ के मुकाबले पढ़ें। गायब लिंक, नेगेटिव फ्लोट, और ऐसी गतिविधियां देखें जिनमें कोई ढील नहीं दिखती जबकि साइट पर सब जानते हैं कि कुछ ढील है।

क्यों: जो क्रिटिकल पथ यह नहीं दर्शाता कि काम वाकई कैसे चलेगा, वह चीजें खिसकते ही आपको गलत गतिविधियों के पीछे भगा देगा। बेसलाइन करने से पहले इसे समझदारी से जांचना साइट पर पता लगाने से सस्ता है।

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

क्यों: बिना मापने की रेखा के प्रगति का कोई अर्थ नहीं है। बेसलाइनिंग वह पल है जब प्रोग्राम ड्राफ्ट होना बंद कर देता है और वह मापदंड बन जाता है जिससे पूरे काम को आंका जाता है।