IT प्रोजेक्ट विफलताओं के संरचनात्मक कारण: बार-बार दोहराई जाने वाली प्रबंधकीय अज्ञानता और उसकी कीमत

• सारांश अवलोकन:
  • मुख्य विषय: IT प्रोजेक्ट की विफलताएं तकनीकी कठिनाइयों से नहीं, बल्कि प्रबंधन की 'जानबूझकर की गई अज्ञानता' और पिछली विफलताओं से सीखने से इनकार करने वाले अहंकार से पैदा होती हैं।
  • मुख्य आंकड़े: पिछले 20 वर्षों में वैश्विक IT खर्च 3 गुना बढ़कर 5.6 ट्रिलियन डॉलर हो गया, लेकिन सफलता दर वहीं की वहीं है, जबकि केवल legacy system मेंटेनेंस पर ही बजट का 75% खर्च हो जाता है।
  • मुख्य उदाहरण: कनाडा के Phoenix सिस्टम में व्यापक प्रबंधकीय विफलता और ब्रिटेन के Horizon मामले में अनैतिक ढंक-छुपाव, 'गलती (Blunder)' नहीं बल्कि 'प्रशासनिक बुराई (Administrative Evil)' हैं।

---

1. प्रस्तावना: भारी निवेश के बावजूद न सुधरती विफलता दर

• निवेश के मुकाबले दक्षता में ठहराव:
  • 2005 के बाद दुनिया भर में IT खर्च 1.7 ट्रिलियन डॉलर से बढ़कर 2025 तक 5.6 ट्रिलियन डॉलर हो गया, यानी 3 गुना से भी अधिक।
  • लेकिन भारी लागत लगाने के बावजूद software project की सफलता दर में पिछले 20 वर्षों में कोई स्पष्ट सुधार नहीं दिखा।
• AI को लेकर भ्रम से सावधान:
  • कई प्रबंधक उम्मीद करते हैं कि AI tools या coding assistant (Copilot) बड़े प्रोजेक्ट सफल बना देंगे, लेकिन लेखक इस पर संदेह जताते हैं।
  • AI system engineering की जटिलता, वित्तीय trade-off, और सबसे बढ़कर प्रोजेक्ट के भीतर की 'organizational politics' को हल नहीं कर सकता।
• विफलता का सार्वभौमिक स्वरूप:
  • software विफलताएं देश, कंपनी के आकार, या लाभकारी/गैर-लाभकारी होने से परे हर जगह होती हैं, और यह केवल तकनीकी त्रुटि नहीं बल्कि 'मानवीय कल्पनाशक्ति की कमी' और 'अवास्तविक लक्ष्यों' से पैदा होती हैं।

2. मुख्य भाग: विफलता के प्रकार और कारणों का गहन विश्लेषण

2.1. बार-बार दोहराई जाने वाली 'गलतियां (Blunder)' और सीखने से इनकार

• विफलता और गलती में अंतर:
  • तकनीकी सीमाओं को चुनौती देते हुए झेली गई 'creative destruction' के रूप में विफलता का स्वागत किया जाना चाहिए।
  • लेकिन अधिकांश IT विफलताएं उन कारणों को दोहराने वाली मात्र 'मूर्खतापूर्ण गलतियां (Blunder)' हैं, जो दशकों से दस्तावेज़ों में दर्ज हैं, जैसे जोखिम प्रबंधन की कमी या जटिलता का कम आकलन।
• प्रबंधन का अहंकार:
  • project manager अक्सर दावा करते हैं कि उनका प्रोजेक्ट "विशेष और अनोखा" है, और इस वजह से वे पिछली विफलताओं या डेटा को नज़रअंदाज़ करते हैं।
  • यह केवल अज्ञानता नहीं, बल्कि जोखिम संकेतों को जानबूझकर अनदेखा करने वाली 'willful ignorance' है।
• legacy system का जाल:
  • अमेरिका में संगठन legacy system मेंटेनेंस पर हर साल 520 बिलियन डॉलर से अधिक खर्च करते हैं, जो कुल IT बजट का 70~75% है।
  • replacement failure के डर से modernization को तब तक टाला जाता है, जब तक सिस्टम भौतिक रूप से टूट न जाए या उसकी लागत-प्रभावशीलता पूरी तरह समाप्त न हो जाए। (उदाहरण: Louisiana Office of Motor Vehicles mainframe)

2.2. प्रमुख विफलताओं के उदाहरण और उनके प्रभाव

• कनाडा का Phoenix payroll system:
  • शुरुआती गलत आकलन: packaged solution (PeopleSoft) अपनाते हुए 80,000 payroll rules और 105 labor union agreements को customize करने की कोशिश की गई।
  • बजट कटौती की कीमत: vendor द्वारा सुझाए गए बजट के 60% से भी कम में प्रोजेक्ट पूरा करने के लिए मुख्य payroll features हटाए गए, testing घटाई गई, और आवश्यक pilot test छोड़ दिए गए।
  • परिणाम: 2016 में rollout के तुरंत बाद सिस्टम ढह गया। कर्मचारियों को वेतन गलत मिलने से भारी वित्तीय पीड़ा हुई, और कुछ मामलों में इसे आत्महत्या के कारणों में गिना गया।
  • लागत: शुरुआती बजट 310 मिलियन Canadian dollar था, लेकिन recovery और समाधान की लागत अब 5.1 बिलियन Canadian dollar (लगभग 3.6 बिलियन USD) से अधिक हो चुकी है।
• ब्रिटेन का Post Office Horizon scandal:
  • तकनीकी दोष: Fujitsu द्वारा दिए गए सिस्टम में middleware bug के कारण वित्तीय mismatch errors पैदा हुए।
  • संगठनात्मक ढंक-छुपाव: management ने software defects की जानकारी होने के बावजूद उन्हें छिपाया, और उल्टा 3,500 postmasters पर गबन और चोरी के आरोप लगाए। इनमें से 900 को दोषी ठहराकर जेल भेजा गया।
  • सामाजिक कीमत: पीड़ितों ने दिवालियापन, तलाक, कारावास और आत्महत्या तक झेली। इसे ब्रिटेन के इतिहास की सबसे खराब IT विफलताओं और न्यायिक त्रासदियों में गिना जाता है।

2.3. स्वचालित निर्णय-निर्माण और 'प्रशासनिक बुराई'

• algorithmic हिंसा:
  • अमेरिका के Michigan के MiDAS (unemployment benefit fraud detection) और ऑस्ट्रेलिया के Robodebt (welfare fraud detection) सिस्टम ने मानवीय निगरानी के बिना केवल algorithm पर निर्भर होकर निर्णय दिए।
  • इनसे हजारों निर्दोष नागरिकों को अपराधी बना दिया गया, लेकिन अधिकारियों ने system errors साबित होने के बाद भी मुआवज़ा देने से इनकार किया या जिम्मेदारी से बचने की कोशिश की।
• AI अपनाने के जोखिम:
  • इस तरह की 'प्रशासनिक बुराई (Administrative Evil)' AI के public infrastructure में और गहराई से घुसने के साथ और बढ़ेगी।
  • EU ने 'explanation मांगने के अधिकार' को लागू किया है, लेकिन दुनिया भर में transparency और algorithmic accountability तय करना बेहद जरूरी है।

3. निष्कर्ष: समाधान और IT कम्युनिटी के सामने चुनौती

• methodology (Agile/DevOps) कोई जादुई चाबी नहीं है:
  • जैसे रिपोर्ट बताती हैं कि Agile project की विफलता दर 65% तक पहुंच सकती है, वैसे ही methodology अपने आप सफलता की गारंटी नहीं देती। लगातार leadership और organizational discipline के बिना कोई भी नई methodology विफल हो जाएगी।
• ईमानदार risk assessment और नैतिक जिम्मेदारी:
  • प्रोजेक्ट शुरू होने से पहले "हम क्या जानते हैं, और क्या नहीं जानते" इस पर ईमानदार gap analysis किया जाना चाहिए।
  • 'human-centered AI' की अवधारणा को सभी IT projects तक बढ़ाते हुए, system failure से अंतिम उपयोगकर्ताओं को होने वाली भावनात्मक और वित्तीय हानि को cost-benefit analysis में शामिल किया जाना चाहिए।
• प्रबंधन के रवैये में बदलाव की मांग:
  • software स्वभाव से fragile और जटिल है। प्रबंधन को केवल बजट नियंत्रित करने वाली शक्ति के रूप में नहीं, बल्कि विफलता की स्थिति में जिम्मेदारी लेने वाले पक्ष के रूप में software development का सम्मान और समर्थन करना चाहिए।
  • बार-बार दोहराई जाने वाली गलतियों को रोकना ही IT उद्योग के 'crisis' से बाहर निकलने का एकमात्र रास्ता है।

[baeba]

Hacker News कमेंट प्रतिक्रियाओं का सारांश

1. क्रमिक डिप्लॉयमेंट और स्केलिंग रणनीति की कमी (Start Small)

• 'Big Bang' तरीके की लगभग तय विफलता: राष्ट्रीय स्तर की परियोजना को एक ही बार में डिप्लॉय करना आत्मघाती कदम है। छोटे स्तर (गांव→शहर→देश) पर क्रमवार सत्यापन करते हुए विस्तार करने की रणनीति ज़रूरी है।
• प्रोडक्ट बनाम सिस्टम का अंतर: WhatsApp जैसे एकल प्रोडक्ट से अलग, जटिल enterprise systems को शुरुआत से ही बहुत बड़े scale को संभालना पड़ता है, इसलिए approach अलग होनी चाहिए।
• मुख्य समाधान: "छोटा बनाओ, सत्यापित करो, फिर फीचर जोड़ो" के सिद्धांत की अनदेखी की जा रही है।

2. प्रबंधन की अक्षमता और जवाबदेही से बचना (Management Issues)

• जवाबदेही के बिना शक्ति संरचना: परियोजना विफल होने पर developers ओवरटाइम करके स्थिति संभालते हैं, लेकिन निर्णय लेने वाला management जिम्मेदारी नहीं लेता, बल्कि कई बार bonus भी ले जाता है—इस विरोधाभासी ढांचे की आलोचना।
• तकनीकी समझ की कमी: तकनीकी कठिनाई को नजरअंदाज कर अवास्तविक deadlines थोपना और 'बुरी खबर' सुनने से इनकार करने वाली आदेश-पालन संस्कृति समस्या समाधान को रोकती है।
• राजनीतिक निर्णय-प्रक्रिया: तकनीकी उपयुक्तता से अधिक, आंतरिक राजनीति या बाहरी vendors के साथ संबंध (जैसे rebate) के आधार पर solutions चुने जाते हैं।

3. नियंत्रण से बाहर जाती आवश्यकताएँ और जटिलता (Complexity & Scope Creep)

• प्रोसेस सरलीकरण पहले न होना: Phoenix Project के उदाहरण की तरह, 80,000 payroll rules को व्यवस्थित किए बिना उन्हें ज्यों का त्यों digitize करने की कोशिश मूल कारण है। अव्यवस्थित offline process केवल अव्यवस्थित digital system ही पैदा करता है।
• बार-बार बदलती आवश्यकताएँ: परियोजना के दौरान management या ग्राहक की बदलती मांगों से काम का दायरा बढ़ना (Scope Creep) परियोजना को दलदल में धकेल देता है।

4. डेवलपर संस्कृति और गलत प्रोत्साहन (Developer Culture)

• रिज़्यूमे-प्रेरित विकास (RDD): परियोजना की सफलता से अधिक, नौकरी बदलने में मदद करने वाली नवीनतम ट्रेंडिंग technologies (frameworks) को जबरन अपनाकर technical debt बढ़ा दी जाती है।
• सीखने की निरंतरता का टूटना: 2~3 साल के चक्र वाली बार-बार नौकरी बदलने (Job Hopping) की संस्कृति के कारण developers अपने लिखे code की दीर्घकालिक विफलता को देख और उससे सीख नहीं पाते।
• पुनर्निर्माण का जुनून: पहले से सत्यापित solutions का उपयोग करने के बजाय, आत्मसंतुष्टि के लिए शुरू से code फिर से लिखने की अक्षम प्रथा।

5. सॉफ़्टवेयर इंजीनियरिंग की विशिष्ट प्रकृति (Engineering Nature)

• भौतिक सीमाओं का अभाव: architecture/hardware के विपरीत, software पर भौतिक सीमाएँ नहीं होतीं, इसलिए यह अनंत जटिलता की अनुमति देता है, जो अंततः नियंत्रण से बाहर की स्थिति पैदा करती है।
• अतीत से न सीखना: अन्य engineering क्षेत्रों में विफलताओं (जैसे bridge collapse) का गहराई से विश्लेषण कर सबक लिया जाता है, लेकिन software industry अक्सर "इस बार अलग है" कहते हुए पुरानी गलतियाँ दोहराती है और 'YOLO' शैली का development दिखाती है।