10.1 पोर्टफ़ोलियो और प्रोग्राम प्रबंधन

अवलोकन और उद्देश्य

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

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

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

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

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

सिफ़ारिशें

इंजीनियरिंग को रणनीति और OKR के साथ संरेखित करें

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

इरादे और ईमानदार क्षितिज के साथ रोडमैप बनाएँ

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

स्पष्ट फ्रेमवर्क और नामित ट्रेड-ऑफ़ के साथ प्राथमिकता दें

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

कई टीमों में निर्भरताओं का प्रबंधन करें

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

विक्रेताओं, ठेकेदारों, और सिस्टम-इंटीग्रेटर को गवर्न करें

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

खरीद, बजट, और बहु-वर्षीय वित्तपोषण को नेविगेट करें

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

ट्रेड-ऑफ़: फ़ायदे और नुकसान

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

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

अपनी टीम के साथ चर्चा करने योग्य प्रश्न

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

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

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

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

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

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

क्षेत्र लेंस

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

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

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

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

उदाहरण

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

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

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

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

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

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

एंटी-पैटर्न और नुकसान

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

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

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

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

स्तर 3: मानकीकरण (Standardize)। रणनीति एक उथली OKR संरचना के माध्यम से टीमों तक स्पष्ट रूप से कैस्केड होती है, और एक प्राथमिकता निर्धारण फ्रेमवर्क दस्तावेज़ीकृत है और पूरे पोर्टफ़ोलियो में लागू होता है। क्रॉस-टीम योजना इवेंट निर्भरताओं को काटने से पहले सामने लाते हैं, टीमों को प्रति परियोजना के बजाय लगातार वित्तपोषित किया जाता है, और वृद्धिशील वित्तपोषण के साथ मॉड्यूलर कॉन्ट्रैक्टिंग एक स्थानीय प्रयोग के बजाय संगठन-व्यापी मानदंड है।

स्तर 4: प्रबंधन (Manage)। पोर्टफ़ोलियो को केवल दस्तावेज़ीकृत ही नहीं, बल्कि बेसलाइन के विरुद्ध मापा जाता है। नेता हर वित्तपोषित विषय के लिए परिणाम की गति, शीर्ष पहलों पर विलंब-लागत, निर्भरता फिसलने की दरें, सहमत परिणामों के विरुद्ध विक्रेता डिलीवरी, और प्रदर्शित परिणामों से जुड़े प्रतिबद्ध खर्च के हिस्से को ट्रैक करते हैं। प्राथमिकता निर्धारण ट्रेड-ऑफ़ और किल मानदंड इस साक्ष्य पर लागू किए जाते हैं, और लागत तथा शेड्यूल पर पूर्वानुमान-बनाम-वास्तविक भिन्नता वकालत के बजाय हर वित्तपोषण निर्णय को संचालित करती है।

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

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

• एक OKR कैस्केड काम को मार्गदर्शन देना बंद करने से पहले कितना उथला हो सकता है, और कल्पना बनने से पहले कितना गहरा?
• एक प्राथमिकता निर्धारण सूत्र निर्णयों को कब बेहतर बनाता है, और कब यह केवल किसी के पूर्वनिर्धारित उत्तर को वैध बनाता है?
• क्या प्लेटफ़ॉर्म टीमों को केंद्रीय बजट से वित्तपोषित किया जाना चाहिए या उपभोग करने वाली टीमों से वापस चार्ज किया जाना चाहिए, और यह उनके प्रोत्साहनों को कैसे बदलता है?
• सरकारी संदर्भ में, विधायी परिवर्तन की आवश्यकता से पहले आप मौजूदा विनियोजन कानून के भीतर वृद्धिशील और मॉड्यूलर वित्तपोषण को कितनी दूर तक धकेल सकते हैं?
• आप रिपोर्टिंग ओवरहेड में डूबे बिना विक्रेता के काम को आंतरिक काम जितना दृश्यमान कैसे रखते हैं?
• जब किसी स्थायी टीम का उत्पाद रणनीतिक प्रासंगिकता खो देता है तो सही प्रतिक्रिया क्या है: लोगों को फिर से तैनात करें, या भंग करके फिर से बनाएँ?

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

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

संदर्भ और आगे पढ़ना

• Donald G. Reinertsen, The Principles of Product Development Flow
• Marty Cagan, Inspired and Empowered
• John Doerr, Measure What Matters
• Christina Wodtke, Radical Focus: Achieving Your Most Important Goals with OKRs
• Mik Kersten, Project to Product
• Jez Humble, Joanne Molesky, and Barry O’Reilly, Lean Enterprise
• Project Management Institute, The Standard for Portfolio Management
• Axelos, Managing Successful Programmes (MSP)
• U.S. Digital Service, Digital Services Playbook
• UK Government Digital Service, Service Manual and Technology Code of Practice
• U.S. Government Accountability Office, Agile Assessment Guide