مدیریت پروژه کشتی RMS تایتانیک و کشتیهای Olympic
ایده ساخت R.M.S. Titanic و خواهرانش، R.M.S. Olympic و H.M.H.S. Britanic، نخستین بار در سال ۱۹۰۷ شکل گرفت. این سه کشتی با هم White Star Line کلاس Olympic کشتیهای اقیانوسپیما بودند. (در سراسر این متن برای وضوح از Olympic(ها) به عنوان اشاره به این کلاس از شناورها استفاده خواهم کرد.) معدود شناورهایی در تاریخ بشر به اندازه 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، سفارشیسازی شده، در تولید اولیه تکمیل و به عنوان یک سرویس، به مسافرانی که قرار بود آنها را جابجا کند بین Southampton و New York تحویل داده شد. برای حفظ حوزه موضوعی، پروژه بزرگتر آزمایش، رفع اشکال، تعمیرات، تغییرات دامنه و بهبودهایی که پس از غرق شدن 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 بیشترین شباهت را به مدل آبشاری در اصطلاح مدیریت پروژه فناوری اطلاعات داشت. فرایند با یک مفهوم سطح بالا شروع شد که بهطور مشترک از Joseph Bruce Ismay نماینده White Star Lines و Lord James Pirrie نماینده شریک کشتیسازی آنها Harland-Wolff ناشی شد. پروژه بهطور مشترک بین دو شرکت مفهومپردازی شد. Titanic پتانسیل اعتبار و سود بزرگی برای هر دو شرکت ارائه میداد و به سرمایهگذاری بزرگی از هر دو نیاز داشت. در حالی که به نظر میرسد منشور اولیه پروژه امروز در دسترس نیست، میتوانیم جلسه بین Ismay و Lord Pirrie را به عنوان منشور غیررسمی پروژه و آغاز پروژه ببینیم. (Sadur)
طراحی فنی کشتیهای کلاس Olympic توسط سرپرست کشتیساز Harland-Wolff، Alexander Carlisle، پس از تهیه نقشههای سطح بالا توسط Ismay و Lord Pirrie انجام شد. Carlisle از ابتدای پروژه تا سال ۱۹۱۰ که بازنشسته شد و نقش طراح ارشد را به Thomas Andrews مدیرعامل Harland-Wolff واگذار کرد، طراح ارشد پروژه بود (Brander 1998). Andrews مسئول مراحل نهایی طراحی Titanic بود. Olympic که در پاییز ۱۹۱۰ به آب انداخته شد، به احتمال زیاد کاملاً زیر نظر 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 را به عنوان یک میکرومدیر بنگریم. او به تصمیمات افرادی که برای هدف تخصص فنی آنها استخدام کرده بود اعتماد نداشت و تصمیمات آنها را به طور مستقیم یا از طریق فشارهای غیرمستقیم نادیده گرفت. میکرومدیریت نتایج منفی زیادی دارد. آشکارترین آن مدیران آموزشندیده و فاقد صلاحیتی است که بر تصمیماتی تأثیر میگذارند که دیگران فکر میکنند از متخصصان واجد صلاحیت آمده. موارد دیگر شامل از بین بردن ارزش تولیدشده توسط تیم پروژه و کاهش وفاداری و روحیه کارکنان است.
در کشتیسازی، در موقعیتهایی که کشتیها از یک کلاس مانند 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 یک تصادف جدی داشته بود و برای تعمیر باید به کارخانههای کشتیسازی در Belfast برده میشد. در حالی که Olympic زیر تعمیر بود، Titanic مجبور بود صبر کند زیرا تنها یک کشتی از آن اندازه میتوانست همزمان مورد کار قرار گیرد. این محدودیتهای زمانی تجاری را بر Titanic تحمیل کرد زیرا طبق برنامه برای مسیر منظم اقیانوس اطلس مقرر شده بود و بلافاصله مورد نیاز بود. به همین دلیل، برخی آزمایشهای اضافی که احتمالاً انجام میشد نادیده گرفته شد و Titanic با آزمایش اصلیاش یعنی سفر از Belfast به Southampton فرستاده شد و حتی در این بخش از سفر هم حداقل یک مسافر پرداختکننده وجود داشت که آن را بیشتر یک سفر واقعی با ظرفیت کم تبدیل کرد تا یک آزمایش مناسب. (Kozak-Holland)
به نظر میرسد White Star Lines و J. B. Ismay کاملاً آماده بودند تا ریسک استثنایی پروژه را برای گرفتن کشتی در سرویس منظم در اسرع وقت بپذیرند. از طریق رویههای استاندارد دریانوردی، بخش بزرگی از ریسک سرمایه خود را از طریق بیمه دریایی کاهش دادند. این آنها را در برابر بسیاری از ناشناختههای احتمالی محافظت میکرد.
در نیمه دوم قرن نوزدهم، هم برای شرکتهای کشتیرانی و هم برای دولتها بهطور فزایندهای رایج میشد که ریسک را به عنوان یک مسئله با اولویت پایین ببینند. S.S. Great Eastern ساختهشده در ۱۸۵۸ در موارد دنیای واقعی بسیار ایمنتر از طراحیهای شناورهای اقیانوسپیمایی که در پنجاه و چهار سال بعد از او دنبال شدند به اثبات رسید. شرایط تا زمانی ادامه پیدا کرد که شرکتها و دولتها وضعیت را در پی غرق شدن Titanic مجدداً ارزیابی کردند. استدلال میشود که شرکتهای کشتیرانی سابقه ایمنی قابل قبول را مشاهده میکردند که نگرش بیتفاوتی آنها نسبت به ایمنی را در طول دههها کشتیرانی نسبتاً بدون حادثه توجیه میکرد. فشارهای بازار مالی برنده شدند و شرکتهایی با استانداردهای ایمنی سست را تشویق کردند و صنعت را به عنوان یک کل از مدیریت ریسک گرانقیمت دور کردند. (Brander 1995)
تحت عنوان کاهش بیشتر ریسکها به دلیل فقدان آزمایش و آموزش، چندین عضو خدمه، بهویژه کاپیتان Smith، از Olympus برای سفر با Titanic در اولین عبور اطلسپیمایی آورده شدند. این میتوانست به عنوان تلاش Ismay برای کسب تجربهای دیده شود که به نظر میرسد «ناشناختهها» ناشی از راندن یک کشتی بدون آزمایش مستقیم آن را کاهش میدهد اما حداقل حداکثر تجربه از شناور نمونه اولیه را داشت. با این حال، این ممکن است دلیل اصلی پشت تصمیم نبوده باشد و بسیار ممکن است که کاپیتان Smith به این دلیل انتخاب شده بود که موقعیت او با White Star Lines بسیار قابل تردید بود پس از اینکه اخیراً یک تصادف جدی مربوط به H.M.S. Hawke ایجاد کرده بود که باعث شده بود Olympic به تعمیرات اورژانسی نیاز پیدا کند و روانه شدن Titanic را به تعویق انداخته بود. کاپیتان Smith احتمالاً نگران بود، نگران شغلش بود و در ذهن یا موقعیت کمی بود که به عنوان آخرین سطح مسئولیت در کشتی عمل کند اگر فشارهای شرکت او را بر خلاف قضاوت بهتر خودش هدایت میکرد. این ممکن است دقیقاً حفرهای عملیاتی باشد که White Star Lines دنبالش بود. این وضعیت احتمالاً بدتر شد زیرا کاپیتان Smith بسیار نزدیک یا خیلی سریع به S.S. City of New York هنگام لنگر انداختن در Southampton نزدیک شد و باعث شد لنگرهایش قطع شود و تقریباً با 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 را هم به عنوان یک پروژه مستقل، که یک قابل تحویل مجزا است، و هم به عنوان بخشی از پروژه مداوم ارائه سرویس مسافری از طریق خانواده کشتیهای Olympic ببینیم.
حضور گروه ضمانت در کشتی فرصتی فراهم میآورد تا تیمهای فنی برداشتی دست اول از کاربرد واقعی محصولشان به دست آورند. در سال ۱۹۱۲ به ندرت یک متخصص فنی در موقعیتی بود که بتواند بر کشتی از این سطح از لوکسبودن سفر کند. بدون حمایت Harland-Wolff در ارائه این فرصت به کارکنانش برای مشاهده کارآیی کار خودشان، آنها ممکن بود هرگز نقش خود را در ارائه سرویس به مشتریان نهایی درک نکنند.
درج کارآموزان در گروه ضمانت به این معنا بود که آموزش غیررسمی مستقیم یکبهیک یا گروه کوچک میتوانست انجام شود. کارآموزان و تکنسینهای ارشد روزهای زیادی برای کار با هم داشتند و کارآموزان فرصت عالی داشتند که در محیطی مناسب برای تیمسازی و انتقال دانش از ارشدهایشان یاد بگیرند. در بسیاری از جهات میتوانیم این زمان را مشابه جلسات تیمسازی خارج از دفتر یا اردوهایی ببینیم که امروزه با بسیاری از شرکتها و گروههای پروژه رایج است.
جایی که بزرگترین تعجب را در تحلیل Titanic مییابیم، فقدان تقریباً کامل رویه عملیاتی استاندارد در استفاده در کشتی است. برخی فرایندها و رویهها مستند شده بودند اما بسیاری نشده بودند. نمونههایی از فرایندهایی که استانداردسازی نشده بودند شامل فرایندهای ارتباطی کلیدی مانند انتقال پیامها از دفتر بیسیم به پل فرماندهی، اطلاعرسانی به مسافران از غرق شدن کشتی و اطلاعرسانی به پل فرماندهی که دیدهبان کوه دریافته یخ دیده است بود. (Kozak-Holland)
رویههای عملیاتی استاندارد در هر وضعیت تحویل سرویس کاملاً حیاتی هستند. در برخی شرکتها اینها حتی میتوانند به اندازه کافی ارزشمند باشند که به عنوان دارایی فکری اصلی شرکت تلقی شوند. بدون SOP یک شرکت نه بیشتر از «تیمبودن» ذاتی کارکنان که در مورد کارمندان جدید ممکن است اسمی باشد، یکپارچگی ندارد. کارکنان باید کاملاً به بهترین رویهها، رسوم، آموزش غیررسمی کارکنان یا امیدواریم آموزش برای یادگیری مشاغل و فرایندهایشان تکیه کنند. اما اینها اگر نوشته نشوند استانداردسازی نخواهند شد و آموزش اجتنابناپذیر از آموزشدهنده به آموزشدهنده متفاوت خواهد بود و هیچ کارمندی نمیتواند تمام دستورالعملها را برای تمام سناریوهای ممکن به خاطر بسپارد.
در شرایط عادی، نبود رویههای عملیاتی استاندارد ممکن است اهمیت نسبتاً جزئی داشته باشد. کارکنان میتوانند اکثر وظایف شغلی را به طور کافی، بهویژه اگر آموزش دیده باشند، بدون نیاز به SOP انجام دهند. اگر میدادند باید SOP را همیشه همراه داشتند. زمانی که SOP بهشدت حیاتی میشود، زمانی است که «رویههای عملیاتی عادی» دیگر در دسترس نیستند یا به اصطلاح مدرنتر، زمانی که عملیات دیگر تحت شرایط BAU (معمول کسبوکار) نیست. برای Titanic، شرایط BAU چندین ساعت قبل از رویداد کوه یخ شکسته بود.
در مورد Titanic بحث درباره رویههای عملیاتی استاندارد بدون بحث درباره ارتباطات دشوار است. پس با ارتباطات در شرایط BAU شروع میکنیم و سپس میبینیم که چگونه فقدان SOP باعث شد وضعیت به سرعت بدتر شود.
Titanic از ابتدا با نقصهای طراحی ارتباطی دست و پنجه نرم میکرد. اتاق بیسیم، مسئول تمام ارتباطات ورودی و خروجی Titanic، توسط White Star Lines اداره نمیشد بلکه با کارکنان Marconi تأمین میشد که پرداخت میشدند تا اول و مهمتر از همه برای مسافران ارتباط برقرار کنند و تنها در صورت باقی ماندن وقت برای کشتی. اپراتورهای بیسیم بیش از حد کار داشتند و کمارزش بودند و اغلب پیامها را به پل فرماندهی منتقل نمیکردند زیرا وظایف دیگری داشتند که توسط Marconi کارفرمایشان اولویت بالاتری داشت. حداقل هشت هشدار یخکوه به اتاق بیسیم Titanic ارسال شد اما تنها برخی از اینها به پل فرماندهی مخابره شد. (Kozak-Holland)
در این مورد، تأکید بر اهمیت مدیریت پیمانکاران شخص ثالث از طریق یک توافقنامه سطح سرویس مهم است. White Star Lines با اجازه دادن به شرکت Marconi برای تأمین کارکنان اتاق بیسیم خود، باید یک SLA واضح داشت که مطالبه میکرد ارتباطات ایمنی و اضطراری برای کشتی اولویت مطلق بر پیامهای شخصی خدمه داشته باشد. همچنین باید اجازه نمیداد Marconi از عدم پیروی از SLA سود اضافی کسب کند یا منفعت مالی داشته باشد. به عنوان یک پیمانکار خارجی، Marconi باید قراردادی میداشت که برای منفعت متقابل طراحی شده بود - یعنی هنگامی که طبق مفاد اجرا میشد، برای همه طرفها عمل درست کردن به سود متقابل بود. قراردادهایی بین فروشندگان که برای یک فروشنده انگیزه مالی ایجاد میکنند که علیه منافع مشتری خود عمل کند بسیار نادرست است.
مهمترین رویداد واحد مربوط به اپراتورهای Marconi، آخرین هشدار یخکوه ارسالشده توسط SS California بود، که بسیار نزدیک به Titanic بود - آنقدر نزدیک که بعداً کشتی دیدن موشکهای اضطراری Titanic بود. California یک هشدار بیسیم برای Titanic ارسال کرد که در یخ فشرده گیر افتاده و نمیتواند با هیچ سرعتی به دلیل شرایط خطرناک پیش برود. اپراتور Marconi پاسخ داد «خاموش شو، خاموش شو، سرم شلوغ است. من با Cape Race کار میکنم و تو مزاحم میشوی.» به ندرت میتوان اولویتهای اتاق بیسیم را حتی با این خطر نزدیک آشکارتر کرد. نهتنها اتاق بیسیم ارتباط با California را حفظ نکرد بلکه از اطلاعرسانی به پل فرماندهی از این آخرین هشدار خارجی نیز سر باز زد. در ناامیدی اپراتور بیسیم California از تلاشهایش برای هشدار دادن به Titanic دست برداشت، بیسیمش را خاموش کرد و به رختخواب رفت. اپراتورهای Marconi نهتنها از توجه به هشدارها خودداری کردند بلکه کانالهای خارجی را به گونهای از خود بیگانه کردند که تنها کشتی به اندازه کافی نزدیک برای نجات آنها، زمانی که Titanic شروع به غرق شدن کرد، پاسخ نداد. (Kuntz)
ارتباطات از پل فرماندهی به خدمه در کل و مسافران هیچ فرایند رسمی نداشت، دستی بود و در بهترین حالت، با بهترین تلاش انجام میشد اگر اصلاً تلاشی صورت میگرفت. پل فرماندهی به هیچکس اطلاع نداد که یک برخورد قریبالوقوع است و هیچکس برای چیزی که میتوانست ضربه بسیار جدی باشد آمادگی نداشت. پس از شروع غرق شدن کشتی، بیش از یک ساعت طول کشید تا پل فرماندهی شروع به اطلاعرسانی به بقیه کشتی کند که دارند غرق میشوند. اطلاعات کلیدی که بر جان مسافران و خدمه تأثیر میگذاشت از آنها پنهان نگه داشته شد و تنها در اختیار چند نفر از کارکنان پل فرماندهی بود که به احتمال زیاد امیدوار بودند رویداد را مخفی نگه دارند یا تبلیغات ناشی از خطر آشکار برای جان انسان را به حداقل برسانند. از آنجایی که هیچ سیستم یا فرایندی برای ارتباط از پل فرماندهی به کل کشتی وجود نداشت، این یک امر ساده بود زیرا برای اطلاعرسانی اخبار به مسافران اصلاً نیاز به تلاش منسجمی بود. (Kozak-Holland)
ارتباطات بین خدمه چندان بهتر نبود. مسئول نگهبانی، به عنوان مثال، در بیرون از پل فرماندهی قرار داشت اما اتصالات ارتباطی حیاتی او در داخل کابین پل فرماندهی بود. پس نگهبانی نمیتوانست به سرعت با سایر کارکنان پل فرماندهی ارتباط برقرار کند یا با دیدهبان کوه و سایر حوزههای عملکردی مرتبط هماهنگی کند. دیدهبان کوه و نگهبانی با یک سیستم زنگ یکطرفه متصل بودند که به آنها امکان ارتباط دو طرفه نمیداد و بسیار کند بود، و نگهبانی هیچ وسیلهای برای بازخورد از فرمانده ربع در سکان هنگام صدور یک فرمان اضطراری نداشت. فرمانها با فریاد کشیدن از فضای باز به سمت پل فرماندهی سربسته داده میشد. نگهبانی فقط میتوانست امیدوار باشد که فرمانده ربع درون پل فرماندهی شنیده، درک کرده و در حال عمل به آن فرمانها بود. ارتباطات از قطبنمای اصلی به همان بدی بود. قطبنما، به جای اینکه بالای پل فرماندهی یا نزدیک آن قرار داشته باشد، در عقب قرار گرفته بود و پل فرماندهی مجبور بود به طور منظم با قطبنما هماهنگی کند که سردرگمی و تأخیرهای زیادی ایجاد میکرد. فکر کمی، اگر اصلاً داشت، به کارآمد یا ایمن کردن پل فرماندهی شده بود. این فقدان طراحی برای ارتباطات مسلماً کمکی به Titanic نکرد زمانی که ارتباطات سریع و دقیق ضروری بود. (Brown)
زمانی که ارتباطات خارجی با دفتر White Star در Boston نهایتاً ارسال شد، اطلاعات مخابرهشده این بود که هیچ آسیب جدی وجود ندارد و رویداد بسیار جزئی بود. با این حال، برخلاف اطلاعات نقطه به نقطه که امروزه رایج است، این اطلاعات پخش و به راحتی توسط کشتیهای دیگر و ایستگاههای رله قابل رهگیری بود. ارتباطات کشتی به ساحل اغلب برای انتشار موثر اطلاعات به مطبوعات تحت پوشش یک بخشنامه داخلی استفاده میشد. پس به جای انتقال اطلاعات صادقانه و حیاتی، بیسیم به عنوان ابزار بازاریابی استفاده شد. آنچه ارسال شد نه یک سیگنال استرس بلکه در واقع چیزی بیش از یک بیانیه مطبوعاتی طراحیشده برای «چرخش» وضعیت نبود. (Kozak-Holland)
ارتباطات در هر مرحله از هر پروژه کلیدی هستند. در مورد Titanic، وضعیت فاجعهبار مسائلی را برجسته میکند که به دلیل ارتباطات رخ داد، اما این صرفاً یک سناریوی بدترین حالت است. پروژهها باید در هنگام تصمیمگیری تا آنجا که ممکن است دادههای بهروز و دقیق داشته باشند. بدون آنها تصمیمات با استفاده از تنها یک تصویر جزئی موجود گرفته میشوند و هرچه اطلاعات درست کمتر موجود باشد، احتمال اتخاذ یک تصمیم خوب کمتر است.
شاید بزرگترین مسئله مدیریت پروژه تأثیرگذار بر Titanic، با این حال، فقدان رویههای عملیاتی استاندارد آن بود. SOP باید به عنوان یک قابل تحویل اساسی پروژه در مراحل بعدی فرایند ساخت تولید میشد. اینکه یک کشتی بدون SOP برای راندن آن قابل دریانوردی تلقی شده باشد واقعاً باور نکردنی است. حتی چابکترین روشهای توسعه از نادیده گرفتن نیاز به مستندسازی کاربر نهایی غافل نمیشوند.
از آنجایی که بخشهای طراحی و ساخت پروژه قادر به ارائه یک SOP یا حداقل یک SOP معقول (برخی رویههای استاندارد عمومی در دفترچه راهنمای White Star Lines وجود داشت) به خدمه Titanic نبودند، هیچ قوانین یا فرایندهای مشخصی برای رسیدگی به ارتباطات، پیگیری هشدارها، ارائه اخطارها و غیره وجود نداشت. هیچ رویه اضطراری برای پیروی وجود نداشت و خدمه مجبور بودند بر اساس چیزی جز تجربه و دانش عمومی دریانوردی عمل کنند.
در این مقطع، هنگام بررسی اقدامات خدمه در شرایط اضطراری، شاهد فروپاشی کامل ساختار فرماندهی هستیم. در یک کسبوکار سنتی، مدیران اجرایی کسبوکار عموماً به عنوان داشتن قدرت تصمیمگیری نهایی در هر اقدام شرکتی، تا زمانی که در محدوده قانونی باشد، و اغلب زمانی که نیست، پذیرفته میشوند. در یک کسبوکار معمولی، یک تصمیم عملیاتی بد منجر به از دست دادن درآمد میشود نه از دست دادن جان. یک مدیر فرزانه نیاز به تأثیر نگذاشتن بر تصمیمات متخصصانی را که برای اتخاذ تصمیمات عملیاتی استخدام شدهاند درک خواهد کرد یا شاید یک هیئت مدیره از یک مدیر بخواهد به کارکنانش گوش دهد. با این وجود، ایده مداخله مدیران اجرایی کسبوکار در عملیات پروژه علیه بهترین رویهها است و به طور گسترده به عنوان یک مسیر اقدام بد پذیرفته شده است.
در مورد 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 از اهمیت اولیه بودند تأثیر نمیگذاشت.
ارتباطات در پروژه به نظر میرسد تا شروع تحویل سرویس به خوبی مدیریت شده باشد. در این مقطع نقصهای طراحی، تصمیمات قابل تردید و فقدان SOP بر شبکه ارتباطی در کشتی تأثیر گذاشت. این ارتباطات میتوانست عملیاتی در نظر گرفته شود نه مبتنی بر پروژه اما استدلال معنایی است. مسائل با Titanic کلنگر بودند و با پیروی از روششناسی طراحی مناسب، تحلیل ریسک نادیده گرفته نمیشد که باعث میشد تولید SOP اجباری شود که مسائل ارتباطی را برجسته یا شاید حتی حل میکرد.
در هسته خود این سوال کیفیت بود. 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 مقالات 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.
متن استماع و تحقیق رسمی سنای آمریکا و بریتانیا از سال ۱۹۱۲ در پروژه تحقیق Titanic.
اولین بار در SheepGuardingLlama منتشر شد.
آگهی
