आपकी टीम असल में काम को कैसे पूरा करती है, इसी के इर्द-गिर्द प्रोजेक्ट मैनेजमेंट सिस्टम बनाने की एक व्यावहारिक गाइड: जेनेरिक PM टूल आखिर क्यों अनदेखे रह जाते हैं, अपने असली चरणों और हैंडऑफ़ को कैसे मॉडल करें, पहले वर्ज़न में क्या चाहिए, और स्टेटस मीटिंग के बिना चल रहे काम को कैसे देखें।
एजेंसियाँ, क्रिएटिव टीमें, कॉन्ट्रैक्टर, प्रोडक्ट टीमें और सेवा-आधारित कारोबार, जिनका डिलीवरी तरीका रेडीमेड प्रोजेक्ट टूल में फ़िट नहीं बैठता।
- आपके असली डिलीवरी चरणों और हैंडऑफ़ पर बना एक प्रोजेक्ट मॉडल
- चल रहे काम का एक ऐसा व्यू जो स्टेटस मीटिंग की जगह ले ले
- एक ऐसा सिस्टम जिसे आप अपनी डिलीवरी प्रक्रिया बदलने पर फिर से ढाल सकें
ज़्यादातर टीमें कोई प्रोजेक्ट मैनेजमेंट टूल आज़मा चुकी हैं और घूम-फिरकर वापस स्प्रेडशीट और चैट पर आ गई हैं। दिक्कत टूल में नहीं थी; दिक्कत यह थी कि वह मेल नहीं खाता था। जेनेरिक प्रोजेक्ट टूल एक तयशुदा आकार थोप देते हैं, यानी कॉलम में सजे हुए टास्क, जबकि आपकी डिलीवरी का अपना एक आकार होता है: आपके चरण, आपकी मंज़ूरियाँ, आपके हैंडऑफ़। जब टूल आपके असल काम करने के तरीके से मेल नहीं खाता, तो उसे अपडेट करना बेकार की मशक्कत बन जाता है और वह चुपचाप दम तोड़ देता है। यह गाइड ऐसा सिस्टम बनाने के बारे में है जो मेल खाता हो, ताकि वह टिका रहे।
क्योंकि वे एक जेनेरिक आकार थोप देते हैं, आमतौर पर टास्क कॉलम-दर-कॉलम खिसकते हुए, जबकि आपकी डिलीवरी के अपने खास चरण, मंज़ूरियाँ और हैंडऑफ़ होते हैं जो उसमें फ़िट नहीं होते। तो लोग सिर्फ़ मैनेजमेंट के दिखावे के लिए टूल को बनाए रखते हैं, जबकि असली तालमेल चैट में होता है, टूल की जानकारी पुरानी पड़ जाती है, और वह देखने की जगह के बजाय अपडेट करने की एक दूसरी जगह बन जाता है। कोई प्रोजेक्ट सिस्टम तभी टिकता है जब उसके चरण आपके ही चरण हों, आपके ही शब्दों में।
इसका एक जाना-पहचाना संकेत होता है: टूल किसी प्रोजेक्ट को "चल रहा है" दिखाता है, जबकि सब जानते हैं कि वह असल में "क्लाइंट के एसेट का इंतज़ार" कर रहा है, एक ऐसी स्थिति जिसके लिए टूल के पास कोई नाम ही नहीं है। हर छूटी हुई स्थिति एक छोटा झूठ है, और छोटे-छोटे झूठों से भरे बोर्ड पर कोई भरोसा नहीं करता, इसलिए कोई उसे ताज़ा नहीं रखता। इलाज ज़्यादा अनुशासन नहीं है; इलाज ऐसा सिस्टम है जिसके चरण असली चरणों से मेल खाते हों, उन अटपटी इंतज़ार वाली स्थितियों समेत जहाँ काम असल में अटकता है।
इसीलिए अपनी डिलीवरी को बयान करके उसके इर्द-गिर्द सिस्टम बनाना, किसी और के टेम्पलेट को कॉन्फ़िगर करने से बेहतर है। चरण, मंज़ूरी के बिंदु और हैंडऑफ़ ही असली उत्पाद हैं, और वे आपके काम करने के तरीके के हिसाब से खास होते हैं।
कोई भी बोर्ड बनाने से पहले, यह दोबारा खींचकर देखें कि हाल के कुछ प्रोजेक्ट शुरू से पूरे होने तक असल में कैसे बढ़े, यह भी कि वे कहाँ अटके। आप अपनी डिलीवरी का आकार निकाल रहे हैं।
एक डिज़ाइन स्टूडियो अपने प्रोजेक्ट बार-बार "क्लाइंट को भेजा" और "क्लाइंट ने जवाब दिया" के बीच की खाई में गँवा देता था, जहाँ चीज़ें बिना किसी ज़िम्मेदार और बिना किसी दिखने वाली घड़ी के कई-कई दिन पड़ी रहती थीं। ईमानदारी से मॉडल करने पर उनके प्रवाह में आठ चरण निकले, जिनमें से तीन इंतज़ार वाली स्थितियाँ थीं, और असली कमाल का फ़ीचर बस इतना था कि इंतज़ार वाली स्थितियों को एक घड़ी के साथ दिखने लायक बना दिया गया। तो "क्लाइंट फ़ीडबैक का इंतज़ार" में एक हफ़्ते से अटका प्रोजेक्ट किसी जेनेरिक "चल रहा है" कॉलम में छिपने के बजाय लाल दिखने लगा। और कुछ नहीं बदला, फिर भी समय पर डिलीवरी छलांग लगा गई।
प्रोजेक्ट टूल शायद किसी भी और तरह के टूल से तेज़ फूलते हैं: टाइम ट्रैकिंग, इनवॉइसिंग, रिसोर्स प्लानिंग, क्लाइंट पोर्टल, डिपेंडेंसी। पहला वर्ज़न वह सबसे छोटी चीज़ है जो काम को दिखने लायक और आगे बढ़ता हुआ बनाए।
बार-बार होने वाली स्टेटस मीटिंग इसलिए होती है क्योंकि स्टेटस कहीं दिखता ही नहीं; लोग वही ज़ोर से बोलने के लिए इकट्ठा होते हैं जो एक अच्छा सिस्टम दिखा देता। प्रोजेक्ट सिस्टम का मकसद उस मीटिंग को गैर-ज़रूरी बनाना है, न कि एक और टूल जोड़ना जिसकी चर्चा आप उसी मीटिंग में करें।
आप वहाँ तब पहुँचते हैं जब कोई भी एक व्यू खोलकर हर प्रोजेक्ट, उसका चरण, उसका मालिक, और वह कितने समय से पड़ा है, यह सब देख सके। घड़ी वाले इंतज़ार वाले चरण खामोश ठहराव को दिखने वाले ठहराव में बदल देते हैं; "क्लाइंट रिव्यू" में आठ दिन से पड़ा प्रोजेक्ट खुद-ब-खुद उभर आता है, और बातचीत खोज के बजाय एक फ़ैसला बन जाती है। जब बोर्ड भरोसेमंद और ताज़ा हो, तो मीटिंग सिकुड़कर उन थोड़ी-सी बातों तक रह जाती है जिन पर सचमुच चर्चा ज़रूरी है, और अक्सर गायब हो जाती है।
सिस्टम को भरोसेमंद बनाए रखना दो चीज़ों पर टिका है जो उसे खुद अपना बनाने से आती हैं: बोर्ड हकीकत से इसलिए मेल खाता है क्योंकि उसके चरण असली चरण हैं, और वह मेल खाता इसलिए रहता है क्योंकि डिलीवरी बदलने पर आप खुद चरण बदल सकते हैं। आपके वर्कफ़्लो के इर्द-गिर्द बना, और बिना किसी इंजीनियरिंग टिकट के फिर से ढाला जा सकने वाला प्रोजेक्ट सिस्टम ही वह है जिसे आपकी टीम ताज़ा रखती है, क्योंकि वह आखिरकार काम की सच्चाई बता रहा होता है।
क्योंकि टूल एक जेनेरिक आकार थोपता है, आमतौर पर कॉलम में सजे टास्क, जो आपके असली डिलीवरी चरणों, मंज़ूरियों और हैंडऑफ़ से मेल नहीं खाता। लोग मैनेजमेंट के लिए उसे बनाए रखते हैं जबकि असली तालमेल चैट में ही रहता है, इसलिए वह पुराना पड़ जाता है। सिस्टम तब टिकता है जब उसके चरण आपके असली चरण हों, उन इंतज़ार वाली स्थितियों समेत जहाँ काम सचमुच अटकता है।
यह दोबारा खींचें कि हाल के कुछ प्रोजेक्ट असल में कैसे बढ़े, यह भी कि वे कहाँ अटके, और असली चरणों को अपने शब्दों में नाम दें: ब्रीफ़ मिला, डिज़ाइन में, क्लाइंट रिव्यू, बदलाव, मंज़ूर, वगैरह। सबसे अहम, "क्लाइंट फ़ीडबैक का इंतज़ार" जैसी इंतज़ार वाली स्थितियाँ ज़रूर शामिल करें, क्योंकि जेनेरिक टूल में काम वहीं छिपता है।
एक साफ़ असली चरण में बैठे प्रोजेक्ट, हर प्रोजेक्ट और चरण के लिए एक मालिक, चरण के हिसाब से चल रहे सारे काम का एक अकेला व्यू, और साफ़ हैंडऑफ़ ताकि अगले मालिक को बिना चैट संदेश के पता चल जाए। टाइम ट्रैकिंग, इनवॉइसिंग और डिपेंडेंसी, ये सब दूसरे वर्ज़न के लिए रुक सकते हैं।
काफ़ी हद तक, हाँ। वह मीटिंग इसलिए होती है क्योंकि स्टेटस कहीं दिखता ही नहीं। जब एक भरोसेमंद व्यू हर प्रोजेक्ट, उसका चरण, उसका मालिक, और वह कितने समय से पड़ा है, यह इंतज़ार वाले चरणों की घड़ी के साथ दिखा दे, तो मीटिंग का खोज वाला हिस्सा गायब हो जाता है और सिर्फ़ असली फ़ैसले बचते हैं। बोर्ड का ताज़ा और सच्चा होना ज़रूरी है, जो उसे खुद अपना बनाने और ढालने से आता है।