RMS Titanic और Olympic जहाजों का Project Management

The idea to build the R.M.S. Titanic और उसकी बहन जहाजों, R.M.S. Olympic और H.M.H.S. Britanic, को बनाने का विचार पहली बार 1907 में आकार लेने लगा। ये तीनों जहाज मिलकर White Star Line की Olympic Class ocean liners थीं। (मैं स्पष्टता के लिए इस पूरे पाठ में जहाजों की श्रेणी के संदर्भ में Olympic(s) का उपयोग करूंगा।) मानव इतिहास में बहुत कम जहाज R.M.S. Titanic जितने प्रसिद्ध और कुख्यात हुए हैं।

Project management के नजरिए से R.M.S. Titanic की जांच करने में यह पहचानना महत्वपूर्ण है कि यह project किस प्रकार का उत्पाद बनाने के लिए तैयार था। कई projects के विपरीत जहां अंतिम customer अंतिम उत्पाद का मालिक होगा, Titanic को एक service, विशेष रूप से एक ferry service, अपने अंतिम customers को प्रदान करने के लिए डिज़ाइन किया गया था। यह "Project Titanic" पर चर्चा करने में एक दिलचस्प चुनौती पैदा करता है क्योंकि project management के अधिकांश दृष्टिकोण एक project को एक स्पष्ट शुरुआत और अंत के साथ-साथ स्पष्ट, अच्छी तरह से परिभाषित stakeholders के रूप में देखते हैं।

R.M.S. Titanic जैसे project के मामले में हम दो दृष्टिकोण ले सकते हैं और दो पक्षों से समस्या का सामना कर सकते हैं। एक मामले में हमारे पास वह project है जिसके द्वारा Olympic श्रेणी के तीन जहाजों की अवधारणा, डिजाइन, निर्माण और White Star Lines को वितरण किया गया था। दूसरे मामले में हमारे पास R.M.S. Titanic है जिसे उसके बड़े भाई R.M.S. Olympic से अधिक customized किया गया, प्रारंभिक उत्पादन में पूर्ण किया गया और एक service के रूप में, उन यात्रियों को प्रदान किया गया जिन्हें वह Southampton और New York के बीच ferry करना था। scope बनाए रखने के लिए मैं R.M.S. Titanic के डूबने के बाद दो बहन जहाजों पर लागू की गई testing, bug fixes, repairs, scope changes और enhancements के और भी बड़े project पर चर्चा नहीं करूंगा। R.M.S. Olympic और H.M.H.S. Britanic दोनों ने अपनी सेवा के वर्षों के दौरान कई बदलाव देखे जिनमें Britanic का ocean liner की भूमिका से His Majesty's Navy के प्रमुख hospital ship के रूप में re-scoping और Olympic को double hull और अतिरिक्त life boats से लैस करना शामिल था क्योंकि crew ने तब तक उस पर सवार होने से इनकार कर दिया जब तक उसे अधिक सुरक्षित नहीं बनाया गया। ("Olympic")

यहाँ मेरा लक्ष्य Titanic की अवधारणा से लेकर service delivery तक और अंततः service failure तक जांच करना है। इस दृष्टिकोण से Titanic के साथ वैसा ही व्यवहार किया जा सकता है जैसा आधुनिक Software-as-a-Service (SaaS) project के साथ किया जाता है। Titanic जैसे जहाज या Salesforce.com या SugarCRM जैसे SaaS products की प्रकृति के कारण हमें उत्पाद के इच्छित जीवनकाल और ongoing upgrades और maintenance पर विचार करने की आवश्यकता है जो इसे चालू रखने के लिए आवश्यक होंगे। Titanic को समुद्र में pilots, seamen, chefs, porters, stewards और अन्य कर्मचारियों की एक बड़ी टीम की आवश्यकता है और re-outfitting, repairs की आवश्यकता थी और, यदि वह बची होती, तो उसे R.M.S. Olympic की तरह एक नया double-hull की आवश्यकता होती। एक SaaS project को इसी तरह datacenter और networking को बनाए रखने के लिए एक staff की आवश्यकता होगी, ongoing upgrades और bug-fixes, नई features आदि। Titanic और SaaS project दोनों के मामले में एक real potential है कि service disruption बेहद महंगा साबित हो सकता है। स्थिर, विश्वसनीय operations बनाए रखना इन दोनों business plans की सफलता में एक प्रमुख कारक है।

आइए Titanic को साकार करने के project के हमारे विश्लेषण की शुरुआत stakeholders की जांच करके करें। हम आसानी से Titanic के यात्रियों और crew को stakeholders के रूप में पहचान सकते हैं, एक company के रूप में White Star Lines के साथ-साथ project engineers, निर्माताओं के रूप में Harland-Wolff, Harland-Wolff में shipwrights और designers के रूप में Alexander Carlisle और Thomas Andrews, service delivery के लिए जिम्मेदार Captain Edward John Smith और अंत में White Star director Joseph Bruce Ismay और उनके executive staff जो project sponsor की भूमिका में थे। इस आकार के किसी भी project में कई महत्वपूर्ण खिलाड़ी होंगे जिनमें से सभी की project में कुछ न कुछ हिस्सेदारी होती है। हम Titanic project में सबसे प्रमुख stakeholders के रूप में केवल इन प्रमुख लोगों पर ध्यान केंद्रित करेंगे।

Titanic project IT Project Management की भाषा में Waterfall Model से सबसे अधिक मिलता-जुलता था। यह process White Star Lines का प्रतिनिधित्व करने वाले Joseph Bruce Ismay और उनके ship building partner Harland-Wolff का प्रतिनिधित्व करने वाले Lord James Pirrie के बीच संयुक्त रूप से एक उच्च स्तरीय अवधारणा से शुरू हुई। Project दोनों कंपनियों के बीच संयुक्त रूप से तैयार किया गया था। Titanic दोनों कंपनियों के लिए बड़ी प्रतिष्ठा और लाभ की संभावना प्रदान करेगा और दोनों से बड़े निवेश की आवश्यकता होगी। जबकि मूल project charter आज हमारे लिए उपलब्ध नहीं दिखता, हम Ismay और Lord Pirrie के बीच की बैठक को अनौपचारिक project charter और project की शुरुआत के रूप में देख सकते हैं। (Sadur)

Olympic class ships का तकनीकी डिजाइन Harland-Wolff के head shipwright Alexander Carlisle द्वारा किया गया था, इसके बाद जब Ismay और Lord Pirrie द्वारा उच्च स्तरीय योजनाएं तैयार की गई थीं। Carlisle 1910 तक project के शुरू से lead designer थे जब वे सेवानिवृत्त हुए और lead design की भूमिका Thomas Andrews को सौंप दी जो Harland-Wolff के managing director थे (Brander 1998)। Andrews Titanic के design के अंतिम चरणों के लिए जिम्मेदार होंगे। Olympic, जो 1910 के पतझड़ में launch हुई, सबसे अधिक संभावना Carlisle के निर्देशन में पूरी तरह से डिजाइन की गई होगी। चूंकि Titanic ने Olympic के लगभग सभी infrastructure (hull design, compass placement, lifeboats, bridge, आदि) साझा किए इसलिए हम सुरक्षित रूप से मान सकते हैं कि Titanic के design में Andrews का योगदान अधिकतर aesthetic था या, software development के शब्दों में, "interface" से संबंधित था। (Thinkquest)

Shipbuilding की construction जैसी प्रकृति के कारण और विशेष रूप से Olympics जैसे विशाल जहाजों के साथ design process में भारी upfront design शामिल है जिसमें बाद में बहुत सीमित feedback loops होते हैं जब designers जहाज का भौतिक रूप से निरीक्षण कर सकते हैं। Software के शब्दों में इसे "Big Design Up Front" या BDUF कहा जाता है। Software में जहां बदलती जरूरतें सामान्य हैं यह आम तौर पर बहुत बुरी practice मानी जाती है लेकिन mechanical और structural engineering में यह केवल एकमात्र उचित समाधान है।

जैसे-जैसे Olympics पर काम आगे बढ़ा, जहाजों के core infrastructure design के बारे में कई निर्णय लिए गए। यह विशेष रूप से खतरनाक है क्योंकि इस प्रकार के project के लिए उपयोग की जाने वाली methodology को plans के approved होने के बाद इस प्रकृति के परिवर्तनों की अनुमति देने के लिए डिजाइन नहीं किया गया था। एक जहाज को एक holistic system के रूप में डिजाइन किया गया है जिसमें interdependent safety systems और उच्च degree of complexity है। अधिकांश software के विपरीत सुरक्षा सुनिश्चित करने के लिए आवश्यक accuracy की degree तक एक जहाज का rapid-prototype करना बहुत मुश्किल है। Safety systems में प्रमुख परिवर्तनों के लिए सही तरीके से किए जाने के लिए specifications के पूर्ण पुनर्कार्य की आवश्यकता होती। लेकिन चूंकि लागत बचत, timeline issues और luxury appointments के कारण परिवर्तन किए गए थे इसलिए परिवर्तनों में बहुत कम holistic thinking लगाई गई। (Kozak-Holland)

Olympics का मूल design और intent यह था कि वे सुरक्षा के लिए नवीनतम technologies को शामिल करेंगे। प्रारंभिक design पूर्ण होने के बाद White Star Lines और विशेष रूप से J.B. Ismay की ओर से architects और engineers पर luxury apartments के पक्ष में safety features को हटाने के लिए business pressure डाला गया। दो सबसे प्रसिद्ध परिवर्तन थे, निश्चित रूप से, lifeboats को हटाना ताकि cabins से view अनावश्यक रूप से बाधित न हो और एक expanded grand ballroom facility की अनुमति देने के लिए कई bulkheads को no longer seal करने और water level से केवल दस feet ऊपर उठने के लिए modify करना। IT projects की तरह, core systems के लिए engineering decisions आम तौर पर business executives की समझ से परे होते हैं। Business side के निर्णयों को अन्यथा technical निर्णयों को प्रभावित करने की अनुमति देना खतरनाक है क्योंकि सामान्य सावधानियां और thought processes को bypass किया जाता है और expertise को नजरअंदाज किया जाता है। इस मामले में ये मानव जीवन की देखभाल और संरक्षण से संबंधित मुद्दे थे। Software में हमारे पास शायद ही कभी ऐसा महत्वपूर्ण काम होता है लेकिन key systems की समझ के बिना business managers को उनके design में शामिल होने की अनुमति देना अत्यंत हानिकारक हो सकता है, भले ही परिणाम business की हानि या संचालन की अधिक लागत जितना हानिरहित हो।

Olympics' designs में देर से किए गए परिवर्तनों से उत्पन्न सबसे नाटकीय समस्याओं में से एक यह थी कि परिवर्तन, प्रत्येक अपने आप में छोटे होने के कारण, सबसे संभावित रूप से कभी भी एक साथ नहीं लिए गए और उस तरीके से एक पूरे के रूप में जांचे गए जैसे मूल जहाज डिजाइन पर विचार किया गया था। जब lifeboats हटाए गए तो शामिल engineers सोच रहे थे कि जहाज को एक floating life raft के रूप में डिजाइन किया गया है और life boats का उद्देश्य केवल यात्रियों को एक motionless ocean liner से दूसरे जहाज तक ferry करना था "worst case scenario" में कि Titanic या Olympic की power चली जाए। एक collision भी उनसे बस पानी में नीचे float करने की उम्मीद थी, डूबने की नहीं। White Star Line की executive committee के आग्रह पर lifeboats को तब तक हटाया गया जब तक केवल minimum legal संख्या नहीं बची। Engineers के लिए यह एक acceptable, हालांकि अनुशंसित नहीं, safety trade-off होता। जहाज का design ऐसा था कि अतिरिक्त life boats एक legal requirement नहीं थे और न ही उन्हें रखने की कोई driving need थी क्योंकि अतिरिक्त boats की usefulness को minimal माना जाता था। अंत में, यह engineers का नहीं बल्कि White Star का निर्णय होता जो shipbuilders का final customer था और जिनके निर्णय उन्हें उनकी आजीविका प्रदान करते थे।

अपने आप में lifeboats को हटाने का निर्णय, सबसे संभावित रूप से, एक minor निर्णय होता। लेकिन इसके अतिरिक्त Olympics के core structural design को सभी tall bulkheads से बदलकर उनमें से चार को waterline से केवल दस feet ऊपर तक significantly कम करने का निर्णय था जिसका अर्थ था कि एक floating life raft के रूप में जहाज की अवधारणा से समझौता किया गया। Bulkheads वास्तव में कभी भी water tight नहीं थे जैसा कि marketing materials हमें विश्वास दिलाते, लेकिन वे काफी tall और बहुत water "resistant" थे और सबसे संभावित रूप से एक बहुत serious hull breach के तहत भी उनके बीच पानी को travel करने से रोकने में सक्षम होते। चूंकि जहाज का प्रारंभिक design safety features से भरपूर था इसे lifeboats की तरह एक redundant feature माना जाता और इसका हटाना जहाज को अधिक सामान्य safety criteria तक नीचे लाना भर होता। व्यक्तिगत रूप से लिए गए परिवर्तन अधिकतर innocuous थे, लेकिन एक साथ लिए गए परिवर्तन जहाज का एक complete redesign बन गए और पूरी तरह से विनाशकारी थे। किसी भी बिंदु पर qualified engineers ने वापस जाकर सभी परिवर्तनों के साथ जहाज की safety features का एक complete reassessment नहीं किया।

कुछ मायनों में हम J.B. Ismay को एक micro-manager के रूप में देख सकते हैं। उन्होंने उन लोगों के निर्णयों पर भरोसा नहीं किया जिन्हें उन्होंने उनकी technical expertise के उद्देश्य से hire किया था और उनके निर्णयों को, प्रत्यक्ष या अप्रत्यक्ष दबावों के माध्यम से, override किया। Micro-managing के कई नकारात्मक परिणाम होते हैं। स्पष्ट है कि untrained और unqualified managers ऐसे निर्णयों को प्रभावित करते हैं जो दूसरे मानते हैं कि qualified professionals से आए हैं। इनमें project team द्वारा उत्पन्न value को कम करना और employee loyalty और morale को कमजोर करना भी शामिल है।

Ship building में, ऐसी situations में जहां जहाजों को Titanic की तरह एक class का बनाया जाता है, हमें तीन प्रमुख project phases पर विचार करने की आवश्यकता है - prototype का design और construction, Olympic; design refinement और Titanic का construction; और अंततः service delivery और operations। Titanic के विशेष मामले में हम देखते हैं कि प्रमुख design और कोई भी structural changes Olympic के पूरा होने से पहले किए गए थे। Thomas Andrews Olympic पर sailed थे लेकिन यह ज्यादातर इसलिए था ताकि वे Titanic के लिए aesthetic modifications कर सकें क्योंकि उस बिंदु पर structural काम को बदलना बहुत देर हो चुकी थी। इसी कारण से, Andrews Titanic पर sailing कर रहे थे ताकि वे जल्द ही launch होने वाले Britanic (Andrews को Gigantic के नाम से जाना जाता था) के लिए ऐसा ही कर सकें।

Project scope के संदर्भ में हम देख सकते हैं कि project प्रारंभ में स्थापित plan के करीब रहा। Construction पूर्व-approved plans के आधार पर किया गया था जिसमें बहुत कम परिवर्तन हुए। Scope में सबसे नाटकीय परिवर्तन Titanic के construction के दौरान हुए जब Olympic की repairs को accommodate करने के लिए project को रोकना पड़ा। Harland-Wolff और White Star Lines दोनों ने समझा कि Titanic में देरी होगी लेकिन Olympic की serviceability को प्राथमिकता मिलती है। किसी भी प्रकार के capital construction project में एक प्रमुख कारक build phases के बीच contract level agreements की आवश्यकता है क्योंकि scope change को accommodate करना construction शुरू होने के बाद लगभग असंभव है। ("Olympic")

Software projects खोजना मुश्किल है जो production prototype के बाद prototype पर आधारित लेकिन उसके समान न होने वाली production implementations की एक series के साथ इस प्रकार के model का closely पालन करते हैं। इसका सबसे करीबी उदाहरण जो मैं सुझा सकता हूं वह है enterprise resource planning (ERP) package SAP। इस package के साथ, और इस जैसे अन्यों के साथ, customers package को उसके prototypical performance और features के आधार पर खरीदते हैं और फिर या तो स्वयं या किसी consulting firm या original vendor के माध्यम से package को अपनी जरूरतों के अनुसार heavily modify करते हैं। आम तौर पर इस approach का advantage यह है कि software package का core, infrastructure, बहुत stable और well tested है और अक्सर situations की एक wide degree में उपयोग किया जाता है जो इसे project side के साथ-साथ client side testing दोनों प्रदान करता है। निश्चित रूप से care लेनी होगी क्योंकि customer-initiated modifications को उस deep testing का benefit नहीं मिलेगा जो आशा है कि core infrastructure पर perform किया गया है और न ही changes को wider client community से "many eyes" का benefit मिलता है।

Olympic class ships के मामले में जहाज के पंद्रह foot model पर serious testing की गई थी और Olympic के पूरा होने पर उस पर testing की गई थी। Olympic की complexity वाले जहाज के साथ यह critical है कि individual systems के unit testing के अलावा real world testing भी perform किया जाए। Olympic को उस प्रकार के जहाज के लिए standard usual testing measures से गुजारा गया था। हालांकि, जब Titanic बनाया गया तो builders और cruise line ने फैसला किया कि चूंकि Titanic essentially Olympic की एक copy थी इसलिए Olympic पर की गई testing और Olympic का ongoing successful उपयोग Titanic के लिए पर्याप्त test था और Titanic को बहुत कम additional testing मिली। हालांकि, यह best practice नहीं है क्योंकि mariners जानते हैं कि सभी जहाज, यहां तक कि copies भी, अलग तरह से व्यवहार करते हैं और प्रत्येक vessel unique है और उसे अपने आप test किया जाना चाहिए। (Kozak-Holland)

Titanic को testing या performance trials के लिए लगभग कोई समय नहीं दिया गया। यह आंशिक रूप से इसलिए हुआ क्योंकि Olympic की एक serious accident हुई थी और उसे Belfast के shipyards में ले जाकर repair करना पड़ा था। जबकि Olympic repairs के दौरान थी, Titanic को प्रतीक्षा करनी पड़ी क्योंकि उस आकार के केवल एक जहाज पर एक समय में काम किया जा सकता था। इसने Titanic पर business time constraints रखा क्योंकि उसे नियमित transatlantic route duty के लिए scheduled किया गया था और तुरंत आवश्यक था। इस वजह से कुछ additional testing जो शायद होती, छोड़ दी गई और Titanic को Belfast से Southampton तक की यात्रा के साथ primary testing के साथ भेजा गया, और यहां तक कि उसकी यात्रा के इस leg पर भी कम से कम एक paying passenger था जिससे यह एक proper test की बजाय एक low capacity true voyage अधिक बन गई। (Kozak-Holland)

ऐसा लगता है कि White Star Lines और J. B. Ismay जहाज को जल्द से जल्द regular service में लाने के लिए exceptional project risk लेने के लिए काफी तैयार थे। Standard maritime procedure के माध्यम से उन्होंने maritime insurance के माध्यम से अपने capital risk का बहुत कम किया। यह उन्हें कई संभावित unknowns से बचाता।

उन्नीसवीं शताब्दी के उत्तरार्ध के दौरान shipping lines और governments दोनों के लिए risk को low priority issue के रूप में देखना तेजी से आम होता जा रहा था। 1858 में बना S.S. Great Eastern को real world cases में उसके बाद के अगले चौवन वर्षों में आने वाले increasingly unsafe ocean going vessels के designs की तुलना में far safer माना जाता था और साबित हुआ था। Titanic के डूबने के बाद companies और governments ने situation का पुनर्मूल्यांकन करने तक conditions decline होती रहीं। यह तर्क दिया जाता है कि shipping companies ने decades के relatively incident-free shipping पर अपने lackadaisical attitude towards safety को justify करते हुए acceptable safety track records को देखा। Financial market pressures ने loose safety standards वाली companies को favor करते हुए industry को expensive risk management से दूर ले जाने के लिए प्रोत्साहित किया। (Brander 1995)

Testing और training की कमी के कारण risks को और कम करने के बहाने के तहत, कई crew members, विशेष रूप से Captain Smith, को Olympus से Titanic की maiden Atlantic crossing पर sail करने के लिए लाया गया। इसे Ismay के experience की तलाश के रूप में देखा जा सकता है जो directly test किए बिना जहाज को sail करने से derived "unknowns" को कम करने के लिए प्रतीत होता है, लेकिन कम से कम prototype vessel से maximum experience होने के साथ। हालांकि, यह underlying reason नहीं हो सकता है और यह बहुत संभव है कि Captain Smith को इसलिए चुना गया क्योंकि White Star Lines के साथ उनकी position H.M.S. Hawke से जुड़ी एक serious accident के बाद काफी questionable थी जिसने Olympic को emergency repairs की जरूरत बनाई थी और Titanic की sailing को delayed किया था। Captain Smith संभवतः nervous, अपने career के बारे में concerned और यदि firm के pressure ने उन्हें उनके better judgment के खिलाफ निर्देशित किया तो जहाज पर जिम्मेदारी के final level के रूप में कार्य करने की कम मनःस्थिति या स्थिति में थे। यह शायद वही operational loophole था जो White Star Lines खोज रही थी। यह situation शायद Captain Smith के Southampton में moored S.S. City of New York के too close या too fast आने से और बढ़ गई, जिससे वह अपनी moorings तोड़ने और Titanic के साथ लगभग collide करने के कारण बनी। (Kozak-Holland)

Customary maritime law के तहत, एक captain जहाज का absolute commander होता है और समुद्र में रहते हुए उसका complete jurisdiction होता है, भले ही higher ranking officials, military या civilian, aboard हों। Captain का moral और legal responsibilities पहले यात्रियों और crew की जान और सुरक्षा के प्रति और फिर cargo और जहाज के प्रति होती है। (Kuntz)

एक बार जब Titanic बनाई, outfitted और sailing के लिए available थी, तो हम एक stage change देखते हैं और overall Titanic project के service delivery phase में चले जाते हैं। इस stage में हम project management के पारंपरिक stages से आगे हैं। अधिकांश scenarios में एक client ने अब finished product का possession ले लिया होता। लेकिन Titanic के मामले में यह service delivery phase बन जाता है।

Service delivery के तहत White Star Lines ने जहाज के साथ उत्पन्न होने वाले किसी भी नए issues की जिम्मेदारी ली। इस बिंदु पर design - build - test की पारंपरिक system का उपयोग अब नहीं किया जाएगा और बजाय इसके service delivery standard operating procedure या SOP द्वारा oversee की जाएगी। Ongoing ship modifications, repairs, tuning और इसी तरह की चीजें जारी रहेंगी लेकिन इन्हें service interruption की आवश्यकता न होने के लिए designed किया जाएगा बल्कि minor होंगी और final customers - यात्रियों - की जानकारी के बिना की जाएंगी। यह वह stage है जहां यात्री हमारे सबसे critical stakeholders के रूप में आते हैं क्योंकि इस scenario में वे न केवल financial stakeholders हैं बल्कि literally जहाज की reliability और crew के operations पर अपनी जान लगा रहे हैं।

Agile Project Management community में stakeholders के भीतर roles को denote करने के लिए एक fable अक्सर उपयोग की जाती है। इन roles को pigs and the chickens के रूप में जाना जाता है। Fable हमें एक chicken और एक pig के बारे में बताती है जो एक साथ एक restaurant खोलने में interested हैं। Pig ने chicken से पूछा कि वे क्या serve करेंगे। Chicken ने जवाब दिया, "Well, bacon and eggs, of course." इस पर pig ने जवाब दिया "I don't think that I am interested. You will be involved but I will be totally committed." (Schwaber 7)

Pig और chicken का metaphor सामान्यतः उन stakeholders के बीच अंतर व्यक्त करने के लिए उपयोग किया जाता है जिनके real money या careers दांव पर हैं बनाम वे stakeholders जिनकी project में एक vested लेकिन non-critical interest है। Chickens project को fail होते नहीं देखना पसंद करते लेकिन failure जरूरी नहीं कि उनके लिए devastating हो। Titanic के मामले में हम देखते हैं कि financial stakeholders, Harland-Wolff और White Star Lines, effectively chickens थे। उन्हें बहुत कुछ खोना था लेकिन उनका investment insured था और बाद में, जैसा कि हम देखेंगे, government भी उस समय Austria और Germany के साथ pending war के कारण इस प्रकृति की companies की रक्षा करने के लिए तैयार थी। न White Star और न Harland-Wolff "totally committed" थे - उनकी definite interest थी और Titanic की सफलता उनके लिए extremely important थी लेकिन Titanic के यात्री और crew truly pigs थे जो literally अपनी जान दांव पर लगाने के लिए तैयार थे। Chicken और pig का metaphor शायद ही कभी इतना उपयुक्त हो।

Ongoing service की higher quality सुनिश्चित करने के लिए Harland-Wolff का एक guarantee group maiden voyage पर present था। इस team में Harland-Wolff के design और construction staff के कई important members शामिल थे जिनमें lead designer Thomas Andrews भी शामिल थे। यह guarantee group Harland-Wolff के सभी major projects पर customary था। यह staff voyage time का उपयोग उनके tests से अलग conditions के तहत construction का assessment करने, customer satisfaction का आकलन करने और improvement के opportunities खोजने के लिए करेगा। Thomas Andrews पहले से ही इसी उद्देश्य के लिए Olympic पर sailed थे और Titanic को improve करने के लिए कई tiny changes किए थे। वह इस journey के कुछ हिस्से में, उदाहरण के लिए, passenger rooms के लिए कम expensive clothing hooks design करने में बिताएंगे। ("Guarantee Group")

Guarantee Group में Harland-Wolff के भीतर कई अलग-अलग technical practices के specialists का प्रतिनिधित्व था। हम fitters, electricians, joiners, draughtsmen, design team और अन्य से प्रतिनिधित्व देखते हैं। यह group, अपने varying specialist areas और seniors और apprentices दोनों सहित अनुभव के अलग-अलग levels के साथ, जहाज बनाने वाली project team का exceptional cross-section होता। उनकी craftsmanship, design और अन्य final components का appraisal देने में दी गई care के साथ aboard उनकी presence को दो प्रमुख तरीकों से देखा जा सकता है।

पहले तरीके में हम इसे Titanic Project पर perform किए गए "post-mortem" के रूप में देख सकते हैं। इस team की भूमिका project की technical success का assessment करना और improvement के क्षेत्रों की तलाश करना था और साथ ही "lessons learned" generate करना था ताकि future projects यहाँ gained experience से benefit कर सकें। Transatlantic trip की cost और उनके regular duties से दूर बिताए गए समय को देखते हुए यह Harland-Wolff द्वारा project knowledge में एक serious investment था और अत्यंत commendable था।

एक अलग दृष्टि से, इस guarantee group को एक construction iteration पर feedback प्रदान करने के रूप में देखा जा सकता है। Olympic का construction पहला iteration होता, Titanic का दूसरा और Britanic का तीसरा। इस approach में हम एक प्रकार की Agile feedback loop का उपयोग होते देखते हैं, जितना संभव हो, ऐसे extreme capital construction project पर भी customer input की अनुमति देने के लिए। Iterations बहुत long हैं, लेकिन यह necessity से है। इस तरह हम Titanic को एक project के रूप में, एक discrete deliverable के रूप में, साथ ही Olympic family of vessels के माध्यम से passenger service deliver करने के ongoing project के हिस्से के रूप में देख सकते हैं।

Guarantee group का aboard ship होना technical teams को उनके product के real world application की first-hand appreciation प्राप्त करने का opportunity प्रदान करता। 1912 में एक technical specialist का इस level की luxury वाले जहाज पर travel करने की position में होना दुर्लभ होता। Harland-Wolff की sponsorship के बिना अपने staff को उनकी own workmanship को काम करते देखने का यह chance प्रदान करने में वे शायद कभी नहीं समझते कि final customers को services प्रदान करने में उनकी own roles क्या हैं।

Guarantee group में apprentices को शामिल करने का मतलब था कि direct one-on-one या small group, informal training perform की जा सकती थी। Apprentices और senior technicians के पास एक साथ काम करने के कई days होते, और apprentices को एक ऐसे setting में अपने seniors से सीखने का great opportunity मिलता जो team building और knowledge transfer के लिए conducive होती। कई मायनों में हम इस समय को off-campus team building sessions या retreats के समान देख सकते हैं जो आज कई companies और project groups में popular हैं।

Titanic के हमारे विश्लेषण में सबसे बड़ा surprise जहाज पर उपयोग में standard operating procedure की लगभग पूर्ण कमी है। कुछ processes और procedures documented थे लेकिन कई नहीं थे। ऐसे processes के उदाहरण जो standardized नहीं थे उनमें key communications processes शामिल थे जैसे wireless office से bridge तक messages ले जाना, passengers को जहाज के डूबने की alert करना और bridge को alert करना कि crow's nest ने एक iceberg देखा है। (Kozak-Holland)

Standard Operating Procedures किसी भी service delivery situation में absolutely critical हैं। कुछ companies में इन्हें company की core intellectual property के रूप में भी इतना valuable माना जा सकता है। SOP के बिना एक company staff की inherent "teamness" से अधिक cohesive नहीं होती जो नए employees के मामले में nominal हो सकती है। Staff को पूरी तरह से best practices, convention, informal staff instruction या, hopefully, training पर rely करना होगा अपनी jobs और processes सीखने के लिए। लेकिन ये standardized नहीं होंगे यदि लिखे नहीं गए हैं और training inevitably trainer से trainer तक vary करेगी और कोई भी employee सभी possible scenarios के लिए सभी instructions retain नहीं कर सकता।

Normal conditions के तहत standard operating procedures की कमी relatively minor importance की हो सकती है। Staff अधिकांश job functions adequately perform कर सकते हैं, विशेष रूप से यदि trained हों, SOP की आवश्यकता के बिना। यदि उन्हें SOP की आवश्यकता होती तो उन्हें इसे हर समय साथ रखना होता। जब SOP extremely critical बन जाती है वह तब है जब "normal operating procedures" उपलब्ध नहीं होते या, modern terms में, जब operations अब BAU (Business as Usual) conditions के तहत नहीं है। Titanic के लिए, BAU conditions iceberg incident से कई hours पहले टूट गई थीं।

Titanic के मामले में standard operating procedures पर चर्चा करना communications पर चर्चा किए बिना मुश्किल है। इसलिए हम BAU conditions के तहत communications से शुरू करेंगे और फिर देखेंगे कि SOP की कमी ने situation को तेजी से कैसे deteriorate किया।

Titanic शुरू से ही communication design flaws से plagued थी। Wireless room, Titanic में और बाहर जाने वाले सभी communications के लिए जिम्मेदार, White Star Lines द्वारा नहीं बल्कि Marconi personnel द्वारा staffed किया गया था जिन्हें पहले और सबसे पहले passengers के लिए communicate करने और यदि time allow करे तो ही जहाज के लिए communicate करने के लिए paid किया गया था। Wireless operators overworked और undervalued थे और अक्सर bridge को messages relay नहीं करते थे क्योंकि उनके अन्य duties थे जिन्हें Marconi, उनके employer, द्वारा higher priority का माना जाता था। Titanic के wireless room को कम से कम आठ iceberg warnings भेजी गई थीं लेकिन इनमें से केवल कुछ ही bridge को relay की गईं। (Kozak-Holland)

इस मामले में service level agreement के माध्यम से third party contractors को manage करने के महत्व पर जोर देना महत्वपूर्ण है। White Star Lines को, Marconi Company को अपना wireless room staff करने की अनुमति देते हुए, एक clear SLA होना चाहिए था जो यह demand करे कि जहाज के लिए safety और emergency communications को crew के personal messages पर absolute priority मिले। उन्हें Marconi को financially benefit नहीं करने देना चाहिए था या SLA का पालन न करने से financially benefit नहीं उठाने देना चाहिए था। एक outside contractor के रूप में Marconi के पास एक contract होनी चाहिए थी जो mutual benefit के लिए designed हो - यानी कि जब stated के अनुसार execute किया जाए तो यह सभी parties के mutual benefits के लिए correctly act करना हो। Vendors के बीच ऐसे contracts जो vendors को उनके clients के भले के खिलाफ काम करने के लिए financial incentives देते हैं बहुत unwise हैं।

Marconi operators से जुड़ा सबसे महत्वपूर्ण single incident SS California द्वारा भेजी गई final iceberg warning थी, जो Titanic के बहुत नजदीक थी - इतनी नजदीक कि बाद में वह Titanic के emergency rockets देखने वाला जहाज होगी। California ने Titanic को radio किया था कि वह pack ice में फंस गई है और dangerous conditions के कारण किसी भी speed से आगे नहीं बढ़ सकती। Marconi operator ने जवाब दिया "Shut up, shut up, I am busy. I am working Cape Race and you are jamming me." यह बमुश्किल स्पष्ट किया जा सकता था कि wireless room की priorities कहाँ थीं, यहां तक कि इतने करीब looming danger के साथ भी। न केवल wireless room ने California के साथ communications open नहीं रखीं बल्कि उन्होंने इस final external warning के बारे में bridge को inform करने से भी इनकार किया। Frustration में California के radio operator ने Titanic को warn करने के अपने attempts छोड़ दिए, अपना wireless बंद कर दिया और सोने चले गए। Marconi operators ने न केवल warnings को heed करने में fail किया बल्कि external channels को alienate किया ताकि उनके rescue करने के लिए काफी नजदीक एकमात्र जहाज ने तब respond नहीं किया जब Titanic डूबने लगी। (Kuntz)

Bridge से crew और passengers तक communications के लिए कोई official process नहीं था, यह manual था और best effort manner में था यदि यह attempt किया जाता था। Bridge ने किसी को नहीं बताया कि एक collision immanent था और कोई भी उस impact के लिए braced नहीं था जो बहुत serious हो सकती थी। एक बार जहाज डूबने लगी तो एक hour से अधिक समय बीत गया इससे पहले कि bridge ने ship के बाकी हिस्से को inform करना शुरू किया कि वे जा रहे हैं। यात्रियों और crew की जान को प्रभावित करने वाली key information उनसे रखी गई थी और केवल कुछ bridge personnel के पास थी जो सबसे अधिक संभावना incident को secret रखने या human life के obvious risk के publicity को minimize करने की उम्मीद कर रहे थे। चूंकि bridge से general ship तक communicate करने के लिए कोई system या process नहीं था यह एक simple matter था क्योंकि passengers को किसी भी news से inform करने के लिए एक concerted effort लगती थी। (Kozak-Holland)

Crew के बीच communications थोड़ी बेहतर थीं। उदाहरण के लिए, Officer of the Watch, bridge के बाहर स्थित था लेकिन उसके critical communications links bridge house के अंदर स्थित थे। इसलिए watch किसी अन्य bridge personnel को rapidly communicate करने या crow's nest और अन्य related functional areas के साथ coordinate करने में असमर्थ था। Crow's nest और watch एक one way bell system से connected थे जो उन्हें duplex में communicate करने की अनुमति नहीं देता था और बहुत slow था, और watch के पास helm पर quartermaster से emergency command दिए जाने पर feedback का कोई means नहीं था। Commands को open air से enclosed bridge की ओर shouting करके दिए गए थे। Watch केवल यह hope कर सकता था कि bridge के अंदर quartermaster ने सुना, समझा और उन commands पर acting कर रहा है। Standard compass से communications उतनी ही खराब थीं। Compass, bridge के ऊपर या नजदीक होने की बजाय, far to the aft रखा गया था और bridge को नियमित आधार पर compass के साथ coordinate करने के लिए forced होना पड़ा जिससे बहुत confusion और delays हुए। Bridge को effective या safe बनाने के लिए, यदि कोई था, बहुत कम सोचा गया था। Communication के लिए design की यह कमी निश्चित रूप से Titanic की कम से कम help करती जब rapid और accurate communications आवश्यक थे। (Brown)

जब Boston में White Star office को external communications अंततः भेजी गई तो relay की गई information यह थी कि कोई serious damage नहीं थी और incident बहुत minor था। हालांकि, आज के common point to point information के विपरीत, यह information broadcast की गई थी और अन्य जहाजों और relay stations द्वारा आसानी से intercepted की जा सकती थी। Ship-to-shore communications को अक्सर एक internal communiqué के बहाने press को effectively information release करने के लिए उपयोग किया जाता था। इसलिए honest और critical information relay करने की बजाय wireless को एक marketing tool के रूप में उपयोग किया गया। जो भेजा गया वह distress signal नहीं था बल्कि effectively situation पर "spin" डालने के लिए designed एक press release से ज्यादा कुछ नहीं था। (Kozak-Holland)

किसी भी project के किसी भी stage में Communications महत्वपूर्ण होती है। Titanic के मामले में catastrophic situation उन issues को highlight करती है जो communications के कारण हुए, लेकिन यह simply एक worst case scenario है। Projects को decisions लेते समय जितना संभव हो उतना up-to-date और accurate data होना चाहिए। इसके बिना decisions केवल एक partial available picture का उपयोग करके लिए जाते हैं और जितनी कम correct information उपलब्ध होगी उतनी ही कम संभावना होगी कि एक अच्छा decision लिया जा सकता है।

शायद Titanic को प्रभावित करने वाला सबसे बड़ा project management issue, हालांकि, standard operating procedures की कमी थी। SOP को construction process के बाद के stages के दौरान एक essential project deliverable के रूप में produce किया जाना चाहिए था। एक जहाज को उसे operate करने के लिए SOP के बिना seaworthy माना जाना truly inconceivable है। यहाँ तक कि सबसे agile development methodologies भी end-user documentation की आवश्यकता को नजरअंदाज करने में fail होती है।

चूंकि project के design और construction portions Titanic के crew को एक SOP, या कम से कम एक reasonable SOP प्रदान करने में fail हुए (White Star Lines manual में ही कुछ generic standard procedures थीं) इसलिए communications, alerts को track करने, warnings प्रदान करने, आदि से निपटने के लिए clearly defined rules या processes नहीं थे। कोई emergency procedure follow नहीं की जानी थी इसलिए crew को केवल experience और general mariner knowledge पर act करने के लिए मजबूर होना पड़ा।

यह इस बिंदु पर है, जब emergency conditions के तहत crew के actions की जांच की जाती है, कि हम command structure के complete breakdown को देखते हैं। एक traditional business में business executives को generally accepted माना जाता है कि उनके पास किसी भी corporate action पर final decision-making power है जब तक वह legal boundaries के भीतर हो, और अक्सर जब वह नहीं होती। Average business में एक bad operational decision life की हानि नहीं बल्कि revenue की हानि का परिणाम होता है। एक wise executive operations decisions लेने के लिए hire किए गए specialists के decisions को override न करने की आवश्यकता को समझेगा या संभवतः एक board को require होगा कि एक executive अपने staff को सुने। फिर भी, project operations में business side executives के interference का idea best practices के खिलाफ है और widely accepted है कि यह एक bad course of action है।

Titanic के मामले में, Captain Smith समुद्र में vessel के command में थे और जहाज और aboard souls के लिए personally responsible थे। उनके boss, J.B. Ismay, के पास port वापस आने पर Smith को command से हटाने की ability हो सकती थी लेकिन समुद्र में उनके पास वह नहीं था और न ही British mariner law के तहत उन्हें bridge से commands देने का अधिकार था क्योंकि वह licensed mariner नहीं थे। (Kuntz)

Iceberg collision की ओर ले जाने वाले समय के दौरान J. B. Ismay Captain Smith पर जहाज को एक irresponsible speed - चौबीस knots से अधिक या पचहत्तर revolutions - पर drive करने के लिए pressure डाल रहे थे। Olympic, Titanic के "test" माना जाने वाला, ने कभी इस speed पर Atlantic cross नहीं किया था और Titanic अब Olympic पर perform किए गए tests की range से बाहर operate कर रही थी, यहां तक कि normal conditions के तहत एक single Atlantic crossing perform करने के लिए पर्याप्त समय के बिना। Ismay और Smith ने Titanic को उसके known performance parameters से परे और, अधिक महत्वपूर्ण रूप से, crew के known operational parameters से परे drive किया। यह simply unknown था कि इस speed पर जहाज के साथ क्या operational risks शामिल होंगे। icebergs से भरे जाने के लिए जाने जाते waters में जाते हुए भी unsafe माना जाने वाली speed बनाए रखना extremely foolish था।

चाहे panic, confusion, insecurity, आदि के कारण हम नहीं जानते लेकिन जब Titanic iceberg से टकराई तो Captain Smith ने एक layman, J.B. Ismay को bridge पर आने और acting ship's master के रूप में executive orders देने शुरू करने दिए जिसके लिए Captain Smith को Ismay को हटाने का अधिकार और obligation था। Ismay ने key operational decisions लिए जिनमें emergency communications, passenger notification और, सबसे महत्वपूर्ण, Titanic को ice shelf से आगे ले जाना शामिल था जो ship के main rupture का actual cause माना जाता है और फिर जहाज को slow speed से आगे continue करना जो hull को और अलग कर रहा था, यहां तक कि additional information उपलब्ध होने के बाद भी कि जहाज डूबने वाला था। (Kozak-Holland)

Titanic से हम अब जितनी दूरी पर हैं उसे देखते हुए यह assess करना मुश्किल हो सकता है कि followed processes क्या थे और यह जानना कि project के साथ क्या right गया जब हम इतना जानते हैं जो wrong गया। हमारे minds में Titanic का डूबना इतना iconic है कि इसे एक marketing और organizational disaster के अलावा कुछ भी देखना best पर मुश्किल है।

अंत में Titanic project immense था लेकिन well managed था। Scope को controlled किया गया और जरूरी होने पर changes को accommodate किया गया। Well established contractual interface के साथ construction phase में Large design up front का उपयोग किया गया और specifications के इस cementation ने careful और accurate scheduling की अनुमति दी। जिन processes द्वारा जहाजों का निर्माण किया गया था वे standard और well known थे। Historical construction data का उपयोग करके Harland-Wolff construction के लिए आवश्यक समय का accurately predict करने में सक्षम था जिससे White Star Lines ships के actual sailing से बहुत पहले marketing और sales शुरू कर सके। Titanic, Olympic की लगभग identical copy होने के कारण, और भी कम surprises था। एकमात्र true surprise White Star Lines की priorities में बदलाव के परिणामस्वरूप हुई जिसके कारण Titanic project को लगभग एक महीने के लिए hold पर रखा गया।

J. Bruce Ismay के शब्दों में "She [Titanic] was not built by contract. She was simply built on a commission." यह indicate करता है कि Titanic की delivery सुनिश्चित करने के लिए Harland-Wolff को exceptional authority उनके own processes और oversight का उपयोग करने के लिए दी गई थी। दोनों companies एक vendor-customer relationship की बजाय partners के रूप में अधिक operate करती थीं। (Kuntz)

Titanic के लिए Project risk को poor तरीके से handle किया गया, primarily British और American passengers की कीमत पर company को liability lawsuits से बचाने के लिए external insurers और, अंत में, British government पर heavily rely करते हुए। Risk को बहुत low माना जाता था और इस वजह से पहले Olympic के साथ और फिर, जब operational disasters minimal थे, Titanic के साथ और भी अधिक careless decisions लिए गए। Careful risk assessment नहीं किया गया। Expert mariners आसानी और quickly कई risk areas को define कर सकते थे जिन्हें address किया जाना था। ऐसे issues जैसे कि एक complete Standard Operating Procedure की कमी को flagged किया जाता और आसानी से handle किया जा सकता था क्योंकि इसके लिए resources को current Titanic team से नहीं आना होता और delivery date या किसी भी variables को impact नहीं करता जो हम अब समझते हैं कि White Star Lines की primary concern थे।

Project पर communication को बहुत well handle किया गया लगता है जब तक service delivery शुरू नहीं हुई। इस बिंदु पर design flaws, questionable decisions और SOP की कमी जहाज पर communication network पर bear करने लगे। इस communication को operational माना जा सकता है न कि project based लेकिन argument semantic है। Titanic के साथ issues holistic थे और proper design methodologies follow किए जाने पर risk analysis miss नहीं की जाती जो SOP के creation को force करती जो communications issues को highlight या शायद fix भी करती।

इसके core पर question quality का था। Titanic को highest quality transatlantic travel option के रूप में propose और sell किया गया था। Quality को, directly या indirectly, Titanic के बारे में बोले गए लगभग हर breath में heralded किया गया। Customer interface को जितना possible था उतना clean और concise रखा गया। यदि results एक customer द्वारा witnessed किए जाते तो कोई expense नहीं छोड़ा गया। लेकिन project का underlying core या infrastructure (Kozak-Holland के अनुसार non-functional requirements - हालांकि मैं इस context में उनके use से agree नहीं करता) जिस पर यह "quality" rest करनी थी, ignored किया गया और Titanic की true quality और White Star Lines के operations की quality ultimately evident बनने वाली थी।

Bibliography and Sources Cited:

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. "IT Project Lessons from Titanic." Gantthead.com the Online Community for IT Project Managers. (2003): 22 February 2008

Brown, David G. "Titanic." Professional Mariner: The Journal of the Maritime Industry. (2005): 23 February 2008

Sadur, James E. Home page. "Jim's Titanic Website: Titanic History Timeline." (2005): 23 February 2008.

ThinkQuest Library. "Designing the Titanic." (Date Unknown): 25 February 2008.

Titanic-Titanic. "Olympic." (Date Unknown): 25 February 2008.

Titanic-Titanic. "Guarantee Group." (Date Unknown): 25 February 2008.

Brander, Roy. P. Eng. "The RMS Titanic and its Times: When Accountants Ruled the Waves - 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture". (1998): 25 February 2008.

Brander, Roy. P. Eng. "The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management." (1995): 25 February 2008.

Additional Notes:

Mark Kozak-Holland ने 2003 में Gantthead पर Titanic पर अपने articles को एक book में republish किया:

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

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.

First published on SheepGuardingLlama.