मंगलवार की स्टेटस मीटिंग उसी बेचैनी के साथ खत्म होती है। आप प्रोजेक्ट मैनेजर हैं, टेक लीड कहते हैं कि API इंटीग्रेशन अनब्लॉक हो गया है, वेंडर कहते हैं कि वे अपडेटेड स्पेसिफिकेशन भेज देंगे, और आपके स्पॉन्सर पूछते हैं कि क्या आप अभी भी लॉन्च की तारीख के हिसाब से चल रहे हैं। आप दस मिनट बाद रीकैप नोट्स भेजते हैं। गुरुवार तक, QA गलत बिल्ड को टेस्ट करता है, वेंडर का स्पेसिफिकेशन कभी नहीं आता, और आपके स्पॉन्सर आपका ही भेजा हुआ रीकैप फॉरवर्ड करके पूछते हैं कि स्कोप में बदलाव को किसने मंज़ूरी दी। जो फ़ैसला अटका हुआ है, वह टेक्निकल नहीं है। सवाल यह है कि अगला कदम कौन उठाएगा और फ़ैसले का रिकॉर्ड क्या माना जाएगा। हर गुज़रते दिन के साथ दोबारा काम करने की ज़रूरत बढ़ती है, और फ़ॉलो-अप मीटिंग्स भी बढ़ती हैं, जिससे लॉन्च की तारीख पर जोखिम भी बढ़ता है।
आप बिना किसी और मीटिंग के इसे ठीक कर सकते हैं। आपको बातचीत से लेकर काम पूरा होने तक का एक ऐसा तरीका चाहिए जिसे बार-बार अपनाया जा सके; एक ऐसा तरीका जिससे फ़ैसलों को ज़िम्मेदार लोगों और ड्यू डेट्स (तय तारीखों) के साथ असाइनमेंट में बदला जा सके; और एक ऐसी साफ़ जगह जहाँ प्रोजेक्ट की असल जानकारी मौजूद हो। यह लेसन एक हफ़्ते की टाइमलाइन का इस्तेमाल करके यह पता लगाता है कि नतीजे कहाँ गायब हो जाते हैं, फिर ‘मीटिंग से काम’ तक की पाइपलाइन के बारे में बताता है, और फिर दिखाता है कि उस पाइपलाइन में AI की भूमिका कहाँ होनी चाहिए और कहाँ नहीं।
टाइमलाइन देखने से पहले, उस पहली कमी या रुकावट का अंदाज़ा लगाएँ जो एक सामान्य रीकैप ईमेल को टीम के लिए अतिरिक्त काम में बदल देती है।
अक्सर ऐसा नहीं होता कि मीटिंग में किसी ने नोट्स न लिखे हों। असल में, मीटिंग से कोई नतीजा तो निकलता है, लेकिन कोई उसे ‘पूरा किए जाने वाले काम’ (डिलीवरेबल) की तरह नहीं देखता।
किसी फ़ैसले पर बात तो हुई, लेकिन यह तय नहीं किया गया कि उसे कौन लागू करेगा (ओनर कौन है)। इसलिए बाद में कोई पक्के तौर पर नहीं कह पाता कि फ़ैसला हुआ था या बस बहस हुई थी। काम सौंपने (हैंडऑफ़) की बात तो हुई—जैसे डेवलपर QA को बिल्ड भेजेंगे—लेकिन इसे किसी ओनर और ड्यू डेट के साथ टास्क के तौर पर असाइन नहीं किया गया। नतीजा यह हुआ कि डेवलपर की बाकी पेंडिंग चीज़ों के बीच यह काम भी कहीं दब गया। किसी डिपेंडेंसी (जैसे वेंडर स्पेसिफिकेशन) का ज़िक्र तो हुआ, लेकिन उसे इंटरनल टास्क वाले सिस्टम में ट्रैक नहीं किया गया। इसलिए, जब तक काम रुक नहीं जाता, तब तक वह नज़र ही नहीं आता। स्पॉन्सर ने कोई ऐसा सवाल पूछा जिसके लिए किसी एक विकल्प को चुनना था, लेकिन जवाब एक लंबे रीकैप ईमेल में कहीं खो गया। स्पॉन्सर ने दोबारा पूछा और आपकी विश्वसनीयता पर सवाल उठ गया।
PM अक्सर यह गलती करते हैं कि रीकैप ईमेल को ही काम का आखिरी पड़ाव मान लेते हैं। यह ज़िम्मेदार काम लगता है क्योंकि इसमें मीटिंग में हुई बातें लिखी होती हैं। लेकिन इसका नतीजा यह होता है कि ओनरशिप की जगह सिर्फ़ डॉक्यूमेंटेशन ले लेता है, और प्रोजेक्ट रिमाइंडर, स्पष्टीकरण और दोबारा काम करने (रीवर्क) के चक्कर में फँस जाता है।
जब मीटिंग से कोई काम निकलता है, तो आपको एक ऐसे पाइपलाइन की ज़रूरत होती है जो आम बातचीत को प्रोजेक्ट के व्यवस्थित आर्टिफैक्ट्स (डॉक्यूमेंट्स/टास्क) में बदल दे। मकसद सिर्फ़ बेहतर नोट्स बनाना नहीं है। मकसद है मीटिंग के नतीजों को ऐसे एक्शन में बदलना जो भरोसेमंद हों और टूल बदलने या याददाश्त कमज़ोर पड़ने पर भी कायम रहें।
पाइपलाइन देखने से पहले, यह तय करें कि जब बहुत सारी मीटिंग्स एक साथ हो जाती हैं, तो कौन सा छूटा हुआ स्टेप आपके प्रोजेक्ट को सबसे ज़्यादा नुकसान पहुँचाता है।