बड़ी आईटी परियोजनाएं विफल क्यों होती हैं या बड़ी लागत / अनुसूची ओवररन होती हैं? [बन्द है]

34

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

ऑस्ट्रेलिया का एक उदाहरण क्वींसलैंड पेरोल परियोजना है जहां उन्होंने परियोजना को वितरित करने के लिए परीक्षण सफलता के मापदंड को बदल दिया।
इस SO प्रश्न में कुछ और असफल परियोजनाएँ देखें ( वेनबैक मशीन पर )

क्या आपको साझा करने के लिए कोई व्यक्तिगत अनुभव मिला है?

project-management project

— प्रितिक
स्रोत

10

इस समस्या के बारे में एक उत्सुक बात यह है कि आप आमतौर पर डेवलपर्स से और प्रबंधकों से पूरी तरह से अलग-अलग उत्तर प्राप्त करते हैं।

— मोजुबा

3

@mojuba मैं दोनों हूँ, और मैंने उत्तर दिया। मुझे उम्मीद है कि कई व्यक्तित्व विकार के निदान में परिणाम नहीं होता है।

— टिम पोस्ट

1

एजाइल सबसे अच्छा है जब ग्राहक को नहीं पता कि वे क्या चाहते हैं। कंपनियां आमतौर पर बड़ी मात्रा में खर्च करने के लिए तैयार नहीं होती हैं, जो खराब परिभाषित की जाने वाली परियोजनाओं पर समाचार पत्रों में लाने के लिए तैयार होती हैं।

— स्पर्शुरेना

1

यह सॉफ्टवेयर की दुनिया के लिए अद्वितीय नहीं है।

— जॉब

1

इस तरह की व्यापक परियोजना की विफलता निजी संस्थानों की तुलना में सरकारी संस्थानों में अधिक होती है, या कम से कम यह समाचारों में अधिक बार लगता है।

— Bratch

34

मुख्य कारण गुंजाइश में वृद्धि है , जिसे पुस्तक "द प्रोगैमैटिक प्रोग्रामर" के रूप में वर्णित किया गया है:

फूला हुआ
करतब
आवश्यकता रेंगना

यह उबला हुआ मेंढक सिंड्रोम का एक पहलू है।

विभिन्न "फुर्तीली" पद्धति का विचार प्रतिक्रिया में तेजी लाने और - उम्मीद है - समय में परियोजना के विकास को सही करता है।

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

इसका मतलब यह नहीं है कि आपके पास एक निश्चित रिलीज की तारीख होनी चाहिए, लेकिन इसका मतलब यह है कि आपको अपने प्रोग्राम के रनिंग वर्जन को बनाने / उसका मूल्यांकन / विमोचन करने के लिए हर समय सक्षम होना चाहिए।

ब्लॉग पोस्ट " लेट प्रोजेक्ट्स एक दिन में एक दिन देर से होते हैं " में कई और उदाहरण हैं:

मुझे पता है कि 'वास्तविक हो रही' बात यह है कि गुंजाइश को फ्लेक्स करना और लॉन्च की तारीख को तय करना होगा, लेकिन यह काम नहीं करता है अगर कार्यक्षमता पर सहमति है जो समय पर पूरा नहीं हो सकती है।

इसलिए हम ऐनक की वकालत नहीं करते हैं या "कार्यक्षमता पर सहमत हैं।" यह समस्या की जड़ है - कह रही है कि आपको इस बारे में सब कुछ पता है कि आपको क्या चाहिए और पहले पिक्सेल के रंग या कोड की लाइन लिखे जाने से पहले ही इसे कैसे लागू किया जाना चाहिए। ।

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

— VonC
स्रोत

1

मैं इसे उत्तर के रूप में चिह्नित कर रहा हूं, हालांकि अच्छे अंक अन्य पदों पर भी हैं। मैं सहमत हूं कि बड़ी परियोजनाओं के लिए "रिलीज मैनेजमेंट" पर ध्यान देना बहुत महत्वपूर्ण है।

— सॉफ्टवेयड

29

आमतौर पर परियोजना की जटिलता को कम करके आंका जाता है ।

— अमीर रज़ाई
स्रोत

2

+1: हालाँकि मैंने कहा है कि शायद कम ही आंका जा सकता है

— केन हेंडरसन

@Confused मुझे "गलत समझा" पसंद है । मुझे कभी नहीं पता था कि यह शब्द इतना पुराना था!

— मार्क सी

फिर मैं अपने सवाल में जोड़ूंगा "जटिलता को कम करके आंका क्यों जाता है?"। गुंजाइश और जटिलता का अनुमान एसडीएलसी का हिस्सा है। इसलिए मुझे कम आंकना एक लक्षण है, कोई कारण नहीं।

— सॉफ्टवेयड

2

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

— अमीर रज़ाई

2

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

— चार्ल्स साल्विया

18

स्टीव मैककोनेल ("कोड कम्प्लीट" प्रसिद्धि की) में क्लासिक गलतियों की एक सूची है ।

कुछ अप्रभावी विकास प्रथाओं को इतनी बार चुना गया है, इतने सारे लोगों द्वारा, इस तरह के पूर्वानुमान के साथ, खराब परिणाम हैं कि वे "क्लासिक गलतियों" के लायक हैं ...

यह खंड तीन दर्जन क्लासिक गलतियों की गणना करता है। मैंने व्यक्तिगत रूप से इनमें से प्रत्येक गलती को कम से कम एक बार देखा है, और मैंने उनमें से कई को खुद बनाया है ...

इस सूची में आम भाजक यह है कि यदि आप गलती से बचते हैं, तो जरूरी नहीं कि आप तेजी से विकास प्राप्त करें, लेकिन यदि आप इसे नहीं टालेंगे तो आपको निश्चित रूप से धीमा विकास मिलेगा।

संदर्भ में आसानी के लिए, सूची को लोगों के विकास-गति आयामों, प्रक्रिया, उत्पाद और प्रौद्योगिकी के साथ विभाजित किया गया है।

लोग

# 1: निर्विवाद प्रेरणा ...

# 2: कमजोर कर्मियों ...

# 3: अनियंत्रित समस्या कर्मचारी ...

# 4: हीरोइक्स ...

# 5: लोगों को देर से प्रोजेक्ट में जोड़ना ...

# 6: शोरगुल, भीड़ भरे कार्यालय ...

# 7: डेवलपर्स और ग्राहकों के बीच घर्षण ...

# 8: अवास्तविक उम्मीदें ...

# 9: प्रभावी परियोजना प्रायोजन की कमी ...

# 10: हिस्सेदारी खरीदने वालों की कमी ...

# 11: उपयोगकर्ता इनपुट की कमी ...

# 12: पदार्थ पर राजनीति ...

# 13: इच्छाधारी सोच ...

प्रक्रिया

# 14: अत्यधिक आशावादी कार्यक्रम ...

# 15: अपर्याप्त जोखिम प्रबंधन ...

# 16: ठेकेदार की विफलता ...

# 17: अपर्याप्त योजना ...

# 18: दबाव में योजना का परित्याग ...

# 19: फ़ज़ी फ्रंट एंड के दौरान समय बर्बाद। "फ़ज़ी फ्रंट एंड" परियोजना शुरू होने से पहले का समय है, जो समय सामान्य रूप से अनुमोदन और बजट प्रक्रिया में खर्च होता है ...

# 20: अपस्ट्रीम अपस्ट्रीम गतिविधियाँ ... जिसे "कोडिंग में कूदना" के रूप में भी जाना जाता है ...

# 21: अपर्याप्त डिजाइन ...

# 22: अल्पकालिक गुणवत्ता आश्वासन ...

# 23: अपर्याप्त प्रबंधन नियंत्रण ...

# 24: समय से पहले या बहुत अधिक अभिसरण। किसी उत्पाद के रिलीज़ होने से कुछ समय पहले, उत्पाद को रिलीज़ के लिए तैयार करने के लिए एक धक्का होता है - उत्पाद के प्रदर्शन में सुधार करना, अंतिम दस्तावेज़ प्रिंट करना, अंतिम मदद-सिस्टम हुक शामिल करना, इंस्टॉलेशन प्रोग्राम को पॉलिश करना, कार्यशीलता को रोकना जो कि होने वाली नहीं है समय पर तैयार, और इतने पर ...

# 25: अनुमानों से आवश्यक कार्यों को पूरा करना ...

# 26: बाद में पकड़ने की योजना ...

# 27: कोड-जैसे-नरक प्रोग्रामिंग। कुछ संगठनों का मानना है कि तेज, ढीले, सभी के रूप में आप जाना कोडिंग तेजी से विकास के लिए एक मार्ग है ...

उत्पाद

# 28: आवश्यकताएँ सोना चढ़ाना। कुछ परियोजनाओं की शुरुआत से ही उनकी आवश्यकता से अधिक आवश्यकताएं हैं ...

# 29: फ़ीचर क्रीप ...

# 30: डेवलपर सोना चढ़ाना। डेवलपर्स नई तकनीक से रोमांचित हैं और कभी-कभी नई सुविधाओं को आज़माने के लिए उत्सुक हैं ... - चाहे उनके उत्पाद में इसकी आवश्यकता हो या न हो ...

# 31: मुझे धक्का दो, बातचीत से मुझे खींचो ...

# 32: अनुसंधान-उन्मुख विकास। क्रे सुपर कंप्यूटर के डिजाइनर सीमोर क्रे का कहना है कि वह एक समय में दो से अधिक क्षेत्रों में इंजीनियरिंग की सीमा को पार करने का प्रयास नहीं करते हैं क्योंकि विफलता का जोखिम बहुत अधिक है (गिल्ब 1988)। कई सॉफ्टवेयर प्रोजेक्ट क्रे से सबक सीख सकते हैं ...

प्रौद्योगिकी

# 33: सिल्वर-बुलेट सिंड्रोम ...

# 34: नए टूल या तरीकों से बचत को कम करके आंका गया ... जब पिछली परियोजनाओं के कोड का पुन: उपयोग किया जाता है तो ओवरस्टीमेटेड बचत का एक विशेष मामला सामने आता है ...

# 35: किसी प्रोजेक्ट के बीच में टूल स्विच करना ...

# 36: स्वचालित स्रोत-कोड नियंत्रण की कमी ...

— gnat
स्रोत

वैसे, बधाई!

— मार्क C

14

बड़ी परियोजना = अधिक जटिलता
अधिक जटिलता = अधिक अनिश्चितताएं
अधिक अनिश्चितताएं = अनुमान
लगाने में कठिन अनुमान
लगाना

— JohnFx
स्रोत

लेकिन "खराब अनुमान" हमेशा बहुत कम अनुमान क्यों लगाते हैं?

— रोमानोजो

मेरे अनुभव में, दो बातें। अनुमान लगाने वाला व्यक्ति बातचीत करने की कोशिश करता है और देने वाला व्यक्ति दबाव में झुक जाता है। दूसरे, अनुमान देने वाला व्यक्ति यह नहीं पहचानता कि टास्क स्विचिंग और संचार में कितना फ्लोट समय शामिल है। इसके अलावा, वे इस गलत धारणा के तहत काम करते हैं कि काम सभी प्रोग्रामिंग है, लेकिन बहुत सारे परियोजना प्रबंधन संचार समय हैं जिनके लिए जिम्मेदार होना चाहिए।

— JohnFx

12

मैं बोली प्रक्रिया को दोष देता हूं। यह उस समूह को पुरस्कृत करता है जो सौदे को कागज पर सबसे सस्ता / तेज कर सकता है।

एक साथ बिड लगाने वाले लोग अपना समय बर्बाद नहीं करना चाहते हैं यदि उनके पास जीतने का कोई मौका नहीं है, इसलिए उनके सामान्य अनुमानों को ताक पर रख दिया जाता है। मैं ऐसे लोगों को जानता हूं जिन्होंने $ 80 बचाने के लिए POE स्विच के बजाय सामान्य स्विच निर्दिष्ट किए हैं। लेकिन परियोजना को पीओई की आवश्यकता थी क्योंकि इसमें आईपी कैमरे थे। वह $ 80 खर्च किए जाने की जरूरत है, लेकिन अब यह कल्पना के बाहर है।

मेरा दृढ़ विश्वास है कि 2 महीने की $ 2,000,000 परियोजना में अभी भी 2 महीने $ 2,000,000 लगेंगे, चाहे आपको कितनी भी बोलियाँ मिलें। अगर आपको लगता है कि यह करना सही है तो महंगा है, इंतजार करें और देखें कि यह गलत करना कितना महंगा है।

— रेक्स एमकॉनटन
स्रोत

मैं वाक्य नहीं समझ सकता, "मुझे एक दृढ़ विश्वास है ..." - इसके बजाय दूसरे भाग को "2 महीने और $ 2M ..." पढ़ना चाहिए?

— मार्क सी

6

एक संभावित कारण यह है कि अनुमान छोटी परियोजनाओं पर आधारित होते हैं, परियोजना के आकार के साथ लागत में रैखिक वृद्धि को मानते हुए, जब वास्तव में लागत में वृद्धि होती है जैसे कि बढ़ती जटिलता, लंबी परियोजना अवधि (आवश्यकता परिवर्तन के लिए अधिक समय) आदि के कारण द्विघात अनुमान है। कठिन, और परियोजना जितनी बड़ी होती है, उतना ही सही ढंग से अनुमान लगाना कठिन हो जाता है।

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

— user281377
स्रोत

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

— टॉम एंडरसन

4

लागत 'प्रबंधन' की दृष्टि में अनुसूची का प्रस्ताव नहीं रखती है जो कि एक महत्वपूर्ण अंतर है। जैसा कि हम जानते हैं, "नौ महिलाएं एक महीने में एक बच्चा नहीं बना सकती हैं" , फिर भी आप आश्चर्यचकित होंगे कि कितने लोग सोचते हैं कि धन की राशि के संबंध में समस्याओं की गहराई में कमी आती है। खराब परियोजना प्रबंधन, अक्सर सूक्ष्म प्रबंधन के रूप में खुद को प्रकट करना सबसे अधिक परियोजनाओं के टंकीकरण (मेरे अनुभव में) का प्रमुख कारण है। माइक्रो प्रबंधन में किक मारता है जब 'प्रबंधन' को पता चलता है कि कुछ नियंत्रण से बाहर हो रहा है और वे क्यों के रूप में संघर्ष कर रहे हैं।

जब यह कारण नहीं होता है, तो परियोजना का अपेक्षित परिणाम संभवत: शुरू करने के लिए संभव नहीं था। मेरे अनुभव में, अगर किसी परियोजना का समय सीमा बहुत कम है, तो लोग ऐसी गलतियाँ करने से डरते हैं, जिनके परिणामस्वरूप 'दोहरा काम' हो जाता है, क्योंकि उन्हें किसी भी चीज़ का अधिक लाभ नहीं मिलता है।

यही कारण है कि प्रबंधन को अनुभवी कार्यक्रमों के साथ आबाद किया जाना चाहिए, जिनके पास सफल परियोजनाओं का निर्माण करने वाली अग्रणी टीमों का इतिहास है। ऐसा व्यक्ति संभव राजस्व के बावजूद "कोई रास्ता नहीं है कि हम जिम्मेदारी से कर सकता है" कह सकते हैं, और लंबे समय तक प्रबंधन में नहीं होंगे, यही वजह है कि हम में से कई (अंततः) पीएचडी के बजाय एमबीए का जवाब देते हैं।

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

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

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

— संशोधित करता है
स्रोत

3

अधिकांश समय दो या दो से अधिक का संयोजन होता है:

विभागों के बीच सहयोग की समस्या
राजनीति ... बहुत ज्यादा राजनीति ...
गलत टीम
अवास्तविक समय-निर्धारण
उपयुक्त कार्यप्रणाली के बिना गुंजाइश बदलना
लापता होने का संकेत

इस विषय पर अच्छी पुस्तक: डेथ मार्च ।

— user2567
स्रोत

3

लोग सोचते हैं कि सॉफ्टवेयर विकास एक पूर्वानुमान प्रक्रिया है, जो एक साल पहले चीजों को मापने और अनुमान लगाने की कोशिश कर रहा है। यह संभव नहीं है! बिल्डिंग सॉफ्टवेयर बोल्ट निर्माण नहीं है।

उसी "प्रवृत्ति" के बाद, वे एक विशाल एनालिसिस (फिर से एक वर्ष आगे) करने की कोशिश करते हुए सोचते हैं कि वे सभी संभावनाओं को कवर करेंगे, और बाद में प्रोग्रामर को केवल टाइपिस्ट में बदल देंगे। कैसे लगता है कि यह काम कर सकता है? इस तरह का व्यवहार सिर्फ बुरे अनुमानों और नौकरशाही के बहुत सारे मामलों को जन्म देता है।

— फर्नांडो
स्रोत

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

— कोनफोर्सफैन

3

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

— वेन कॉनराड को दर्शाता है
स्रोत

2

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

मैं बड़ी प्रणालियों में आया हूं जो समय पर आया था ( परियोजना के दौरान अनुसूची एक बार और केवल एक बार चली गई) और कल्पना पर (मेरे पास बजटीय जानकारी तक कोई पहुंच नहीं थी क्योंकि हम कई आपूर्तिकर्ताओं में से सिर्फ 1 थे)। एक जो मुझे अभी भी प्रभावित करता है (और मैंने इस साइट पर इसके बारे में थोड़ा सा लिखा है) एक बड़े (भाग्य 500 के पहले 100 में) वित्तीय ग्राहक के लिए एक बड़ी एकीकृत ग्राहक प्रबंधन प्रणाली थी। मेरा अनुमान है कि उन्होंने कॉन्फ्रेंस कॉल के दौरान लोगों के वेतन पर $ 100k / दिन (एक वर्ष से अधिक के लिए) उड़ा दिया।

बैगेज हैंडलिंग सिस्टम के मामले में, सॉफ्टवेयर मैनेजरों ने कहा "इस आकार और जटिलता की परियोजनाओं के आधार पर, इस सिस्टम को बनाने और डिबग करने में 4 साल लगेंगे।" बिक्री और कार्यकारी प्रबंधकों ने कहा "हवाई अड्डे 2 साल में खुलता है, हमने ग्राहक को बताया कि इसमें 2 साल लगेंगे, इसलिए आपके पास इसे करने के लिए 2 साल हैं।" यह देखने के लिए कि क्या आप एक प्रोग्रामर या मिसमैनेजर हैं, परीक्षा निम्नलिखित प्रश्न का सरल उत्तर है: "क्या बैगेज हैंडलिंग सिस्टम देर से या समय पर आया था?"

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

— Tangurena
स्रोत

2

वास्तविकता की धारणा

यहाँ इस समस्या का सबसे अच्छा वर्णन है जो मैंने कभी पाया है। Businessballs.com से ट्री स्विंग

मुझे " प्रोग्रामिंग की वास्तविकता" की अवधारणा पर शुरू किया गया था, जो कि मेरी प्रोग्रामिंग कारर थी। इसके लिए मैं तहेदिल से आभारी हूं। मेरा मानना है कि यह सबसे बड़ा कारण है कि कोई भी परियोजना विफल हो जाती है, न कि केवल आईटी परियोजनाएं।

— माइकल रिले - उर्फ गनी
स्रोत

2

विफलताओं का एक कारण यह है कि एक बड़ी परियोजना आमतौर पर एक हाई-प्रोफाइल, महत्वपूर्ण-से-व्यावसायिक परियोजना है। जब परियोजनाएं और कार्य हाई-प्रोफाइल होते हैं, तो यह लोगों को झूठ बोलने के लिए प्रोत्साहित करता है।

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

इत्यादि इत्यादि।

मैं कई साल पहले एक परियोजना पर था, एक ग्राहक के लिए। बोली और परियोजना की योजना पूरी होने के बाद मुझे लाया गया था। लगातार तेज, तेज और हास्यास्पद लागत काटने के फैसले, कर्मचारियों की भारी ओवरलोडिंग, उनके लिए कोई संसाधन नहीं होने का लगातार दबाव था; कोई डेस्क, कंप्यूटर, कुछ भी।

अंत में, मुझे पता चला कि इस परियोजना पर 7 महीने और 16 मिलियन डॉलर की बोली लगाई गई थी। मैंने एक लिफाफे के पीछे अनुमान लगाया कि यह 24 महीने और 50 से 100 मिलियन होना चाहिए। मैंने अपने प्रबंधक और उनके प्रबंधक के साथ एक बैठक की, और अपना मामला प्रस्तुत किया, और समय या बजट देने के दौरान हम कहीं भी नहीं आ रहे थे; उन्होंने सभी समस्याओं का समाधान किया। बैठक के अंत में सीआईओ ने कॉल किया और मूल बोली में दोष के अपवाद के साथ इन दोनों प्रबंधकों को अनिवार्य रूप से बताया जो मैंने कहा था।

मेरे पास प्रोजेक्ट को रोल करने का एक मौका था जब उन्होंने प्रौद्योगिकियों को एक में बदल दिया जो मैं कुशल नहीं था। मैंने बहुत बाद में किसी से बात की। जब परियोजना लगभग आधी हो गई तो रद्द कर दी गई ... 12 महीने और 35 मिलियन डॉलर पर।

हाई प्रोफाइल बड़े प्रोजेक्ट लोगों को यह कहते हुए हतोत्साहित करते हैं, "यह एक गलती है"। गलतियों को बर्दाश्त नहीं किया जाता है।

— रॉन रूबल
स्रोत

1

VonC के उत्तर पर थोड़ा विस्तार:

इस बड़ी परियोजनाओं में एक "सभी या कुछ नहीं" मानसिकता है। परिभाषित परियोजना को एक ही बार में जारी किया जाना है - अक्सर क्योंकि यह एक मौजूदा प्रणाली से एक बदलाव है।

इसका मतलब यह है कि फीचर / आवश्यकता रेंगना की समस्याओं को संबोधित करना कठिन होता है, इसलिए जब परियोजना को फलित होता है तो इसे अक्सर बैठक की आवश्यकताओं के रूप में नहीं देखा जाता है। यदि मौजूदा सिस्टम को अपडेट कर दिया गया है या इस बीच तकनीक आगे बढ़ गई है तो इसे समाप्त किया जा सकता है।

इसका क्या हल है?

मैं वास्तव में नहीं जानता कि कोई भी दो प्रणालियों को दो के बीच विभाजित कार्यों के बदलते सेट के साथ समानांतर में चलाना चाहता है।

— ChrisF
स्रोत

1

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

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

— चार्ल्स ई। ग्रांट
स्रोत

1

एक ऐसा कारक जिसे अभी तक छुआ गया है, लेकिन अभी तक संबोधित नहीं किया गया है:

बस के बारे में सभी नाटकीय विफलताओं अनुबंध थे कि बोली लगाई गई थी। ऐसी स्थिति में एक सक्षम कंपनी का क्या होता है? वे एक यथार्थवादी अनुमान लगाते हैं और इस प्रकार लगभग निश्चित रूप से किसी ऐसे व्यक्ति के अधीन होते हैं जिन्होंने खराब अनुमान लगाया था।

अगर कंपनी ठीक से अनुमान नहीं लगा सकती है तो क्या यह आश्चर्य की बात है कि वे एक सिस्टम भी ठीक से नहीं बना सकते हैं?

— लोरेन Pechtel
स्रोत

वे अच्छी तरह से ठीक से अनुमान लगाने में सक्षम हो सकते हैं, लेकिन बोली प्राप्त करेंगे और फिर बोली खोने की तुलना में लागत और शेड्यूल ओवररन के लिए जा सकते हैं। बेशक, यह बेईमान विक्रेताओं के लिए चयन करता है।

— डेविड थॉर्नले

एक सामान्य रणनीति उच्च गुणवत्ता टीम के साथ लागत पर जाना है। एक बार अनुबंध के जीतने के बाद, परिवर्तन नियंत्रण और रखरखाव पर पैसा बनाया जा सकता है (उत्तरार्द्ध आमतौर पर मूल परियोजना की तुलना में बहुत अधिक है) और कम महंगे कर्मचारियों को प्रतिस्थापित करके।

— माइकल ग्राज़ेब्रुक

0

माइकल Krigsman पर ZDNet पर एक ब्लॉग " आईटी परियोजना विफलताओं ," के लिए समर्पित है कि यहाँ ब्याज की हो सकती है।

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

— जेबी किंग
स्रोत

0

फुर्तीली परियोजनाओं के इन प्रकार में इस्तेमाल किया जा सकता है या पारंपरिक दृष्टिकोण अभी भी सबसे अच्छा है।

कारण है कि अच्छी तरह से लागू चुस्त प्रक्रियाओं इस समस्या से ग्रस्त नहीं लगते क्योंकि एक सरल कारण के लिए है। आप एक बड़े प्रोजेक्ट को फुर्तीले तरीके से शुरू नहीं कर सकते। आप एक या दूसरे को चुन सकते हैं।

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

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

अनिवार्य रूप से, बड़ी परियोजनाएं विफल हो सकती हैं क्योंकि उनका लक्ष्य सभी संभावित ग्राहकों की सभी समस्याओं को हल करना है। एक फुर्तीली परियोजना का यह लक्ष्य कभी नहीं होता है, इसके बजाय प्रत्येक संस्करण में एक ही ग्राहक को एक महत्वपूर्ण समस्या हो सकती है। हालांकि, एक लंबे समय के बाद, एक फुर्तीली परियोजना ग्राहकों की एक बहुत कुछ के लिए महत्वपूर्ण मुद्दों का समाधान हो सकता है।

— SingleNegationElimination
स्रोत

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

— माइकल ग्राज़ेब्रुक

0

वास्तविक उपयोगकर्ताओं को जहाज करने में विफलता

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

लागत का सही अनुमान लगाने में विफलता

अगर परियोजनाओं को लगता है कि वे निवेश पर अपनी वापसी को आगे बढ़ाएंगे, तो वे रद्द हो जाते हैं।

गुणवत्ता को नियंत्रित करने में विफलता

पर्याप्त दोषों के साथ आगे की गति शून्य या उससे नीचे गिरना संभव है। बिना किसी प्रगति के, निरंतर अस्तित्व के लिए तर्क करना कठिन है।

— जोएरी सेब्रेट्स
स्रोत

0

वे हॉफस्टैटर के नियम को भूल गए: यह हमेशा आपकी अपेक्षा से अधिक समय लेता है, तब भी जब आप हॉफस्टैटर के नियम को ध्यान में रखते हैं।

— ब्रायन कार्लटन
स्रोत

0

वेब डेवलपमेंट में जो चीजें मैंने देखी हैं:

बहुत सारे रसोइए - मेजर बी एंड एम रिटेलर जहां जोर अचानक वेब पर स्थानांतरित हो गया। नए हेड पनीर को प्रभावित करने के लिए अचानक 20 विभाग प्रमुख हर पहल को अंजाम दे रहे हैं। मुझे एक बार नए आइकन लागू करने पड़े क्योंकि कानूनी रूप से पुराने लोगों के लुक को पसंद नहीं किया गया था।
लक्ष्यों को प्राप्त करने से अधिक मेल खाने वाले चश्मे पर अधिक ध्यान दें - "IE6 की तुलना में IE6 के आइकन थोड़े फीके हैं। कृपया उस लॉन्च-डेट-क्रिटिकल काम को छोड़ दें जो आप कर रहे हैं और हमारे ग्राहक आधार के .05% भाग लेने के लिए भयानक चीजें करते हैं जो दिन लगेंगे लागू करने और IE के अनुभव को और भी धीमा करने के लिए। "
खराब उपकरण जो गैर-देवों द्वारा उठाए गए हैं, जिन्हें सलाह के लिए अपने घर के देवों से पूछने के लिए भी परेशान नहीं किया जा सकता है।
उपकरणों द्वारा उठाए गए बुरे देवता - "क्यों हम 20 सक्षम जावा का भुगतान करते हैं, जब हम 200 बमुश्किल कोड साक्षर लोगों को आउटसोर्स कर सकते हैं जो संस्करण नियंत्रण का उपयोग करने के लिए बहुत कम जानते हैं?" जैसा कि वे एक साथ और विभिन्न देशों के लोगों के साथ, मुख्य रूप से 3 बड़े ऐप के लिए बैक-एंड पर काम करते हैं।
खराब / टूटा हुआ आर्किटेक्चर - घबराए हुए लोगों की परतों पर परतें, ऐसा-किया-कल कोड, जो लोग निकाल दिए गए थे या अब प्रबंधक हैं।

— एरिक रेपेन
स्रोत