RMS 泰坦尼克号与奥林匹克级船舶的项目管理

建造 R.M.S. 泰坦尼克号及其姊妹船 R.M.S. 奥林匹克号和 H.M.H.S. 不列颠尼克号的构想，最初于 1907 年开始成形。这三艘船共同构成了白星航运公司的奥林匹克级 远洋客轮。（为清晰起见，本文通篇将用奥林匹克级来指代这一级别的船舶。）人类历史上鲜有船舶能像 R.M.S. 泰坦尼克号那样广为人知、声名狼藉。

从项目管理的角度审视 R.M.S. 泰坦尼克号时，首先要明确这个项目所要产出的是何种类型的产品。与许多最终客户将拥有最终产品的项目不同，泰坦尼克号被设计用来向其终端客户交付一项服务，尤其是一项摆渡服务。这给讨论“泰坦尼克号项目”带来了一个有趣的挑战，因为大多数项目管理观点都认为项目具有明确的起点和终点，以及清晰、定义明确的利益相关方。

对于像 R.M.S. 泰坦尼克号这样的项目，我们可以采取两种视角，从两个方面切入这一议题。一方面，我们有这样一个项目：构思、设计、建造奥林匹克级三艘船舶并将其交付给白星航运公司。另一方面，我们有 R.M.S. 泰坦尼克号——它在其前辈 R.M.S. 奥林匹克号的基础上进行了进一步的定制化，完成了初步生产并被交付，作为一项服务，提供给它将在南安普敦与纽约之间摆渡的乘客。为了控制范围，我不会讨论在 R.M.S. 泰坦尼克号沉没之后，对其两艘姊妹船所进行的测试、缺陷修复、维修、范围变更和增强这一规模更为庞大的项目。R.M.S. 奥林匹克号和 H.M.H.S. 不列颠尼克号在其服役年间都经历了许多变更，包括将不列颠尼克号从远洋客轮的角色重新定位为第一次世界大战期间英国皇家海军的主力医院船，以及为奥林匹克号加装双层船壳和额外的救生艇——因为船员们在它被改造得更安全之前拒绝驾驶它出航。（“Olympic”）

我的目标是在此审视泰坦尼克号这项服务，从构思到服务交付，并最终到服务失败的全过程。从这一视角来看，泰坦尼克号大可被当作现代的软件即服务（SaaS）项目来对待。由于泰坦尼克号这样的船舶，或像 Salesforce.com 或 SugarCRM 这样的 SaaS 产品的本质特性，我们需要考虑产品的预期寿命，以及为使其持续运转所需的持续升级和维护。泰坦尼克号在海上时需要大量的引航员、水手、厨师、行李员、乘务员等人员，并需要重新装配、维修；而且，倘若它幸存下来，它本会需要像 R.M.S. 奥林匹克号那样加装一层新的双层船壳。SaaS 项目同样需要人员来维护数据中心和网络，需要持续的升级和缺陷修复、新功能等等。无论是泰坦尼克号还是 SaaS 项目，都实实在在地存在服务中断的可能，而这可能代价极其高昂。维持稳定、可靠的运营，是这两种商业计划能否成功的一个主要因素。

让我们从审视利益相关方入手，开始分析这个促成泰坦尼克号问世的项目。我们可以轻易地识别出：泰坦尼克号的乘客和船员是利益相关方，白星航运公司作为一家公司以及项目工程师也是利益相关方，哈兰德与沃尔夫作为建造方，亚历山大·卡莱尔和托马斯·安德鲁斯作为哈兰德与沃尔夫的造船师和设计师，负责服务交付的爱德华·约翰·史密斯船长，以及最后担任项目发起人角色的白星航运公司董事约瑟夫·布鲁斯·伊斯梅及其管理团队。在任何这种规模的项目中，都会有许多重要的参与者，他们都在项目中拥有某种利益。我们将只聚焦于这些关键人物，将其视为泰坦尼克号项目中最为突出的利益相关方。

用 IT 项目管理的术语来说，泰坦尼克号项目最接近于瀑布模型。这一流程始于一个高层次的构想，它由代表白星航运公司的约瑟夫·布鲁斯·伊斯梅与代表其造船合作伙伴哈兰德与沃尔夫的詹姆斯·皮里勋爵共同提出。该项目由这两家公司共同构思。泰坦尼克号将为两家公司带来巨大的声望和盈利潜力，同时也需要两家公司投入大量资金。尽管今天我们似乎无法获得最初的项目章程，但我们可以把伊斯梅与皮里勋爵之间的那次会面视为非正式的项目章程，以及该项目的启动。（Sadur）

奥林匹克级船舶的技术设计，是在伊斯梅与皮里勋爵拟定高层次方案之后，由哈兰德与沃尔夫的首席造船师亚历山大·卡莱尔承担的。卡莱尔自项目伊始就一直是该项目的首席设计师，直至 1910 年他退休，并将首席设计的职责移交给哈兰德与沃尔夫的董事总经理托马斯·安德鲁斯（Brander，1998）。安德鲁斯将负责泰坦尼克号设计的最后阶段。于 1910 年秋季下水的奥林匹克号，极有可能是完全在卡莱尔的指导下设计完成的。由于泰坦尼克号几乎沿用了奥林匹克号的全部基础结构（船壳设计、罗盘布置、救生艇、舰桥等等），我们可以有把握地认为，安德鲁斯对泰坦尼克号设计的贡献大多属于美学层面，或者用软件开发的术语来说，是与“界面”相关的部分。（Thinkquest）

由于造船工作类似于建筑施工，尤其是像奥林匹克级这样巨型的船舶，其设计过程涉及大量的前期设计，而后期一旦设计师能够实地检查船舶时，反馈回路却极为有限。用软件术语来说，这被称为“大量前期设计”（BDUF）。在需求频繁变化的软件领域，这通常被视为一种非常糟糕的做法，但在机械和结构工程中，这干脆就是唯一合理的解决方案。

随着奥林匹克级船舶工作的推进，人们就船舶的核心基础结构设计做出了若干决策。这尤其危险，因为针对此类项目所采用的方法论，并非设计来允许在方案获批后再进行这种性质的变更。船舶被设计为一个整体系统，具有相互依存的安全系统和高度的复杂性。与大多数软件不同，要将船舶快速原型化到确保安全所需的精确程度是非常困难的。要正确地对安全系统做出关键性变更，本会需要对规格说明进行全面的重新设计。但由于这些变更是出于成本节约、进度问题和豪华装潢而做出的，因此在这些变更中几乎没有融入任何整体性的思考。（Kozak-Holland）

奥林匹克级最初的设计意图是要采用当时最新的安全技术。在初步设计完成后，来自白星航运公司、尤其是 J.B. 伊斯梅的商业压力施加到了建筑师和工程师身上，要求他们去除安全设施，以换取头等舱的奢华享受。其中最为著名的两项变更当然是：移除救生艇，以免船舱的视野被不必要地遮挡；以及对若干舱壁进行改动，使其不再密闭，且仅高出水平面十英尺，以便扩建一座宏大的舞厅。与 IT 项目一样，关于核心系统的工程决策通常超出了商业高管的认知范围。允许商业方面的决策去影响本应属于技术性的决策是危险的，因为通常的预防措施和思考过程被绕过了，专业知识也被忽视了。在这个案例中，这些是关乎人命的关照与保全的问题。在软件领域，我们很少面对如此重要的任务，但允许不了解关键系统的业务经理参与其设计，可能会造成极大的危害——即便其后果良性到仅仅是业务损失或运营成本上升。

对奥林匹克级设计的后期变更所引发的最为戏剧性的问题之一是：这些变更，每一项单独看都很微小，但极有可能从未被放在一起、以当初考量整船设计的那种方式作为一个整体来审视。当救生艇被移除时，参与其中的工程师们的想法是：这艘船被设计成一座漂浮的救生筏，而救生艇的用途仅仅是在泰坦尼克号或奥林匹克号失去动力这一“最坏情况”下，将乘客从一艘静止不动的远洋客轮摆渡到另一艘船上。即便发生碰撞，预计也只会使它们低低地漂在水面上，而不会沉没。应白星航运公司执行委员会的要求，救生艇被移除，直至仅剩下法律规定的最低数量。对工程师而言，这本会是一种可以接受、尽管并不推荐的安全权衡。这艘船的设计使得配备额外的救生艇既不是法律上的要求，也没有任何迫切需要去保留它们，因为人们认为这些额外救生艇的用处微乎其微。归根结底，这本不会是工程师的决定，而是白星航运公司的决定——它是造船方的最终客户，而其决策为造船方提供了生计。

单独来看，移除救生艇的决定极有可能只是一个无关紧要的决定。但与此同时，人们还做出了一项决定，要改变奥林匹克级的关键结构设计——将原本全部为高大舱壁的设计，改为其中四道舱壁被大幅降低至仅高出水线十英尺，这意味着这艘船作为漂浮救生筏的构想被破坏了。这些舱壁从来都不像营销材料会让我们相信的那样真正水密，但它们相当高大，且非常“抗”水，极有可能即便在非常严重的船壳破损情况下也能阻止水在它们之间流动。由于这艘船最初的设计充满了安全设施，因此这一点本会像救生艇一样，被视为一项冗余功能，而移除它只不过是把这艘船降低到更常见的安全标准而已。逐项来看，这些变更大多无害，但合在一起看，这些变更就成了对这艘船的彻底重新设计，并且是彻头彻尾的灾难。在任何环节，合格的工程师都没有回过头去，针对所有已落实的变更，对这艘船的安全设施进行一次完整的重新评估。

在某些方面，我们可以把 J.B. 伊斯梅看作一个微观管理者。他不信任那些被他因技术专长而聘用之人所做的决定，并直接或通过间接的压力推翻了他们的决定。微观管理会带来许多负面结果。最明显的就是未经训练、不具资格的管理者去影响那些他人以为出自合格专业人士之手的决策。其他结果还包括侵蚀项目团队所创造的价值，以及损害员工的忠诚度和士气。

在造船业中，在像泰坦尼克号这样成批建造同级船舶的情况下，我们需要考虑三个主要的项目阶段——原型船奥林匹克号的设计与建造；泰坦尼克号的设计完善与建造；以及最后的服务交付与运营。尤其就泰坦尼克号而言，我们可以看到，主要的设计以及任何结构性的变更，都是在奥林匹克号建成之前做出的。托马斯·安德鲁斯曾乘坐奥林匹克号航行，但这主要是为了让他能为泰坦尼克号做出美学上的改动，因为在那个时间点上，要改动结构性的工作已为时过晚。出于同样的原因，安德鲁斯也乘坐着泰坦尼克号航行，以便为即将下水的不列颠尼克号（安德鲁斯称之为“巨人号”）做类似的事情。

就项目范围而言，我们可以看到这个项目紧密地遵循了最初确立的计划。建造工作是基于预先批准的方案进行的，几乎没有变更。范围中最为戏剧性的变更发生在泰坦尼克号的建造期间，当时项目不得不停工，以便腾出条件来维修奥林匹克号。哈兰德与沃尔夫以及白星航运公司双方都明白，泰坦尼克号会被延误，但奥林匹克号的可服役性具有优先权。任何类型的资本建设项目中的一个主要因素，是各建造阶段之间需要订立合同层面的协议，因为一旦建造开始，要适应范围变更几乎是不可能的。（“Olympic”）

很难找到这样紧密遵循此类模型的软件项目：先有一个生产型原型，随后是一系列基于该原型、但又与之不完全相同的生产实施。我所能设想到的与此最接近的例子，是企业资源规划（ERP）套件 SAP。对于这款套件以及与之类似的其他套件，客户基于其原型化的性能和功能购买该套件，然后或者自行、或者通过一家咨询公司或原始供应商，对该套件进行大量改造，以满足自身的需求。一般来说，这种做法的优势在于：软件套件的核心，即基础结构，非常稳定且经过充分测试，并且常常在广泛多样的情境中被使用，从而使其同时获得了项目方和客户方两方面的测试。当然，必须谨慎，因为客户自行发起的改造，将无法享有人们所期望的、对核心基础结构所做的那种深入测试的好处，这些改动也无法获得来自更广泛客户群体的“众目睽睽”之利。

就奥林匹克级船舶而言，人们在这艘船十五英尺长的模型上进行了认真的测试，并在奥林匹克号建成时进行了测试。对于像奥林匹克号这样复杂的船舶，除了对各个单独系统进行单元测试之外，进行真实世界的测试至关重要。奥林匹克号经受了对此类船舶而言属于标准的常规测试措施。然而，当泰坦尼克号建成时，建造方和邮轮公司认为，由于泰坦尼克号本质上是奥林匹克号的复制品，因此已经完成的测试以及奥林匹克号持续成功的使用，对泰坦尼克号来说就足以充当测试了，于是泰坦尼克号只接受了极少的额外测试。然而，这并非最佳实践，因为航海人员都知道，所有船舶——即便是复制品——其表现也各不相同，每一艘船都是独一无二的，必须对其本身进行测试。（Kozak-Holland）

泰坦尼克号几乎没有获得任何用于测试或性能试航的时间。这部分是因为奥林匹克号发生了一起严重事故，不得不被送往贝尔法斯特的船坞进行维修。在奥林匹克号维修期间，泰坦尼克号不得不等待，因为同一时间只能对一艘那种尺寸的船舶进行作业。这给泰坦尼克号施加了商业上的时间限制，因为它已被排定执行定期的跨大西洋航线任务，并且急需立即投入使用。正因为如此，一些本来很可能会进行的额外测试被跳过了，泰坦尼克号就这样被派了出去，其主要的测试就是从贝尔法斯特到南安普敦的航程；而且，即便在这段航程上，也至少有一名付费乘客在船，这使其更像是一次低载客量的真实航行，而非一次正儿八经的测试。（Kozak-Holland）

看起来，白星航运公司和 J.B. 伊斯梅相当愿意承担非同寻常的项目风险，以便尽可能快地让这艘船投入正常服役。通过标准的航海程序，他们借助海上保险化解了大部分资本风险。这将保护他们免受许多潜在未知因素的影响。

在十九世纪的后半叶，无论是航运公司还是各国政府，都越来越普遍地把风险视为一个低优先级的问题。建于 1858 年的S.S. 大东方号被认为，并且在真实世界的案例中也证明，远比此后五十四年间相继问世、安全性日益降低的远洋船舶的设计要安全得多。在泰坦尼克号沉没之后，各公司和政府重新评估了局面，在此之前，状况会持续恶化。有人认为，航运公司将尚可接受的安全记录看作是为它们数十年来在相对无事故的航运中对安全所持的漫不经心态度提供了正当理由。金融市场的压力占了上风，偏袒那些安全标准宽松的公司，从而促使整个行业逐渐摒弃代价高昂的风险管理。（Brander，1995）

以进一步化解因缺乏测试和训练而产生的风险为名，若干船员，最值得注意的是史密斯船长，被从奥林匹克号调来驾驶泰坦尼克号进行它的首次大西洋横渡。这可以被看作是伊斯梅在寻求经验，这看似能够减少那种因未经直接测试便驾驶一艘船而产生的“未知”，但至少拥有从原型船上得来的最大限度的经验。然而，这或许并非这一决定背后的根本原因，而且很有可能史密斯船长之所以被选中，是因为他在白星航运公司的地位相当岌岌可危——他不久前刚刚造成了一起涉及 H.M.S. 霍克号的严重事故，那起事故导致奥林匹克号需要紧急维修，并延误了泰坦尼克号的出航。史密斯船长很可能心绪不宁，为自己的职业生涯而忧虑，无论从心境还是处境上，都不大可能在公司的压力将他引向违背其更明智判断的方向时，去充当船上最终一级的责任担当。这或许正是白星航运公司所寻求的那个运营上的漏洞。这一情形很可能因史密斯船长在南安普敦停泊时，过于贴近或过快地驶近 S.S. 纽约城号而进一步加剧——这导致后者挣脱了缆绳，差点与泰坦尼克号相撞。（Kozak-Holland）

根据惯常的海事法，船长是船舶的绝对指挥者，在海上拥有完全的管辖权，即便有军方或民方的更高级别官员在船上亦是如此。船长首先对乘客和船员的生命与安全负有道德和法律上的责任，其次才是对货物和船舶负责。（Kuntz）

一旦泰坦尼克号建造、装配完毕并可供航行，我们就看到了一次阶段的转换，进入了整个泰坦尼克号项目的服务交付阶段。在这一阶段，我们已经越过了传统的项目管理各阶段。在大多数情形下，客户此时本应已接管了完工的产品。但就泰坦尼克号而言，这成了服务交付阶段。

在服务交付之下，白星航运公司对这艘船将会出现的任何新问题承担责任。在这一阶段，传统的“设计—建造—测试”体系将不再被使用，取而代之的是，服务交付将由标准操作规程（SOP）来监督管理。持续的船舶改装、维修、调校等等仍会继续，但这些都被设计为不至于达到需要中断服务的程度，而是较为细微，且在最终客户——乘客——并不知情的情况下完成。正是在这一阶段，乘客作为我们最为关键的利益相关方登场了，因为在这一情形下，他们不仅仅是财务上的利益相关方，而是实实在在地把自己的性命押在了这艘船的可靠性和船员的运营之上。

在敏捷项目管理界，有一则寓言常被用来标示利益相关方内部的各种角色。这些角色被称为猪与鸡。这则寓言讲的是一只鸡和一头猪有意一起开一家餐馆。猪问鸡他们将供应什么。鸡回答说：“嗯，当然是培根和鸡蛋啦。”对此猪回应道：“我想我没什么兴趣。你只是参与其中，而我却要全身心地投入。”（Schwaber 7）

猪与鸡这个比喻通常被用来表达两类利益相关方之间的区别：一类是真金白银或职业生涯岌岌可危的利益相关方，另一类则是对项目有切身利益但并非攸关存亡的利益相关方。鸡固然不愿看到项目失败，但失败对它们而言未必是毁灭性的。就泰坦尼克号而言，我们看到，财务上的利益相关方哈兰德与沃尔夫以及白星航运公司，实际上就是鸡。它们要损失的固然很多，但它们的投资已经投保；而且我们稍后将会看到，由于当时与奥地利和德国之间一触即发的战争，政府甚至愿意保护此类性质的公司。无论是白星航运公司还是哈兰德与沃尔夫，都没有“全身心地投入”——它们确有切实的利益，泰坦尼克号的成功对它们极为重要，但泰坦尼克号的乘客和船员才是这里真正的猪，他们愿意拿自己的性命作赌注。猪与鸡的比喻鲜有比此更为贴切的时候。

为了确保更高质量的持续服务，一支来自哈兰德与沃尔夫的保证团队登上了这艘船的处女航。这支团队包括哈兰德与沃尔夫设计和建造团队中的许多重要成员，其中就有首席设计师托马斯·安德鲁斯。这种保证团队在哈兰德与沃尔夫所有的重大项目上都是惯例。这支团队会利用航行的时间，在不同于其测试时的各种条件下评估建造质量，衡量客户满意度，并寻找改进的机会。托马斯·安德鲁斯此前已经为了这同一个目的乘坐过奥林匹克号，并做出了许多微小的改动来改进泰坦尼克号。举例来说，他会在这次航程中花一部分时间，为乘客客房设计更为廉价的衣钩。（“Guarantee Group”）

保证团队由来自哈兰德与沃尔夫内部许多不同技术工种的专家组成。我们看到其中有来自钳工、电工、细木工、制图员、设计团队等等的代表。这一群体，凭借其各不相同的专业领域，以及其涵盖资深人员和学徒在内、参差不一的经验水平，本会是建造这艘船的项目团队一个极佳的横截面缩影。他们随船在场，并悉心评估工艺、设计及其他最终组件，这一点可以从两个主要的角度来看待。

从第一个角度，我们可以把这看作是对泰坦尼克号项目进行的一次“事后复盘”。这支团队的职责是评估项目在技术上的成功，寻找有待改进的方面，并总结出“经验教训”，以便未来的项目能够从这里所获得的经验中受益。考虑到这趟跨大西洋之旅的成本，以及他们脱离日常职责所花费的时间，这是哈兰德与沃尔夫在项目知识方面进行的一项严肃的投资，极为值得称道。

从另一个角度来看，这支保证团队可以被视为在对一次建造迭代提供反馈。奥林匹克号的建造是第一次迭代，泰坦尼克号的建造是第二次，而不列颠尼克号的建造则是第三次。在这种思路下，我们看到了一种敏捷 反馈回路正在被尽可能地加以利用，以便即便在这样一个极端的资本建设项目上也能允许客户的输入。这些迭代非常漫长，但这是出于必要。这样一来，我们就可以把泰坦尼克号既看作一个独立自足的项目——作为一项离散的交付物，又看作是通过奥林匹克级系列船舶来交付客运服务这一持续项目的一部分。

保证团队随船在场，本会为技术团队提供一个机会，让他们亲身体会到自己产品在真实世界中的应用。在 1912 年，一名技术专家鲜有机会乘坐这种豪华级别的船舶旅行。如果没有哈兰德与沃尔夫的资助，为其员工提供这一目睹自身手艺如何运作的机会，他们或许永远无法理解自己在为最终客户提供服务这件事中所扮演的角色。

保证团队中纳入学徒，意味着可以进行直接的一对一或小组形式的非正式培训。学徒和资深技师本会有许多天的时间在一起工作，而学徒们本会获得一个绝佳的机会，在一种有利于团队建设和知识传递的环境中向他们的前辈学习。在许多方面，我们可以把这段时光看作类似于如今许多公司和项目团队所青睐的异地团队建设活动或务虚会。

在我们对泰坦尼克号的分析中，最令人意外之处在于：这艘船上几乎完全没有使用标准操作规程。一些流程和程序有文档记录，但许多却没有。未被标准化的流程示例包括一些关键的通信流程，比如将电文从无线电室传递到舰桥、向乘客发出船舶正在下沉的警报，以及向舰桥通报瞭望台已发现一座冰山。（Kozak-Holland）

在任何服务交付情形中，标准操作规程都绝对至关重要。在某些公司里，这些规程甚至可能被认为价值连城，构成公司的核心知识产权。没有 SOP，一家公司的凝聚力就不会超过员工之间那种与生俱来的“团队默契”——而在新员工的情况下，这种默契可能微乎其微。员工将不得不完全依赖最佳实践、惯例、非正式的同事指点，或者但愿还有培训，来学习他们的工作和流程。但如果这些没有被写下来，它们就不会被标准化，而培训也将不可避免地因培训者而异，没有任何一名员工能够记住针对所有可能情形的全部指示。

在正常条件下，缺乏标准操作规程或许只是一件相对次要的事情。员工可以充分地履行大部分工作职能，尤其是在受过训练的情况下，并不需要 SOP。如果真需要，他们就得随时随身携带 SOP。SOP 变得极其关键的时候，是在“正常运营程序”不再可用之时，或者用更现代的术语来说，是在运营不再处于 BAU（业务照常）条件之下的时候。对泰坦尼克号而言，BAU 条件在撞上冰山的事件之前数小时就已被打破。

就泰坦尼克号而言，谈论标准操作规程很难不同时谈论通信。因此，我们将从 BAU 条件下的通信谈起，然后看看 SOP 的缺失是如何导致局面迅速恶化的。

泰坦尼克号从一开始就饱受通信设计缺陷的困扰。负责泰坦尼克号一切进出通信的无线电室，并非由白星航运公司运营，而是由马可尼公司的人员配备，他们受雇首要且最重要的是为乘客进行通信，只有在时间允许的情况下才为船舶服务。无线电报务员超负荷工作且不受重视，常常不会把电文转达给舰桥，因为他们还有其他被他们的雇主马可尼公司视为优先级更高的职责。至少有八条冰山警告被发送到了泰坦尼克号的无线电室，但其中只有一部分被转达给了舰桥。（Kozak-Holland）

在这个案例中，重要的是要强调通过服务级别协议来管理第三方承包商的重要性。白星航运公司在允许马可尼公司为其无线电室配备人员时，本应订立一份明确的 SLA，要求船舶的安全和紧急通信务必拥有绝对优先于船员个人电文的优先权。他们也本不应允许马可尼公司因不遵守 SLA 而获取额外的利润或得到经济上的好处。作为一家外部承包商，马可尼公司本应拥有一份为互利而设计的合同——也就是说，当按约定执行时，对各方而言正确地行事都符合彼此的利益。在供应商之间订立那种为供应商损害其客户利益提供经济激励的合同，是非常不明智的。

涉及马可尼公司报务员的最重要的单一事件，是 SS 加利福尼亚号发来的最后一条冰山警告，该船离泰坦尼克号极近——近到后来它会成为目睹泰坦尼克号发射紧急信号弹的那艘船。加利福尼亚号用无线电向泰坦尼克号发出警告，称它已被浮冰群困住，由于危险的状况，无论以何种速度都无法继续前进。马可尼公司的报务员回复道：“闭嘴，闭嘴，我很忙。我正在与雷斯角通联，你在干扰我。”即便危险已如此逼近地迫在眉睫，也很难把无线电室的优先事项摆放在何处表现得更为清楚了。无线电室不仅没有与加利福尼亚号保持通信畅通，而且还拒绝将这最后一条来自外部的警告告知舰桥。在沮丧之下，加利福尼亚号的无线电报务员放弃了警告泰坦尼克号的尝试，关掉了他的无线电设备，去睡觉了。马可尼公司的报务员不仅没有理会这些警告，还疏远了外部通信渠道，以至于当泰坦尼克号开始下沉时，唯一一艘近到足以施救的船却没有回应。（Kuntz）

从舰桥到广大船员以及乘客的通信没有任何正式的流程，全靠人工，并且充其量只是在尝试进行的情况下以尽力而为的方式来完成。舰桥没有通知任何人碰撞即将发生，也没有人为一次本可能极其严重的撞击做好支撑防护。这艘船开始下沉之后，过了一个多小时，舰桥才开始通知船上其他人他们正在下沉。影响乘客和船员生命的关键信息一直对他们隐瞒着，仅由舰桥上寥寥数名人员掌握，他们极有可能是希望对这一事件保密，或者把对人命所面临的明显风险的公开度降到最低。由于不存在任何从舰桥向全船进行通信的系统或流程，这就成了一件轻而易举的事——因为要把任何消息哪怕只是告知乘客，都得费一番齐心协力的功夫。（Kozak-Holland）

船员之间的通信也好不到哪里去。举例来说，值班官位于舰桥之外，但他至关重要的通信链路却位于舰桥室之内。因此，值班人员无法迅速与任何其他舰桥人员通信，也无法与瞭望台及其他相关功能区域协调配合。瞭望台与值班人员之间由一套单向铃铛系统相连，该系统不允许他们进行双工通信，速度非常之慢；而且，当下达紧急命令时，值班人员无法从舵位上的舵手那里获得任何反馈。命令是从露天处朝着封闭的舰桥喊出来的。值班人员只能寄希望于舰桥内的舵手听见了、听懂了，并正在依令行事。来自标准罗盘的通信也同样糟糕。这具罗盘没有被安置在舰桥上方或附近，而是被放在了远远靠后的船尾，舰桥不得不定期与该罗盘进行协调，这造成了大量的混乱和延误。在使舰桥变得高效或安全这件事上，几乎没有投入什么思考——如果说有的话。当快速而准确的通信成为必需时，这种通信设计上的欠缺无疑对泰坦尼克号毫无助益。（Brown）

当最终向白星航运公司位于波士顿的办事处发出对外通信时，所转达的信息是：并无严重损坏，且该事件非常轻微。然而，与如今常见的点对点信息不同，这一信息是广播发出的，可以轻易被其他船舶和中继站截获。船岸通信常被用来在内部公报的幌子下，实质上向新闻界发布信息。因此，无线电被用作了一种营销工具，而不是用来转达诚实而关键的信息。所发出的并不是求救信号，实质上不过是一份旨在为局面“粉饰”的新闻稿罢了。（Kozak-Holland）

通信在任何项目的任何阶段都至关重要。就泰坦尼克号而言，这一灾难性的局面凸显了因通信而产生的种种问题，但这仅仅是一个最坏情况下的情形。项目在做决策时，需要拥有尽可能最新、最准确的数据。没有这些数据，决策就只能依据一幅仅有一部分的可用图景来做出，而可用的正确信息越少，就越不可能做出一个好的决策。

然而，影响泰坦尼克号的最重大的项目管理问题，或许还是它缺乏标准操作规程。SOP 本应在建造过程的后期阶段，作为一项必不可少的项目交付物被制作出来。一艘船在没有任何 SOP 来运营它的情况下竟被认定为适航，这实在是匪夷所思。即便是最为敏捷的开发方法论，也不会忽视对最终用户文档的需要。

由于项目的设计和建造部分未能为泰坦尼克号的船员提供 SOP，或者至少未能提供一份合理的 SOP（白星航运公司手册本身倒是有一些通用的标准程序），因此对于处理通信、追踪警报、发出警告等等，并没有清晰界定的规则或流程。没有任何可遵循的应急程序，于是船员们被迫只能凭借经验和一般的航海知识而别无其他地行动。

正是在这一点上，当审视船员在紧急状况下的行动时，我们目睹了指挥结构的彻底崩溃。在一家传统企业中，业务高管通常被公认为对任何公司行动拥有最终的决策权，只要该行动落在法律界限之内——而且往往即便不在界限之内亦是如此。在一般的企业中，一个糟糕的运营决策所导致的是收入损失，而不是生命损失。一位明智的高管会理解，不应去推翻那些被聘来做运营决策的专家所做的决定，或者也可能由一个董事会要求一位高管听取其下属的意见。尽管如此，业务方高管干预项目运营这种想法是违背最佳实践的，并被广泛公认为是一种糟糕的行事方式。

就泰坦尼克号而言，史密斯船长在海上指挥着这艘船，并亲身对这艘船以及船上的生灵负责。他的上司 J.B. 伊斯梅或许有能力在返港后让史密斯被解除指挥权，但在海上他既没有这种能力，根据英国航海法他也无权从舰桥下达命令，因为他不是一名持证的航海人员。（Kuntz）

在通往撞上冰山的那段时间里，J.B. 伊斯梅一直在向史密斯船长施压，要求他以一种不负责任的速度驾驶这艘船——超过二十四节，即七十五转。被视为泰坦尼克号“测试”的奥林匹克号，从未以这一速度横渡过大西洋，而泰坦尼克号此时的运行甚至超出了在奥林匹克号上所做测试的范围，连在正常条件下完成一次大西洋横渡所需的足够时间都没有。伊斯梅和史密斯把泰坦尼克号驱使到了超出其已知性能参数的程度，更重要的是，超出了船员已知的运营参数。这艘船在这一速度下会涉及何种运营风险，根本就是未知的。在驶入已知遍布冰山的水域的同时，还维持着一个本应被视为不安全的速度，这是极其愚蠢的。

究竟是出于惊慌、混乱、不安等等何种原因，我们不得而知，但当泰坦尼克号撞上冰山时，史密斯船长允许一个外行 J.B. 伊斯梅走上舰桥，并开始以代理船长的身份发布行政命令——而对此，史密斯船长本拥有将伊斯梅逐出的权利和义务。伊斯梅做出了若干关键的运营决策，包括紧急通信、乘客通知，以及——最为重要的——让泰坦尼克号向前驶离冰架，而这被认为正是这艘船主体破裂的实际原因；接着，即便在已经掌握了这艘船即将沉没的更多信息之后，他仍让这艘船继续以慢速向前行驶，把船壳一点点扯裂开来。（Kozak-Holland）

鉴于我们如今与泰坦尼克号之间相隔的时间距离，要评估当时所遵循的各项流程，并在我们已知如此之多出了岔子的地方的情况下去弄清这个项目中哪些事做对了，可能是很困难的。泰坦尼克号的沉没在我们心目中如此具有标志性，以至于要把它看作除了一场营销和组织上的灾难以外的任何事物，往好里说也是困难重重。

归根结底，泰坦尼克号项目规模浩大，但管理得当。范围得到了控制，并在必要时容纳了变更。项目采用了大量前期设计，并与建造阶段之间订立了完善的合同化衔接，而这种对规格说明的固化使得周密而准确的进度安排成为可能。建造这些船舶所采用的流程是标准的、广为人知的。借助历史建造数据，哈兰德与沃尔夫得以准确预测建造所需的时间，使白星航运公司能够远在这些船舶实际起航之前就开始进行营销和销售。泰坦尼克号作为奥林匹克号几乎一模一样的复制品，意外之处甚至更少。唯一真正的意外，源于白星航运公司优先事项的变更，导致泰坦尼克号项目被搁置了大约一个月。

用 J. 布鲁斯·伊斯梅的话说：“她（泰坦尼克号）不是按合同建造的。她只不过是按委托建造的。”这表明，哈兰德与沃尔夫被授予了非同寻常的权限，去运用他们自己的流程和监管来确保泰坦尼克号的交付。这两家公司与其说是处于供应商与客户的关系，不如说更像是以合作伙伴的身份在运作。（Kuntz）

泰坦尼克号的项目风险处理得很糟糕，严重依赖外部保险机构，并最终依赖英国政府，以牺牲主要为英国和美国乘客的利益为代价，来保护公司免受责任诉讼。风险被认为非常之低，正因为如此，先是在奥林匹克号上、随后在运营灾难极少之后甚至更变本加厉地在泰坦尼克号上，做出了许多漫不经心的决定。并没有进行周密的风险评估。专业的航海人员本可以轻而易举且迅速地界定出许多需要加以解决的风险领域。诸如缺乏一份完整的标准操作规程之类的问题本会被标记出来，并且本可以轻松地得到处理——因为为此所需的资源本无需取自当前的泰坦尼克号团队，也本不会影响交付日期或我们如今所理解的、白星航运公司最为关切的任何变量。

该项目上的通信，在服务交付开始之前似乎都处理得非常好。但到了这一阶段，设计缺陷、可疑的决策以及 SOP 的缺失，便对船上的通信网络产生了影响。这种通信可以被认为是运营性的，而非基于项目的，但这种区分只是语义上的争论。泰坦尼克号的问题是整体性的；倘若遵循了恰当的设计方法论，风险分析就不会被遗漏，而这本会迫使 SOP 的编制，进而本会凸显、甚或还可能修复那些通信问题。

从其核心来看，问题归结为一个质量问题。泰坦尼克号被作为最高质量的跨大西洋旅行选择来提出和推销。在几乎每一句谈及泰坦尼克号的话语中，质量都被直接或间接地大肆宣扬。客户界面被保持得尽可能整洁而简练。只要成果会被客户目睹，便不惜一切代价。但这“质量”所要赖以为基的、项目底层的核心或基础结构（按照 Kozak-Holland 的说法即非功能性需求——尽管我并不赞同他们在此语境下的用法）却被忽视了，而泰坦尼克号真正的质量以及白星航运公司运营的质量，终将彻底地显露无遗。

参考文献与所引来源：

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 的关于泰坦尼克号的系列文章重新出版成了一本书：

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.

1912 年美国参议院及英国官方听证与调查记录，载于 泰坦尼克号调查项目。

首发于 SheepGuardingLlama。