RMS 타이타닉과 올림픽 선박의 프로젝트 관리

R.M.S. 타이타닉과 그 자매선인 R.M.S. 올림픽과 H.M.H.S. 브리태닉을 건조하자는 아이디어는 1907년에 처음 구체화되기 시작했습니다. 이 세 척의 선박은 White Star Line의 올림픽 클래스 원양 정기선이었습니다. (명확성을 위해 본문 전체에서 해당 선박 등급을 지칭할 때 올림픽(들)이라는 표현을 사용하겠습니다.) 인류 역사상 R.M.S. 타이타닉만큼 널리 알려지고 악명 높은 선박은 거의 없습니다.

R.M.S. 타이타닉을 프로젝트 관리 관점에서 살펴볼 때, 이 프로젝트가 어떤 유형의 결과물을 목표로 했는지를 먼저 파악하는 것이 중요합니다. 최종 고객이 최종 산출물을 소유하는 많은 프로젝트와 달리, 타이타닉은 최종 고객에게 서비스, 특히 페리 서비스를 제공하도록 설계되었습니다. 이는 '타이타닉 프로젝트'를 논의할 때 흥미로운 과제를 만들어냅니다. 대부분의 프로젝트 관리 관점에서는 프로젝트가 명확한 시작과 종료 시점, 그리고 명확하게 정의된 이해관계자를 가진다고 보기 때문입니다.

R.M.S. 타이타닉과 같은 프로젝트의 경우 두 가지 관점에서 접근할 수 있습니다. 한편으로는 올림픽 클래스의 세 선박이 구상되고, 설계되고, 건조되어 White Star Line에 인도된 프로젝트가 있습니다. 다른 한편으로는 R.M.S. 타이타닉이 선배 격인 R.M.S. 올림픽을 넘어 맞춤화되고, 초기 생산이 완료되어 사우샘프턴과 뉴욕 사이를 운항할 승객들에게 서비스로 인도된 경우가 있습니다. 범위를 유지하기 위해 R.M.S. 타이타닉 침몰 이후 두 자매선에 적용된 테스트, 버그 수정, 수리, 범위 변경 및 개선 등의 더 큰 프로젝트는 논의하지 않겠습니다. R.M.S. 올림픽과 H.M.H.S. 브리태닉은 모두 운항 기간 동안 많은 변화를 겪었는데, 브리태닉은 원양 정기선에서 제1차 세계대전 중 영국 해군의 주요 병원선으로 재편되었고, 올림픽은 승무원들이 더 안전한 조치가 취해지기 전까지 승선을 거부하면서 이중 선체와 추가 구명보트가 장착되었습니다. ("Olympic")

제 목표는 타이타닉을 구상에서 서비스 제공, 그리고 궁극적으로 서비스 실패에 이르기까지 하나의 서비스로 검토하는 것입니다. 이 관점에서 타이타닉은 현대의 서비스형 소프트웨어(SaaS) 프로젝트를 다루는 방식과 유사하게 다룰 수 있습니다. 타이타닉이나 Salesforce.com, SugarCRM과 같은 SaaS 제품의 특성상 제품의 의도된 수명과 운영을 유지하기 위해 필요한 지속적인 업그레이드 및 유지보수를 고려해야 합니다. 타이타닉은 항해 중 파일럿, 선원, 요리사, 짐꾼, 스튜어드 등 많은 승무원이 필요했고, 재정비, 수리가 필요했으며, 살아남았다면 R.M.S. 올림픽처럼 새로운 이중 선체가 필요했을 것입니다. SaaS 프로젝트 역시 데이터센터와 네트워크를 유지할 인력, 지속적인 업그레이드와 버그 수정, 새로운 기능 등이 필요합니다. 타이타닉과 SaaS 프로젝트 모두 엄청난 비용을 초래할 수 있는 서비스 중단의 가능성이 존재합니다. 안정적이고 신뢰할 수 있는 운영을 유지하는 것은 이러한 두 가지 비즈니스 계획의 성공에 있어 핵심 요소입니다.

타이타닉을 실현시키는 프로젝트 분석을 이해관계자 검토부터 시작하겠습니다. 타이타닉의 승객과 승무원, 회사로서의 White Star Line, 프로젝트 엔지니어들, 건조사인 Harland-Wolff, Harland-Wolff의 조선 기술자이자 설계자인 Alexander Carlisle과 Thomas Andrews, 서비스 제공을 책임진 에드워드 존 스미스 선장, 그리고 프로젝트 스폰서 역할을 한 White Star 이사 조지프 브루스 이즈메이와 그의 경영진을 이해관계자로 쉽게 식별할 수 있습니다. 이 규모의 프로젝트에는 프로젝트에 일정한 이해관계를 가진 많은 중요한 인물이 있습니다. 타이타닉 프로젝트의 가장 주요한 이해관계자로서 이 핵심 인물들에만 집중하겠습니다.

타이타닉 프로젝트는 IT 프로젝트 관리 용어로 워터폴 모델과 가장 유사합니다. 프로세스는 White Star Line을 대표하는 조지프 브루스 이즈메이와 조선 파트너인 Harland-Wolff를 대표하는 제임스 피리 경이 공동으로 제시한 고수준 개념에서 시작되었습니다. 프로젝트는 두 회사 간에 공동으로 구상되었습니다. 타이타닉은 두 회사 모두에게 큰 위상과 이익 잠재력을 제공하고 양측의 대규모 투자를 필요로 했습니다. 원래의 프로젝트 헌장은 현재 우리에게 전해지지 않지만, 이즈메이와 피리 경의 회동을 비공식적인 프로젝트 헌장이자 프로젝트 개시로 볼 수 있습니다. (Sadur)

올림픽 클래스 선박의 기술적 설계는 이즈메이와 피리 경이 고수준 계획을 수립한 후 Harland-Wolff의 수석 조선 기술자 Alexander Carlisle이 담당했습니다. Carlisle은 1910년 은퇴하여 Harland-Wolff 전무이사인 Thomas Andrews에게 수석 설계 역할을 넘길 때까지 프로젝트 창설부터 수석 설계자였습니다(Brander 1998). Andrews는 타이타닉 설계의 최종 단계를 책임지게 됩니다. 1910년 가을에 진수된 올림픽은 대부분 Carlisle의 지휘 하에 완전히 설계되었을 것입니다. 타이타닉이 올림픽의 인프라(선체 설계, 나침반 위치, 구명보트, 선교 등)를 거의 공유했으므로, Andrews의 타이타닉 설계에 대한 기여는 대부분 미적인 것이었거나 소프트웨어 개발 용어로 "인터페이스" 관련이었다고 안전하게 가정할 수 있습니다. (Thinkquest)

올림픽과 같은 거대한 선박 건조에서 설계 프로세스는 초기에 대규모 설계를 진행하고, 설계자들이 선박을 물리적으로 검사할 수 있는 이후에는 피드백 루프가 매우 제한적입니다. 소프트웨어 용어로 이를 "빅 디자인 업 프론트" 또는 BDUF라고 합니다. 요구사항 변경이 빈번한 소프트웨어에서는 일반적으로 매우 나쁜 관행으로 여겨지지만, 기계 및 구조 공학에서는 단순히 유일한 합리적 해결책입니다.

올림픽 건조가 진행되면서 선박의 핵심 인프라 설계에 관한 여러 결정이 내려졌습니다. 이는 특히 위험한데, 이 유형의 프로젝트에 적용된 방법론이 계획이 승인된 후 이러한 성격의 변경을 허용하도록 설계되지 않았기 때문입니다. 선박은 상호 의존적인 안전 시스템과 높은 수준의 복잡성을 가진 전체론적 시스템으로 설계됩니다. 대부분의 소프트웨어와 달리 안전성을 보장하기에 충분한 정확도로 선박을 신속하게 프로토타입화하는 것은 매우 어렵습니다. 안전 시스템에 핵심적인 변경을 가하려면 올바르게 수행하기 위해 사양 전체를 재작업해야 했을 것입니다. 그러나 비용 절감, 일정 문제, 고급 인테리어를 이유로 변경이 이루어졌기 때문에 변경 사항에 대한 전체론적 사고가 거의 이루어지지 않았습니다. (Kozak-Holland)

올림픽의 원래 설계 의도는 최신 안전 기술을 통합하는 것이었습니다. 초기 설계가 완료된 후 White Star Line, 특히 J.B. 이즈메이로부터 건축가와 엔지니어들에게 안전 기능 대신 1등석 사치품을 위해 안전 기능을 제거하라는 사업적 압력이 가해졌습니다. 가장 유명한 두 가지 변경은 물론 객실 전망이 불필요하게 가려지지 않도록 구명보트를 제거한 것과, 확장된 그랜드 볼룸 시설을 위해 일부 격벽이 더 이상 밀봉되지 않고 수면 위 불과 3미터(10피트)까지만 올라오도록 수정한 것입니다. IT 프로젝트와 마찬가지로 핵심 시스템에 대한 엔지니어링 결정은 일반적으로 비즈니스 경영진의 이해 범위를 벗어납니다. 비즈니스 측의 결정이 기술적 결정에 영향을 미치도록 허용하는 것은 위험합니다. 일반적인 예방 조치와 사고 프로세스가 우회되고 전문 지식이 간과되기 때문입니다. 이 경우 이는 인간의 생명 보호 및 보존과 관련된 문제였습니다. 소프트웨어에서는 그토록 중요한 작업이 드물지만, 핵심 시스템에 대한 이해 없이 비즈니스 관리자가 설계에 관여하도록 허용하는 것은 결과가 사업 손실이나 운영 비용 증가와 같이 양호한 수준에 불과하더라도 매우 해로울 수 있습니다.

올림픽 설계의 후기 변경으로 인해 발생한 가장 심각한 문제 중 하나는, 각각의 변경이 단독으로는 작은 것들이었기 때문에 원래 선박 설계를 고려할 때와 같은 방식으로 함께 전체적으로 검토된 적이 없었다는 것입니다. 구명보트가 제거될 때, 관련 엔지니어들은 선박이 떠있는 구명 뗏목으로 설계되었고 구명보트의 목적은 단순히 타이타닉이나 올림픽이 동력을 잃는 "최악의 경우"에 움직이지 않는 원양 정기선에서 다른 선박으로 승객을 수송하는 것이라고 생각했습니다. 충돌이 발생해도 배가 물에 낮게 떠 있게 할 뿐 가라앉지는 않을 것으로 예상했습니다. 구명보트는 White Star Line 경영위원회의 요청에 따라 법적 최소 수량만 남을 때까지 제거되었습니다. 엔지니어들에게 이는 권장되지는 않지만 용인할 수 있는 안전 절충안이었을 것입니다. 선박 설계상 추가 구명보트를 갖추는 것이 법적 요건이 아니었고, 추가 보트의 유용성이 최소한이라고 여겨졌으므로 보존해야 할 절실한 이유도 없었습니다. 결국 이것은 엔지니어들의 결정이 아니라 조선사의 최종 고객이자 생계를 책임지는 White Star의 결정이었을 것입니다.

구명보트 제거 결정만 놓고 보면 아마도 사소한 것이었을 것입니다. 그러나 추가로 올림픽의 핵심 구조 설계를 모든 높은 격벽을 갖추는 것에서 네 개의 격벽을 수선 위 불과 3미터(10피트)로 현저히 낮추는 것으로 변경하기로 한 결정은 배가 떠있는 구명 뗏목이라는 개념을 손상시켰습니다. 격벽은 마케팅 자료에서 우리를 믿게 했던 것처럼 진정으로 방수되지는 않았지만, 매우 높았고 물에 상당히 "내성"이 있었으며, 매우 심각한 선체 파손 상황에서도 격벽 사이를 물이 이동하지 못하게 할 수 있었을 것입니다. 선박의 초기 설계에는 안전 기능이 가득했으므로, 이는 구명보트처럼 중복 기능으로 여겨졌을 것이고 제거는 단지 선박을 더 일반적인 안전 기준으로 낮추는 것에 불과했을 것입니다. 개별적으로 취하면 변경들은 대부분 무해했지만, 합쳐지면 선박의 완전한 재설계가 되어 완전히 재앙적이었습니다. 자격을 갖춘 엔지니어들이 모든 변경 사항이 적용된 상태에서 선박의 안전 기능에 대한 완전한 재평가를 다시 진행한 적이 없었습니다.

어떤 면에서 J.B. 이즈메이는 마이크로매니저로 볼 수 있습니다. 그는 기술적 전문성을 위해 고용한 사람들의 결정을 신뢰하지 않고 직접적으로 또는 간접적인 압력을 통해 그들의 결정을 번복했습니다. 마이크로매니지먼트는 여러 부정적인 결과를 낳습니다. 가장 명백한 것은 훈련되지 않고 자격 없는 관리자가 다른 사람들이 자격 있는 전문가로부터 나온 것으로 믿는 결정에 영향을 미친다는 것입니다. 그 외에도 프로젝트 팀이 창출하는 가치를 약화시키고 직원 충성도와 사기를 저하시킵니다.

타이타닉처럼 동급 선박으로 건조되는 조선업에서는 세 가지 주요 프로젝트 단계를 고려해야 합니다. 프로토타입인 올림픽의 설계 및 건조, 타이타닉의 설계 개선 및 건조, 그리고 마지막으로 서비스 제공 및 운영입니다. 특히 타이타닉의 경우, 주요 설계와 구조적 변경은 올림픽 완성 전에 이루어졌습니다. Thomas Andrews는 올림픽에 승선했지만, 이는 그 시점에 구조적 작업을 변경하기에는 이미 너무 늦었기 때문에 주로 타이타닉을 위한 미적 수정을 위해서였습니다. 같은 이유로 Andrews는 타이타닉에도 승선하여 곧 진수될 브리태닉(Andrews는 기간틱이라고 알고 있었습니다)을 위해 비슷한 작업을 하기 위해서였습니다.

프로젝트 범위 측면에서 프로젝트가 처음에 수립된 계획을 밀접하게 따랐음을 알 수 있습니다. 건조는 변경이 거의 없이 사전 승인된 계획에 따라 진행되었습니다. 범위에서 가장 극적인 변화는 올림픽 수리를 위해 프로젝트를 중단해야 했던 타이타닉 건조 중에 발생했습니다. Harland-Wolff와 White Star Line 양측 모두 타이타닉이 지연되겠지만 올림픽의 운항 가능성이 우선시된다는 것을 이해했습니다. 모든 유형의 자본 건설 프로젝트에서 중요한 요소는 건설 단계 간의 계약 수준 합의의 필요성인데, 이는 건설이 시작된 후에는 범위 변경을 수용하는 것이 거의 불가능하기 때문입니다. ("Olympic")

생산 프로토타입을 기반으로 하되 동일하지 않은 일련의 생산 구현이 뒤따르는 이 유형의 모델을 밀접하게 따르는 소프트웨어 프로젝트를 찾기는 어렵습니다. 제가 가장 가깝게 생각할 수 있는 예는 전사적 자원 관리(ERP) 패키지인 SAP입니다. 이 패키지와 유사한 제품들을 통해 고객은 프로토타입 성능과 기능을 기반으로 패키지를 구매한 다음, 자체적으로 또는 컨설팅 회사나 원래 벤더를 통해 패키지를 자신의 필요에 맞게 대폭 수정합니다. 일반적으로 이러한 접근 방식의 장점은 소프트웨어 패키지의 핵심인 인프라가 매우 안정적이고 잘 테스트되어 있으며 광범위한 상황에서 사용되어 프로젝트 측과 클라이언트 측 모두의 테스트를 거쳤다는 것입니다. 물론 고객이 주도한 수정은 핵심 인프라에 수행되었기를 바라는 심층 테스트의 혜택을 받지 못하고, 더 넓은 클라이언트 커뮤니티의 "다수의 눈"이라는 혜택도 없다는 점에 주의해야 합니다.

올림픽 클래스 선박의 경우 15피트 모형에 대한 심각한 테스트가 수행되었고, 올림픽 완성 시 테스트가 이루어졌습니다. 올림픽과 같은 복잡성을 가진 선박의 경우 개별 시스템의 단위 테스트에 더해 실제 환경 테스트가 필수적입니다. 올림픽은 이 유형의 선박에 표준적인 일반 테스트 방법을 거쳤습니다. 그러나 타이타닉이 건조되었을 때, 건조사와 크루즈 회사는 타이타닉이 기본적으로 올림픽의 복사본이므로 올림픽에서 수행된 테스트와 지속적인 성공적 운항이 타이타닉에도 충분한 테스트라고 결정했으며, 타이타닉은 추가 테스트를 거의 받지 못했습니다. 그러나 이것은 모든 선박이, 심지어 복사본이라도, 다르게 작동하고 각 선박은 고유하며 독자적으로 테스트되어야 한다는 것을 아는 선원들에게는 모범 사례가 아닙니다. (Kozak-Holland)

타이타닉은 테스트나 성능 시험에 거의 시간을 부여받지 못했습니다. 이는 부분적으로 올림픽이 심각한 사고를 당하여 벨파스트의 조선소로 가져가 수리를 받아야 했기 때문입니다. 올림픽이 수리되는 동안, 그 크기의 선박은 한 번에 하나만 작업할 수 있었으므로 타이타닉은 기다려야 했습니다. 이로 인해 타이타닉에는 사업적 시간 제약이 생겼는데, 정기 대서양 횡단 항로 임무가 예정되어 있었고 즉시 필요했습니다. 이 때문에 원래 이루어졌을 일부 추가 테스트가 생략되었고, 타이타닉은 벨파스트에서 사우샘프턴으로의 항해를 주요 테스트로 삼아 출항했으며, 이 항해에도 최소한 한 명의 유료 승객이 있어서 적절한 테스트라기보다는 저용량 실제 항해에 가까웠습니다. (Kozak-Holland)

White Star Line과 J.B. 이즈메이는 가능한 한 빨리 선박을 정규 운항에 투입하기 위해 예외적인 프로젝트 리스크를 기꺼이 감수할 준비가 되어 있었던 것으로 보입니다. 표준 해상 절차를 통해 그들은 해상 보험으로 자본 리스크의 상당 부분을 완화했습니다. 이는 많은 잠재적 미지수에 대해 그들을 보호할 것이었습니다.

19세기 후반에 들어 선박 회사들과 정부 모두에서 위험을 우선순위가 낮은 문제로 보는 것이 점점 더 일반화되었습니다. 1858년에 건조된 S.S. 그레이트 이스턴은 이후 54년간 점점 더 안전하지 않아지는 원양 항해 선박들의 설계보다 훨씬 더 안전한 것으로, 실제 사례에서도 입증되었다고 여겨집니다. 타이타닉의 침몰을 계기로 회사들과 정부들이 상황을 재평가할 때까지 상황은 계속 악화될 것이었습니다. 해운 회사들이 수십 년간 상대적으로 사고 없는 운항을 보내면서 용인할 수 있는 안전 실적이 안전에 대한 느슨한 태도를 정당화한다고 보았다는 주장이 있습니다. 재정 시장 압력이 느슨한 안전 기준을 가진 회사들을 선호하여 업계 전체가 비싼 위험 관리에서 멀어지도록 장려했습니다. (Brander 1995)

테스트 및 훈련 부족으로 인한 위험을 추가로 완화한다는 명목 하에, 여러 승무원, 특히 스미스 선장이 타이타닉의 처녀 대서양 횡단 항해를 위해 올림피아에서 이적해 왔습니다. 이는 이즈메이가 선박을 직접 테스트하지 않아 발생하는 "미지수"를 줄이기 위해 적어도 프로토타입 선박에서 최대한의 경험을 활용하려는 경험 추구로 볼 수 있습니다. 그러나 이것이 결정의 근본적인 이유가 아닐 수도 있으며, 스미스 선장이 선택된 것은 그가 최근 H.M.S. 호크와 관련된 심각한 사고를 일으켜 올림픽이 긴급 수리를 받아야 했고 타이타닉의 출항을 지연시켰던 것과 관련이 있을 수 있습니다. 스미스 선장은 아마도 불안했고, 자신의 경력을 염려했으며, 회사의 압력이 자신의 판단에 반하는 방향으로 유도할 경우 선박의 최종 책임자로 행동할 마음이나 입장이 아니었을 것입니다. 이것이 바로 White Star Line이 찾고 있던 운영상의 허점이었을 수도 있습니다. 이 상황은 스미스 선장이 사우샘프턴에 정박 중인 S.S. 시티 오브 뉴욕에 너무 가깝거나 빠르게 접근하여 그 선박의 계선줄이 끊어지고 타이타닉과 거의 충돌할 뻔한 사건으로 더욱 악화되었을 것입니다. (Kozak-Holland)

관습적인 해양법에 따르면, 선장은 선박의 절대 지휘관이며 상위 계급의 군 또는 민간 관계자가 탑승하더라도 항해 중에 완전한 관할권을 가집니다. 선장은 승객과 승무원의 생명과 안전에, 그다음으로 화물과 선박에 대해 도덕적, 법적 책임을 집니다. (Kuntz)

타이타닉이 건조되고, 장비를 갖추고 항해 준비가 완료되면, 단계 변화가 일어나고 우리는 전체 타이타닉 프로젝트의 서비스 제공 단계로 이동합니다. 이 단계에서 우리는 전통적인 프로젝트 관리 단계를 넘어섰습니다. 대부분의 시나리오에서 클라이언트는 이제 완성된 제품을 인수했을 것입니다. 그러나 타이타닉의 경우 이것이 서비스 제공 단계가 됩니다.

서비스 제공 하에 White Star Line은 선박에서 발생할 새로운 문제들에 대한 책임을 지게 되었습니다. 이 시점에서 설계-건조-테스트의 전통적인 시스템은 더 이상 사용되지 않고, 대신 서비스 제공은 표준 운영 절차(SOP)에 의해 감독될 것이었습니다. 지속적인 선박 수정, 수리, 조정 등은 계속 이루어지겠지만, 이는 서비스 중단을 필요로 하는 수준이 아니며 최종 고객인 승객들에게 알리지 않고 소규모로 진행될 것이었습니다. 승객들이 이 단계에서 가장 중요한 이해관계자로 등장하는데, 이 시나리오에서 그들은 단순한 재정적 이해관계자가 아니라 문자 그대로 선박의 신뢰성과 승무원의 운항에 자신의 목숨을 걸고 있기 때문입니다.

애자일 프로젝트 관리 커뮤니티에는 이해관계자 내의 역할을 표현하기 위해 자주 사용되는 우화가 있습니다. 이 역할은 돼지와 닭으로 알려져 있습니다. 우화는 닭과 돼지가 함께 레스토랑을 열고 싶어한다고 이야기합니다. 돼지가 닭에게 무엇을 제공할 것이냐고 묻습니다. 닭이 "물론, 베이컨과 계란이죠."라고 대답합니다. 이에 돼지는 "저는 관심이 없을 것 같아요. 당신은 관여되겠지만 저는 완전히 헌신해야 하니까요."라고 대답합니다. (Schwaber 7)

돼지와 닭의 비유는 보통 실제 돈이나 경력이 걸려 있는 이해관계자와 헌신적이지만 비결정적인 이해관계를 가진 이해관계자의 차이를 표현하기 위해 사용됩니다. 닭들은 프로젝트가 실패하는 것을 원하지 않지만, 실패가 반드시 그들에게 치명적이지는 않습니다. 타이타닉의 경우 재정적 이해관계자인 Harland-Wolff와 White Star Line이 사실상 닭이었습니다. 그들은 잃을 것이 많았지만 투자는 보험으로 보장되었고, 나중에 살펴보겠지만, 정부는 임박한 오스트리아 및 독일과의 전쟁으로 인해 이 시기에 이런 성격의 회사들을 보호하려 했습니다. White Star도 Harland-Wolff도 "완전히 헌신"하지는 않았습니다. 그들은 명확한 이해관계를 가졌고 타이타닉의 성공이 그들에게 매우 중요했지만, 타이타닉의 승객과 승무원이야말로 자신의 목숨을 담보로 건 진정한 돼지였습니다. 돼지와 닭의 비유가 이보다 더 적절할 수 없을 것입니다.

지속적인 서비스의 더 높은 품질을 보장하기 위해 Harland-Wolff의 보증 그룹이 처녀 항해에 동행했습니다. 이 팀에는 수석 설계자 Thomas Andrews를 포함한 Harland-Wolff 설계 및 건설 스태프의 많은 중요한 구성원이 포함되었습니다. 이 보증 그룹은 Harland-Wolff의 모든 주요 프로젝트에서 관례적인 것이었습니다. 이 스태프는 항해 시간을 활용하여 테스트와는 다른 조건에서의 건조 상태를 평가하고, 고객 만족도를 측정하며, 개선 기회를 찾았습니다. Thomas Andrews는 이미 이와 같은 목적으로 올림픽에 승선하여 타이타닉을 개선하기 위한 많은 작은 변경을 가했습니다. 예를 들어 그는 이 항해의 일부를 승객실용 더 저렴한 의류 고리를 설계하는 데 보냈습니다. ("Guarantee Group")

보증 그룹은 Harland-Wolff 내의 많은 다른 기술 분야의 전문가들로 구성되었습니다. 피터, 전기 기사, 목공, 제도사, 설계팀 등의 대표자를 볼 수 있습니다. 다양한 전문 분야와 선배 및 견습생이 포함된 다양한 경험 수준을 가진 이 그룹은 선박을 건조한 프로젝트 팀의 탁월한 단면을 보여주었을 것입니다. 장인 정신, 설계 및 기타 최종 구성 요소를 평가하는 데 기울인 세심한 주의로 그들의 존재는 두 가지 주요 방식으로 볼 수 있습니다.

첫 번째 방식으로 이를 타이타닉 프로젝트에 대한 "사후 검토"로 볼 수 있습니다. 이 팀의 역할은 프로젝트의 기술적 성공을 평가하고 개선 영역을 찾으며, 향후 프로젝트가 여기서 얻은 경험의 혜택을 받을 수 있도록 "교훈"을 생성하는 것이었습니다. 대서양 횡단 여행 비용과 정규 업무에서 벗어난 시간을 고려하면, 이것은 Harland-Wolff의 프로젝트 지식에 대한 진지한 투자이자 매우 칭찬할 만한 것이었습니다.

다른 관점에서 이 보증 그룹은 건설 반복에 대한 피드백을 제공하는 것으로 볼 수 있습니다. 올림픽 건조가 첫 번째 반복, 타이타닉이 두 번째, 브리태닉이 세 번째입니다. 이 접근 방식에서 우리는 이러한 극단적인 자본 건설 프로젝트에서도 고객 입력을 가능한 한 허용하기 위해 애자일 피드백 루프가 활용되는 것을 봅니다. 반복은 매우 길지만 이는 필연적입니다. 이런 방식으로 타이타닉을 개별 인도물인 독립된 프로젝트로도, 올림픽 선박 가족을 통한 승객 서비스 제공을 위한 지속적인 프로젝트의 일부로도 볼 수 있습니다.

보증 그룹이 선박에 승선한 것은 기술 팀이 자신들의 제품에 대한 실제 응용을 직접 경험할 수 있는 기회를 제공했을 것입니다. 1912년에 기술 전문가가 이 수준의 럭셔리 선박을 여행할 수 있는 위치에 있는 경우는 드물었을 것입니다. 자신들의 솜씨가 작동하는 것을 목격할 기회를 제공하는 Harland-Wolff의 후원 없이는, 그들은 최종 고객에게 서비스를 제공하는 자신들의 역할을 이해하지 못했을 수도 있습니다.

보증 그룹에 견습생이 포함된 것은 1:1 또는 소그룹의 비공식 교육이 수행될 수 있음을 의미했습니다. 견습생과 선임 기술자들은 함께 작업할 많은 날을 보냈을 것이며, 견습생들은 팀 빌딩과 지식 이전에 적합한 환경에서 선임자들로부터 배울 수 있는 좋은 기회를 가졌을 것입니다. 여러 면에서 이 시간은 오늘날 많은 회사와 프로젝트 그룹에서 인기 있는 오프캠퍼스 팀 빌딩 세션이나 리트릿과 유사한 것으로 볼 수 있습니다.

타이타닉 분석에서 가장 큰 놀라움은 선박에서 사용되는 표준 운영 절차가 거의 전무하다는 것입니다. 일부 프로세스와 절차가 문서화되었지만 많은 것들이 그렇지 않았습니다. 표준화되지 않은 프로세스의 예로는 무선 사무소에서 선교로 메시지를 전달하는 것, 선박이 침몰 중임을 승객에게 알리는 것, 망루에서 빙산을 봤다고 선교에 경보를 보내는 것과 같은 핵심 통신 프로세스가 있었습니다. (Kozak-Holland)

표준 운영 절차는 모든 서비스 제공 상황에서 절대적으로 중요합니다. 일부 회사에서는 이것이 회사의 핵심 지적 재산으로 여겨질 정도로 가치 있을 수 있습니다. SOP 없이 회사는 스태프의 고유한 "팀워크"보다 더 응집력이 없으며, 신입 직원의 경우 그것이 미미할 수 있습니다. 스태프는 모범 사례, 관습, 비공식 직원 지시 또는 바라건대 훈련에만 의존하여 자신의 직무와 프로세스를 배워야 합니다. 그러나 이것들은 기록되지 않으면 표준화되지 않을 것이고, 훈련은 불가피하게 강사마다 다를 것이며, 어떤 직원도 모든 가능한 시나리오에 대한 모든 지시를 기억할 수 없습니다.

정상적인 조건에서 표준 운영 절차의 부재는 상대적으로 경미한 중요성을 가질 수 있습니다. 훈련을 받은 경우 특히, 스태프는 SOP 없이도 대부분의 직무 기능을 적절히 수행할 수 있습니다. 그렇지 않다면 항상 SOP를 지참해야 할 것입니다. SOP가 매우 중요해지는 시점은 "정상 운영 절차"가 더 이상 가능하지 않을 때, 즉 더 현대적인 용어로 운영이 더 이상 BAU(비즈니스 일상 상태) 조건이 아닐 때입니다. 타이타닉의 경우 빙산 사고가 발생하기 몇 시간 전에 이미 BAU 조건이 무너졌습니다.

타이타닉의 경우 표준 운영 절차를 논하지 않고 커뮤니케이션을 논하기가 어렵습니다. 따라서 BAU 조건 하에서의 커뮤니케이션으로 시작하여 SOP의 부재가 어떻게 상황을 빠르게 악화시켰는지 살펴보겠습니다.

타이타닉은 처음부터 통신 설계 결함으로 시달렸습니다. 타이타닉의 모든 통신을 담당하는 무선실은 White Star Line이 운영하지 않고 Marconi 직원이 배치되어 있었는데, 그들은 우선적으로 승객을 위해 통신하고 시간이 허용되는 경우에만 선박을 위해 통신하도록 보수를 받았습니다. 무선 통신사들은 과중한 업무에 시달렸고 충분한 대우를 받지 못했으며, Marconi(그들의 고용주)가 더 높은 우선순위로 여기는 다른 의무가 있었기 때문에 종종 선교로 메시지를 전달하지 않았습니다. 적어도 8개의 빙산 경고가 타이타닉 무선실로 전송되었지만 일부만이 선교로 전달되었습니다. (Kozak-Holland)

이 경우 서비스 수준 협약을 통한 제3자 계약자 관리의 중요성을 강조하는 것이 중요합니다. White Star Line은 Marconi 회사가 무선실에 인력을 배치하도록 허용하면서, 선박의 안전 및 긴급 통신이 승무원의 개인 메시지보다 절대적으로 우선시되어야 한다는 명확한 SLA를 가져야 했습니다. 또한 Marconi가 SLA를 따르지 않음으로써 추가 수익을 얻거나 재정적 이익을 얻지 못하도록 해야 했습니다. 외부 계약자인 Marconi는 상호 이익을 위해 설계된 계약, 즉 명시된 대로 실행될 때 모든 당사자의 상호 이익이 올바르게 행동하는 계약을 가져야 했습니다. 벤더가 클라이언트에게 해가 되는 방향으로 일하도록 재정적 인센티브를 제공하는 벤더 간 계약은 매우 현명하지 못합니다.

Marconi 통신사들과 관련된 가장 중요한 단일 사건은 타이타닉에 매우 가까이 있던 SS 캘리포니아가 보낸 마지막 빙산 경고였습니다. 캘리포니아는 나중에 타이타닉의 비상 로켓을 목격하는 선박이 될 만큼 가까이 있었습니다. 캘리포니아는 타이타닉에 무선으로 유빙에 갇혀 위험한 상황으로 인해 어떤 속도로도 전진할 수 없다는 경고를 보냈습니다. Marconi 통신사는 "닥쳐요, 닥쳐요. 저 바빠요. 케이프 레이스와 통신 중인데 방해하고 있잖아요."라고 답했습니다. 그토록 위험이 가까이 도사리고 있음에도 무선실의 우선순위가 어디에 있는지 이보다 더 명확할 수 없었습니다. 무선실은 캘리포니아와 통신을 유지하지 않았을 뿐만 아니라 이 마지막 외부 경고를 선교에 알리는 것도 거부했습니다. 좌절한 캘리포니아의 무선 통신사는 타이타닉에 경고하려는 시도를 포기하고 무선을 끄고 잠자리에 들었습니다. Marconi 통신사들은 경고를 무시했을 뿐만 아니라, 타이타닉이 침몰하기 시작했을 때 구조를 위해 충분히 가까이 있는 유일한 선박이 응답하지 않도록 외부 채널을 소외시켰습니다. (Kuntz)

선교에서 승무원 전체와 승객으로의 통신에는 공식적인 프로세스가 없었고, 수동으로 이루어졌으며, 최선의 경우에도 시도가 이루어진다면 최선의 노력으로 이루어졌습니다. 선교는 충돌이 임박했다는 것을 누구에게도 알리지 않았으며, 매우 심각한 충격이 될 수 있었던 것에 대해 아무도 대비하지 않았습니다. 선박이 침몰하기 시작한 후 선교가 나머지 선박에게 가라앉고 있다는 것을 알리기 시작하기까지 한 시간 이상이 걸렸습니다. 승객과 승무원의 생명에 영향을 미치는 핵심 정보가 그들로부터 감춰지고 소수의 선교 인원만이 알고 있었는데, 그들은 아마도 사건을 비밀로 유지하거나 명백한 인명 위험에 대한 언론 노출을 최소화하기를 바랐을 것입니다. 선교에서 선박 전체로 통신하는 시스템이나 프로세스가 없었기 때문에 이것은 간단한 문제였으며, 승객들에게 어떤 뉴스든 알리기 위해서는 의도적인 노력이 필요했습니다. (Kozak-Holland)

승무원들 사이의 통신도 크게 나을 바 없었습니다. 예를 들어 당직 사관은 선교 밖에 위치해 있었지만 그의 중요한 통신 연결은 선교 건물 안에 있었습니다. 따라서 당직은 다른 선교 인원과 신속하게 통신하거나 망루 및 기타 관련 기능 구역과 조율할 수 없었습니다. 망루와 당직은 양방향 통신이 불가능하고 매우 느린 단방향 벨 시스템으로 연결되어 있었으며, 당직은 긴급 명령이 내려졌을 때 키를 잡은 조타수로부터 피드백을 받는 수단이 없었습니다. 명령은 밀폐된 선교를 향해 개방 공간에서 소리를 질러 전달되었습니다. 당직은 선교 안의 조타수가 그 명령을 듣고 이해하고 실행 중인지 기도할 수밖에 없었습니다. 표준 나침반으로부터의 통신도 마찬가지로 나빴습니다. 나침반이 선교 위나 근처에 위치하는 대신, 선미 멀리에 배치되어 선교가 정기적으로 나침반과 조율해야 했고 이는 많은 혼란과 지연을 초래했습니다. 선교를 효과적이거나 안전하게 만들기 위한 생각이 거의 없었습니다. 이러한 통신을 위한 설계 부족은 빠르고 정확한 통신이 필요했을 때 타이타닉에 전혀 도움이 되지 않았습니다. (Brown)

보스턴의 White Star 사무소로의 외부 통신이 마침내 전송되었을 때 전달된 정보는 심각한 피해가 없고 사건이 매우 경미하다는 것이었습니다. 오늘날 흔한 점대점 정보와 달리 이 정보는 방송되어 다른 선박과 중계 기지에 의해 쉽게 가로챌 수 있었습니다. 선박 대 육지 통신은 종종 내부 전보를 가장하여 효과적으로 언론에 정보를 공개하는 데 사용되었습니다. 그래서 정직하고 중요한 정보를 전달하는 대신 무선이 상황에 "스핀"을 걸도록 설계된 보도 자료에 불과한 것으로 마케팅 도구로 사용되었습니다. 전송된 것은 조난 신호가 아니라 사실상 언론 보도 자료였습니다. (Kozak-Holland)

통신은 모든 프로젝트의 모든 단계에서 핵심입니다. 타이타닉의 경우 파국적인 상황이 통신 때문에 발생한 문제를 부각시키지만, 이것은 단순히 최악의 경우 시나리오입니다. 프로젝트는 결정을 내릴 때 가능한 한 최신의 정확한 데이터를 가져야 합니다. 그것 없이는 사용 가능한 그림의 일부만을 사용하여 결정이 내려지고, 올바른 정보가 적을수록 좋은 결정이 내려질 가능성이 낮아집니다.

그러나 타이타닉에 영향을 미친 가장 큰 프로젝트 관리 문제는 표준 운영 절차의 거의 완전한 부재였습니다. SOP는 건설 프로세스의 후반 단계에서 필수적인 프로젝트 인도물로 생산되었어야 했습니다. SOP 없이 선박을 운항하는 것이 항해에 적합하다고 판단된 것은 정말로 상상할 수 없는 일입니다. 가장 애자일한 개발 방법론조차도 최종 사용자 문서의 필요성을 간과하지 않습니다.

프로젝트의 설계 및 건설 부분이 타이타닉 승무원에게 SOP를 제공하지 못했거나, 적어도 합리적인 SOP(White Star Line 매뉴얼 자체에 일부 일반적인 표준 절차가 있었습니다)를 제공하지 못했기 때문에, 통신, 경보 추적, 경고 제공 등을 처리하기 위한 명확하게 정의된 규칙이나 프로세스가 없었습니다. 따라야 할 비상 절차가 없었으므로 승무원은 경험과 일반 항해 지식에만 의존해야 했습니다.

이 시점에서, 비상 상황 하에서 승무원의 행동을 검토할 때, 우리는 지휘 구조의 완전한 붕괴를 목격합니다. 전통적인 비즈니스에서 비즈니스 경영진은 일반적으로 법적 경계 내에서, 그리고 종종 그렇지 않더라도 모든 기업 행동에 대한 최종 의사 결정권을 가진 것으로 받아들여집니다. 평균적인 비즈니스에서 나쁜 운영 결정은 인명 손실이 아닌 수익 손실을 초래합니다. 현명한 경영진은 운영 결정을 내리기 위해 고용한 전문가들의 결정을 무시하지 않아야 할 필요성을 이해하거나, 아마도 이사회가 경영진이 스태프의 말을 들을 것을 요구할 것입니다. 그럼에도 불구하고, 비즈니스 측 경영진이 프로젝트 운영에 개입하는 것은 모범 사례에 반하며, 나쁜 행동으로 널리 받아들여집니다.

타이타닉의 경우 스미스 선장이 항해 중 선박을 지휘하고 선박과 탑승자들에게 개인적으로 책임을 졌습니다. 그의 상사인 J.B. 이즈메이는 귀항 후 스미스를 지휘관직에서 해임할 수 있었지만, 항해 중에는 영국 해양법 하에서 면허 있는 선원이 아니므로 선교에서 명령을 내릴 권한이 없었습니다. (Kuntz)

빙산 충돌에 이르는 시간 동안 J.B. 이즈메이는 스미스 선장에게 24노트 또는 75회전을 초과하는 무책임한 속도로 선박을 운항하도록 압력을 가하고 있었습니다. 타이타닉의 "테스트"로 여겨지던 올림픽은 이 속도로 대서양을 횡단한 적이 없었으며, 타이타닉은 정상적인 조건에서 대서양 횡단을 한 번도 수행할 시간도 없이 올림픽에서 수행된 테스트 범위마저 벗어나 운항하고 있었습니다. 이즈메이와 스미스는 타이타닉을 알려진 성능 매개변수를 넘어, 더 중요하게는 승무원의 알려진 운영 매개변수를 넘어 몰았습니다. 이 속도에서 어떤 운영 위험이 수반될지 단순히 알 수 없었습니다. 빙산이 산재해 있다고 알려진 해역에 진입하면서도 위험하다고 여겨졌어야 할 속도를 유지하는 것은 극도로 어리석은 것이었습니다.

공황, 혼란, 불안 등의 이유인지는 모르지만, 타이타닉이 빙산에 충돌했을 때 스미스 선장은 이즈메이가 선교에 들어와 실질적으로 선박의 지휘관으로서 임원 명령을 내리기 시작하도록 허용했으며, 스미스 선장은 이즈메이를 퇴거시킬 권리와 의무가 있었습니다. 이즈메이는 비상 통신, 승객 통보, 그리고 가장 중요하게는 타이타닉을 빙붕에서 앞으로 이동시키는 결정(이것이 선박의 주요 파열의 실제 원인으로 여겨집니다)을 포함한 핵심 운영 결정을 내렸으며, 선박이 침몰할 것이라는 추가 정보가 입수된 후에도 선박을 저속으로 전진시켜 선체를 더욱 분리시켰습니다. (Kozak-Holland)

우리가 지금 타이타닉과 시간적으로 멀리 떨어져 있다는 점을 감안하면, 프로젝트에서 잘 진행된 것을 평가하고 잘못된 것이 너무 많다는 것을 알면서도 그것을 알아내기가 어려울 수 있습니다. 타이타닉의 침몰은 우리 마음속에 너무 상징적이어서, 마케팅과 조직적 재앙 이외의 것으로 보는 것은 최선의 경우에도 어렵습니다.

결국 타이타닉 프로젝트는 방대했지만 잘 관리되었습니다. 범위는 통제되었고 필요한 경우 변경이 수용되었습니다. 사전에 대규모 설계를 진행하고 건설 단계와의 잘 확립된 계약적 인터페이스를 사용했으며, 사양의 이 확정은 신중하고 정확한 일정 관리를 허용했습니다. 선박 건조 프로세스는 표준화되어 있었고 잘 알려져 있었습니다. 역사적 건설 데이터를 사용하여 Harland-Wolff는 건설에 필요한 시간을 정확하게 예측할 수 있어, White Star Line이 선박의 실제 출항보다 훨씬 앞서 마케팅과 판매를 시작할 수 있었습니다. 올림픽과 거의 동일한 복사본인 타이타닉은 놀라운 일이 더욱 적었습니다. 유일한 진정한 놀라움은 White Star Line의 우선순위 변경으로 인해 타이타닉 프로젝트가 약 한 달간 보류된 것에서 비롯되었습니다.

J. Bruce Ismay의 말에 따르면 "그녀[타이타닉]는 계약에 의해 건조된 것이 아닙니다. 단순히 커미션으로 건조되었습니다." 이는 Harland-Wolff가 타이타닉 인도를 보장하기 위해 자신들의 프로세스와 감독을 사용할 수 있는 예외적인 권한이 부여되었음을 나타냅니다. 두 회사는 벤더-고객 관계라기보다는 파트너로서 더 많이 운영되었습니다. (Kuntz)

타이타닉에 대한 프로젝트 리스크는 외부 보험사에 크게 의존하고, 결국에는 주로 영국과 미국 승객들의 비용으로 회사를 책임 소송으로부터 보호하기 위해 영국 정부에 의존하는 방식으로 불량하게 처리되었습니다. 리스크는 매우 낮다고 여겨졌으며, 이 때문에 먼저 올림픽과 함께, 그리고 운영 재난이 최소화되자 타이타닉과 함께 더욱 그렇게 많은 부주의한 결정들이 내려졌습니다. 신중한 위험 평가가 이루어지지 않았습니다. 숙련된 선원들은 해결해야 할 많은 위험 영역을 쉽고 빠르게 정의할 수 있었을 것입니다. 완전한 표준 운영 절차의 부재와 같은 문제들은 표시될 수 있었고, 이를 위한 자원이 현재 타이타닉 팀에서 나올 필요가 없었고 White Star Line에게 주요 관심사로 이해되는 변수들 중 어느 것에도 영향을 미치지 않았을 것이므로, 쉽게 처리될 수 있었습니다.

프로젝트의 통신은 서비스 제공이 시작될 때까지는 매우 잘 처리된 것으로 보입니다. 이 시점에서 설계 결함, 의심스러운 결정들, 그리고 SOP의 부재가 선박의 통신 네트워크에 영향을 미쳤습니다. 이 통신은 운영적인 것으로 볼 수 있고 프로젝트 기반이 아닐 수 있지만, 그 논거는 의미론적입니다. 타이타닉의 문제는 전체론적이었으며, 올바른 설계 방법론을 따랐다면 위험 분석이 누락되지 않았을 것이고, 이는 SOP의 생성을 강제했을 것이며, 이는 통신 문제를 부각시키거나 어쩌면 수정하기까지 했을 것입니다.

핵심은 품질 문제였습니다. 타이타닉은 최고 품질의 대서양 횡단 여행 옵션으로 제안되고 판매되었습니다. 품질은 타이타닉에 대해 직접적으로 또는 간접적으로 언급되는 거의 모든 순간에 선포되었습니다. 고객 인터페이스는 가능한 한 깔끔하고 간결하게 유지되었습니다. 고객이 목격할 결과라면 어떤 비용도 아끼지 않았습니다. 그러나 이 "품질"이 기대고 있을 프로젝트의 기저 핵심 또는 인프라(Kozak-Holland에 따르면 비기능적 요구사항 — 비록 제가 이 맥락에서의 그들의 사용에 동의하지 않지만)는 무시되었고, 타이타닉의 진정한 품질과 White Star Line 운영의 품질은 궁극적으로 명백해지게 되었습니다.

참고 문헌 및 인용 출처:

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.

US Senate and British Official Hearing and Inquiry Transcripts from 1912 at the Titanic Inquiry Project.

최초 게재: SheepGuardingLlama.