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