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