Titanic परियोजना प्रबंधन और सॉफ्टवेयर परियोजनाओं के साथ तुलना

कुछ ही परियोजनाओं ने Titanic और उसके sister Olympic जहाजों, Olympic और Britannic द्वारा प्राप्त की गई प्रसिद्धि और कुख्याति हासिल की है, जिनका डिज़ाइन इस वर्ष एक सौ दस साल पहले शुरू हुआ था। बेशक, परियोजना प्रबंधन के संबंध में Olympic जहाजों के भाग्य से हम कई सबक सीख सकते हैं और वास्तव में परियोजना प्रबंधन के कई पहलू हैं जो कवर करने योग्य हैं।

(जहाजों को समग्र रूप से संदर्भित करते समय मैं उन्हें The Olympics के रूप में सरल रूप से संदर्भित करूंगा क्योंकि तीनों मिलकर White Star Line के Olympic Class जहाज थे। Titanic की व्यक्तिगत और बाद की प्रसिद्धि यहाँ अप्रासंगिक है। साथ ही, मैं यहाँ यह स्थिति लेता हूँ कि Olympic जहाजों, उनके इतिहास और भाग्य से संबंधित सामान्य जानकारी पाठक को सामान्य ज्ञान है और उन्हें दोबारा कवर नहीं करूंगा।)

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

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

सबसे पहले, हमें Olympics परियोजना में stakeholders की पहचान करनी होगी। White Star Lines स्वयं (प्रायोजक कंपनी और प्राथमिक निवेशक) और इसके निदेशक Joseph Bruce Ismay, Harland-Wolff (contracted ship builder) अपने प्रमुख डिजाइनरों Alexander Carlisle और Thomas Andrews के साथ, जहाजों के crew जिसमें Captain Edward John Smith शामिल हैं, ब्रिटिश सरकार जैसा कि हम बाद में देखेंगे और, सबसे महत्वपूर्ण, यात्री।

किसी भी stakeholders के समूह की तरह अलग-अलग भूमिकाएं निभाई जाती हैं। एक तरफ White Star sponsor और निवेशक है और एक आधुनिक software project में एक प्रायोजक customer, manager या department के सादृश्य होगा। Harland-Wolff डिजाइनर और निर्माता थे और एक आधुनिक software team में software engineering “team members” यानी developers से सबसे अधिक संबंधित थे। जहाजों के crew परियोजना पूरी होने के बाद संचालन के लिए जिम्मेदार थे और एक IT operations team के तुलनीय होंगे जो अंतिम software को पूरा होने के बाद चलाने का काम संभालती है। यात्री बहुत हद तक आज के end users की तरह थे, जो इंजीनियरिंग deliverable (जहाज या software) और उस उत्पाद के ऊपर बनी सेवा (ferry service या IT managed services) दोनों से लाभ उठाने की उम्मीद कर रहे थे। (“Olympic”)

परियोजना के विश्लेषण की एक और धुरी chicken और pig stakeholders की है जहाँ chickens निवेशित हैं और जोखिम उठाते हैं जबकि pigs पूरी तरह निवेशित हैं और अंतिम जोखिम उठाते हैं। सामान्य software में हम इन तुलनाओं का उपयोग stakeholders की डिग्री के बारे में बात करने के लिए करते हैं – वे जो शामिल हैं बनाम वे जो committed हैं, लेकिन Olympic जहाजों के मामले में ये शब्द नए और भयावह अर्थ लेते हैं क्योंकि crew और यात्रियों ने शाब्दिक रूप से जहाजों के संचालन चरण में अपनी जानें दांव पर लगाई, जबकि निवेशक और निर्माता केवल वित्तीय जोखिम में थे। (Schwaber)

दूसरा, मुझे लगता है कि Olympics के संदर्भ में मौजूद विभिन्न परियोजनाओं के बीच अंतर करना उपयोगी है। बेशक, तीन जहाजों का भौतिक रूप से डिज़ाइन और निर्माण था। यह एक एकल परियोजना है, दो स्पष्ट घटकों के साथ – एक डिज़ाइन का और एक निर्माण का। और तीन discrete deliverables, अर्थात् तीन Olympic जहाज। निर्माण चरण के अंत में एक अत्यंत स्पष्ट सीमांकन बिंदु है जहाँ जहाज की असेंबली में शामिल परियोजना प्रबंधक और teams काम बंद करेंगे और जहाज चलाने वाला crew काम संभालेगा।

यहाँ हम आधुनिक प्रौद्योगिकी की दुनिया में एक महत्वपूर्ण सादृश्य पहले से ही खींच सकते हैं जहाँ software products को software engineers द्वारा डिज़ाइन और विकसित किया जाता है और, जब वे पूरे हो जाते हैं, IT operational staff को सौंप दिए जाते हैं जो अंतिम उत्पाद के वास्तविक इच्छित उपयोग को संभालते हैं। ये दोनों teams एक ही संगठनात्मक छतरी के तहत आंतरिक हो सकती हैं या दो, या अधिक, बहुत अलग संगठनों से हो सकती हैं। लेकिन engineering और operational विभागों के बीच का अंतर आज अधिकांश व्यवसायों में उतना ही स्पष्ट और विशिष्ट बना हुआ है जितना एक सदी से अधिक पहले जहाज निर्माण और ferry service के लिए था।

हम एक कदम आगे जा सकते हैं और White Star के transatlantic ferry service की तुलना कई आधुनिक software as a service vendors जैसे Microsoft Office 365, Salesforce या G Suite से कर सकते हैं। इन मामलों में प्रश्नाधीन कंपनी के पास एक engineering या product development team है जो मूल product बनाती है और फिर एक दूसरी team है जो उस in-house product को लेती है और इसे एक service के रूप में संचालित करती है। यह software development space में एक तेजी से महत्वपूर्ण business model है कि software बनाने वाली कंपनी ही इसकी अंतिम operator होगी, लेकिन external clients के लिए। कई मायनों में आधुनिक software और IT के लिए Olympics की प्रासंगिकता घटने की बजाय बढ़ रही है।

यह एक महत्वपूर्ण interface understanding सामने लाता है जो Olympics पर चूक गई और अक्सर आज भी चूकती है: hand-off के प्रत्येक पक्ष का मानना था कि दूसरा पक्ष अंततः सुरक्षा के लिए जिम्मेदार था। Engineers ने अपने design की सुरक्षा का प्रचार किया, लेकिन जब दबाव डाला गया तो compromise करने के लिए तैयार हो गए यह मानकर कि operational procedures जोखिमों को कम कर देंगी और उनके अपने प्रयास बड़े पैमाने पर अनावश्यक हैं। इसी तरह, जब चीजें आगे बढ़ाते रहने और अच्छा समय बनाने के लिए दबाव डाला गया तो operations team procedures पर compromise करने के लिए तैयार हो गई क्योंकि उनका मानना था कि engineering team ने इतना आगे जाकर उनके प्रयासों को अनिवार्य रूप से बेकार कर दिया है, जहाज इतना सुरक्षित था कि operational सावधानियाँ बस जरूरी नहीं थीं। इस गलत संचार ने प्रयास को दो प्रकार की अत्यधिक सुरक्षा की प्रणालियों से मूल रूप से शून्य तक ले गया। यदि किसी भी पक्ष ने समझ लिया होता कि दूसरा कैसे काम करेगा या करता था, तो वे इसे ध्यान में रख सकते थे। अंत में, दोनों पक्षों ने कम से कम कुछ हद तक यह माना कि सुरक्षा “दूसरी team का काम” था। जबकि जहाज का भारी प्रचार सुरक्षा के आधार पर किया गया था, वास्तविकता यह थी कि यह पिछली आधी सदी से अधिक की सामान्य प्रवृत्ति को जारी रखता था, जहाँ हर साल जहाज पिछले साल की तुलना में कम सुरक्षित बनाए और संचालित किए जाते थे। (Brander 1995)

आज हम IT और software engineering के बीच यही समस्या उत्पन्न होते देखते हैं – स्थिरता के आसपास कम (हालाँकि वह निश्चित रूप से सच है) लेकिन अब security के बारे में, जिसे Olympics के संदर्भ में safety के समान देखा जा सकता है। Security पिछले दशक में प्रौद्योगिकी की बाड़ के दोनों तरफ सबसे महत्वपूर्ण विषयों में से एक बन गई है और उद्योग उन चुनौतियों का सामना करता है जो दोनों पक्षों द्वारा security practices को पूरी तरह से लागू करने की आवश्यकता से बनी हैं – कोई भी अकेले वास्तव में सुरक्षित सिस्टम लागू करने में सक्षम नहीं है। Operations के दौरान procedurally इसे enforce करने का विकल्प safety या security की planning करना नहीं है।

आज की एक उत्कृष्ट तुलना British Airways है और वे Atlantic के पार हर flight की देखरेख कैसे करते हैं। North Atlantic पर हवाई यातायात के प्राथमिक वाहक के रूप में, वही रास्ता जो Olympics को पार करना था, British Airways को सुरक्षा में उत्कृष्टता की प्रतिष्ठा बनाए रखनी होती है। 2017 में भी, North Atlantic के ऊपर से उड़ान भरना एक नाजुक और जटिल यात्रा है।

किसी भी British Airways flight के उड़ान भरने से पहले, pilots और crew को एक तीन सौ पृष्ठ की mission manual की समीक्षा करनी होती है जो उन्हें जहाज, crew, मौसम आदि के विवरण सहित सब कुछ बताती है। यह प्रक्रिया इतनी intense है कि British Airways यह स्वीकार करने से इनकार करती है कि यह एक flight है, लेकिन आधिकारिक तौर पर Atlantic के हर एक trip को “mission” के रूप में संदर्भित करती है; विशेष रूप से इसमें शामिल सभी को ऐसे प्रयास की गंभीरता और जोखिम को समझाने के लिए। वे स्पष्ट रूप से इस बारे में सोचने के तरीके को बदलने के महत्व को समझते हैं और जानते हैं कि क्या हो सकता है यदि लोग यह मानने लगें कि बाकी सभी ने अपना काम अच्छे से किया है और वे अपने काम में कोनों को काट सकते हैं। वे नहीं चाहते कि कोई भी लापरवाह हो जाए या यह महसूस करने लगे कि flight, भले ही हर दिन कई बार पूरी हो, कभी भी routine है। (Winchester)

यदि British Airways का approach Titanic के साथ उपयोग किया जाता, तो बहुत संभव है कि जब आपदा आई तो वह नहीं आती। अकेले operational पक्ष ने आपदा को रोका जा सकता था। इसी तरह, यदि जहाज के engineers को आज Boeing या AirBus के समान मानकों पर रखा जाता तो वे management द्वारा project पर काम करते समय safety requirements को संशोधित करने के लिए इतनी आसानी से दबाव में नहीं आते।

Olympics को वास्तव में जो प्रभावित किया, कई मायनों में, वह अनियंत्रित scope creep का एक रूप था। परियोजना “big design up front” के साथ एक पारंपरिक waterfall approach के रूप में शुरू हुई और प्रारंभिक requirements अच्छी थीं जिसमें safety एक महत्वपूर्ण भूमिका निभा रही थी। यदि मूल परियोजना requirements और यहाँ तक कि मूल design का अधिकांश उपयोग किया जाता, तो जहाज उनसे कहीं अधिक सुरक्षित होते। लेकिन बड़े dining rooms या अधिक शानदार फिटिंग की नई requirements ने प्राथमिकता ली और परियोजना के scope और parameters को इन नए बदलावों को accommodate करने के लिए बदल दिया गया। किसी भी परियोजना की तरह, कोई भी बदलाव vacuum में नहीं होता बल्कि लागत, सुरक्षा या delivery date जैसे अन्य कारकों के लिए परिणाम होंगे। (Sadur)

Titanic पर scope creep विशेष रूप से नाटकीय था, लेकिन छिपा हुआ था और अधिकांश भाग के लिए जरूरी नहीं था। Dining room के आकार में बदलाव जैसे छोटे बदलावों को इंगित करना आसान है, लेकिन कहीं अधिक महत्वपूर्ण वह समय सीमा में बदलाव था जिसमें जहाज को deliver करना था। जिस चीज ने वास्तव में scope को बदला वह यह था कि प्रारंभिक deadlines और projects को अपेक्षाकृत सख्ती से बनाए रखना था। यह विशेष रूप से समस्याग्रस्त था क्योंकि Titanic के dry dock काम और बाद के moored काम के बीच, पुराना sibling Olympic, बड़े repairs के लिए कई बार लाया गया था जिसका Titanic के अपने काम को पूरा करने के लिए original schedule में उपलब्ध समय पर बहुत बड़ा प्रभाव पड़ा। Scope modification का यह प्रकार को अनदेखा करना या ignore करना बहुत आसान है, विशेष रूप से hindsight में, क्योंकि physical deliverables और original dates किसी नाटकीय तरीके से नहीं बदले। लेकिन सभी इरादों और उद्देश्यों के लिए, Titanic को उसके मूल रूप से नियोजित की तुलना में बहुत तेजी से production के माध्यम से rushed किया गया था।

आधुनिक software engineering में यह अच्छी तरह से स्वीकार किया जाता है कि कोई भी यह अनुमान नहीं लगा सकता कि एक design task को उतना समय लगेगा जितना वे engineers जो खुद task कर रहे हैं। यह भी आमतौर पर स्वीकार किया जाता है कि management pressure के माध्यम से engineering और design efforts को महत्वपूर्ण रूप से तेज करने का कोई साधन नहीं है। एक बार जब एक परियोजना अधिकतम गति से चल रही है, तो वह तेज नहीं होगी। तेज होने के प्रयास अक्सर गलतियों, oversights या misses की ओर ले जाते हैं। हम software में इसे सच जानते हैं और मान सकते हैं कि जहाज के design के लिए भी यह सच होना चाहिए क्योंकि सिद्धांत समान हैं। यदि Titanic को इस process के लिए उचित मात्रा में समय दिया गया होता, तो संभव है कि safety measures पर अधिक पूरी तरह से विचार किया जाता या कम से कम hand off पर operational team को ठीक से communicated किया जाता। जिन teams को rush किया जाता है उन्हें compromise करने के लिए मजबूर किया जाता है और चूंकि समय को constraint के रूप में adjust नहीं किया जा सकता, इसलिए corners को कहीं और काटने पड़ते हैं और लगभग हमेशा यह quality और thoroughness से आता है। यह एक गलती के रूप में या शायद design के एक हिस्से को बदलते समय शामिल सभी कारकों की पूरी तरह से समीक्षा करने में विफल होने के रूप में प्रकट हो सकता है।

यह हमें holistic design thinking की ओर ले जाता है। परियोजना की शुरुआत में Olympics को सुरक्षा को ध्यान में रखकर design किया गया था: सुरक्षा जो कई अलग-अलग systems के सावधानीपूर्वक अंतर-कार्यों के परिणामस्वरूप होती है जो मिलकर एक अत्यधिक विश्वसनीय जहाज बनाने के लिए हैं। हम इस आकार के जहाज के घटकों को अलग-अलग नहीं देख सकते, वे कोई अर्थ नहीं रखते – hull का design, decks की शैली, cargo का वजन, उपयोग की गई materials, bulkheads की शैली सभी परस्पर संबंधित हैं और एक साथ कार्य करना चाहिए।

जब परियोजना को अधिक तेजी से पूरा करने या parameters बदलने के लिए दबाव डाला गया तो यह holistic thinking और पहले के निर्णयों की स्पष्ट पुनर्समीक्षा नहीं की गई या पर्याप्त रूप से नहीं की गई। बल्कि, individual घटकों को इस बात की परवाह किए बिना बदला गया कि यह जहाज के पूरे के भीतर उनकी भूमिका को कैसे प्रभावित करेगा और इसके परिणामस्वरूप overall safety पर क्या प्रभाव पड़ेगा। जो एक छोटे से बदलाव की तरह लग सकता था उसके अनपेक्षित परिणाम थे जो अदृश्य थे क्योंकि holistic project management को छोड़ दिया गया था। (Kozak-Holland)

Engineering में यह बदलाव operations में स्वाभाविक रूप से परिलक्षित हुआ। प्रत्येक बदलाव, जैसे कि binoculars का उपयोग न करना या ice bucket readings न लेना, व्यक्तिगत रूप से कुछ हद तक minor था, लेकिन एक साथ लेने पर वे अविश्वसनीय रूप से प्रभावशाली थे। संभवतः, लेकिन हम निश्चित नहीं हो सकते, एक cohesive project management या कम से कम process improvement system का उपयोग नहीं किया जा रहा था। कौन यह देख रहा था कि binoculars का उपयोग किया जाए, कि water tests accurate हों और इसी तरह? कोई भी check इस बात को उजागर करता कि उन tasks के लिए आवश्यक tools बिल्कुल भी मौजूद नहीं थे। कोई रास्ता नहीं था कि procedures का एक साधारण test run भी किया जा सके, regular checking और process improvement की तो बात ही छोड़ें। Process improvement को इस तथ्य से विशेष रूप से उजागर किया जाता है कि Captain Smith ने RMS Olympic पर practice की थी, उसकी पाँचवीं voyage पर एक समुद्री collision का कारण बना और फिर Titanic के प्रारंभिक launch के साथ लगभग उसी गलती को दोहराने के करीब आ गया। जो Olympic जहाजों के सभी captains और pilots के लिए एक महत्वपूर्ण सीखा हुआ सबक होना चाहिए था, उसे बजाय ignore किया गया और लगभग तुरंत दोहराया गया। (“Olympic”)

बेशक जहाज निर्माण और software बहुत अलग चीजें हैं, लेकिन कई सबक साझा किए जा सकते हैं। सबसे महत्वपूर्ण सबकों में से एक जहाज निर्माण द्वारा सामना की गई सीमाओं को देखना और पहचानना है कि software के साथ काम करते समय हमें इन्हीं सीमाओं को बनाए रखने की आवश्यकता कब नहीं है। Olympic और Titanic को लगभग एक ही समय में बनाया गया था और Olympic के निर्माण से प्राप्त engineering knowledge को Titanic के निर्माण पर लागू होने का समय बिल्कुल नहीं मिला, उसके संचालन की तो बात ही छोड़ें। आधुनिक software में हम ऐसी constraint की कभी उम्मीद नहीं करेंगे और real code में या यहाँ तक कि conceptually रूप से आगे बढ़ने से पहले, इस पर आधारित additional software पर आगे बढ़ने से पहले, software को कम से कम कुछ छोटी सीमा तक test करने में सक्षम होंगे। आज परियोजना प्रबंधन को आधुनिक समय और हमारे अलग उद्योग में जो अंतर मौजूद हैं, उनका अपने फायदे के लिए सर्वोत्तम तरीके से लाभ उठाने की आवश्यकता है। कुछ software projects को अभी भी इस तरह की processes की आवश्यकता होती है लेकिन ये समय के साथ कम और कम सामान्य हो गई हैं और आज केवल बीस साल पहले की तुलना में नाटकीय रूप से कम सामान्य हैं।

Harland-Wolff द्वारा Olympics के साथ किए गए काम का मूल्यांकन करना उचित है क्योंकि उन्होंने clearly अपने purview के भीतर जो feedback loops संभव थे उन्हें incorporate करने की कोशिश की। न केवल उन्होंने पहले के जहाजों के निर्माण का उपयोग बाद के जहाजों के लिए अधिक सीखने के लिए करने की कोशिश की, हालाँकि यह बहुत सीमित था क्योंकि जहाज अधिकांशतः एक साथ निर्माणाधीन थे और अधिकांश सबकों को लागू करने का समय नहीं होता, लेकिन कहीं अधिक महत्वपूर्ण रूप से उन्होंने जहाजों के साथ एक “guarantee group” भेजने का असाधारण कदम उठाया। इस guarantee group में सभी प्रकार के support trades से सभी प्रकार के apprentice और master ship builders शामिल थे। (“Guarantee Group”)

Direct feedback के लिए guarantee group का उपयोग अभूतपूर्व था, और वास्तव में अभी भी है, और जहाज निर्माताओं के लिए hard cost और समय में एक बड़ा निवेश था कि इतने मूल्यवान workers को Atlantic के पार luxury में आगे-पीछे sail करने के लिए sacrifice किया जाए। Group अपने काम को पहले हाथ से inspect करने में सक्षम था, इसे action में देखा, working ship के context में इसके उपयोग की समझ हासिल की, team building, knowledge transfers और अधिक पर एक साथ काम किया। यह ship yards से feedback की तुलना में कहीं अधिक मूल्यवान था जहाँ जहाज निर्माण में overlap हो रहे थे, यह उनके जहाज निर्माण enterprise के भविष्य में एक मजबूत निवेश था: industrial education के प्रति एक commitment जो संभवतः दशकों तक उन्हें लाभान्वित करती।

आधुनिक deployment styles, tools और शिक्षा ने अधिकांश software को Waterfall methodology के तहत बनाए जाने से – जो turn of the [last] century के जहाज निर्माण से बहुत अलग नहीं थी – Agile methodologies की कुछ डिग्री का लाभ उठाने की ओर ले गई है जो rapid testing, evaluation, changes और deployment की अनुमति देती है। Scope creep कुछ ऐसी चीज से बदल गया है जिसे development process के भीतर expected और assumed के रूप में treated किया जा सकता है यहाँ तक कि लगभग leveraged भी किया जा सकता है। Big design up front के साथ मूलभूत समस्याओं में से एक यह है कि इसके लिए हमेशा customer या customer-role stakeholder को “big decisions up front” लेने की आवश्यकता होती है जो अक्सर उनके लिए design की तुलना में engineers के लिए बनाना कहीं अधिक कठिन होता है। ये early decisions अक्सर scope creep या बाद के change requests का एक प्राथमिक contributor होती हैं और अक्सर agile processes द्वारा कम या avoid की जा सकती हैं जो निरंतर परिवर्तन होने की उम्मीद करती हैं और इसे process में शामिल करती हैं।

Ship builders, Harlan और Wolff, ने testing के लिए Olympic का पंद्रह फुट का model बनाया जो कुछ हद तक उपयोगी है, लेकिन निश्चित रूप से full size जहाज बाद में जो hydrological action produce करेगा उसकी नकल करने में विफल रहा और नए vessel के आकार के कुछ अधिक खतरनाक side effects की भविष्यवाणी करने में विफल रहा जब अन्य जहाजों के पास होता था जो group की पहली दुर्घटना और जो लगभग दूसरी थी उसकी ओर ले गई। builders design और निर्माण process के दौरान हर उपलब्ध stage पर test और सीखने के हर प्रयास करते दिखते हैं। (Kozak-Holland)

आधुनिक project management की तुलना में यह developers या यहाँ तक कि customers के लिए hands-on experience के लिए एक rapid mock-up या wireframe produce करने के तुलनीय होगा किसी unforeseen कारण के लिए dead end path में जो हो सकता है उसमें आगे effort invest करने से पहले। यह user interface design में विशेष रूप से महत्वपूर्ण है जहाँ actual users को physically system में manipulate करने और अपने लिए judge करने का chance provide किए बिना usability या satisfaction ratings को properly predict करने की अक्सर बहुत कम क्षमता होती है। (Esposito)

हमें, निश्चित रूप से, वित्तीय रुझानों और बलों के संबंध में उनके historical juxtaposition के context में Olympics द्वारा उठाए गए जोखिम पर विचार करना होगा। उस समय, पिछली सदी के मध्य से शुरू होकर, प्रचलित वित्तीय सोच यह थी कि जीवन, cargo या जहाजों के नुकसान के संदर्भ में जोखिम भरे की ओर झुकना सबसे अच्छा था, न कि सुरक्षित की ओर; और insurance vehicles के माध्यम से अंतर को overcome करना। Financial रूप से जहाजों के लिए जोखिम भरे तरीके से operate करना मानव जीवन के बारे में अत्यधिक सतर्क होने की तुलना में बस अधिक फायदेमंद था। यह trend, Olympics के समय तक, लगभग साठ वर्षों से अच्छी तरह से स्थापित हो चुकी थी और Titanic के डूबने की भारी publicity तक बदलना शुरू नहीं होगी। जनता पर market impact तब तक मौजूद नहीं था जब तक कि “unsinkable” जहाज, इतनी सारी जानों के साथ, ऐसे spectular तरीके से नहीं डूब गया।

जोखिम और इसके वित्तीय trade offs के प्रति यह approach एक है जिसे project managers को आज उसी तरह समझना चाहिए जैसे वे एक सौ साल से अधिक पहले करते थे। यह मानना आसान है कि जोखिम इतना महत्वपूर्ण है कि इसे समाप्त करने के लिए कोई भी लागत उचित है, लेकिन projects इस तरह नहीं सोच सकते। जोखिम को कम करने की खोज में असीमित संसाधन खर्च करना संभव है। वास्तविक दुनिया में यह आवश्यक है कि हम जोखिमों को जोखिम शमन की लागत के साथ संतुलित करें। इसका एक अच्छा उदाहरण आधुनिक समय में है, लेकिन specifically software development से बाहर, United States में credit card fraud को handle करने में। केवल पिछले कुछ वर्षों तक, US credit card industry की सामान्य राय यह थी कि theft को रोकने के लिए credit cards पर अधिक security measures की लागत उनके न होने के जोखिमों की तुलना में बहुत अधिक थी; essentially यह fake transactions को reimburse करने में पैसा खर्च करना उन fake transactions को रोकने की तुलना में अधिक cost effective था। यह cost to risk ratio कभी-कभी counter-intuitive और यहाँ तक कि frustrating हो सकता है, लेकिन यह एक है जिसे तार्किक, calculated fashion में project decisions को drive करना होगा।

इसी तरह, IT में systems design करना सामान्य है यह मानते हुए कि downtime essentially असीमित लागत है और वास्तविक outage event की लागत से कहीं अधिक खर्च करने की कोशिश में downtime risk को कम करने की कोशिश करना जो घटित होने पर होने की संभावना होगी। यह clearly मूर्खतापूर्ण है, लेकिन इस प्रकार का cost analysis इतना कम चलाया जाता है या सही ढंग से चलाया जाता है कि इस mentality का शिकार होना बहुत आसान हो जाता है। Software engineering projects में हमें समान fashion में जोखिमों का approach करना चाहिए। यह स्वीकार करना कि किसी भी प्रकार का जोखिम है, और वास्तविक जोखिम निर्धारित करना, उस जोखिम के प्रभाव की magnitude और उसे mitigation strategies की लागत से तुलना करना जोखिम के संबंध में एक उचित project management निर्णय लेने के लिए critical है। (Brander 1995)

बहुत बड़ी परियोजनाओं के लिए भी विशेष रुचि का, जिनके लिए Olympics निश्चित रूप से qualify करती थी, “too big to fail” होने की एक additional concept है। यह, बेशक, एक आधुनिक phrase है जो पिछले दशक के financial crisis के दौरान आई, लेकिन इसकी concept और वास्तविकता कहीं पुरानी है और किसी भी ऐसी परियोजना के लिए एक मूल्यवान consideration है जो ऐसे scale पर आती है जो यदि परियोजना पूरी तरह से विफल हो जाती तो एक “national financial disaster” register करती। Olympics के मामले में British सरकार ने अंततः निवेशकों को कुल आपदा से बचाया क्योंकि उस समय सबसे बड़ी passenger lines में से एक का collapse देश के लिए devastating होता।

White Star Lines simply “too big to fail” था और government द्वारा afloat रखा गया था, so to speak, कुछ साल बाद Cunard में forcibly merge होने से पहले। यह concept, यह जानते हुए कि government company के विफल होने के जोखिमों को स्वीकार नहीं करना चाहेगी, उस समय calculated या considered किया गया हो सकता है, हम नहीं जानते। हम जानते हैं, हालाँकि, कि आज बहुत बड़ी परियोजनाओं के साथ इसे ध्यान में रखा जाता है। इसका एक उदाहरण currently Lockheed Martin का F-35 fighter है जो dramatically over budget है, अपनी delivery date से पीछे है और अब useful होने की संभावना भी नहीं मानी जाती है, लेकिन विभिन्न government sponsors द्वारा वर्षों से buoyed किया गया है जो project को राष्ट्रीय अर्थव्यवस्था के लिए बहुत महत्वपूर्ण देखते हैं, यहाँ तक कि deliver करने में विफलता की स्थिति में भी, project को पूरी तरह से collapse होने देने के लिए। जैसे-जैसे यह phenomenon बेहतर और बेहतर जाना जाता है, यह संभव है कि हम अपने risk analysis phases में इसे अधिक परियोजनाओं को ध्यान में रखते हुए देखेंगे। (Ellis)

समीकरण के operational पक्ष पर jumping करते हुए हम Titanic के डूबने की ओर ले जाने वाले पहलुओं के किसी भी संख्या की जांच कर सकते हैं, लेकिन मूल रूप से मेरा मानना है कि जो सबसे स्पष्ट था वह पूरे process में standard operating procedures की कमी थी। यह कुछ हद तक समझ में आता है क्योंकि जहाज अपनी maiden voyage पर था और process documentation और improvement के लिए बहुत कम समय था। हालाँकि यह एक लंबे समय से चले आ रहे shipping line का flagship था जिसकी एक reputation को बनाए रखना था और इन मामलों में बहुत अनुभव था। यह भी नजरअंदाज करेगा कि जब तक Titanic अपनी पहली voyage का प्रयास कर रहा था, तब तक Olympic पहले से ही इतनी अधिक service में था कि standard operating procedures का एक satisfactory set विकसित करने के लिए पर्याप्त से अधिक था।

Baseline documentation की उम्मीद maiden voyage पर भी की जाती, यह unreasonable है कि इस पैमाने का जहाज बिल्कुल भी function करे जब तक कि crew के बीच coordination और communication न हो। पहले जहाज के sail करने से पहले basic crew operational procedures बनाने और तैयार करने के लिए वर्षों का समय था, और निश्चित रूप से इस प्रकृति के सभी जहाजों के लिए यह किया जाना होगा, लेकिन यह स्पष्ट था कि ऐसी operating procedures Titanic के मामले में lacking, missing और untested थीं।

Operating procedures के लिए जिम्मेदार party को शायद project equation के operations पक्ष से identify किया जाएगा, लेकिन engineering और construction teams द्वारा या उनके साथ coordinate किए गए ऐसे documentation की कुछ degree होनी चाहिए। Titanic पर जो procedures टूटीं उनमें दबाव में chain of command failures शामिल थीं जिसमें company के director ने bridge का control ले लिया और captain ने इसे होने दिया, wireless operators को iceberg warnings से ऊपर priority के रूप में passenger messages relay करने का निर्देश दिया गया, wireless operators को उन्हें warn करने की कोशिश करने वाले अन्य जहाजों को broadcasting बंद करने के लिए कहने की अनुमति दी गई, critical messages bridge तक नहीं पहुँचे, critical jobs के लिए आवश्यक tools supply नहीं किए गए और इसी तरह। (Kuntz)

जैसा कि जहाजों के engineering और design के साथ आवश्यक था, जहाजों के operations को strong और holistic guidance की आवश्यकता थी यह ensure करने के लिए कि जहाज और उसका crew एक whole के रूप में काम करे न कि Marconi wireless operators जैसे departments को एक individual unit के रूप में देखे। उस उदाहरण में, वे officially जहाज के crew नहीं थे बल्कि Marconi के employees थे जो paid passenger communiques को handle करने के लिए on board थे और केवल ship emergency traffic को handle करने के लिए यदि समय अनुमति देता। यदि उन्हें holistic operational management system के हिस्से के रूप में oversee किया जाता, यहाँ तक कि outside contractors के रूप में भी, तो संभव है कि उनकी procedures कहीं अधिक safety focused होती या, कम से कम, bridge तक messages पहुँचाने के आसपास service level agreements स्पष्ट रूप से defined होते न कि ad hoc और discretionary।

किसी भी परियोजना और परियोजना component में, project goals, deliverables, procedures आदि चाहे जो भी हो, अच्छा documentation critical है और project management के सफल होने की बहुत कम उम्मीद है यदि अच्छे communications और documentation परियोजना के भीतर आंतरिक रूप से और stakeholders के साथ बाह्य रूप से, हम जो कुछ भी करते हैं उसके केंद्र में नहीं हैं।

आज हम पाते हैं कि Olympic, Titanic और Britannic के project management के सबक आज भी हमारे लिए मूल्यवान हैं और उस युग का context चाहे iterative project design को जहाँ संभव हो push करना, tribal knowledge में निवेश करना, जोखिम की गणना करना, system engineering और system operations की भूमिकाओं को समझना या product costs पर protective external forces के interactions अभी भी relevant हैं। परियोजनाओं को प्रभावित करने वाले कारक cycles में आते और जाते हैं, आज हम trends को Olympics के समान models की ओर झुकते देखते हैं न कि dissimilar। भविष्य में, संभवतः, pendulum फिर से swing करेगा। underlying lessons बहुत relevant हैं और ऐसे ही रहेंगे। हम White Star के projects हमारे अपने projects से कैसे similar हैं और उनसे कैसे different हैं, दोनों का मूल्यांकन करके बहुत कुछ सीख सकते हैं।

Bibliography and Sources Cited:

Miller, Scott Alan. Project Management of the RMS Titanic and the Olympic Ships, 2008.

Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2003.

Kuntz, Tom. Titanic Disaster Hearings: The Official Transcripts of the 1912 Senate Investigation, The. New York: Pocket Books, 1998. Audio Edition via Audible.

Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.

Brown, David G. “Titanic.” Professional Mariner: The Journal of the Maritime Industry, February 2007.

Esposito, Dino. “Cutting Edge – Don't Gamble with UX—Use Wireframes.” MSDN Magazine, January 2016.

Sadur, James E. Home page. “Jim's Titanic Website: Titanic History Timeline.” (2005): 13 February 2017.

Winchester, Simon. “Atlantic.” Harper Perennial, 2011.

Titanic-Titanic. “Olympic.” (Date Unknown): 15 February 2017.

Titanic-Titanic. “Guarantee Group.” (Date Unknown): 15 February 2017.

Brander, Roy. P. Eng. “The RMS Titanic and its Times: When Accountants Ruled the Waves – 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture”. (1998): 16 February 2017.

Brander, Roy. P. Eng. “The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management.” (1995): 16 February 2017.

Ellis, Sam. “This jet fighter is a disaster, but Congress keeps buying it.”. Vox, 30 January 2017.

Additional Notes:

Mark Kozak-Holland ने मूल रूप से अपनी पुस्तक 2003 में Titanic पर Gantthead articles की एक series के रूप में प्रकाशित की:

Kozak-Holland, Mark. “IT Project Lessons from Titanic.” Gantthead.com the Online Community for IT Project Managers and later ProjectManagement.com (2003): 8 February 2017.

More Reading:

Kozak-Holland, Mark. Avoiding Project Disaster: Titanic Lessons for IT Executives. Toronto: Multi-Media Publications, 2006.

Kozak-Holland, Mark. On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive. IBM Press, 2002.

US Senate and British Official Hearing and Inquiry Transcripts from 1912 at the Titanic Inquiry Project.