इंजीनियरिंग टीमों के लिए प्रोजेक्ट किकऑफ़ मीटिंग एजेंडा
वह सवाल जिसे किकऑफ़ मीटिंग्स छोड़ देती हैं
एक अच्छी तरह चली प्रोजेक्ट किकऑफ़ टीम को इस पर अलाइन छोड़ती है कि क्या बनाना है, कौन क्या करता है, और चीज़ें कब तक चाहिए। वह अलाइनमेंट आमतौर पर करीब तीन हफ्ते टिकता है। फिर स्कोप रेंगता है, कोई स्टेकहोल्डर किसी मूल धारणा पर अपना मन बदल देता है, कोई डिपेंडेंसी फिसल जाती है, और टीम को पता चलता है कि उन्होंने कभी इस पर सहमति ही नहीं बनाई थी कि जब दो वाजिब लोग असहमत हों तो फैसला कौन करता है।
जिस सवाल को अधिकांश किकऑफ़ एजेंडा छोड़ देते हैं वह है: जब कुछ गलत हो जाए तो यह टीम फैसले कैसे करेगी? प्रोजेक्ट प्लान नहीं — फैसला-लेने का ढाँचा। जब किसी फ़ीचर को काटना पड़े तो स्कोप का जिम्मा किसके पास है? जब कोई तकनीकी कंस्ट्रेंट किसी प्रोडक्ट आवश्यकता को अमान्य कर दे तो टीम क्या करती है? जब दो विभाग अलग-अलग चीज़ें चाहें तो किस स्टेकहोल्डर की अंतिम राय चलेगी?
इन सवालों का जवाब किकऑफ़ में देना आसान है क्योंकि तब कुछ भी दाँव पर नहीं होता। आधे-प्रोजेक्ट में जब हर किसी की एक राय हो, तब इनका जवाब देना कहीं ज्यादा कठिन होता है। नीचे दिया गया टेम्पलेट कठिन हिस्सा शुरू होने से पहले इनके लिए समय सुरक्षित रखता है।
एजेंडा (इसे कॉपी-पेस्ट करें)
अवधि: प्रोजेक्ट की जटिलता के आधार पर 60–90 मिनट
फॉर्मैट: संचालित; सभी मुख्य स्टेकहोल्डर और योगदानकर्ता मौजूद, या शुरू करने से पहले असिंक तरीके से समीक्षित
सेक्शन 1 — प्रोजेक्ट का लक्ष्य और स्कोप (20 मिनट)
- लक्ष्य को एक वाक्य में बताएँ: सफलता कैसी दिखती है, हो सके तो मापने योग्य
- इन-स्कोप: प्रोजेक्ट क्या डिलीवर करेगा, विशिष्ट रूप से नामित
- आउट-ऑफ-स्कोप: यह प्रोजेक्ट स्पष्ट रूप से क्या नहीं करेगा — कम से कम तीन चीज़ें सूचीबद्ध करें
- सफलता के मापदंड: टीम को कैसे पता चलेगा कि प्रोजेक्ट पूरा हो गया?
- EM या PM इस सेक्शन का जिम्मा लेता है; अगर बताया गया स्कोप व्यवहार्यता से मेल नहीं खाता तो इंजीनियर आपत्ति उठाते हैं
सेक्शन 2 — भूमिकाएँ और जिम्मेदारी (15 मिनट)
- हर वर्कस्ट्रीम के लिए एक जिम्मेदार का नाम लें — टीम नहीं, एक व्यक्ति
- इन पर अंतिम फैसला कौन करता है: प्रोडक्ट स्कोप, तकनीकी आर्किटेक्चर, बाहरी संवाद?
- हर बड़े फैसले-प्रकार पर कौन सूचित है बनाम परामर्शित बनाम फैसला-लेने वाला?
- उस प्रोजेक्ट लीड का नाम लें जो जवाबदेह है अगर और कुछ स्पष्ट न हो
सेक्शन 3 — कंस्ट्रेंट्स और रिस्क (15 मिनट)
- सख्त कंस्ट्रेंट्स: समय-सीमा, बजट, कंप्लायंस, दूसरी टीमों पर डिपेंडेंसीज़
- ज्ञात रिस्क: सबसे ऊपर की वे तीन चीज़ें कौन-सी हैं जो इस प्रोजेक्ट को पटरी से उतार सकती हैं?
- हर रिस्क के लिए: संभावना, प्रभाव, और शमन का जिम्मेदार
- किस चीज़ से प्रोजेक्ट रद्द या काफी हद तक घटा दिया जाएगा? अभी इसका नाम लें
सेक्शन 4 — संवाद योजना (10 मिनट)
- टीम कितनी बार सिंक करेगी? किस फॉर्मैट में?
- स्टेटस अपडेट किसे मिलता है, और कैसे? यह न मान लें कि सभी स्टेकहोल्डर एक ही चैनल चाहते हैं
- प्रोजेक्ट डॉक्युमेंटेशन कहाँ रहता है?
- अगर कुछ प्रोजेक्ट को ब्लॉक करे तो एस्केलेशन का रास्ता क्या है?
सेक्शन 5 — ओपन सवाल (15 मिनट)
- हर उस सवाल को सूचीबद्ध करें जिसका जवाब टीम आज नहीं दे सकती
- हर एक के लिए: एक जिम्मेदार और एक तारीख सौंपें जिससे जवाब चाहिए
- बिना तारीख और जिम्मेदार वाले सवाल आधे रास्ते पर भी खुले ही रहेंगे
सेक्शन 6 — अगले कदम (10 मिनट)
- असली काम शुरू करने के लिए अगले पाँच कारोबारी दिनों में जो तीन चीज़ें ज़रूर होनी चाहिए
- हर अगले कदम का एक ही जिम्मेदार हो
- पुष्टि करें कि किकऑफ़ रीकैप कैसे और किसे बाँटा जाएगा
लोकप्रिय किकऑफ़ टेम्पलेट्स कहाँ गलती करते हैं
अधिकांश किकऑफ़ टेम्पलेट्स प्रोजेक्ट प्लान को लेकर पूरी तरह विस्तृत होते हैं पर इस पर पतले कि जब प्लान न टिके तो क्या होता है। वे एक साफ़-सुथरा स्कोप दस्तावेज़ और एक RACI मैट्रिक्स तैयार करते हैं, जो उपयोगी है। पर वे इसका कोई साझा जवाब नहीं देते कि "जब डेटाबेस वेंडर आधे-प्रोजेक्ट में अपनी कीमत तिगुनी कर दे तो हम क्या करते हैं?" या "अगर हम 80% फ़ीचर पूरे होने पर सख्त समय-सीमा से टकरा जाएँ तो क्या कटता है?"
स्कोप-आउट का अभाव दूसरा लगातार दिखने वाला अंतराल है। क्या इन-स्कोप है, यह बताना सीधा है। क्या स्पष्ट रूप से बाहर है, यह बताना — प्रोजेक्ट जो तीन-चार विशिष्ट चीज़ें नहीं करेगा उन्हें सूचीबद्ध करना — स्टेकहोल्डर उम्मीदों के बारे में वही बातचीत करवाता है पर दूसरी दिशा से। जो स्टेकहोल्डर यह मानने वाले थे कि मोबाइल क्लाइंट शामिल है, उन्हें छठे हफ्ते के बजाय किकऑफ़ में ही पता चल जाता है।
तीसरा अंतराल ओपन सवाल सेक्शन है। टीमें किकऑफ़ में यह सामने नहीं लाना चाहतीं कि वे क्या नहीं जानतीं, क्योंकि यह तैयारी की कमी मानने जैसा लगता है। पर अनजाने जवाब आधे-प्रोजेक्ट के ब्लॉकर्स बन जाते हैं, और आधे-प्रोजेक्ट के ब्लॉकर्स महँगे होते हैं। आप जितनी जल्दी जान लेंगे कि सवाल मौजूद है, उतनी जल्दी कोई जवाब का जिम्मा ले सकता है।
एक बहु-महीने के प्रोजेक्ट में ये अंतराल कैसे ओवरहेड में संचित होते हैं, इसके लिए: मीटिंग टैक्स।
किकऑफ़ नोट्स को सही रखना क्यों सार्थक है
किकऑफ़ दस्तावेज़ किसी भी प्रोजेक्ट में सबसे ज्यादा बार संदर्भित की जाने वाली कलाकृति होता है। जब स्कोप विवादित होता है, जब कोई नया टीम सदस्य जुड़ता है, जब कोई स्टेकहोल्डर पूछता है "क्या हमने किकऑफ़ में X तय नहीं किया था?" — यही वह चीज़ है जिसे लोग जाँचते हैं। एक अच्छी तरह डॉक्युमेंट की गई किकऑफ़ एक ऐसा प्रोजेक्ट है जिसे संभालना आसान है।
Pavleur पूरी किकऑफ़ को अपने-आप कैप्चर करता है: बताए अनुसार स्कोप, सौंपे अनुसार भूमिकाएँ, नाम लिए अनुसार रिस्क, जिम्मेदारों सहित ओपन सवाल, जिम्मेदारों और तारीखों सहित अगले कदम। अगर किसी ने मीटिंग के बीच में प्रोजेक्ट ब्रीफ़, कोई डायग्राम, या कोई रिक्वायरमेंट्स दस्तावेज़ स्क्रीनशेयर किया, तो वह दृश्य चर्चा के साथ रिपोर्ट में शामिल होता है। सिर्फ-ऑडियो वाले टूल्स आपको बताते हैं कि किसने क्या कहा; वे उस आर्किटेक्चर डायग्राम को कैप्चर नहीं करते जो स्क्रीन पर था जब टेक लीड डिपेंडेंसी बता रहा था। नतीजतन बनी रिपोर्ट पहले दिन से ही प्रोजेक्ट के सत्य-के-स्रोत दस्तावेज़ के रूप में काम आती है। यह पारंपरिक मीटिंग कैप्चर टूल्स से कैसे तुलना करता है, इसके लिए: Pavleur बनाम विकल्प।
उपस्थिति पर एक टिप्पणी
इस प्रोजेक्ट पर जिस भी व्यक्ति से फैसला लेने की उम्मीद है, उसे किकऑफ़ में हाज़िर होना चाहिए, या काम शुरू होने से पहले पूरी रिकॉर्डिंग और लिखित सारांश की समीक्षा करनी चाहिए। जो स्टेकहोल्डर किकऑफ़ मिस करता है और दो हफ्ते बाद स्कोप अनौपचारिक रूप से जान लेता है, वह एक आधे-प्रोजेक्ट का स्कोप विवाद है जो होने का इंतज़ार कर रहा है। किकऑफ़ का काम साझा संदर्भ बनाना है, और साझा संदर्भ तभी मौजूद होता है जब प्रासंगिक लोग कमरे में हों।