10.6 परियोजना प्रबंधन

अवलोकन और प्रेरणा

परियोजना प्रबंधन बाधाओं के तहत इरादे को दिए गए परिणामों में बदलने का अनुशासन है। आप लोगों, दायरे, अनुसूची, लागत, जोखिम, और गुणवत्ता का समन्वय करते हैं ताकि काम वास्तव में समाप्त हो और मूल्य प्रदान करे। सॉफ़्टवेयर में इसे अक्सर संदेह से देखा जाता है, भारी-भरकम योजनाओं और गैंट चार्ट से जुड़ा हुआ जिन्हें वास्तविकता नज़रअंदाज़ कर देती है। लेकिन अंतर्निहित ज़रूरत कभी दूर नहीं होती। किसी को यह सुनिश्चित करना चाहिए कि सही काम सही क्रम में हो, निर्भरताएँ प्रबंधित हों, जोखिम जल्दी सामने आएँ, और हितधारकों को पता हो कि क्या अपेक्षित है। सवाल यह नहीं है कि क्या परियोजनाओं का प्रबंधन करना है, बल्कि यह है कि आप अपने दायित्वों को पूरा करते हुए इसे कितनी हल्की और अनुकूली ढंग से कर सकते हैं।

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

एंटरप्राइज़ और सरकारी संदर्भ दांव बढ़ाते हैं और बाधाओं को बदल देते हैं। एंटरप्राइज़ रणनीति और बजट चक्रों (अध्याय 10.1) के मुकाबले आपस में जुड़ी पहलों के पोर्टफ़ोलियो प्रबंधित करते हैं। सरकारें खरीद नियम, बहु-वर्षीय विनियोग, ठेकेदार प्रबंधन, और सार्वजनिक जवाबदेही जोड़ती हैं। वहाँ, ऐतिहासिक डिफ़ॉल्ट (बड़े, निश्चित-दायरे वाले, वॉटरफ़ॉल अनुबंध) के पास महंगी, दृश्यमान विफलता का लंबा रिकॉर्ड है। यह अध्याय उन बुनियादी बातों को कवर करता है जो प्रेडिक्टिव, अनुकूली, और हाइब्रिड दृष्टिकोणों में लागू होती हैं। अध्याय 10.7 (एजाइल) अनुकूली डिलीवरी पर गहराई से जाता है, और अध्याय 10.1 एकल परियोजना के ऊपर पोर्टफ़ोलियो और कार्यक्रम प्रबंधन को कवर करता है।

मुख्य सिद्धांत

• परिणामों का प्रबंधन करें, गतिविधि का नहीं। पूरा होने का मतलब है दिया गया मूल्य, बंद किए गए कार्य नहीं।
• विभाजित करें और क्रमबद्ध करें। छोटा, क्रमबद्ध, निर्भरता-जागरूक काम बड़े-धमाके वाली योजनाओं को मात देता है।
• अनुमान सीमाएँ हैं, वादे नहीं। अनिश्चितता को ईमानदारी से संप्रेषित करें।
• जोखिम को जल्दी और लगातार सामने लाएँ। सबसे सस्ती समस्या वह है जिसे पहले पकड़ा जाए।
• तरीके को काम के अनुसार मिलाएँ। प्रेडिक्टिव, अनुकूली, या हाइब्रिड: अनिश्चितता और बाधाओं के अनुरूप फिट करें।
• स्थिति को पारदर्शी बनाएँ। दृश्यमान प्रवाह आश्वस्त करने वाली रिपोर्टों को मात देता है।
• हितधारक टीम का हिस्सा हैं। ग्राहक की अनुपस्थिति एक परियोजना जोखिम है।

सिफ़ारिशें

जानबूझकर प्रेडिक्टिव, अनुकूली, या हाइब्रिड चुनें

कोई सार्वभौमिक रूप से सही डिलीवरी मॉडल नहीं है; तरीके और संदर्भ के बीच एक फिट है:

• प्रेडिक्टिव (योजना-संचालित, “वॉटरफ़ॉल”): दायरा पहले से तय होता है, फिर अनुसूची और लागत निकाली जाती है। वास्तव में स्थिर, अच्छी तरह समझी गई आवश्यकताओं और कठोर बाहरी बाधाओं (नियामक प्रमाणन, भौतिक एकीकरण) वाले काम के लिए उपयुक्त। इसका विफलता मोड यह दिखावा करना है कि सॉफ़्टवेयर आवश्यकताएँ स्थिर हैं जबकि वे नहीं हैं।
• अनुकूली (एजाइल): दायरा लचीला होता है; समय और लागत छोटे पुनरावृत्तियों में तय होते हैं जो कार्यशील सॉफ़्टवेयर देते हैं और सीख को अवशोषित करते हैं। अधिकांश उत्पाद और डिजिटल-सेवा काम के लिए उपयुक्त, जहाँ आवश्यकताओं की खोज की जाती है (अध्याय 11.1, 10.7)।
• हाइब्रिड: एक प्रेडिक्टिव गवर्नेंस शेल के अंदर एक अनुकूली कोर, एंटरप्राइज़ और सरकार में आम और अक्सर सही, जहाँ वित्तपोषण, अनुपालन, और अनुबंध माइलस्टोन और ऑडिट की मांग करते हैं जबकि डिलीवरी पुनरावृत्ति से लाभान्वित होती है।

PMBOK (Project Management Body of Knowledge, Project Management Institute से) और PRINCE2 (PRojects IN Controlled Environments) जैसे फ्रेमवर्क प्रेडिक्टिव और हाइब्रिड अभ्यास को संहिताबद्ध करते हैं। मुद्दा यह है कि उनके अनुशासन (भूमिकाएँ, जोखिम, स्टेज गेट) को उधार लें बिना ऐसे अनुष्ठान आयात किए जिनकी काम को ज़रूरत नहीं है।

दायरे को ट्रिपल कॉन्स्ट्रेंट के मुकाबले प्रबंधित करें

दायरा, अनुसूची, और लागत गुणवत्ता से बंधी हुई एक साथ चलती हैं: क्लासिक “आयरन ट्रायंगल।” आप तीनों को स्थिर नहीं कर सकते और मुफ़्त में दायरा जोड़ सकते। कुछ न कुछ झुकता है, और अन्यथा दिखावा करना ही वह तरीका है जिससे डेथ मार्च शुरू होते हैं। समझौतों को स्पष्ट बनाएँ, और तय करें कि कौन सा चर झुकता है। अनुकूली तरीके समय और लागत को स्थिर करते हैं और दायरे को झुकाते हैं। निश्चित-मूल्य अनुबंध दायरे और लागत को स्थिर करते हैं, और वास्तव में गुणवत्ता या अनुसूची को झुकाते हैं जब तक आप उन्हें प्रबंधित नहीं करते। एक हल्की परिवर्तन प्रक्रिया (अध्याय 12.3) से दायरा रेंगन को नियंत्रित करें, और सब कुछ खिसकाने के बजाय एक मूल्यवान कोर तक डी-स्कोपिंग को प्राथमिकता दें।

ईमानदारी से, सीमाओं में अनुमान लगाएँ, और फिर से पूर्वानुमान करें

अनुमान वह जगह है जहाँ परियोजनाएँ खुद से सबसे अधिक झूठ बोलती हैं। अनुमानों को एकल संख्याओं के बजाय संभाव्य सीमाओं के रूप में मानें, और दूर, खराब समझे गए काम के लिए उन्हें चौड़ा करें (अनिश्चितता का शंकु)। सापेक्ष और अनुभवजन्य तरीकों को प्राथमिकता दें: ऐतिहासिक थ्रूपुट और साइकल टाइम (अध्याय 11.2, 11.3) वीरतापूर्ण बॉटम-अप अनुमानों से बेहतर पूर्वानुमान करते हैं। जहाँ आप कर सकें, अनुमान को माप से बदलें। 8 आइटम/सप्ताह बंद करने वाली एक टीम को 40 आइटम के लिए लगभग 5 सप्ताह लगेंगे, स्टोरी पॉइंट्स की परवाह किए बिना (लिटल का नियम फिर से: थ्रूपुट और प्रगति में काम, अनुमान नहीं, डिलीवरी समय तय करते हैं)। जैसे-जैसे वास्तविकता आती है, लगातार फिर से पूर्वानुमान करें। एक योजना जो कभी नहीं बदलती वह प्रबंधित नहीं हो रही है।

निर्भरताओं और क्रिटिकल पाथ को प्रबंधित करें

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

एक जीवंत जोखिम रजिस्टर चलाएँ

जोखिम प्रबंधन सबसे उच्च-प्रभाव वाली परियोजना-प्रबंधन गतिविधि है, और सबसे अधिक बार छोड़ी जाने वाली भी। एक सरल, जीवंत जोखिम रजिस्टर रखें: प्रत्येक जोखिम के साथ उसकी संभावना, प्रभाव, मालिक, और शमन या आकस्मिकता (अध्याय 12.3)। इसे नियमित रूप से समीक्षा करें, बीते हुए जोखिमों को हटाएँ, और नए उभरने पर जोड़ें। जोखिमों (हो सकता है) को मुद्दों (पहले से हो रहा है) और निर्णयों (अध्याय 1.6) से अलग बताएँ। लक्ष्य कोई दस्तावेज़ नहीं है। यह आगे देखने की एक आदत है, ताकि आप समय सीमा पर समस्याओं की खोज करने के बजाय उनका अनुमान लगाएँ।

हितधारकों को जोड़ें और पारदर्शी रूप से संप्रेषित करें

अधिकांश “आश्चर्यजनक” परियोजना विफलताएँ किसी ऐसे व्यक्ति को पहले से दिखाई दे रही थीं जिसकी बात नहीं सुनी गई। हितधारकों की पहचान करें, उनकी चिंताओं को समझें, और उन्हें वास्तव में शामिल रखें। ग्राहक की अनुपस्थिति खुद एक शीर्ष जोखिम है। आशावाद को पुरस्कृत करने वाली हरे-पीले-लाल रिपोर्टों के बजाय पारदर्शी प्रवाह (दृश्यमान बोर्ड, बर्न-अप चार्ट, प्रदर्शित कार्यशील सॉफ़्टवेयर) के माध्यम से स्थिति संप्रेषित करें। ईमानदारी से और जल्दी आगे बढ़ाएँ। एक अच्छी तरह चलाई गई परियोजना बुरी खबर को तेज़ी से यात्रा कराती है।

समझौते: फ़ायदे और नुकसान

दृष्टिकोण	फ़ायदे	नुकसान
प्रेडिक्टिव / वॉटरफ़ॉल	अनुमानित दायरा और लागत; अनुबंध- और ऑडिट-अनुकूल	अनिश्चित आवश्यकताओं के लिए ख़राब फिट; देर से फ़ीडबैक; बड़े-धमाके का जोखिम
अनुकूली / एजाइल	तेज़ फ़ीडबैक; बदलाव को अवशोषित करता है; जल्दी मूल्य	पहले से दायरा/लागत तय करना कठिन; एक जुड़े हुए ग्राहक की ज़रूरत
हाइब्रिड	गवर्नेंस के अंदर पुनरावृत्ति; एंटरप्राइज़/सरकार में फिट	गतियों के बीच तनाव; दोनों सेट के ओवरहेड विरासत में मिल सकते हैं
विस्तृत पूर्व-अनुमान	योजनाकारों और वित्तपोषकों के लिए आराम	सटीक रूप से ग़लत; बनाना महंगा; तेज़ी से क्षय
अनुभवजन्य पूर्वानुमान (प्रवाह मीट्रिक)	आधारित, स्व-सुधारने वाला	इतिहास और अनुशासन की आवश्यकता; कम “निश्चित”-दिखने वाला
भारी जोखिम/प्रक्रिया अनुष्ठान	गहन; उच्च-दांव वाले कार्यक्रमों के लिए अच्छा	छोटी टीमों को धीमा करता है; बॉक्स-टिकिंग बन सकता है

केंद्रीय तनाव है पूर्वानुमेयता बनाम अनुकूलनशीलता। वित्तपोषक, अनुबंध, और ऑडिट दृढ़ प्रतिबद्धताएँ चाहते हैं। अनिश्चित सॉफ़्टवेयर काम को सीखने के लिए जगह चाहिए। इसे उसी तरह सुलझाएँ जैसे एजाइल करता है (अध्याय 10.7): परिणामों और समय सीमाओं के प्रति दृढ़ता से प्रतिबद्ध रहें जबकि दायरे को झुकने दें, और डिलीवरी को जमाए बिना निगरानी को संतुष्ट करने के लिए हाइब्रिड गवर्नेंस का उपयोग करें।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. आप दोनों के ओवरहेड को विरासत में पाए बिना अनुकूली डिलीवरी टीमों को एक प्रेडिक्टिव गवर्नेंस शेल में कैसे लपेटेंगे? हाइब्रिड एंटरप्राइज़ और सरकार में आम और अक्सर सही है, जहाँ वित्तपोषण चक्र, अनुपालन, और अनुबंध माइलस्टोन और ऑडिट की मांग करते हैं जबकि डिलीवरी पुनरावृत्ति से लाभान्वित होती है। जोखिम वास्तविक है: एक ख़राब तरीके से डिज़ाइन किया गया हाइब्रिड एक साथ वॉटरफ़ॉल के भारी दस्तावेज़ीकरण और एजाइल के अनुष्ठान विरासत में पाता है, और टीमें एक-दूसरे से लड़ती दो गतियों का घर्षण महसूस करती हैं। सबूत लाएँ: मैप करें कि आपके वित्तपोषण द्वार, अनुपालन चेकपॉइंट, और अनुबंध माइलस्टोन वास्तव में कहाँ गिरते हैं, और जाँचें कि क्या प्रत्येक ऐसे दस्तावेज़ की मांग करता है जिसे डिलीवरी काम अन्यथा उत्पन्न नहीं करता। उत्तर से पुनरावृत्ति को निगरानी से लड़ने के बजाय उसे संतुष्ट करना चाहिए, प्रदर्शित कार्यशील वृद्धियों और एक जीवंत जोखिम रजिस्टर को गवर्नेंस लय में फीड करके, अलग रिपोर्ट इकट्ठा करने के लिए रुकने के बजाय। PRINCE2 जैसे फ्रेमवर्क के अनुशासन को उधार लें बिना ऐसे अनुष्ठान आयात किए जिनकी काम को ज़रूरत नहीं है।

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

3. क्या आप जानते हैं कि यदि अनुसूची और लागत हिलना बंद हो जाएँ तो आप किस न्यूनतम मूल्यवान कोर तक डी-स्कोप करेंगे? दायरा, अनुसूची, और लागत गुणवत्ता से बंधे हुए एक साथ चलते हैं, और जब वित्तपोषक तीनों को स्थिर करते हैं, तो गुणवत्ता मूक रिलीज़ वाल्व बन जाती है और डेथ मार्च शुरू होते हैं। अनुकूली तरीके समय और लागत को स्थिर करते हैं और दायरे को झुकाते हैं, जो तभी काम करता है जब आपने पहले से तय कर लिया हो कि कौन सा हिस्सा वास्तविक मूल्य देता है और कौन सी विशेषताएँ परक्राम्य हैं। सबूत लाएँ: अपनी वर्तमान रिलीज़ के लिए, क्या आप उस कोर का नाम बता सकते हैं जिसे शिप होना ही चाहिए और वह सूची जिसे आप पहले काटेंगे, या हर विशेषता को चुपचाप अनिवार्य माना जाता है? उत्तर से आपको सब कुछ खिसकाने के बजाय एक मूल्यवान कोर तक डी-स्कोप करने में सक्षम होना चाहिए, और इसे दबाव आने से पहले तय किया जाना चाहिए, समय सीमा पर तात्कालिक रूप से नहीं। बाकी को एक हल्की परिवर्तन प्रक्रिया से नियंत्रित करें ताकि दायरा रेंगन उस मार्जिन को न खा जाए जिस पर आप भरोसा कर रहे थे।

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

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

6. सबसे हल्की प्रक्रिया क्या है जो अभी भी आपके वास्तविक दायित्वों को पूरा करती है, और अनुष्ठान जोखिम कम करने से कहाँ अलग हो गया है? कम-प्रबंधन और अति-प्रबंधन दोनों वास्तविक लागत वहन करते हैं: एक तरफ़ अराजकता, पुनःकार्य, और छूटी हुई निर्भरताएँ, और दूसरी तरफ़ बॉक्स-टिकिंग जो जोखिम कम किए बिना डिलीवरी को धीमा करती है। तनाव यह है कि ऑडिट, अनुपालन, और अनुबंध शर्तें वास्तविक आवश्यकताएँ थोपती हैं, फिर भी टीमें हर अनुष्ठान को उसकी जगह कमाना बंद करने के बहुत बाद तक बनाए रखती हैं। सबूत लाएँ: प्रत्येक आवर्ती रिपोर्ट, गेट, और बैठक के लिए, उस विशिष्ट दायित्व या जोखिम का नाम बताएँ जिसे यह संबोधित करता है, और किसी भी ऐसे को चिह्नित करें जिसे कोई भी किसी से नहीं जोड़ सकता। उत्तर से आपको ऐसे अनुष्ठान को सेवानिवृत्त करने देना चाहिए जो केवल आश्वासन देता है जबकि उन कलाकृतियों को संरक्षित रखना चाहिए जो किसी वास्तविक ऑडिटर या वित्तपोषक को संतुष्ट करती हैं। एंटरप्राइज़ और सरकारी संदर्भों में, प्रत्येक अनुष्ठान को उस नामित विनियोग, खरीद, या नियामक नियम से मैप करें जिसकी यह सेवा करता है, ताकि आप अनुपालन की मांगों का अनुमान लगाने के बजाय बाकी को काटने का बचाव निगरानी के सामने कर सकें।

क्षेत्र लेंस

स्टार्टअप। लगभग बिना किसी अनुष्ठान के लेकिन वास्तविक अनुशासन के साथ प्रबंधित करें। रिलीज़ को छोटे क्रमबद्ध हिस्सों में तोड़ें, दायरे को एक मूल्यवान कोर तक झुकने देते हुए लॉन्च तारीख़ के प्रति प्रतिबद्ध रहें, और संस्थापकों को एक तारीख़ के बजाय एक सीमा बताएँ, हर हफ़्ते फिर से पूर्वानुमान करें कि आप वास्तव में कितने हिस्से बंद करते हैं। एक साझा दस्तावेज़ में दस-पंक्ति का जोखिम रजिस्टर जो उस एक निर्भरता का नाम बताता है जो तारीख़ को डुबो सकती है, एक मालिक और एक बैकअप योजना के साथ, किसी भी टूल से अधिक मूल्यवान है, क्योंकि आपका सबसे दुर्लभ संसाधन ध्यान है और एक खिसकाव जिसे आप देर से देखते हैं वह कंपनी को समाप्त कर सकता है।

छोटा व्यवसाय। आपके पास कोई परियोजना प्रबंधक नहीं है और थोड़ी ही गुंजाइश है, इसलिए एक गवर्नेंस कार्यालय खड़ा करने के बजाय उन टूल पर निर्भर रहें जो आप पहले से चलाते हैं। एक दृश्यमान बोर्ड पर काम को ट्रैक करें, एक छोटी जीवंत जोखिम सूची रखें, और शुरू से प्रक्रिया बनाने के बजाय एक शेड्यूलिंग या टिकटिंग उत्पाद ख़रीदना पसंद करें। पहले से तय करें कि रिलीज़ के लायक होने के लिए कौन सी एकल विशेषता शिप होनी चाहिए, क्योंकि जब अनुसूची कसती है तो आपके पास उस पल में दायरे पर बातचीत करने के लिए अतिरिक्त लोग नहीं होंगे।

एंटरप्राइज़। समस्या कई टीमों, विक्रेताओं, और वित्तपोषण चक्रों में समन्वय है। अनुकूली टीमों को एक प्रेडिक्टिव गवर्नेंस शेल में लपेटें, अलग रिपोर्ट इकट्ठा करने के बजाय प्रदर्शित वृद्धियों और एक जीवंत जोखिम रजिस्टर को माइलस्टोन लय में फीड करें, और एक क्रॉस-टीम निर्भरता मैप बनाए रखें ताकि क्रिटिकल पाथ को खोजने के बजाय प्रबंधित किया जाए। पोर्टफ़ोलियो में सीमा-आधारित, अनुभवजन्य रूप से फिर से पूर्वानुमानित अनुमानों को मानकीकृत करें ताकि नेतृत्व आशावादी स्थिर तारीख़ों के बजाय ईमानदार, संकुचित होते प्रक्षेपणों पर परियोजनाओं की तुलना करे।

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

उदाहरण

स्टार्टअप। अपना पहला भुगतान किया गया उत्पाद शिप करने की दौड़ में लगा सात लोगों का एक स्टार्टअप परियोजना को लगभग बिना किसी अनुष्ठान के लेकिन वास्तविक अनुशासन के साथ प्रबंधित करता है। यह रिलीज़ को छोटे क्रमबद्ध हिस्सों में तोड़ता है, हर विशेषता का वादा करने के बजाय दायरे को एक मूल्यवान कोर तक झुकने देते हुए एक लॉन्च तारीख़ के प्रति प्रतिबद्ध रहता है, और संस्थापकों को एक तारीख़ के बजाय एक सीमा बताता है, हर हफ़्ते फिर से पूर्वानुमान करता है कि टीम वास्तव में कितने हिस्से बंद करती है। एक साझा दस्तावेज़ में दस-पंक्ति का जोखिम रजिस्टर उस एक निर्भरता का नाम बताता है जो तारीख़ को डुबो सकती है, एक अधूरा भुगतान एकीकरण, एक मालिक और एक बैकअप योजना के साथ, ताकि सबसे बड़े ख़तरे को समय सीमा पर खोजे जाने के बजाय देखा जाए।

एंटरप्राइज़। अपना लोन-ओरिजिनेशन प्लेटफ़ॉर्म बदल रहा एक बैंक एक हाइब्रिड कार्यक्रम चलाता है: तिमाही वित्तपोषण माइलस्टोन और अनुपालन गेट वाला एक प्रेडिक्टिव शेल, जो हर दो हफ़्ते में कार्यशील वृद्धियाँ देने वाली अनुकूली टीमों को लपेटता है। एक क्रॉस-टीम निर्भरता मैप उजागर करता है कि एक साझा पहचान सेवा क्रिटिकल पाथ पर है। इसलिए कार्यक्रम इसे पहले क्रमबद्ध करता है और इसे डी-रिस्क करता है, देर से होने वाले झरने से बचता है। अनुमानों को सीमाओं के रूप में व्यक्त किया जाता है और वास्तविक थ्रूपुट से मासिक रूप से फिर से पूर्वानुमानित किया जाता है, ताकि नेतृत्व एक स्थिर तारीख़ के बजाय जो चुपचाप खिसकती है, एक ईमानदार, संकुचित होता प्रक्षेपण देखे।

सरकार। एक एजेंसी एकल निश्चित-मूल्य, निश्चित-दायरे वाले वॉटरफ़ॉल अनुबंध (कई सार्वजनिक विफलताओं के पीछे का पैटर्न) को मॉड्यूलर खरीद के लिए छोड़ देती है: छोटी, परिणाम-आधारित वृद्धियाँ एक ऐसे गवर्नेंस फ्रेमवर्क के तहत अनुकूली रूप से प्रदान की जाती हैं जो विनियोग और निगरानी को संतुष्ट करता है। एक जीवंत जोखिम रजिस्टर और पारदर्शी, प्रदर्शित वृद्धियाँ ऑडिटरों और विधायकों को वास्तविक दृश्यता देती हैं। क्योंकि दायरा निश्चित वित्तपोषण के भीतर एक मूल्यवान कोर तक झुकता है, कार्यक्रम एक दूर के गो-लाइव पर सब कुछ जोखिम में डालने के बजाय उपयोगी क्षमता जल्दी शिप कर सकता है (अध्याय 10.1, 10.3)।

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

अच्छे परियोजना प्रबंधन पर प्रतिफल पर टाली गई विफलता का दबदबा है। बड़ी सॉफ़्टवेयर परियोजनाएँ मूल निश्चित योजना को हासिल करने की तुलना में देर से होने, बजट से अधिक जाने, या रद्द होने की कहीं अधिक संभावना रखती हैं, और नुकसान बहुत बड़े हैं: डूबी हुई लागत, साथ ही छूटा हुआ मूल्य, साथ ही, सरकार में, सार्वजनिक और राजनीतिक क्षति। यहाँ के अनुशासन (ईमानदार अनुमान, निर्भरता प्रबंधन, जल्दी जोखिम काम, जुड़े हुए हितधारक, और अनुकूली दायरा) ठीक वही हैं जो किसी परियोजना को विफलता वक्र से दूर ले जाते हैं। एक बड़े ओवररन या रद्दीकरण की संभावना में एक मामूली कटौती भी परियोजना को अच्छी तरह प्रबंधित करने की लागत को बौना बना देती है।

कुल स्वामित्व लागत पर, हल्का, अनुकूली प्रबंधन काम के पूरे जीवनकाल में लागत को कम करता है। तेज़ फ़ीडबैक महंगी ग़लतियों को जल्दी पकड़ता है। वृद्धिशील डिलीवरी जल्दी मूल्य लौटाना शुरू करती है, जो ROI समय को बेहतर बनाती है। पारदर्शी प्रवाह उस रिपोर्टिंग ओवरहेड को कम करता है जो भारी गवर्नेंस थोपता है। कम-प्रबंधन (अराजकता, पुनःकार्य, छूटी हुई निर्भरताएँ) और अति-प्रबंधन (अनुष्ठान जो डिलीवरी को धीमा करता है) दोनों वास्तविक लागत वहन करते हैं। लक्ष्य सबसे हल्की प्रक्रिया है जो आपके वास्तविक दायित्वों को पूरा करती है। नेतृत्व के सामने मामला बनाएँ किसी हालिया परेशानी भरी परियोजना की पूरी लोड की गई लागत की तुलना एक जोखिम रजिस्टर, एक निर्भरता मैप, और ईमानदार सीमा-आधारित पूर्वानुमानों की लगभग-शून्य लागत से करके।

विरोधी पैटर्न और नुकसान

• सब कुछ-निश्चित योजनाएँ: दायरा, अनुसूची, और लागत सभी लॉक किए गए, गुणवत्ता मूक रिलीज़ वाल्व के रूप में।
• वादों के रूप में अनुमान: एक-संख्या वाली तारीख़ों को प्रतिबद्धताओं के रूप में माना जाता है, फिर सबूत के आगे बचाया जाता है।
• निर्भरताओं को नज़रअंदाज़ करना: प्रत्येक टीम की वेलोसिटी का प्रबंधन करते हुए जबकि क्रॉस-टीम क्रिटिकल पाथ खिसकता है।
• जोखिम रजिस्टर तमाशा: एक दस्तावेज़ जो एक बार बनाया गया और कभी दोबारा नहीं देखा गया।
• तरबूज़ स्थिति: बाहर हरा, अंदर लाल; ईमानदारी पर आशावाद को पुरस्कृत किया जाता है।
• अनुपस्थित ग्राहक: कोई जुड़ा हुआ हितधारक नहीं, इसलिए ग़लत चीज़ आत्मविश्वास से बनाई जाती है।
• बड़े-धमाके की डिलीवरी: सब कुछ अंत में एकीकृत और रिलीज़ किया जाता है, जोखिम को अधिकतम करता है (अध्याय 11.2 से तुलना करें)।
• अपने आप में प्रक्रिया: अनुष्ठान और रिपोर्टें जो जोखिम कम किए बिना प्रयास खा जाती हैं।

परिपक्वता मॉडल

• स्तर 1 (आरंभ करें): परियोजनाएँ वीरता और उम्मीद पर चलती हैं; दायरा, जोखिम, और निर्भरताएँ यदि प्रबंधित भी होती हैं तो तदर्थ रूप से; अनुमान एक-संख्या वाले हैं जिन्हें सबूत के आगे बचाया जाता है; आश्चर्य समय सीमा पर आते हैं।
• स्तर 2 (विकसित करें): बुनियादी योजना, स्थिति रिपोर्टिंग, और एक जोखिम सूची कुछ परियोजनाओं में मौजूद है लेकिन दूसरों में नहीं; डिलीवरी तरीका फिट के बजाय आदत से चुना जाता है; अनुमान और निर्भरता ट्रैकिंग टीम-दर-टीम अलग होती है, इसलिए अभ्यास संगठन में असंगत है।
• स्तर 3 (मानकीकृत करें): एक दस्तावेज़ीकृत दृष्टिकोण पूरे संगठन में लागू होता है: डिलीवरी तरीका काम के अनुसार चुना जाता है, दायरे को ट्रिपल कॉन्स्ट्रेंट के मुकाबले प्रबंधित किया जाता है, एक जीवंत जोखिम रजिस्टर और निर्भरता मैप हर परियोजना पर अपेक्षित है, और अनुमान सीमा-आधारित हैं और जुड़े हुए हितधारकों के साथ फिर से पूर्वानुमानित किए जाते हैं।
• स्तर 4 (प्रबंधित करें): डिलीवरी को आधाररेखाओं के मुकाबले मापा और नियंत्रित किया जाता है। थ्रूपुट, साइकल टाइम, पूर्वानुमान सटीकता, निर्भरता और जोखिम समापन दरें, और अनुसूची व लागत विचलन को प्रति परियोजना ट्रैक किया जाता है और पोर्टफ़ोलियो में जोड़ा जाता है; प्रक्षेपण अनुभवजन्य और संकुचित होते हैं; खिसकाव जल्दी सामने आते हैं और आशावाद के बजाय सबूत पर फिर से दायरा तय करने या फिर से बेसलाइन करने को ट्रिगर करते हैं।
• स्तर 5 (समन्वित करें): परियोजना प्रबंधन पोर्टफ़ोलियो, वित्तपोषण, और जोखिम योजना के साथ एकीकृत है और लगातार सुधरता है। हाइब्रिड गवर्नेंस डिलीवरी को धीमा किए बिना निगरानी को संतुष्ट करता है, क्रॉस-टीम और क्रॉस-विक्रेता निर्भरताओं को सक्रिय रूप से प्रबंधित किया जाता है, रेट्रोस्पेक्टिव मापे गए बदलाव को वापस अभ्यास में फीड करते हैं, और संगठन अपने तरीकों को अनुकूलित करता है और बाधाओं व प्राथमिकताओं के बदलने के साथ काम को पुनर्संतुलित करता है।

चर्चा के लिए विचार

1. आपकी वर्तमान पहलों में से प्रत्येक को वास्तव में कौन सा डिलीवरी तरीका (प्रेडिक्टिव, अनुकूली, हाइब्रिड) चाहिए, और क्या यह उससे मेल खाता है जिसका आप उपयोग कर रहे हैं?
2. जब आपने आख़िरी बार किसी तारीख़ के प्रति प्रतिबद्धता जताई, तो क्या वह एक सीमा थी या एक एकल संख्या, और इसने अपेक्षाओं को कैसे आकार दिया?
3. अभी आपकी टीमों में क्रिटिकल-पाथ निर्भरता क्या है, और इसे डी-रिस्क करने का मालिक कौन है?
4. क्या आपका जोखिम रजिस्टर एक जीवंत आदत है या एक बार का दस्तावेज़?
5. जब दायरा, अनुसूची, और लागत सभी स्थिर होते हैं तो गुणवत्ता चुपचाप कहाँ दबाव को अवशोषित कर रही है?
6. यदि आप अनुमान को मापे गए थ्रूपुट से बदल दें तो आपके पूर्वानुमान कैसे बदलेंगे?

मुख्य निष्कर्ष

• परियोजना प्रबंधन दायरा-अनुसूची-लागत-गुणवत्ता बाधा के तहत इरादे को दिए गए परिणामों में बदलता है।
• तरीके को काम के अनुसार मिलाएँ: प्रेडिक्टिव, अनुकूली, या हाइब्रिड, और एंटरप्राइज़/सरकार में हाइब्रिड गवर्नेंस को प्राथमिकता दें।
• अनुमानों को सीमाओं के रूप में मानें, अनुभवजन्य प्रवाह मीट्रिक से फिर से पूर्वानुमान करें, और एक-संख्या वाली तारीख़ों को झूठ न बनने दें।
• निर्भरताएँ और जोखिम बड़े पैमाने पर प्रमुख विफलता मोड हैं: दोनों को लगातार मैप और प्रबंधित करें।
• हितधारकों को जुड़ा हुआ और स्थिति को पारदर्शी रखें; बुरी खबर को तेज़ी से यात्रा कराएँ।
• ROI टाली गई विफलता है; सबसे हल्की प्रक्रिया जो आपके दायित्वों को पूरा करती है जीतती है। अध्याय 10.7 (एजाइल), 10.1 (पोर्टफ़ोलियो और कार्यक्रम प्रबंधन), 11.2 (डिलीवरी), और 11.3 (क्यूइंग थ्योरी) देखें।

संदर्भ और आगे पढ़ने के लिए

• Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide).
• AXELOS, Managing Successful Projects with PRINCE2.
• Frederick Brooks, The Mythical Man-Month (किसी देर से चल रही परियोजना में लोगों को जोड़ना इसे और देर क्यों कर देता है)।
• Tom DeMarco and Timothy Lister, Peopleware and Waltzing with Bears (जोखिम प्रबंधन)।
• Steve McConnell, Software Estimation: Demystifying the Black Art.
• Daniel Vacanti, Actionable Agile Metrics for Predictability (अनुभवजन्य पूर्वानुमान)।
• Standish Group, CHAOS Report (सॉफ़्टवेयर परियोजना परिणाम, आलोचनात्मक रूप से पढ़ें)।
• U.S. Digital Service, Digital Services Playbook; UK Government, Government Service Standard (आधुनिक सार्वजनिक-क्षेत्र की डिलीवरी)।
• Bent Flyvbjerg and Dan Gardner, How Big Things Get Done (मेगाप्रोजेक्ट डिलीवरी)।