タイタニックのプロジェクト管理とソフトウェアプロジェクトとの比較
タイタニックとその姉妹船であるオリンピック、ブリタニックという3隻のオリンピック級客船ほど名声と悪名を得たプロジェクトはほとんどありません。これらの船の設計が始まったのは今からちょうど110年前のことです。もちろん、オリンピック級船の運命からプロジェクト管理に関して学べる多くの教訓があり、実際に取り上げる価値のある多くのプロジェクト管理の側面があります。
（3隻をまとめて言及する際は、3隻が合わせてWhite Star Lineのオリンピック級船を構成していることから、単にザ・オリンピックスと呼びます。タイタニックの個別のその後の名声はここでは関係ありません。また、オリンピック級船、その歴史と運命に関する一般的な情報は読者の共通知識として前提としており、改めては説明しません。）
オリンピックスのプロジェクト管理がどれほど頻繁に取り上げられてきたかを考えると、現代の世界における現在のプロジェクト管理を貴重な歴史的レンズを通して見られる現代的な類似事例をいくつか見ることの方が賢明だと思います。プロジェクト管理は何千年もの間続いてきた学問分野であり、その課題、スキル、技法の多くはそれほど変わっておらず、過去の落とし穴は今日の私たちにも非常に当てはまります。過去から学ばなければ同じ過ちを繰り返すという古い格言が当てはまります。
したがって、ここでの私の目標は、プロジェクトのリスク分析、認識、プロファイルを検討し、それを現代のプロジェクト管理に適用することです。
まず、オリンピックスプロジェクトのステークホルダーを特定しなければなりません。White Star Lines自体（スポンサー企業および主要投資家）とその取締役Joseph Bruce Ismay、Harland-Wolff（契約造船業者）とその主要設計者Alexander CarlisleとThomas Andrews、Captain Edward John Smithを含む乗組員、後で見るように英国政府、そして最も重要なのは乗客です。
あらゆるステークホルダーグループと同様に、異なる役割があります。White Star は一方でスポンサーおよび投資家であり、現代のソフトウェアプロジェクトではスポンサーである顧客、マネージャー、または部門に類似しています。Harland-Wolff は設計者および建造者であり、現代のソフトウェアチームのソフトウェアエンジニアリングの「チームメンバー」——開発者自身——に最も密接に関連しています。船の乗組員はプロジェクト完了後の運用を担当し、最終的なソフトウェアの運用を引き継ぐITオペレーションチームに相当します。乗客は今日のエンドユーザーと同様であり、エンジニアリングの成果物（船またはソフトウェア）とその製品上に構築されたサービス（フェリーサービスまたはITマネージドサービス）の両方から恩恵を受けることを望んでいます。（「Olympic」）
プロジェクト分析のもう一つの軸は、チキンとピッグのステークホルダーの概念です。チキンは投資されリスクを負う一方で、ピッグは完全に投資されて最終的なリスクを負います。通常のソフトウェアでは、これらの比較を使って関与しているステークホルダーとコミットしているステークホルダーの度合いについて話しますが、オリンピック級船の場合、これらの用語は新しく恐ろしい意味を持ちます。投資家と建設業者は財政的なリスクのみを負っていた一方で、乗組員と乗客は船の運航段階において文字通り命を賭けていたからです。（Schwaber）
次に、オリンピックスの文脈に存在する異なるプロジェクトを区別することが有用だと思います。もちろん、3隻の船の設計と建造がありました。これは単一のプロジェクトであり、設計と建造という2つの明確なコンポーネントを持ち、3隻のオリンピック級船という3つの明確な成果物があります。建造フェーズの終わりには、船の組み立てに関わったプロジェクトマネージャーとチームが作業を停止し、船を運航する乗組員が引き継ぐという、非常に明確な区切りのポイントがあります。
ここで現代のテクノロジーの世界との重要な類似点を見出すことができます。ソフトウェア製品はソフトウェアエンジニアによって設計・開発され、完成するとITオペレーションスタッフに引き渡され、最終製品の実際の意図された使用を引き継ぎます。これら2つのチームは、単一の組織傘下の内部にある場合もあれば、2つ以上の全く別の組織から来る場合もあります。しかし、エンジニアリングと運用部門の分離は、1世紀以上前の造船とフェリーサービスのときと同様に、今日のほとんどのビジネスでも同様に明確に明確です。
さらに一歩進んで、White StarのTransatlantic フェリーサービスをMicrosoft Office 365、Salesforce、G Suiteなどの多くの現代のSaaSベンダーと比較することができます。これらの場合、問題の企業はコア製品を作成するエンジニアリングまたは製品開発チームを持ち、次にその社内製品を取得してサービスとして運用する2番目のチームを持っています。これは、ソフトウェアを作成した同じ会社がその最終的なオペレーターになるというソフトウェア開発分野においてますます重要なビジネスモデルになっており、外部クライアントのためのものです。多くの面で、現代のソフトウェアとITへのオリンピックスの関連性は低下するのではなく高まっています。
これは、オリンピックスで見落とされ、今日でもしばしば見落とされている重要なインターフェース理解を浮き彫りにします。引き渡しの両側が、もう一方の側が最終的に安全の責任を持つと信じていたのです。エンジニアは設計の安全性を声高に主張しましたが、圧力をかけられると、運用手順がリスクを軽減し、自分たちの努力は主に冗長であるという前提で妥協することをいとわなかったのです。同様に、スピードを維持し好成績を収めるよう圧力をかけられると、運用チームは手順を妥協することをいとわなかった——なぜなら彼らはエンジニアリングチームが自分たちの努力を本質的に無駄にするほど船を安全にしていると信じており、運用上の予防措置は単に正当化されないと考えたからです。このコミュニケーション不足により、取り組みは2種類の極めて安全なシステムを持つものから基本的に何もないものへと落ちてしまいました。どちらの側も相手がどのように運用するか、またはしたかを理解していれば、それを考慮に入れることができたでしょう。結果として、両側とも少なくともある程度は安全が「相手チームの仕事」だと思っていたのです。船は安全性を強く宣伝していましたが、現実は過去半世紀以上の一般的な傾向を継続しており、毎年船はその前の年よりも安全性を低くして製造・運航されていました。（Brander 1995）
今日、私たちはITとソフトウェアエンジニアリングの間に同じ問題が生じているのを見ています——安定性については確かにそうですが（それも当てはまりますが）——今はセキュリティについてであり、オリンピックスの文脈における安全性と同様に見ることができます。セキュリティは過去10年間で技術の両面で最も重要なトピックの1つになっており、業界は両側が徹底的にセキュリティプラクティスを実行する必要性によって生じる課題に直面しています——どちらも単独では本当に安全なシステムを実装することはできません。安全やセキュリティのための計画は、運用中に手続き的に施行することの代替にはなりません。
今日の優れた比較例はBritish Airwaysであり、彼らがどのように大西洋を横断するすべてのフライトを監督するかです。大西洋横断航空交通の主要キャリアとして、オリンピックスが横断しようとしていた同じルートを、British Airwaysは安全性における卓越性の評判を維持しなければなりません。2017年でも、北大西洋を飛ぶのは微妙で複雑な旅です。
British Airwaysのフライトが離陸する前に、パイロットと乗組員は300ページのミッションマニュアルを確認しなければなりません。これには飛行機、乗組員、天気などに関するすべての詳細が記載されています。このプロセスは非常に徹底的であるため、British Airwaysは大西洋横断を「フライト」と呼ぶことさえ拒否し、公式にはすべての旅行を「ミッション」と呼んでいます——関係するすべての人に、そのような取り組みに伴う深刻さとリスクを伝えるためです。彼らは、人々がそのような旅行についての考え方を変えることの重要性を明確に理解しており、たとえ1日に数回完了するとしても、フライトが日常的になることがないよう気を配っています。（Winchester）
British Airwaysのアプローチがタイタニックに使われていたならば、災害はそのときには起きなかった可能性が非常に高いです。運用側だけで災害を防げたかもしれません。同様に、船のエンジニアが今日のBoeingやAirBusと同じ基準に保たれていたならば、管理者によって安全要件を修正するよう圧力をかけられたとき、それほど容易には妥協しなかったでしょう。
オリンピックスに実際に影響を与えたのは、多くの意味で、チェックされていないスコープクリープの一形態でした。プロジェクトは「ビッグデザインアップフロント」の伝統的なウォーターフォールアプローチで始まり、当初の要件は安全性が重要な役割を果たすという良いものでした。元のプロジェクト要件、さらには元の設計の多くが使用されていたならば、船はそれよりもはるかに安全だったでしょう。しかし、より大きな食堂や豪華な内装への新しい要件が優先され、これらの新しい変更に対応するためにプロジェクトのスコープとパラメーターが変更されました。すべてのプロジェクトと同様に、いかなる変更も真空状態では起こりませんが、コスト、安全性、納期などの他の要因に影響を及ぼします。（Sadur）
タイタニックに特有のスコープクリープは劇的でしたが、隠れており、ほとんどの場合必ずしも明白ではありませんでした。食堂の大きさの変更などの小さな変更を指摘するのは簡単ですが、それよりもはるかに重要だったのは、船を納品しなければならない時間枠の変更でした。スコープを実際に変えたのは、当初の締め切りとプロジェクトが比較的厳密に維持されなければならなかったことでした。タイタニックのドック作業と後の係留作業の最中に、兄姉船のオリンピックが何度も大規模修理のために持ち込まれ、これがタイタニック自身の作業を完了するための元のスケジュールで利用可能な時間に非常に大きな影響を与えたことが特に問題でした。このタイプのスコープ変更は、物理的な成果物と元の日付が劇的な方法では変更されなかったため、特に後から見ると、見落としたり無視したりすることが非常に容易です。しかし、あらゆる意図と目的からして、タイタニックは当初計画されていたよりもはるかに速く製造が急がれました。
現代のソフトウェアエンジニアリングでは、設計タスクにかかる時間を、タスクを実行するエンジニア自身ほどうまく見積もれる人はいないと広く受け入れられています。また、管理プレッシャーによってエンジニアリングと設計の努力を大幅に加速させる手段はないとも一般的に受け入れられています。プロジェクトが最高速度で動いていれば、それ以上速くなることはありません。速くしようとする試みは、しばしばミス、見落とし、または漏れにつながります。これはソフトウェアで真実であることがわかっており、原則が同じであるため、船の設計でも同様に真実だったと仮定できます。タイタニックにこのプロセスに適切な時間が与えられていたならば、安全対策がより徹底的に検討されたか、少なくとも引き渡しの際に運用チームに適切に伝達されていたかもしれません。急がされたチームは妥協を余儀なくされ、時間は制約なので調整できないため、他のどこかで手を抜かなければならず、ほとんど常にそれは品質と徹底性から来ます。これはミスとして現れるか、設計の一部を変更する際に関係するすべての要因を完全にレビューできないこととして現れるかもしれません。
これにより、ホリスティックな設計思考が導かれます。プロジェクトの最初、オリンピックスは安全性を念頭に置いて設計されました。一緒になって高い信頼性の船を目指した多くの別々のシステムの慎重な相互作用から生まれる安全性です。この規模の船のコンポーネントを個別に見ることはできません——それでは意味をなしません。船体の設計、デッキのスタイル、積み荷の重量、使用される材料、隔壁のスタイルはすべて相互に関連しており、一緒に機能しなければなりません。
プロジェクトがより迅速に完了するか、パラメーターを変更するよう押されたとき、このホリスティックな思考と以前の決定の明確な再検討は行われなかったか、十分に行われませんでした。むしろ、個々のコンポーネントが船全体の中での役割への影響を考慮せずに変更され、全体的な安全性への影響がありました。細かな変更に見えたものが、ホリスティックなプロジェクト管理が放棄されたため予測されなかった意図しない結果をもたらしました。（Kozak-Holland）
エンジニアリングへのこの変更は、もちろん運用にも反映されました。双眼鏡を使用しないことや氷バケツの読み取りを行わないことなどの各変更は個別には多少マイナーでしたが、一緒になると信じられないほど大きな影響を持ちました。おそらくですが確信はできませんが、凝集したプロジェクト管理、または少なくともプロセス改善システムが使用されていませんでした。双眼鏡が使用されていること、水のテストが正確であることなどを誰が監督していたのでしょうか？どんな確認でも、これらのタスクに必要なツールが全く存在しなかったことを明らかにしていたでしょう。手順の簡単なテスト実行さえ実行されていた可能性はなく、定期的な確認やプロセス改善はなおさらです。プロセス改善は、Captain SmithがRMSオリンピックで練習し、5回目の航海で海上衝突を引き起こし、その後タイタニックの初回進水でほぼ同じ間違いを繰り返したという事実によって特に強調されます。オリンピック級船のすべての船長とパイロットが学ぶべき重要な教訓だったはずのものが、代わりに無視され、ほぼ直ちに繰り返されました。（「Olympic」）
もちろん造船とソフトウェアは非常に異なるものですが、多くの教訓を共有できます。最も重要な教訓の一つは、造船が直面した限界を見て、ソフトウェアを扱う際に同じ制限を保持することを強制されていないことを認識することです。オリンピックとタイタニックはほぼ同時に建造され、オリンピックの建造から得られたエンジニアリング知識が、まして運用を、タイタニックの建造に適用される時間が全くありませんでした。現代のソフトウェアではこのような制約を期待することは決してなく、実際のコードでも概念的にも、それに基づくソフトウェアに進む前に、少なくともある程度ソフトウェアをテストできるでしょう。今日のプロジェクト管理は、より現代的な時代と私たちの異なる業界の両方に存在する違いを最大限に活用する必要があります。一部のソフトウェアプロジェクトはまだこのようなプロセスを必要としますが、これらはますます少なくなり、今日ではわずか20年前よりも劇的に少なくなっています。
Harland-Wolffがオリンピックスで行った作業を評価することは非常に価値があります。彼らは当時の範囲内で可能なフィードバックループを組み込もうと明らかに努力していました。後の船のためにより多くを学ぶために以前の船の建造を利用しようとしただけでなく（船はほぼ同時に建造されており、ほとんどの教訓を適用する時間がなかったため、これは非常に限られていましたが）、さらに重要なことに、彼らは「保証グループ」を船と一緒に航海させるという並外れた措置を講じました。この保証グループは、あらゆる種類のサポートトレードのあらゆる種類の見習い及び熟練造船業者で構成されていました。（「Guarantee Group」）
直接フィードバックのための保証グループの使用は、当時も今も前例がなく、多くの貴重な労働者を大西洋を豪華に往復させるために犠牲にした造船業者にとって、ハードコストと時間の膨大な投資でした。グループは自分たちの仕事を直接検査し、それが実際に動いているのを見て、稼働中の船の文脈内でその使用を理解し、チームビルディング、知識移転などに取り組むことができました。これは船が建造で重複していた造船所からのフィードバックよりもはるかに価値があり、これは彼らの造船事業の未来への強力な投資でした：おそらく数十年にわたって彼らに恩恵をもたらしたであろう産業教育へのコミットメント。
現代の展開スタイル、ツール、教育により、大多数のソフトウェアが先進世紀転換期の造船とそれほど異ならないウォーターフォール手法の下で作成されていたものから、ほとんどのソフトウェアが迅速なテスト、評価、変更、展開を可能にするアジャイル手法をある程度活用するまでに進化してきました。スコープクリープは軽減または重度に管理しなければならないものから、開発プロセス内で予期され想定されるものとして扱われるほどにまで変化しました——ほぼ活用さえできるまでに。ビッグデザインアップフロントの根本的な問題の一つは、常に顧客またはカスタマー役のステークホルダーに「ビッグデシジョンアップフロント」を求めることであり、これは設計がエンジニアにとって難しいよりもはるかに難しいことが多いです。これらの初期決定はスコープクリープや後の変更リクエストの主要な要因になることが多く、変化が継続的に起こることを要件に組み込むアジャイルプロセスによって削減または回避できることが多いです。
造船業者Harland and Wolffはテストのためにオリンピックの15フィートモデルを建造しましたが、これはある程度は有用でしたが、もちろんフルサイズの船が後に生み出す水力学的作用を模倣することに失敗し、他の船に近いときの新しい船の大きさのより危険な副作用を予測することに失敗しました——これがグループの最初の事故とほぼ2回目につながりました。建造業者は設計と建造プロセスのすべての段階でテストし学ぶためにあらゆる努力をしたようです。（Kozak-Holland）
現代のプロジェクト管理と比較すると、これは予見されない理由でデッドエンドとなるかもしれないものにさらなる努力を投資する前に、開発者やユーザーが実際に経験できるよう、迅速なモックアップまたはワイヤーフレームを作成することに相当します。これは特にユーザーインターフェース設計において重要で、実際のユーザーがシステムを物理的に操作し、自分が探している体験を提供するかどうかを自分で判断する機会を提供せずに、使いやすさや満足度を適切に予測する能力がないことが多いからです。（Esposito）
もちろん、オリンピックスが引き受けたリスクを財政的なトレンドと力に関する歴史的並置の文脈で考慮しなければなりません。当時、前世紀の中頃から始まり、支配的な財政的考え方は、人命、貨物、または船の損失という観点から安全よりも危険に傾く方が最善であり、保険を通じてその差を補うというものでした。船がリスクを冒した方法で運航する方が財政的に有利であるという理由で、人命よりも優先されていたのです。このトレンドは、オリンピックスの時代までにほぼ60年間確立されており、タイタニックの沈没の大規模な報道が始まるまでは変わりませんでした。「不沈」の船がこれほど多くの人命を乗せてこれほど壮大な方法で失われるまで、市場の公衆への影響は存在しませんでした。
リスクとその財政的トレードオフへのこのアプローチは、プロジェクトマネージャーが100年以上前と同様に今日でも理解しなければならないものです。リスクはそれを排除するためにどんなコストでも払う価値があると信じることに陥りやすいですが、プロジェクトはそのように考えることはできません。リスク軽減の追求に無限のリソースを費やすことは可能です。現実世界では、リスクとリスク軽減のコストのバランスを取ることが必要です。現代における素晴らしい例は、米国のクレジットカード詐欺の取り扱いです。ここ数年まで、クレジットカードの窃盗を防ぐためのより高度なセキュリティ対策のコストは、それを行わないリスクと比べて高すぎるというのが米国のクレジットカード業界の一般的な見解でした。基本的に、偽の取引を防止するよりも偽の取引の払い戻しに費やす方がより費用効果が高いと見なされていたのです。このコスト対リスクの比率は時に直感に反し、さらには苛立たしくなることもありますが、論理的で計算された方法でプロジェクトの決定を推進しなければならないものです。
同様に、ITではシステムのダウンタイムが本質的に無限のコストであると信じてシステムを設計し、実際に発生した場合のダウンタイムイベント自体のコストよりもはるかに多くのコストをダウンタイムリスクの軽減に費やすことが一般的です。これは明らかに愚かですが、このタイプのコスト分析が実行されるか、正確に実行されることは非常に稀であるため、このメンタリティの餌食になることがはるかに容易です。ソフトウェアエンジニアリングプロジェクトでは、同様の方法でリスクにアプローチしなければなりません。いかなる種類のリスクも存在することを受け入れ、実際のリスクを判断し、そのリスクの影響の大きさを判断し、それを軽減戦略のコストと比較することは、リスクに関する適切なプロジェクト管理決定を行うために重要です。（Brander 1995）
また、非常に大きなプロジェクトにとって特に興味深いのは、オリンピックスが確かに該当する「大きすぎて潰せない」という追加の概念です。これはもちろん、過去10年間の金融危機の際に生まれた現代的な表現ですが、この概念と現実ははるかに古く、プロジェクトが完全に失敗した場合に「国家的な財政的災害」を記録するような規模に落ちるどんなプロジェクトにとっても価値ある考慮事項です。オリンピックスの場合、英国政府は最終的に投資家を全体的な災害から守り、最大の乗客路線の一つの崩壊は当時の国にとって壊滅的だったでしょう。
White Star Linesは単純に「大きすぎて潰せない」であり、政府によってある意味で救済され、その数年後にCunardに強制合併されました。この概念——政府が会社の失敗のリスクを受け入れたくないことを知ること——は当時計算または考慮されたかもしれませんが、私たちにはわかりません。しかし、今日では非常に大きなプロジェクトでこれが考慮されていることはわかっています。現在起きている例として、Lockheed MartinのF-35戦闘機があります。これは大幅に予算超過し、納期を過ぎており、もはや有用である可能性も低いと見なされていますが、国家経済にとってプロジェクトが完全に崩壊することを許すには重要すぎると見なす異なる政府スポンサーによって長年支えられてきました。この現象がより広く知られるにつれて、より多くのプロジェクトがリスク分析フェーズでこれを考慮するようになる可能性があります。（Ellis）
方程式の運用側に飛ぶと、タイタニックの沈没につながったいくつかの側面を検討することができますが、核心において私が最も明白だと思うのは、プロセス全体を通じた標準的な作業手順の欠如です。船が処女航海中だったため、プロセスの文書化と改善のための時間がほとんどなかったことから、これはある程度理解できます。しかし、これは長年にわたる実績と評判を保持した老舗海運会社の看板船でした。タイタニックが最初の航海を試みる頃には、オリンピックはすでに満足のいく標準的な作業手順を作成するのに十分すぎるほどの実績があったことも見落とされます。
処女航海でさえ基本的な文書が期待されていたはずです。この規模の船がスタッフ間の調整とコミュニケーションなしに機能することは合理的に期待できません。最初の船が出航する前に基本的な乗組員の作業手順を作成・準備するための時間——実際には数年——は十分ありましたし、もちろんこれはこの種のすべての船に対して行わなければならなかったでしょうが、タイタニックの場合にはそのような作業手順が欠けており、欠如しており、未テストだったことは明白でした。
作業手順に責任を持つ側はプロジェクト方程式の運用側から来ると特定されるでしょうが、エンジニアリングと建設チームからもある程度の文書が提供または調整される必要があったでしょう。タイタニックで機能しなかった多くの手順には、圧力下での指揮系統の失敗（会社の取締役が艦橋を引き継ぎ船長がそれを許した）、氷山警告よりも乗客メッセージの中継を優先するよう無線通信士に指示したこと、他の船が警告しようとしているのを放送を止めるよう無線通信士に告げることを許したこと、重要なメッセージが艦橋に届けられなかったこと、重要な業務に必要なツールが提供されなかったことなどが含まれていました。（Kuntz）
船のエンジニアリングと設計に必要だったのと同様に、船の運用にも強力でホリスティックなガイダンスが必要であり、マルコーニ無線通信士のような部門を個別のユニットとして見るのではなく、船とその乗組員が全体として機能するようにしていました。その例では、彼らは公式に船の乗組員ではなく、有料の乗客通信を処理し、時間が許す場合にのみ船の緊急通信を処理するために乗船したMarconiの従業員でした。外部請負業者としてでさえ、ホリスティックな運用管理システムの一部として監督されていれば、彼らの手順はおそらくはるかに安全に焦点を当てたものになっていたか、少なくともメッセージを艦橋に届けることに関するサービスレベル合意が、アドホックで裁量的なものではなく明確に定義されていたでしょう。
あらゆるプロジェクトとプロジェクトコンポーネントにおいて、プロジェクトの目標、成果物、手順などの良い文書が重要であり、プロジェクト管理は、プロジェクト内部でも外部のステークホルダーとの間でも、良いコミュニケーションと文書化がすべての中心でなければ、成功の望みはほとんどありません。
今日わかることは、オリンピック、タイタニック、ブリタニックのプロジェクト管理の教訓が今日の私たちにとってまだ価値があり、可能な限り反復的なプロジェクト設計への推進、部族的知識への投資、リスクの計算、システムエンジニアリングとシステム運用の役割、または製品コストに対する保護的な外部力の相互作用の理解という時代の文脈が依然として関連しているということです。プロジェクトに影響を与える要因はサイクルで変化し、今日私たちはオリンピックスのモデルに似た傾向に向かうトレンドを見ています。将来、振り子はおそらく再び振れるでしょう。根本的な教訓は非常に関連性があり、今後もそうであり続けるでしょう。私たち自身のプロジェクトがWhite Starのものとどのように似ているか、そして彼らとどのように異なるかを評価することで、多くを学ぶことができます。
参考文献および引用資料：
Miller, Scott Alan. Project Management of the RMS Titanic and the Olympic Ships, 2008.
Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2003.
Kuntz, Tom. Titanic Disaster Hearings: The Official Transcripts of the 1912 Senate Investigation, The. New York: Pocket Books, 1998. Audio Edition via Audible.
Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.
Brown, David G. “Titanic.” Professional Mariner: The Journal of the Maritime Industry, February 2007.
Esposito, Dino. “Cutting Edge – Don't Gamble with UX—Use Wireframes.” MSDN Magazine, January 2016.
Sadur, James E. Home page. “Jim's Titanic Website: Titanic History Timeline.” (2005): 13 February 2017.
Winchester, Simon. “Atlantic.” Harper Perennial, 2011.
Titanic-Titanic. “Olympic.” (Date Unknown): 15 February 2017.
Titanic-Titanic. “Guarantee Group.” (Date Unknown): 15 February 2017.
Brander, Roy. P. Eng. “The RMS Titanic and its Times: When Accountants Ruled the Waves – 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture“. (1998): 16 February 2017.
Brander, Roy. P. Eng. “The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management.” (1995): 16 February 2017.
Ellis, Sam. “This jet fighter is a disaster, but Congress keeps buying it.”. Vox, 30 January 2017.
追記：
Mark Kozak-Hollandは当初2003年にGanttheadのタイタニックに関する一連の記事として本を出版しました：
Kozak-Holland, Mark. “IT Project Lessons from Titanic.” Gantthead.com the Online Community for IT Project Managers and later ProjectManagement.com (2003): 8 February 2017.
さらに読む：
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.
広告
