खरबों डॉलर झोंकने के बाद भी बार-बार विफल होने वाली बड़े पैमाने की सॉफ़्टवेयर परियोजनाएँ

• 2005 के बाद से दुनिया भर में IT खर्च तीन गुने से भी ज़्यादा बढ़ा है, लेकिन बड़े सॉफ़्टवेयर प्रोजेक्ट्स की सफलता दर में लगभग कोई सुधार नहीं हुआ है
• कनाडा की Phoenix payroll system, ब्रिटेन की Post Office Horizon, और अमेरिका व ऑस्ट्रेलिया की welfare और administrative systems में प्रबंधन, संगठन और नैतिक विफलताएँ बार-बार दोहराई गईं
• AI tools या copilot इन समस्याओं को हल नहीं कर सकते; मानवीय कल्पनाशक्ति की कमी, अवास्तविक लक्ष्य, और risk management की विफलता अब भी मुख्य कारण हैं
• legacy systems की maintenance cost IT बजट का 70~75% खा जाती है, और Agile·DevOps अपनाने पर भी organizational leadership और cultural change के बिना विफलता दर ऊँची रहती है
• बार-बार होने वाली management mistakes और जवाबदेही से बचना सामाजिक लागत को बढ़ाते हैं, और पारदर्शिता, नैतिकता, तथा human-centered system design को अनिवार्य कार्य के रूप में सामने लाते हैं

---

सॉफ़्टवेयर विफलता की लगातार बनी रहने वाली समस्या

• पिछले 20 वर्षों में IT खर्च 1.7 ट्रिलियन डॉलर से बढ़कर 5.6 ट्रिलियन डॉलर हो गया, लेकिन सॉफ़्टवेयर सफलता दर ठहरी हुई है
  • विफलता देश, उद्योग या संगठन के प्रकार की परवाह किए बिना होती है
  • विफलता की सामाजिक और आर्थिक लागत लगातार बढ़ रही है
• साफ़ तौर पर कहा गया है कि AI प्रबंधन की समस्याएँ हल नहीं कर सकता
  • बड़े प्रोजेक्ट्स के जटिल हितधारकों और राजनीतिक कारकों को AI के लिए नियंत्रित करना कठिन है
  • IT projects में पहले से ही अतार्किक निर्णय-प्रक्रिया इतनी अधिक है कि AI के सीखने लायक उदाहरण भी कम हैं
• विफलता के कारणों में मानवीय कल्पनाशक्ति की कमी, अस्पष्ट लक्ष्य, जटिलता को संभालने में असफलता, और जोखिम नियंत्रण का अभाव शामिल हैं
  • दशकों से वही कारक दोहराए जा रहे हैं, जिससे “failure déjà vu” जैसी स्थिति बनी हुई है

कनाडा का Phoenix payroll system

• 2016 में शुरू किया गया CA$310 million का Phoenix system 80,000 payroll rules और 105 union agreements को एकीकृत करने की कोशिश में विफल रहा
  • बजट बचाने के लिए testing और pilot प्रक्रियाएँ घटाई गईं, और core functions तक हटा दिए गए
• नतीजतन 9 वर्षों में 4.3 लाख कर्मचारियों में से 70% ने payroll errors का अनुभव किया
  • मार्च 2025 तक 3,49,000 errors अनसुलझे थे, जिनमें आधे से ज़्यादा 1 साल से अधिक समय से लंबित थे
  • कर्मचारियों की आत्महत्या के मामले तक रिपोर्ट हुए
• कुल लागत CA$5.1 billion से अधिक रही, और auditor general ने इसे “project management और oversight की अकल्पनीय विफलता” कहा

ब्रिटेन का Post Office Horizon system

• 1999 में लागू किया गया Fujitsu का Horizon POS system अपनी आंतरिक त्रुटियों को छिपाते हुए 3,500 branch managers पर झूठे accounting और fraud के आरोप लगवाने का कारण बना
  • 900 लोग दोषी ठहराए गए, 236 को जेल हुई, और 13 से अधिक ने आत्महत्या की
• तकनीकी, प्रबंधकीय, कानूनी और नैतिक विफलताएँ मिलकर काम करती रहीं
  • bug-भरा middleware, अनियंत्रित scope expansion, अपर्याप्त testing, और staffing की कमी
  • management ने समस्या उठाने वालों के प्रति शत्रुतापूर्ण रवैया अपनाया, सबूत छिपाए, और संगठित cover-up की कोशिश की
• 2016 और 2021 में replacement की कोशिशें भी विफल रहीं, और अब भी Horizon का उपयोग हो रहा है
  • नए system का बजट £410 million है, और जुलाई 2026 में निर्णय तय है

अन्य प्रमुख विफलता के मामले

• Minnesota MNLARS: 2016 में शुरू, 2019 में रद्द, लागत $100 million
• Australia Modernising Business Registers: AU$480 million का बजट बढ़कर AU$2.8 billion हुआ, 2022 में रद्द
• Louisiana vehicle registration system: 50 साल पुराने mainframe की बार-बार विफलता से 2025 में आपातस्थिति घोषित
• Jaguar Land Rover: 2025 के cyberattack के बाद एक महीने से ज़्यादा समय तक वैश्विक operations बंद, नुकसान $1.2~1.9 billion
• Lidl ERP: SAP-आधारित €500 million ERP विफल होने के बाद अपने पुराने system पर वापसी (2017)
• Boeing 737 Max: MCAS design defect से 346 मौतें, कुल लागत का अनुमान $74 billion
• F-35 Block 4 upgrade: timeline 5 साल देर से, लागत $10.5 billion से बढ़कर $16.5 billion

विफलता की आर्थिक लागत

• अमेरिका में 2022 में software failure की लागत $1.81 trillion रही, जिसमें development failure $260 billion था
  • कुल राशि defense budget ($778 billion) से भी बड़ी है
• legacy systems की maintenance cost सालाना $520 billion है, जो IT budget का 70~75% है
  • replacement cost ऊँची होने और failure risk ज़्यादा होने से बदलाव टलता रहता है
• NTT DATA 2024 report: 80% संगठनों ने कहा कि पुरानी technology innovation में बाधा डालती है
  • अधिकतर executives मानते हैं कि legacy infrastructure market response को बाधित करता है

Agile·DevOps की सीमाएँ

• iterative और incremental development के फैलने के बावजूद विफलता दर बनी हुई है
  • कुछ reports में Agile projects की failure rate 65% और DevOps की 90% तक बताई गई है
• सफल adoption के लिए leadership, organizational discipline, training, और cultural change ज़रूरी हैं
  • लेकिन अधिकतर संगठन इन्हें बनाए नहीं रख पाते

बार-बार दोहराई जाने वाली प्रबंधन गलतियाँ और सीखने का अभाव

• IT project managers अक्सर “हमारा project अलग है” कहकर पिछली विफलताओं से मिले सबक को नज़रअंदाज़ करते हैं
  • कनाडा सरकार ने 1995 की पहली payroll system विफलता से मिले सबक को Phoenix में फिर दोहराया
• अधिकांश विफलताएँ नवोन्मेषी प्रयासों से अधिक साधारण management mistakes से पैदा होती हैं
  • यह “creative destruction” से ज़्यादा “financial destruction” के करीब है
• AI-आधारित administrative systems की विफलताओं के उदाहरण
  • अमेरिका का MiDAS unemployment benefits system और ऑस्ट्रेलिया का Centrelink Robodebt गलत algorithm के कारण लाखों लोगों पर अनुचित कार्रवाई का कारण बने
  • सरकारों ने त्रुटि स्वीकारने और मुआवज़ा देने में उदासीन रवैया दिखाया

जवाबदेही, नैतिकता और पारदर्शिता की ज़रूरत

• AI-embedded systems की अस्पष्ट decision-making नागरिकों के अधिकारों के हनन का खतरा पैदा करती है
  • EU ने ‘algorithmic decisions के लिए explanation का अधिकार’ कानूनी रूप से सुनिश्चित किया है
  • दुनिया भर में automated systems की transparency और accountability को मानवाधिकार के रूप में स्थापित करने की ज़रूरत बताई जा रही है
• software liability law और professional licensing पर चर्चा है, लेकिन इनके लागू होने की संभावना कम दिखती है
• अधिक यथार्थवादी विकल्प है management की ईमानदारी, आलोचनात्मक सोच, और नैतिक निर्णय-क्षमता को मजबूत करना
  • जोखिमों को स्पष्ट रूप से पहचानना और vendors के बढ़ा-चढ़ाकर किए गए वादों से सावधान रहना ज़रूरी है
  • AI सहित सभी IT systems पर human-centered design principles लागू करने पर ज़ोर दिया गया है

निष्कर्ष: बार-बार की जा रही गलतियों को कब रोका जाएगा

• सॉफ़्टवेयर development मूल रूप से जटिल और नाज़ुक है, और छोटी गलतियाँ बड़े परिणाम दे सकती हैं
• सफल projects के लिए पर्याप्त संसाधन, leadership, और accountability अनिवार्य हैं
• users पर पड़ने वाली भावनात्मक और आर्थिक क्षति को भी लागत-आकलन में शामिल करना चाहिए
• 1968 के “software crisis” के बाद 50 से अधिक वर्षों से वही गलतियाँ दोहराई जा रही हैं
  • “नई गलतियाँ कीजिए”

  “हर कोई गलती कर सकता है, लेकिन केवल मूर्ख ही अपनी गलती पर अड़ा रहता है” - रोम के वक्ता Cicero

[GN⁺]

Hacker News प्रतिक्रिया

• लेख के आख़िरी हिस्से में दिया गया समाधान थोड़ा कमजोर लगा।
  मेरे हिसाब से असली समाधान है छोटे स्तर से शुरू करना और वास्तविक production environment में उसे validate करना।
  उदाहरण के लिए, अगर देशव्यापी payroll system बनाना हो, तो पहले 50 लोगों वाले किसी छोटे कस्बे में उसे टेस्ट करना चाहिए, bugs ठीक करने चाहिए, और फिर धीरे-धीरे बड़े शहरों तक विस्तार करना चाहिए।
  छोटे पैमाने पर समस्याएँ हल किए बिना एक ही बार में राष्ट्रीय स्तर पर जाने वाला software development process जैसी कोई चीज़ नहीं होती।

  • जब मैंने एक बड़े retail chain में POS system replacement project पर काम किया था, तो हमने पहले सिर्फ़ कंपनी कैफेटेरिया और clearance store—इन दो जगहों पर ही early deployment किया था।
    transaction volume कम था, इसलिए समस्या आने पर उसे manually संभाला जा सकता था, और PCI compliance से भी बचा जा सकता था।
    असली stores में rollout से पहले इस तरह की testing की वजह से हम बिना किसी बड़े incident के deadline पूरी कर पाए।
    अगर शुरुआत से ही इसे customer-facing stores में deploy किया होता, तो tax calculation errors या performance issues की वजह से बड़ा हंगामा हो सकता था।
  • यह तरीका product के लिए तो ठीक है, लेकिन system के लिए इसकी सीमाएँ हैं।
    incremental scaling अक्सर technical debt बढ़ाती है, और अंत में कोई भी codebase के core को लेकर आश्वस्त नहीं रहता, इसलिए टीम rewrite के डर में फँस जाती है।
    WhatsApp जैसे अपेक्षाकृत simple product के लिए भी शुरुआत से large-scale scalability को ध्यान में रखकर engineering design चाहिए।
  • असली बात है ऐसे एक व्यक्ति का होना जो पूरे system को समझता हो।
    छोटे और सफल systems में ऐसे लोग बन पाना आसान होता है, और वे users और developers दोनों का trust जीतकर system को धीरे-धीरे बढ़ा सकते हैं।
    बड़े projects में failure की संभावना ज़्यादा होती है, इसलिए Precautionary Principle के हिसाब से छोटे स्तर से शुरुआत करनी चाहिए।
  • आख़िरकार ज़रूरत सादगी की है — Plan → Implement → Test → Repeat।
    किसी भी project की बुनियादी cycle यही है।
  • How Big Things Get Done में भी यही सिद्धांत ज़ोर देकर कहा गया है।
    छोटे स्तर से शुरू करो, modularize करो और फिर scale करो। Tesla की megafactory वाली मिसाल काफ़ी प्रभावशाली थी।

• तकनीकी इतिहास का अध्ययन करते हुए मुझे लगा कि hardware industry अतीत की सफलता और विफलता से सीखती है, लेकिन software industry ऐसा नहीं करती।
  ज़्यादातर developers पुराने systems को खोलकर समझना नहीं सीखते, और हर पीढ़ी वही समस्याएँ दोबारा झेलती है।

  • मैं एक बड़ी tech company में काम करता हूँ, और लगभग हर बड़े project के अंत में हमेशा अव्यवस्थित आख़िरी-मिनट की दौड़ शुरू हो जाती है।
    retrospective में हर बार यही पूछा जाता है कि “developers अगली बार क्या अलग करेंगे”, लेकिन managers कभी जवाबदेह नहीं ठहराए जाते।
    नतीजा यह कि वही समस्याएँ बार-बार दोहराई जाती हैं और उसका बोझ developers पर डाल दिया जाता है।
  • पीढ़ी बदलने के साथ developers सिर्फ़ पहले से मौजूद tech stack के ऊपर काम करते रहते हैं।
    पिछली पीढ़ियाँ समस्याएँ stack के निचले हिस्से में हल करती थीं, लेकिन अब लोग सिर्फ़ ऊपर की layers में समाधान ढूँढ़ते हैं।
    नतीजतन abstraction का tower बनता जाता है, resources ज़्यादा लगते हैं, लेकिन functionality लगभग वही रहती है।
    अब हम उस दौर में पहुँच रहे हैं जहाँ AI models के ऊपर software की एक और layer चढ़ाई जाएगी।
  • ERP जैसे बड़े systems पर लंबे समय तक काम करने के अनुभव से कहूँ, तो समस्या tools नहीं बल्कि काबिल project managers की कमी है।
    इसमें अनुभव और व्यक्तित्व दोनों मायने रखते हैं, और कम ego तथा problem-solving mindset ज़रूरी है।
    ज़्यादातर लोग project की complexity को कम करके आँकते हैं।
  • बहुत से developers code पढ़ना सीखते ही नहीं।
    graduate school के दौरान मैंने TinyOS का source code एक हफ़्ते तक पढ़कर उसकी structure समझी थी, और वह अनुभव बहुत काम आया।
    किसी अनजान codebase को तेज़ी से समझ लेने की क्षमता बेहद उपयोगी होती है।
  • तकनीक का तेज़ी से बदलना शायद जानबूझकर बनाया गया पैटर्न भी हो सकता है।
    अगर नई languages और frameworks समय-समय पर आती रहें, तो कंपनियाँ लगातार कम वेतन वाले नए hires ला सकती हैं।
    मुझे लगता है कि यही एक वजह है कि software को दूसरे engineering fields की तरह नहीं लिया जाता।

• बुनियादी तौर पर यह programming की नहीं, बल्कि अक्षम management की समस्या है।
  ज़्यादातर projects में business requirements साफ़-साफ़ defined ही नहीं होतीं, और सब कुछ अनुमान के आधार पर चलता है।

• बड़े public IT projects की विफलता को contract structure और incentives देखकर आसानी से समझा जा सकता है।
  समस्या यह है कि योग्यता से ज़्यादा time-billed consulting पर निर्भरता रहती है।
  सफल projects में technology से ज़्यादा inter-organizational alignment और competence अहम होते हैं।

  • आख़िरकार समस्या लोगों और राजनीति की है, software की नहीं।
  • अगर किसी के पास पढ़ने लायक literature या case studies हों, तो कृपया सुझाव दें।

• मुझे लगता है Silicon Valley में ageism सचमुच एक बड़ी समस्या है।
  अनुभव को नज़रअंदाज़ कर दिया जाता है, और अतीत के सबक़ बिल्कुल शामिल नहीं किए जाते।
  hardware industry ने विरासत का सम्मान करते हुए भी innovation जारी रखा।

  • लेकिन कुछ लोग कहते हैं कि “अनुभव को छोड़ देना evolution का हिस्सा है।”
    उनका मानना है कि जो लोग पुरानी विफलताओं से सीख चुके होते हैं, वे नए प्रयोग कर ही नहीं पाते।

• software projects आख़िरकार मानवीय विफलता की वजह से असफल होते हैं।
  perfect process या tools से ज़्यादा ज़रूरी हैं motivated और accountable लोग।
  लोगों के ठीक से काम करने के लिए कानूनी Consequences भी होने चाहिए।
  physical construction की तरह, हर चरण में independent verification और accountability तय होनी चाहिए।

  • लेकिन अगर जवाबदेही बहुत भारी हो जाए, तो कोई भी risk लेना नहीं चाहेगा।
    इसलिए व्यवहारिक दृष्टि से कुछ स्तर का जोखिम लेकर आगे बढ़ना पड़ता है।
  • 35 साल के अनुभव से कहूँ, तो विफलताओं की जड़ ज़्यादातर लोग और culture ही रहे हैं।
    सफल projects कुछ ऐसे लोगों की वजह से सफल हुए जिनमें emotional intelligence और leadership थी।
    आख़िरकार software engineering लोगों की समस्या है।
  • अगर कोई सचमुच engineer है, तो उसे engineering failure cases से सीखना चाहिए।
    लेकिन industry अब भी जवाबदेही से बचने और trends के पीछे भागने में फँसी हुई है।

• यह समस्या सिर्फ़ software तक सीमित नहीं है।
  Auburn Dam, Columbia River Crossing, Big Dig जैसे बड़े civil engineering projects भी budget overruns के लिए बदनाम हैं।

  • लेकिन “97% budget overrun” का मतलब हमेशा failure नहीं होता।
    अगर शुरुआती budget ही अवास्तविक था, तो वह सिर्फ़ वास्तविक लागत का सामने आना है।
    इसलिए छोटे projects से धीरे-धीरे scale करने वाला approach महत्वपूर्ण है।

• मैं न developer हूँ, न PM, लेकिन मुझे बड़े पैमाने की success stories जानने की जिज्ञासा थी।
  मैं hospital में काम करता हूँ, इसलिए healthcare से जुड़ी success stories हों तो और अच्छा होगा।
  The Phoenix Project पढ़कर मुझे Agile और DevOps mindset की थोड़ी समझ मिली, लेकिन उसे practical काम में लागू करना कठिन लगता है।
  मैं छोटे projects में सफलता के बीज बोना चाहता हूँ।

  • सबसे प्रतिनिधि success stories हैं Unix और Linux।
    Multics की जटिलता पर पुनर्विचार से शुरुआत हुई, और Ken Thompson ने सिर्फ़ 3 हफ़्तों में Unix खुद लिख दिया—यहीं से सब शुरू हुआ।
    संबंधित लेख देखें।
  • success को define करना महत्वपूर्ण है — deadline पूरी करना नहीं, बल्कि deployment के बाद लंबे समय तक value देना ही असली सफलता है।
    Conway’s Law, key personnel risk, स्पष्ट ownership, testing culture—ये सब भी ज़रूरी हैं।
    सबसे बढ़कर, “ना” कहने का साहस होना चाहिए।
  • Google Search और Facebook भी success stories हैं, लेकिन वे सरकारी projects की तरह शुरू से ही विशाल रूप में शुरू नहीं हुए थे।
    healthcare.gov जैसी मिसालें भी हैं, जहाँ शुरुआती विफलता के बाद सुधार हुआ।
  • भारत का UPI बड़े पैमाने की लगभग आदर्श success story है।
  • अमेरिका का Direct File project भी 94% लोगों द्वारा सकारात्मक रूप से आंका गया था।

• IT community को दोष देने से पहले कंपनियों की short-term profit वाली संस्कृति को देखना चाहिए।
  security और reliability हमेशा budget cuts की पहली शिकार बनती हैं।
  executives विफल होने पर भी golden parachute लेकर निकल जाते हैं, और जवाबदेही developers पर छोड़ जाते हैं।
  सरकारें भी कंपनियों की कमज़ोर security failures पर ठीक से सज़ा नहीं देतीं।
  आख़िर में वही निंदक यथार्थ दोहराया जाता है—“AI, consultants, outsourcing” से सब ठीक हो जाएगा।

• AI पर खरबों रुपये फूँक देने से स्थिति बेहतर नहीं होगी, बल्कि और खराब होगी।

  • जब AI bubble फटेगा, तो उसके बाद आर्थिक संकट और राजनीतिक अव्यवस्था आएगी।
    पश्चिमी समाज पहले से अस्थिर है और अतिदक्षिणपंथ की ओर झुक रहा है।
    अगला संकट सिर्फ़ financial collapse नहीं, बल्कि सामाजिक विघटन तक जा सकता है।
    मानवता को संकट के बजाय समझ के ज़रिए प्रगति की ओर बढ़ना चाहिए।
  • लेकिन AI मूल रूप से एक amplifier है।
    process अच्छा हो तो यह परिणामों को बेहतर बनाता है, और process खराब हो तो समस्याओं को तेज़ कर देता है।
    दिशा वही रहती है, बस रफ़्तार बढ़ जाती है।

[kgun9]

अगर इसे इतने लंबे समय तक ठीक नहीं किया गया, तो क्या यह डेवलपमेंट तकनीक या डेवलपमेंट सिद्धांतों की समस्या नहीं, बल्कि इसे अपनाने वाले ऑपरेशंस पक्ष की समस्या नहीं होगी...

[s0400615]

यूके पोस्ट ऑफिस स्कैंडल पर एक ड्रामा भी है.
अभी तक पीड़ितों को मुआवज़ा नहीं मिला है, इसलिए यह अब भी जारी है.

[t7vonn]

हाल की घरेलू मिसाल के तौर पर Gyeonggi Credit Guarantee Foundation के next-generation कंप्यूटिंग सिस्टम के निर्माण की विफलता का मामला याद आता है।

https://v.daum.net/v/20251111165048155

[pcj9024]

क्या दूसरे देशों में भी इतने बड़े SI प्रोजेक्ट चलाए जाते हैं?