إدارة مشروع سفينة RMS Titanic والسفن الأولمبية
بدأت فكرة بناء R.M.S. Titanic وشقيقتيها، R.M.S. Olympic وH.M.H.S. Britanic، تتشكّل لأول مرة عام 1907. وقد شكّلت هذه السفن الثلاث معًا فئة White Star Line الأولمبية من السفن الكبيرة. (سأستخدم عبارة Olympic(s) للإشارة إلى هذه الفئة من السفن في جميع أنحاء هذا النص لأسباب تتعلق بالوضوح.) قليلة هي السفن في تاريخ البشرية التي اكتسبت شهرةً واسعةً وسمعةً مثيرةً للجدل كـ R.M.S. Titanic.
عند دراسة R.M.S. Titanic من منظور إدارة المشاريع، يجدر بنا أولًا تحديد نوع المنتج الذي كان يسعى هذا المشروع إلى إنتاجه. خلافًا لكثير من المشاريع التي يمتلك فيها العميل النهائي المنتج النهائي، صُمِّمت Titanic لتقديم خدمة، وتحديدًا خدمة نقل بحري، لعملائها النهائيين. وهذا ما يُفضي إلى تحدٍّ مثير عند مناقشة "مشروع Titanic"، إذ ترى معظم وجهات نظر إدارة المشاريع أن المشروع يتسم ببداية ونهاية محددتين فضلًا عن أصحاب مصلحة واضحين ومحددي الصلاحيات.
في حالة مشروع من نوع R.M.S. Titanic، يمكننا اعتماد وجهتَي نظر والتعامل مع المسألة من جانبين. في الأول، لدينا المشروع الذي تصوّرت فيه السفن الثلاث التابعة لفئة Olympic وصُمِّمت وبُنيت وسُلِّمت إلى خطوط White Star Lines. وفي الثاني، لدينا R.M.S. Titanic بما أُضيف إليها من تخصيصات تتجاوز سابقتها R.M.S. Olympic، وقد اكتمل إنتاجها الأولي وسُلِّمت كخدمة للركاب الذين كانت ستقلّهم عبر الرحلات البحرية بين ساوثهامبتون ونيويورك. وحرصًا على تضييق نطاق البحث، لن أتناول المشروع الأوسع المتعلق بالاختبار وإصلاح الأخطاء والإصلاحات وتغييرات النطاق والتحسينات التي أُجريت على السفينتين الشقيقتين إثر غرق R.M.S. Titanic. فقد شهدت كلٌّ من R.M.S. Olympic وH.M.H.S. Britanic تغييرات جوهرية عديدة خلال سنوات خدمتهما، شملت إعادة تحديد دور Britanic من سفينة ركاب كبيرة إلى السفينة الحربية الرئيسية لجلالة الملك خلال الحرب العالمية الأولى، وتزويد Olympic بـهيكل مزدوج وقوارب نجاة إضافية بعد أن رفض طاقمها الإبحار عليها حتى تُجعَل أكثر أمانًا. ("Olympic")
هدفي هنا هو دراسة Titanic بوصفها خدمة، من مرحلة التصوّر وصولًا إلى تقديم الخدمة، وفي نهاية المطاف، فشل الخدمة. من هذا المنظور يمكن التعامل مع Titanic تمامًا كما يُتعامل مع مشروع البرمجيات كخدمة (SaaS) الحديث. ونظرًا لطبيعة سفينة كـ Titanic أو منتجات SaaS كـSalesforce.com أو SugarCRM، علينا مراعاة العمر التشغيلي المقصود للمنتج والترقيات والصيانة المستمرة اللازمة لإبقائه يعمل. فالـ Titanic تستلزم طاقمًا ضخمًا من الربابنة والبحارة والطهاة والحمّالين وأصحاب الخدمات في البحر، وتطلّبت إعادة تجهيز وإصلاحات، وكانت ستحتاج لو بقيت إلى هيكل مزدوج كما حصلت عليه R.M.S. Olympic. وبالمثل، يستلزم مشروع SaaS طاقمًا للحفاظ على مركز البيانات والشبكات، وترقيات مستمرة وإصلاح للأخطاء، وميزات جديدة، وما إلى ذلك. في حالتَي Titanic ومشروع SaaS على حدٍّ سواء، ثمة احتمال حقيقي لانقطاع الخدمة الذي قد يكون مكلفًا للغاية. فصون عمليات ثابتة وموثوقة عامل رئيسي في نجاح كلا خطتَي الأعمال هاتين.
لنبدأ تحليلنا للمشروع الرامي إلى تحقيق Titanic بفحص أصحاب المصلحة. يمكننا بسهولة تحديد ركاب Titanic وطاقمها بوصفهم أصحاب مصلحة، وخطوط White Star Lines بوصفها شركة، فضلًا عن مهندسي المشروع، وHarland-Wolff بوصفها المقاولة المنفّذة، وAlexander Carlisle وThomas Andrews بوصفهما بنّائَي سفن ومصمّمَين في Harland-Wolff، والكابتن Edward John Smith المسؤول عن تقديم الخدمة، وأخيرًا مدير White Star Joseph Bruce Ismay وطاقمه التنفيذي الذين كانوا يضطلعون بدور راعي المشروع. وفي أي مشروع من هذا الحجم ستكون ثمة لاعبون كثيرون مهمون لديهم جميعًا مصلحة ما في المشروع. وسنركّز فقط على هؤلاء الأشخاص الرئيسيين بوصفهم أبرز أصحاب المصلحة في مشروع Titanic.
أشبه ما يكون مشروع Titanic بـالنموذج التسلسلي (Waterfall) في مصطلحات إدارة مشاريع تقنية المعلومات. انطلقت العملية من مفهوم رفيع المستوى جاء مشتركًا بين Joseph Bruce Ismay ممثلًا لخطوط White Star Lines واللورد James Pirrie ممثلًا لشريكهم في بناء السفن Harland-Wolff. وقد تصوّر الشركتان المشروع معًا. وكانت Titanic ستمنح كلتا الشركتين هيبةً رفيعة وإمكانات ربح واعدة وستستلزم استثمارًا ضخمًا من كلتيهما. وعلى الرغم من عدم توفر وثيقة الميثاق الأصلية للمشروع لنا اليوم على ما يبدو، يمكننا النظر إلى اجتماع Ismay واللورد Pirrie باعتباره ميثاق المشروع غير الرسمي وانطلاقة المشروع. (Sadur)
اضطلع Alexander Carlisle، كبير بنّائي السفن في Harland-Wolff، بالتصميم التقني لسفن فئة Olympic بعد أن رسم Ismay واللورد Pirrie الخطط رفيعة المستوى. وكان Carlisle هو المصمم الرئيسي للمشروع منذ بدايته حتى عام 1910 حين تقاعد وسلّم دور التصميم الرئيسي إلى Thomas Andrews، المدير التنفيذي لـ Harland-Wolff (Brander 1998). وكان Andrews مسؤولًا عن المراحل الأخيرة من تصميم Titanic. وكانت Olympic، التي أُطلقت في خريف عام 1910، قد صُمِّمت في معظمها على الأرجح تحت إشراف Carlisle. وبما أن Titanic تشترك مع Olympic في معظم بنيتها التحتية (تصميم الهيكل، وموضع البوصلة، وقوارب النجاة، والجسر، وما إلى ذلك)، يمكننا الافتراض بثقة أن مساهمات Andrews في تصميم Titanic كانت في معظمها جمالية، أو بعبارات تطوير البرمجيات، متعلقة بـ"الواجهة". (Thinkquest)
نظرًا للطابع الإنشائي لبناء السفن، ولا سيما مع السفن الضخمة كـOlympics، تنطوي عملية التصميم على تصميم مكثّف مسبق مع حلقات تغذية راجعة محدودة جدًا لاحقًا حين يتمكن المصممون من فحص السفينة ميدانيًا. يُعرف هذا في مصطلحات البرمجيات بـ"التصميم الشامل المسبق (BDUF)". وفي البرمجيات حيث تكون المتطلبات المتغيرة شائعة، يُعدّ هذا النهج ممارسةً سيئة بوجه عام، لكنه في الهندسة الميكانيكية والإنشائية هو ببساطة الحل المعقول الوحيد.
مع تقدم العمل في Olympics، اتُّخذت عدة قرارات بشأن تصميم البنية التحتية الأساسية للسفن. وهذا بالغ الخطورة إذ إن المنهجية المعتمدة لهذا النوع من المشاريع لم تُصمَّم لاستيعاب تغييرات من هذا النوع بعد الموافقة على الخطط. فالسفينة مصمَّمة كنظام متكامل تتشابك فيه أنظمة السلامة المتعاضدة بدرجة عالية من التعقيد. وخلافًا لمعظم البرمجيات، يصعب جدًا بناء نموذج أولي سريع لسفينة بالدرجة اللازمة لضمان السلامة. وكان إجراء تغييرات جوهرية على أنظمة السلامة يستلزم إعادة صياغة شاملة للمواصفات كي يُنجَز الأمر صحيحًا. لكن بما أن التغييرات أُجريت بدواعي توفير التكاليف ومشكلات الجداول الزمنية وعوامل الفخامة، لم يُوضَع في الحسبان أي تفكير شمولي في التغييرات. (Kozak-Holland)
كان التصميم الأصلي وغاية Olympics دمج أحدث التقنيات للسلامة. وبعد اكتمال التصميم الأولي، مورس ضغط تجاري من خطوط White Star Lines وخاصةً J.B. Ismay على المعماريين والمهندسين لإزالة ميزات السلامة لصالح ترفيات الدرجة الأولى. وأشهر التغييرين كان بطبيعة الحال إزالة قوارب النجاة كي لا تحجب المناظر من الكبائن دون ضرورة، وتعديل عدة من الحواجز المائية لتُصبح غير محكمة الإغلاق وترتفع عشرة أقدام فقط فوق منسوب الماء بهدف توسيع قاعة الاحتفالات الكبرى. وكما هو الحال في مشاريع تقنية المعلومات، تقع قرارات الهندسة للأنظمة الجوهرية في الغالب خارج نطاق إدراك المديرين التنفيذيين من جانب الأعمال. إن السماح للجانب التجاري بالتأثير على القرارات التقنية أمر خطير، إذ تُتجاوَز الاحتياطات المعتادة وأساليب التفكير وتُهمَل الخبرة. وفي هذه الحالة كانت المسائل تتعلق بالحفاظ على الأرواح وسلامتها. وفي البرمجيات نادرًا ما تكون لدينا مهمة بهذه الأهمية، لكن السماح للمديرين التجاريين الذين لا يُدركون طبيعة الأنظمة الرئيسية بالتدخل في تصميمها قد يكون ضارًا للغاية حتى لو كانت النتيجة بسيطة كخسارة الأعمال أو ارتفاع تكاليف التشغيل.
من أشد المشكلات إثارةً للدراما التي نجمت عن التغييرات المتأخرة في تصاميم Olympics أن التغييرات، كلٌّ منها صغير في حد ذاته، لم تُفحَص على الأرجح مجتمعةً قط ودُرِسَت كوحدة متكاملة بالطريقة ذاتها التي روعي فيها التصميم الأصلي للسفينة. فعند إزالة قوارب النجاة، كان المهندسون المعنيون يظنون أن السفينة مصمَّمة لتكون طوفًا نجاةً عائمًا وأن الغرض من قوارب النجاة مجرد نقل الركاب من السفينة الكبيرة الثابتة إلى سفينة أخرى في "أسوأ سيناريو" ممكن وهو أن تفقد Titanic أو Olympic طاقتها. بل كان يُتوقع أن التصادم لن يزيد عن جعلهما تطفوان منخفضتين في الماء دون أن تغرقا. وقُلِّصت قوارب النجاة حتى بقي الحد الأدنى المطلوب قانونًا بناءً على توصية اللجنة التنفيذية لخطوط White Star Line. وبالنسبة للمهندسين، كان هذا مقايضةً مقبولة في مجال السلامة وإن لم تكن مستحسنة. فتصميم السفينة كان بحيث لا يُشترط قانونًا وجود قوارب نجاة إضافية، ولم تكن ثمة ضرورة ملحّة للاحتفاظ بها لأن الفائدة العملية من القوارب الإضافية كانت تُعدّ ضئيلة. وفي نهاية المطاف، لم يكن قرار المهندسين هو الفيصل بل قرار White Star بوصفها العميل النهائي للبنّائين الذين كانت قراراتها تُعيلهم.
في حد ذاته كان قرار إزالة قوارب النجاة على الأرجح قرارًا ثانويًا. لكن إضافةً إلى ذلك، اتُّخذ قرار تغيير التصميم الإنشائي الأساسي لـOlympics من اعتماد جميع الحواجز المائية المرتفعة إلى خفض أربعة منها بصورة ملحوظة إلى عشرة أقدام فقط فوق خط الماء، مما أخلّ بمفهوم السفينة كطوف نجاة عائم. ولم تكن الحواجز المائية حقًا محكمة الإغلاق كما أوحت بذلك المواد التسويقية، لكنها كانت مرتفعة جدًا وشديدة "المقاومة للماء" وكان يُرجَّح أنها كانت ستتمكن من منع انتقال الماء بينها حتى في حال اختراق حاد جدًا للهيكل. وبما أن التصميم الأصلي للسفينة كان حافلًا بميزات السلامة، كان هذا سيُعدّ كقوارب النجاة ميزةً متكررة، وكان إزالتها لن تعني إلا خفض السفينة إلى معايير السلامة الأكثر شيوعًا. فُرادى، كانت التغييرات في معظمها غير ضارة، لكن مجتمعةً أضحت إعادة تصميم كاملة للسفينة وكارثة تامة. ولم يعد المهندسون المؤهلون في أي وقت لإجراء تقييم شامل لميزات سلامة السفينة مع مراعاة جميع التغييرات مجتمعةً.
من بعض جوانب النظر، يمكن اعتبار J.B. Ismay مديرًا تدخليًا (Micromanager). فقد كان لا يثق بقرارات من استأجرهم بسبب خبرتهم التقنية، وتجاوزها إما بصورة مباشرة أو من خلال ضغوط غير مباشرة. وللإدارة التدخلية نتائج سلبية عديدة. أوضحها أن المديرين غير المدرَّبين وغير المؤهلين يؤثرون في قرارات يعتقد الآخرون أنها جاءت من متخصصين مؤهلين. وتشمل النتائج الأخرى تآكل القيمة التي يولّدها فريق المشروع وتدهور ولاء الموظفين وروحهم المعنوية.
في بناء السفن، حيث تُبنى السفن بحسب فئة كما في حالة Titanic، نحتاج إلى النظر في ثلاث مراحل رئيسية للمشروع: تصميم وبناء النموذج الأولي Olympic؛ وتحسين التصميم وبناء Titanic؛ وأخيرًا تقديم الخدمة والتشغيل. وفي حالة Titanic تحديدًا نجد أن التصميم الرئيسي وأي تغييرات هيكلية أُجريت قبل اكتمال Olympic. أبحر Thomas Andrews على Olympic لكن ذلك كان في معظمه لإجراء تعديلات جمالية لصالح Titanic إذ كان إجراء أي تعديلات هيكلية في تلك المرحلة أمرًا متعذرًا. وللسبب ذاته، كان Andrews مبحرًا على Titanic لكي يفعل الأمر ذاته لصالح Britanic التي كانت ستُطلق قريبًا (التي كان Andrews يعرفها بـGigantic).
من حيث نطاق المشروع، نرى أن المشروع التزم بالخطة الأولية على نحو وثيق. وسارت أعمال البناء وفق خطط معتمدة مسبقًا مع إجراء تغييرات طفيفة. أشد التغييرات درامية في النطاق حدث أثناء بناء Titanic حين اضطرت للتوقف لاستيعاب إصلاح Olympic. وفهم كلا الطرفين، Harland-Wolff وخطوط White Star Lines، أن تسليم Titanic سيتأخر لكن تشغيل Olympic كانت له الأولوية. وعامل رئيسي في أي نوع من مشاريع البناء الرأسمالية هو الحاجة إلى اتفاقيات تعاقدية بين مراحل البناء إذ يكاد يستحيل استيعاب تغييرات النطاق بمجرد بدء الإنشاء. ("Olympic")
يصعب إيجاد مشاريع برمجيات تتبع هذا النموذج عن كثب بنموذج أولي للإنتاج تليه سلسلة من تطبيقات الإنتاج المستندة إلى النموذج الأولي دون أن تكون مطابقة له. أقرب مثال يمكنني افتراضه هو حزمة تخطيط موارد المؤسسات (ERP) SAP. فمع هذه الحزمة، وغيرها من نظيراتها، يشتري العملاء الحزمة بناءً على أدائها النموذجي وميزاتها ثم يعمدون إما بأنفسهم أو عبر شركة استشارية أو البائع الأصلي إلى تعديل الحزمة على نطاق واسع وفق احتياجاتهم. والميزة من هذا النهج في العموم أن جوهر حزمة البرمجيات، أي البنية التحتية، مستقر جدًا وخضع لاختبارات شاملة وكثيرًا ما يُستخدم في مجموعة واسعة من الحالات مما يمنحه فائدة الاختبار من جانب المشروع ومن جانب العميل كليهما. ولا بد من التنبّه طبعًا لأن التعديلات التي يُجريها العميل لن تحظى بالاختبار المعمّق الذي يُؤمَل أن البنية التحتية الأساسية قد خضعت له، ولن تتمتع التغييرات بفائدة "العيون الكثيرة" من المجتمع الأوسع للعملاء.
في حالة سفن فئة Olympic، أُجريت اختبارات جدية على نموذج بحجم خمسة عشر قدمًا للسفينة، كما أُجريت اختبارات على Olympic عند اكتمالها. ومع سفينة بتعقيد Olympic، من الضروري إجراء اختبارات في العالم الحقيقي إضافةً إلى الاختبارات الفردية للأنظمة المنفردة. وخضعت Olympic للتدابير الاختبارية المعتادة الخاصة بسفينة من هذا النوع. غير أنه عند بناء Titanic، قرر البنّاؤن وشركة الرحلات البحرية أنه بما أن Titanic نسخة شبه مطابقة من Olympic، فإن الاختبارات التي أُجريت والاستخدام الناجح المستمر لـ Olympic كافٍ اختبارًا لـ Titanic، فنالت Titanic اختبارات إضافية شحيحة جدًا. غير أن هذه ليست ممارسة فضلى إذ يعلم البحارة أن جميع السفن، حتى النسخ منها، تتصرف بطريقة مختلفة وكل سفينة فريدة ويجب اختبارها بمفردها. (Kozak-Holland)
لم يُتَح للـ Titanic سوى وقت ضئيل جدًا للاختبار أو التجارب الأدائية. جاء ذلك جزئيًا لأن Olympic تعرّضت لحادث خطير واضطُرت للتوجه إلى حوض السفن في بلفاست لإصلاحها. وبينما كانت Olympic تخضع للإصلاح، اضطرت Titanic للانتظار إذ لا يمكن العمل على سوى سفينة واحدة من هذا الحجم في وقت واحد. فرض ذلك قيودًا زمنية تجارية على Titanic لأنها كانت مجدولة لخدمة منتظمة على خط الأطلسي وكانت مطلوبة فورًا. ولذلك جرى تخطّي بعض الاختبارات الإضافية التي كانت ستُجرى على الأرجح، وأُرسلت Titanic في رحلتها مع اقتصار اختباراتها الرئيسية على الرحلة من بلفاست إلى ساوثهامبتون، وحتى في هذا الجزء من رحلتها كان هناك راكب واحد على الأقل يدفع أجر سفره مما جعلها أشبه برحلة حقيقية منخفضة السعة لا اختبارًا صحيحًا. (Kozak-Holland)
يبدو أن خطوط White Star Lines وJ. B. Ismay كانا على استعداد تام لتحمّل مخاطر استثنائية للمشروع بهدف إدخال السفينة في الخدمة المنتظمة في أقرب وقت ممكن. وقد خففا كثيرًا من مخاطرهما الرأسمالية عبر التأمين البحري وفق الإجراءات البحرية المعتادة، مما حماهما من كثير من المجاهيل المحتملة.
خلال النصف الأخير من القرن التاسع عشر، بات من الشائع متزايدًا أن تنظر شركات الشحن والحكومات على حدٍّ سواء إلى المخاطر باعتبارها قضية ذات أولوية منخفضة. وتُعدّ S.S. Great Eastern المبنية عام 1858 أكثر أمانًا بكثير من تصاميم السفن المحيطية المتزايدة الخطورة التي تلتها خلال الأربعة والخمسين عامًا التالية، وقد أثبت الواقع ذلك. واستمر تراجع المعايير حتى أعادت الشركات والحكومات تقييم الوضع في أعقاب غرق Titanic. ويُجادَل بأن شركات الشحن نظرت إلى سجلاتها المقبولة في مجال السلامة باعتبارها مسوّغًا لموقفها المتهاون تجاه السلامة على مدى عقود من الشحن الخالي نسبيًا من الحوادث. وفازت ضغوط الأسواق المالية لصالح الشركات ذات معايير السلامة المتساهلة مشجّعةً الصناعة بأسرها على الابتعاد عن إدارة المخاطر المكلفة. (Brander 1995)
بذريعة تخفيف المخاطر الناجمة عن نقص الاختبارات والتدريب، استُقدم عدة أفراد من الطاقم، أبرزهم الكابتن Smith، من Olympic للإبحار على Titanic في رحلتها الأطلسية الأولى. يمكن النظر إلى هذا باعتباره مسعى من Ismay لاستقطاب الخبرة التي تبدو كأنها تُخفف من "المجاهيل" الناجمة عن الإبحار على سفينة لم تُختبر مباشرةً مع امتلاك أقصى قدر من الخبرة المستمدة من السفينة النموذجية. غير أن هذا قد لا يكون السبب الحقيقي للقرار، وثمة احتمال كبير أن الكابتن Smith اختير لأن مكانته في خطوط White Star Lines كانت مشكوكًا فيها بعد أن تسبّب مؤخرًا في حادث خطير مع H.M.S. Hawke مما اضطر Olympic للخضوع لإصلاحات طارئة وأخّر إبحار Titanic. وكان الكابتن Smith على الأرجح قلقًا وخائفًا على مسيرته المهنية، وفي وضع نفسي لا يُمكّنه من الاضطلاع بالمستوى النهائي من المسؤولية على متن السفينة لو توجّهت إليه ضغوط من الشركة تخالف حكمه. وربما كان هذا بالضبط الثغرة التشغيلية التي كانت خطوط White Star Lines تسعى إليها. وقد تفاقم هذا الوضع على الأرجح حين اقترب الكابتن Smith من S.S. City of New York اقترابًا شديدًا أو بسرعة مفرطة وهي راسية في ساوثهامبتون مما جعلها تكسر حبال رسوّها وتكاد تصطدم بـ Titanic. (Kozak-Holland)
وفق قانون البحر العرفي، يعدّ الكابتن القائد المطلق للسفينة ويتمتع بسلطة كاملة في عرض البحر حتى لو كان على متنها مسؤولون أعلى رتبةً عسكريون كانوا أم مدنيون. وللكابتن مسؤوليات أخلاقية وقانونية تضع في أولويتها أرواح الركاب والطاقم وسلامتهم، ثم البضائع والسفينة. (Kuntz)
بمجرد أن اكتملت Titanic وجُهِّزت وأصبحت جاهزة للإبحار، شهدنا تغييرًا في المرحلة وانتقلنا إلى مرحلة تقديم الخدمة في المشروع الكلي لـ Titanic. في هذه المرحلة تجاوزنا المراحل التقليدية لإدارة المشاريع. وفي معظم السيناريوهات كان العميل قد استلم المنتج النهائي بهذا الوقت. لكن في حالة Titanic أضحت هذه مرحلة تقديم الخدمة.
في إطار تقديم الخدمة، تحمّلت خطوط White Star Lines مسؤولية أي مشكلات جديدة تطرأ على السفينة. عند هذه النقطة لم يعد يُستخدم النظام التقليدي من التصميم والبناء والاختبار، وعوضًا عنه أشرفت على تقديم الخدمة إجراءات التشغيل الموحّدة (SOP). وكانت التعديلات والإصلاحات والضبط المستمرة للسفينة وما شابهها ستستمر لكنها ستُصمَّم بحيث لا ترقى إلى مستوى يستلزم انقطاع الخدمة، بل ستكون طفيفة وتجري دون علم العملاء النهائيين - الركاب. وفي هذه المرحلة يبرز الركاب بوصفهم أصحاب المصلحة الأشد أهمية، لأنه في هذا السيناريو لا يقتصر دورهم على أصحاب المصلحة الماليين بل يراهنون حرفيًا بأرواحهم على موثوقية السفينة وكفاءة تشغيل الطاقم.
في مجتمع إدارة المشاريع الرشيقة (Agile) ثمة حكاية تُستخدم كثيرًا للتعبير عن الأدوار داخل أصحاب المصلحة. وتُعرف هذه الأدوار بـالخنازير والدجاج. تحكي الحكاية عن دجاجة وخنزير يرغبان في فتح مطعم معًا. يسأل الخنزير الدجاجة عما سيقدمانه. فتجيب الدجاجة: "حسنًا، لحم الخنزير المقدد والبيض بالطبع." فيرد الخنزير: "لا أظنني مهتم. أنتِ ستشاركين لكنني سأكون منخرطًا كليًا." (Schwaber 7)
تُستخدم استعارة الخنزير والدجاجة عادةً للتعبير عن الفرق بين أصحاب المصلحة الذين يخاطرون بأموال حقيقية أو مسيرات مهنية وأصحاب المصلحة الذين لهم مصلحة جوهرية لكنها غير حيوية في المشروع. تُفضّل الدجاجات ألا يفشل المشروع لكن الفشل ليس بالضرورة كارثيًا بالنسبة لها. في حالة Titanic نجد أن أصحاب المصلحة الماليين، Harland-Wolff وخطوط White Star Lines، كانوا دجاجات فعليًا. كان لديهم ما يخسرونه لكن استثمارهم كان مؤمَّنًا عليه وسنجد لاحقًا أن الحكومة كانت مستعدة حتى لحماية شركات من هذا النوع في ذلك الوقت نظرًا للحرب الوشيكة مع النمسا وألمانيا. لم يكن White Star ولا Harland-Wolff "منخرطَين كليًا" - فقد كانت لديهم مصلحة أكيدة وكان نجاح Titanic بالغ الأهمية لهما، لكن ركاب وطاقم Titanic كانوا هم الخنازير الحقيقيين الراغبين في المخاطرة بحياتهم ذاتها. نادرًا ما تكون استعارة الخنزير والدجاجة أدق تعبيرًا.
ضمانًا لجودة أعلى للخدمة الجارية، كانت مجموعة الضمان من Harland-Wolff حاضرةً في الرحلة الأولى. وضم هذا الفريق عددًا كبيرًا من أعضاء طاقم التصميم والبناء في Harland-Wolff بمن فيهم المصمم الرئيسي Thomas Andrews. واعتادت Harland-Wolff على وجود مجموعة الضمان هذه في جميع مشاريعها الكبرى. وكان هذا الطاقم سيستغل وقت الرحلة لتقييم أعمال البناء في ظروف مغايرة لظروف اختباراتهم، وقياس رضا العملاء، والبحث عن فرص للتحسين. وكان Thomas Andrews قد أبحر بالفعل على Olympic لهذا الغرض بالذات وأجرى تعديلات طفيفة عديدة لتحسين Titanic. وكان سيخصص جزءًا من هذه الرحلة، على سبيل المثال، لتصميم علاّقات ملابس أرخص لغرف الركاب. ("Guarantee Group")
ضمّت مجموعة الضمان متخصصين من تخصصات تقنية عديدة داخل Harland-Wolff. رأينا تمثيلًا من عمال التركيب، والكهربائيين، والنجارين، والرسامين الهندسيين، وفريق التصميم وغيرهم. وكان هذا الفريق بتخصصاته المتنوعة وبمستوياته المختلفة من الخبرة بين كبار المتخصصين والمتدربين، قطاعًا استثنائيًا من فريق المشروع الذي بنى السفينة. ويمكن النظر إلى وجودهم على متن السفينة مع الرعاية المبذولة في تقييم الأعمال اليدوية والتصميم وغيرها من المكوّنات النهائية من جانبين رئيسيين.
من الجانب الأول، يمكن النظر إلى هذا باعتباره "تقييمًا لاحقًا للمشروع" يُجرى على مشروع Titanic. وكان دور هذا الفريق تقييم النجاح التقني للمشروع والبحث عن مجالات للتحسين وتوليد "الدروس المستفادة" كي تعود المشاريع المستقبلية بالفائدة من التجربة المكتسبة هنا. وبالنظر إلى تكاليف رحلة الأطلسي والوقت المستغرق بعيدًا عن مهامهم المعتادة، كان هذا استثمارًا جادًا في المعرفة المشروع من قِبَل Harland-Wolff وأمرًا جديرًا بالإشادة البالغة.
من منظور آخر، يمكن النظر إلى مجموعة الضمان هذه باعتبارها مزوّدة للتغذية الراجعة في دورة بناء متكررة. إذ يُعدّ بناء Olympic التكرار الأول وبناء Titanic التكرار الثاني وبناء Britanic الثالث. ومن هذا المنهج نرى نوعًا من التطوير الرشيق (Agile) وحلقة تغذية راجعة للعملاء تُوظَّف بأقصى إمكاناتها الممكنة للسماح بمدخلات العملاء حتى في مشروع بناء رأسمالي بهذه الضخامة. وإن كانت الدورات طويلة جدًا إلا أن ذلك ضرورة. وبهذه الطريقة يمكننا رؤية Titanic مشروعًا مستقلًا من حيث كونها قابلًا للتسليم محددًا، وكذلك جزءًا من المشروع الجاري لتقديم خدمة الركاب عبر عائلة السفن الأولمبية.
كان وجود مجموعة الضمان على متن السفينة يُتيح للفرق التقنية فرصة التعرف مباشرةً على التطبيق الواقعي لمنتجهم. ونادرًا ما كان يسنح لمتخصص تقني في عام 1912 السفر على سفينة بهذا المستوى من الفخامة. فدون رعاية Harland-Wolff التي أتاحت لموظفيها هذه الفرصة لمشاهدة أعمالهم في العمل، ربما لم يكونوا ليدركوا دورهم في تقديم الخدمات لعملائهم النهائيين قط.
انضمام المتدربين إلى مجموعة الضمان أتاح إجراء تدريب غير رسمي مباشر بين فرد وآخر أو ضمن مجموعات صغيرة. وكان للمتدربين وكبار التقنيين أيام عديدة للعمل معًا، وكانت الفرصة سانحة للمتدربين للتعلم من كبارهم في بيئة مواتية لبناء الفريق ونقل المعرفة. وبأوجه عديدة يمكننا رؤية هذا الوقت باعتباره مشابهًا لجلسات بناء الفريق خارج الحرم الرسمي أو برامج الاستجمام الشائعة لدى كثير من الشركات ومجموعات المشاريع اليوم.
أكبر مفاجأة في تحليلنا لـ Titanic هي شبه الغياب الكامل لإجراءات التشغيل الموحّدة على متن السفينة. فبعض العمليات والإجراءات كانت موثّقة لكن كثيرًا منها لم يكن. وتشمل أمثلة العمليات غير الموحّدة عمليات الاتصالات الرئيسية كنقل الرسائل من غرفة اللاسلكي إلى الجسر، وتنبيه الركاب بغرق السفينة، وإبلاغ الجسر بأن طاقم المراقبة رصد جبل جليدي. (Kozak-Holland)
إجراءات التشغيل الموحّدة ضرورية كليًا في أي موقف يتعلق بتقديم الخدمة. وفي بعض الشركات يمكن حتى اعتبارها ذات قيمة بالغة لدرجة أنها تمثّل الملكية الفكرية الجوهرية للشركة. فبدون إجراءات التشغيل الموحّدة لا تكون الشركة أكثر تماسكًا من مستوى "روح الفريق" الكامنة في الموظفين والتي قد تكون اسمية في حالة الموظفين الجدد. وسيضطر الموظفون إلى الاعتماد كليًا على أفضل الممارسات والتقاليد والتوجيهات غير الرسمية من الموظفين أو، إن كان الحظ مواتيًا، التدريب لتعلّم وظائفهم وعملياتهم. لكن هذه لن تكون موحّدة إن لم تُكتب، وسيتفاوت التدريب حتمًا من مدرّب إلى آخر ولن يتمكن أي موظف من الاحتفاظ بجميع التعليمات لجميع السيناريوهات الممكنة.
في الظروف الاعتيادية، قد يكون لغياب إجراءات التشغيل الموحّدة أهمية نسبية محدودة. فيستطيع الموظفون أداء معظم وظائفهم بكفاءة، ولا سيما إن تلقّوا تدريبًا، دون الحاجة إلى إجراءات التشغيل الموحّدة. لو احتاجوا إليها لاضطروا لحملها معهم في جميع الأوقات. تصبح إجراءات التشغيل الموحّدة بالغة الأهمية حين لا تعود "إجراءات التشغيل الاعتيادية" متاحة أو، بعبارة أكثر حداثة، حين تخرج العمليات عن ظروف "العمل المعتاد (BAU)". وبالنسبة لـ Titanic، انكسرت ظروف العمل المعتاد قبل ساعات من حادثة الجبل الجليدي.
في حالة Titanic يصعب مناقشة إجراءات التشغيل الموحّدة دون التطرق إلى الاتصالات. لذا سنبدأ بالاتصالات في ظروف العمل المعتاد ثم نرى كيف أدى غياب إجراءات التشغيل الموحّدة إلى تدهور الوضع بسرعة.
عانت Titanic من عيوب تصميمية في الاتصالات منذ البداية. فغرفة اللاسلكي، المسؤولة عن جميع الاتصالات الواردة والصادرة من Titanic، لم تكن تديرها خطوط White Star Lines بل كان يعمل فيها موظفو شركة Marconi المكلّفون بإيلاء الأولوية في الاتصالات للركاب أولًا وللسفينة فقط إن سمح الوقت. وكان مشغّلو اللاسلكي منهكين ومستهانًا بهم وكثيرًا ما كانوا لا يُحيلون الرسائل إلى الجسر لأن لديهم مهام أخرى تعدّها Marconi، صاحبة عملهم، ذات أولوية أعلى. وقد أُرسلت ما لا يقل عن ثماني تحذيرات من الجبال الجليدية إلى غرفة لاسلكي Titanic لكن لم يُحَل منها إلى الجسر سوى بعضها. (Kozak-Holland)
في هذه الحالة من المهم التأكيد على أهمية إدارة المقاولين الخارجيين عبر اتفاقية مستوى الخدمة (SLA). كان ينبغي لخطوط White Star Lines، إذ سمحت لشركة Marconi بتزويد غرفة لاسلكيها بالموظفين، أن تمتلك اتفاقية مستوى خدمة واضحة تُوجب أن تأخذ اتصالات السلامة والطوارئ للسفينة الأولوية المطلقة على الرسائل الشخصية للطاقم. وكان ينبغي ألا يُتاح لـ Marconi تحقيق ربح إضافي أو الاستفادة ماليًا من عدم الالتزام باتفاقية مستوى الخدمة. فبوصفها مقاولًا خارجيًا كان ينبغي أن يكون عقد Marconi مصمَّمًا للمنفعة المتبادلة، أي أن يصب التنفيذ الصحيح للعقد في مصلحة جميع الأطراف. والعقود التي تمنح الموردين حوافز مالية تجعلهم يعملون ضد مصالح عملائهم خيار بالغ الحماقة.
أهم حادثة منفردة تتعلق بمشغّلي Marconi كانت آخر تحذير من الجبال الجليدية أرسلته SS California، التي كانت قريبة جدًا من Titanic لدرجة أنها ستكون لاحقًا السفينة التي رصدت صواريخ الطوارئ من Titanic. أرسلت California بالراديو تحذيرًا إلى Titanic مفاده أنها أصبحت محاصرة في الجليد المتراكم ولا تستطيع المضي قُدُمًا بأي سرعة نظرًا للظروف الخطرة. فردّ مشغّل Marconi: "اصمت، اصمت، أنا مشغول. أنا أعمل مع Cape Race وأنت تتداخل معي." وبالكاد كان بالإمكان إيضاح أولويات غرفة اللاسلكي على نحو أجلى حتى مع تلك المخاطر الداهمة من قريب. ولم يكتفِ طاقم غرفة اللاسلكي بعدم الإبقاء على قنوات اتصال مفتوحة مع California، بل رفض أيضًا إبلاغ الجسر بهذا التحذير الخارجي الأخير. وفي إحباط، استسلم مشغّل راديو California من محاولاته تحذير Titanic وأغلق جهاز لاسلكيه وذهب إلى النوم. لم يكتفِ مشغّلو Marconi بعدم الاكتراث بالتحذيرات بل نفّروا القنوات الخارجية أيضًا بحيث إن السفينة الوحيدة القريبة بما يكفي لإنقاذهم لم تستجب حين بدأت Titanic في الغرق. (Kuntz)
لم يكن ثمة أي إجراء رسمي للاتصالات من الجسر إلى الطاقم عمومًا وإلى الركاب، وكانت يدوية وعلى أفضل تقدير تجري على مبدأ بذل الجهد دون ضمان النتيجة إن أُجريت أصلًا. فلم يُخطر الجسر أحدًا بأن التصادم وشيك ولم يتهيأ أحد لما كان من الممكن أن يكون ارتطامًا بالغ الخطورة. وحين بدأت السفينة في الغرق، مرّ أكثر من ساعة قبل أن يبدأ الجسر في إبلاغ بقية السفينة بأنهم يغرقون. وظلّت المعلومات الحيوية المتعلقة بأرواح الركاب والطاقم محتجزة لدى عدد قليل من أفراد الجسر الذين كانوا على الأرجح يأملون في إبقاء الحادثة طيّ الكتمان أو التقليل من الإضرار بسمعتهم في ظل خطر واضح على الأرواح. وبما أنه لم يكن ثمة نظام أو إجراء للتواصل من الجسر إلى السفينة عمومًا، كان الأمر بسيطًا إذ يستلزم بذل جهد متعمد لإبلاغ الركاب بأي أخبار على الإطلاق. (Kozak-Holland)
كانت الاتصالات بين أفراد الطاقم في مستوى أدنى بقليل. فضابط المناوبة، على سبيل المثال، كان يقف خارج الجسر بينما كانت وصلاته الاتصالية الحيوية داخل بيت الجسر. ولذا لم يستطع المناوب التواصل بسرعة مع أي من أفراد الجسر أو التنسيق مع طاقم المراقبة وغيرها من المناطق الوظيفية ذات الصلة. وكان نظام الربط بين طاقم المراقبة والجسر جرسًا أحادي الاتجاه لا يتيح الاتصال ثنائي الاتجاه وكان بطيئًا للغاية، وليس لدى المناوب أي وسيلة لتلقّي تأكيد من الدفّة عند إصدار أمر طارئ. كانت الأوامر تُعطى بالصياح من الهواء الطلق باتجاه الجسر المغلق. ولم يكن المناوب يعلم إلا بالأمل أن مسؤول الدفة داخل الجسر سمع الأمر وفهمه وينفّذه. وكانت الاتصالات من البوصلة الرئيسية لا تقل سوءًا. فبدلًا من وضع البوصلة فوق الجسر أو بجانبه، وُضعت في الجزء الخلفي البعيد من السفينة مما اضطر الجسر إلى التنسيق مع البوصلة بصورة منتظمة وهو ما تسبّب في كثير من الارتباك والتأخير. ولم يُولَ سوى قليل من الاهتمام، إن أُولي أي اهتمام، لجعل الجسر فعّالًا أو آمنًا. وهذا الإخفاق في تصميم الاتصالات لم يُسهم بأي قدر في مساعدة Titanic حين كانت الاتصالات السريعة والدقيقة ضرورة قصوى. (Brown)
حين أُرسلت الاتصالات الخارجية أخيرًا إلى مكتب White Star في بوسطن، كانت المعلومات المُرسَلة تفيد بأنه لا يوجد ضرر جسيم وأن الحادثة طفيفة جدًا. غير أن هذه المعلومات، خلافًا للاتصالات نقطة لنقطة الشائعة اليوم، كانت تُبثّ وأمكن اعتراضها بسهولة من سفن ومحطات تتابع أخرى. وكثيرًا ما كانت اتصالات السفينة بالشاطئ تُستخدم فعليًا لإيصال المعلومات إلى الصحافة في صورة اتصالات داخلية. لذا بدلًا من إرسال معلومات صادقة وحيوية، استُخدم اللاسلكي كأداة تسويقية. ما أُرسل لم يكن إشارة استغاثة بل كان في حقيقته لا أكثر من بيان صحفي يسعى إلى "توظيف الحادثة" في أحسن صورة. (Kozak-Holland)
الاتصالات عنصر محوري في أي مرحلة من أي مشروع. في حالة Titanic أبرز الوضع الكارثي مشكلات نجمت عن الاتصالات، لكن هذا مجرد سيناريو الحالة القصوى. تحتاج المشاريع إلى أكبر قدر ممكن من البيانات الحديثة والدقيقة عند اتخاذ القرارات. فبدونها تُتّخذ القرارات استنادًا إلى صورة جزئية متاحة وكلما قلّت المعلومات الصحيحة المتاحة كلما انخفض احتمال اتخاذ قرار سليم.
ربما أبرز قضايا إدارة المشاريع الؤثرة في Titanic كان غياب إجراءات التشغيل الموحّدة. وكان ينبغي إنتاج إجراءات التشغيل الموحّدة بوصفها نتاجًا جوهريًا للمشروع خلال المراحل المتأخرة من عملية البناء. إن اعتبار سفينة صالحة للإبحار دون وجود إجراءات تشغيل موحّدة لتشغيلها أمر يكاد يكون مستعصيًا على التصديق. فحتى أكثر منهجيات التطوير رشاقةً لا تغفل عن الحاجة إلى توثيق للمستخدم النهائي.
بما أن مراحل التصميم والبناء في المشروع فشلت في تزويد طاقم Titanic بإجراءات تشغيل موحّدة أو على الأقل إجراءات معقولة (كانت ثمة بعض الإجراءات العامة الموحّدة في دليل خطوط White Star Lines نفسه)، لم تكن ثمة قواعد أو إجراءات واضحة لمعالجة الاتصالات وتتبع التنبيهات وإصدار التحذيرات وغير ذلك. ولم يكن ثمة إجراء طارئ يُتّبع فاضطر الطاقم للتصرف بناءً على الخبرة الشخصية والمعرفة البحرية العامة وحسب.
في هذه النقطة، حين ندرس تصرفات الطاقم في ظروف الطوارئ، نشهد الانهيار التام لهيكل القيادة. في الأعمال التقليدية يُقبل عمومًا أن للمديرين التنفيذيين السلطة النهائية في اتخاذ القرار بشأن أي إجراء مؤسسي طالما يقع ضمن الحدود القانونية، وكثيرًا ما يتجاوزها. وفي الأعمال الاعتيادية يُفضي القرار التشغيلي الخاطئ إلى خسارة إيرادات لا إلى خسارة أرواح. والمدير الحكيم يُدرك ضرورة عدم تجاوز قرارات المتخصصين الذين وُظّفوا لاتخاذ القرارات التشغيلية، وربما يشترط مجلس الإدارة على المدير التنفيذي الاستماع إلى موظفيه. وبالرغم من ذلك، يُعدّ تدخّل المديرين التنفيذيين من جانب الأعمال في تشغيل المشروع ممارسةً مخالفة للمعايير الفضلى ومقبولًا بشكل واسع كونه مسار عمل سيئ.
في حالة Titanic، كان الكابتن Smith قائد السفينة في البحر وكان مسؤولًا شخصيًا عن السفينة والأرواح على متنها. فرئيسه J.B. Ismay ربما كان قادرًا على إقالة Smith من القيادة عند العودة إلى الميناء، لكن في البحر لم يكن قادرًا على ذلك، ولم يكن يحق له بموجب قانون البحر البريطاني إصدار أوامر من الجسر كونه لم يكن بحارًا مرخّصًا. (Kuntz)
خلال الفترة السابقة للاصطدام بالجبل الجليدي، كان J. B. Ismay يضغط على الكابتن Smith لقيادة السفينة بسرعة مفرطة تبلغ أربعة وعشرين عقدة أو خمسة وسبعين دورة. ولم تكن Olympic، التي تُعدّ "الاختبار" لـ Titanic، قد عبرت الأطلسي بهذه السرعة قط، وكانت Titanic تعمل الآن حتى خارج نطاق الاختبارات التي أُجريت على Olympic دون أن يُتَح لها وقت لإجراء ولو رحلة أطلسية واحدة في ظروف اعتيادية. وقاد Ismay وSmith الـ Titanic إلى ما هو أبعد من معاملها الأدائية المعروفة وما هو أهم، إلى ما هو أبعد من المعاملات التشغيلية المعروفة للطاقم. وكان ببساطة مجهولًا ما المخاطر التشغيلية التي تنطوي عليها السفينة بهذه السرعة. وكان الإبقاء على ما كان ينبغي اعتباره سرعة غير آمنة مع الإبحار في مياه معروفة بكثافة الجبال الجليدية أمرًا بالغ الحماقة.
سواء بسبب الذعر أو الارتباك أو انعدام الثقة بالنفس أو غير ذلك، لسنا ندري، لكن حين اصطدمت Titanic بالجبل الجليدي سمح الكابتن Smith لشخص غير متخصص هو J.B. Ismay بالصعود إلى الجسر وإصدار أوامر تنفيذية بوصفه قائدًا فعليًا للسفينة، في حين كان من حق الكابتن Smith وواجبه إجلاء Ismay. وأصدر Ismay قرارات تشغيلية حيوية شملت اتصالات الطوارئ وإبلاغ الركاب، والأهم من ذلك كله، قرار تحريك Titanic إلى الأمام بعيدًا عن حافة الجبل الجليدي وهو ما يُعتقد أنه السبب الفعلي للانشقاق الرئيسي في هيكل السفينة، ثم الاستمرار في تحريكها للأمام بسرعة منخفضة وهو ما زاد من تفتّت الهيكل حتى بعد توافر معلومات إضافية تفيد بأن السفينة ستغرق. (Kozak-Holland)
نظرًا للمسافة الزمنية التي تفصلنا الآن عن Titanic، يصعب تقييم العمليات المتّبعة ومعرفة ما سار صوابًا في المشروع حين نعرف الكثير مما سار خطأ. فغرق Titanic ترسّخ في أذهاننا لدرجة أن رؤيتها بوصفها سوى كارثة تسويقية وتنظيمية بات أمرًا عسيرًا في أفضل الأحوال.
في المحصلة كان مشروع Titanic ضخمًا لكن مُدارًا جيدًا. فقد ضُبط النطاق وجرى التكيّف مع التغييرات عند الضرورة. وجرى اعتماد التصميم الشامل المسبق مع واجهة تعاقدية راسخة لمرحلة البناء، وأتاح هذا التثبيت للمواصفات جدولة دقيقة ومحكمة. وكانت العمليات التي بُنيت بها السفن موحّدة ومعروفة. وباستخدام بيانات البناء التاريخية تمكّنت Harland-Wolff من التنبؤ بدقة بالوقت اللازم للبناء مما أتاح لخطوط White Star Lines الشروع في التسويق والمبيعات قبل وقت طويل من الإبحار الفعلي للسفن. وكانت Titanic، بوصفها نسخة شبه مطابقة من Olympic، تنطوي على مفاجآت أقل. والمفاجأة الحقيقية الوحيدة جاءت من تغيّر الأولويات من جانب خطوط White Star Lines مما أدى إلى توقف مشروع Titanic لمدة شهر تقريبًا.
وفق ما صرّح به J. Bruce Ismay: "لم تُبنَ [Titanic] بعقد. بل بُنيت ببساطة على أساس عمولة." وهذا يدل على أن Harland-Wolff مُنحت صلاحية استثنائية لاستخدام عملياتها الخاصة والإشراف على ضمان تسليم Titanic. وعملت الشركتان أشبه بشريكتين لا في علاقة بائع وعميل. (Kuntz)
أُديرت مخاطر مشروع Titanic بصورة سيئة، إذ جرى الاعتماد اعتمادًا كبيرًا على شركات التأمين الخارجية وفي نهاية المطاف على الحكومة البريطانية لحماية الشركة من دعاوى المسؤولية على حساب الركاب البريطانيين والأمريكيين في معظمهم. وكانت المخاطر تُعدّ منخفضة جدًا ولهذا اتُّخذت كثير من القرارات المتهورة أولًا مع Olympic ثم، حين كانت الكوارث التشغيلية محدودة، تصاعدت أكثر مع Titanic. ولم يُجرَ تقييم دقيق للمخاطر. فالبحارة الخبراء كانوا بإمكانهم بسهولة وسرعة تحديد مجالات مخاطر عديدة تستوجب المعالجة. وكانت مسائل كغياب إجراءات التشغيل الموحّدة الشاملة ستُرصد ويمكن معالجتها بيسر إذ إن الموارد اللازمة لذلك لا يلزم أن تأتي من فريق Titanic الحالي ولن تؤثر على موعد التسليم أو أي من المتغيرات التي ندرك اليوم أنها كانت الشاغل الأول لخطوط White Star Lines.
يبدو أن الاتصالات في المشروع كانت مُدارة على نحو جيد جدًا حتى بدأ تقديم الخدمة. عند هذه النقطة أثّرت عيوب التصميم والقرارات المشكوك فيها وغياب إجراءات التشغيل الموحّدة في شبكة الاتصالات على متن السفينة. ويمكن اعتبار هذه الاتصالات تشغيلية لا مشروعية، لكن الحجة لفظية. فمشكلات Titanic كانت شاملة ولو اتُّبعت منهجيات تصميم سليمة لما أُغفلت تحليلات المخاطر مما كان سيُفضي إلى إنشاء إجراءات التشغيل الموحّدة التي كانت ستُبرز مشكلات الاتصالات أو ربما تعالجها.
في جوهرها كانت القضية تتعلق بالجودة. فقد قُدِّمت Titanic وبِيعت باعتبارها خيار السفر عبر الأطلسي الأعلى جودة. وقد تُرجمت الجودة، بصورة مباشرة أو غير مباشرة، في تقريبًا كل كلمة قيلت عن Titanic. وحُرص على أن تكون واجهة العميل نظيفة وموجزة قدر الإمكان. ولم يُبخَل بأي نفقة إن كانت نتائجها ستكون مشهودة من العميل. لكن الجوهر الحقيقي أو البنية التحتية للمشروع (المتطلبات غير الوظيفية وفقًا لـ Kozak-Holland - وإن كنت لا أتفق مع استخدامها في هذا السياق) التي كانت تستند إليها هذه "الجودة" أُهمل، وبات الجودة الحقيقية لـ Titanic وجودة عمليات خطوط White Star Lines شاهدة على نفسها في نهاية المطاف.
المراجع والمصادر:
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.
ملاحظات إضافية:
أعاد Mark Kozak-Holland نشر مقالاته عام 2003 على Gantthead عن Titanic في كتاب:
Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.
قراءات إضافية:
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.
نُشر أولًا على SheepGuardingLlama.
إعلان
