타이타닉의 프로젝트 관리와 소프트웨어 프로젝트와의 비교

지금으로부터 110년 전에 설계가 시작된 타이타닉과 그 자매선인 올림픽, 브리태닉만큼 명성과 악명을 얻은 프로젝트는 거의 없습니다. 물론 올림픽 선박들의 운명에서 프로젝트 관리에 관해 우리가 배울 수 있는 많은 교훈이 있으며, 사실 다룰 가치 있는 프로젝트 관리의 많은 측면이 있습니다.

(선박들을 전체적으로 지칭할 때 저는 단순히 올림픽스(The Olympics)라고 부르겠습니다. 세 척 모두 White Star Line의 올림픽 클래스 선박이었기 때문입니다. 타이타닉의 개별적이고 후대의 명성은 여기서 관련이 없습니다. 또한, 올림픽 선박들, 그 역사와 운명에 관한 일반적인 정보는 독자에게 상식으로 알려져 있다는 입장을 취하며 다시 다루지 않겠습니다.)

올림픽스의 프로젝트 관리가 다뤄진 빈도를 감안할 때, 저는 오늘날 세계에서 현재의 프로젝트 관리를 가치 있는 역사적 렌즈를 통해 볼 수 있는 몇 가지 현대적 유사점을 살펴보는 것이 더 현명하다고 생각합니다. 프로젝트 관리는 수천 년 동안 지속되어 온 분야이며, 많은 도전, 기술 및 기법은 그리 많이 변하지 않았고, 과거의 함정은 오늘날 우리에게도 여전히 매우 적용됩니다. 과거에서 배우지 않으면 반드시 반복하게 된다는 옛 격언이 적용됩니다.

따라서 여기서 제 목표는 프로젝트의 리스크 분석, 인식 및 프로파일을 검토하고 이를 현대 프로젝트 관리에 적용하는 것입니다.

먼저 올림픽스 프로젝트의 이해관계자들을 파악해야 합니다. White Star Lines 자체(후원 회사 및 주요 투자자)와 그 디렉터 Joseph Bruce Ismay, 주요 설계자 Alexander Carlisle과 Thomas Andrews를 둔 Harland-Wolff(계약된 조선사), 선장 Edward John Smith를 포함하는 선원, 나중에 살펴볼 영국 정부, 그리고 가장 중요하게는 승객들입니다.

모든 이해관계자 그룹과 마찬가지로 다양한 역할이 있습니다. White Star는 한편으로는 스폰서이자 투자자이며, 현대 소프트웨어 프로젝트에서는 후원 고객, 관리자 또는 부서에 비유할 수 있습니다. Harland-Wolff는 설계자이자 건설자로 현대 소프트웨어 팀의 소프트웨어 엔지니어링 “팀원”, 즉 개발자 자신들과 가장 유사합니다. 선박 승무원들은 프로젝트 완료 후 운영을 담당했으며, 최종 소프트웨어 완성 후 운영을 맡는 IT 운영 팀에 비유할 수 있습니다. 승객들은 오늘날의 최종 사용자와 같아, 엔지니어링 결과물(선박 또는 소프트웨어)과 그 제품 위에 구축된 서비스(페리 서비스 또는 IT 관리 서비스) 모두에서 혜택을 받기를 바랬습니다. (“Olympic”)

프로젝트 분석의 또 다른 축은 닭(chicken)과 돼지(pig) 이해관계자로, 닭은 투자하고 위험을 감수하는 반면 돼지는 완전히 투자하고 궁극적인 위험을 감수합니다. 일반적인 소프트웨어에서 우리는 이 비유를 이해관계자의 정도를 이야기하는 데 사용합니다. 관련된 자와 헌신한 자를 구분하는 것이지만, 올림픽 선박의 경우 이 용어들은 새롭고 끔찍한 의미를 갖습니다. 투자자와 건설자가 재정적 위험만 감수한 반면, 선원과 승객은 선박의 운영 단계에서 문자 그대로 생명을 걸었기 때문입니다. (Schwaber)

둘째로, 올림픽스의 맥락 내에 존재하는 다양한 프로젝트들을 구별하는 것이 유용하다고 생각합니다. 물론 세 척의 선박을 물리적으로 설계하고 건설하는 단일 프로젝트가 있었습니다. 이는 설계와 건설이라는 두 가지 명확한 구성 요소를 가진 단일 프로젝트로, 세 척의 올림픽 선박이라는 세 가지 개별 결과물을 냅니다. 건설 단계의 끝에는 조선에 관여한 프로젝트 관리자와 팀이 작업을 중단하고 선박을 운영하는 승무원이 인수하는 매우 명확한 구분점이 있습니다.

여기서 우리는 이미 현대 기술 세계와 중요한 유사점을 도출할 수 있습니다. 소프트웨어 제품은 소프트웨어 엔지니어가 설계하고 개발하며, 완성되면 최종 제품의 실제 의도된 사용을 담당하는 IT 운영 직원에게 인계됩니다. 이 두 팀은 단일 조직 산하에 내부적으로 있거나 두 개 이상의 매우 다른 조직에서 올 수 있습니다. 그러나 엔지니어링과 운영 부서 간의 분리는 한 세기 이상 전 조선과 페리 서비스에서 그랬던 것처럼 오늘날 대부분의 기업에서도 여전히 명확하고 뚜렷합니다.

한 걸음 더 나아가 White Star의 대서양 횡단 페리 서비스를 Microsoft Office 365, Salesforce 또는 G Suite와 같은 많은 현대 서비스형 소프트웨어(SaaS) 벤더와 비교할 수 있습니다. 이러한 경우 해당 회사는 핵심 제품을 만드는 엔지니어링 또는 제품 개발 팀과, 그 사내 제품을 서비스로 운영하는 두 번째 팀을 보유합니다. 이것은 소프트웨어를 만드는 동일한 회사가 궁극적으로 그것을 운영하게 되는 소프트웨어 개발 분야에서 점점 더 중요한 비즈니스 모델이 되고 있습니다. 하지만 외부 고객을 위해서입니다. 많은 면에서 올림픽스와 현대 소프트웨어 및 IT의 관련성은 줄어들기보다 오히려 증가하고 있습니다.

이것은 올림픽스에서 놓쳤고 오늘날에도 종종 놓치는 중요한 인터페이스 이해를 제기합니다. 인계의 양쪽 모두 상대방이 궁극적으로 안전에 책임이 있다고 믿었습니다. 엔지니어들은 설계의 안전성을 자랑했지만, 압박을 받을 때 운영 절차가 위험을 완화할 것이고 자신들의 노력은 대부분 불필요하다고 가정하며 타협할 의사가 있었습니다. 마찬가지로, 속도를 유지하고 좋은 시간을 내라는 압박을 받을 때 운영 팀은 절차를 타협할 의사가 있었습니다. 왜냐하면 엔지니어링 팀이 자신들의 노력을 본질적으로 낭비하게 만들 정도로 선박이 안전하게 만들어졌다고 믿었기 때문입니다. 이 잘못된 의사소통은 두 가지 유형의 극도의 안전 시스템을 기본적으로 없는 것으로 만들었습니다. 양측 중 어느 한쪽이라도 상대방이 어떻게 운영하는지 이해했다면, 이를 고려할 수 있었을 것입니다. 결국 양측 모두 적어도 어느 정도는 안전이 “상대방의 일”이라고 가정했습니다. 선박은 안전을 바탕으로 크게 광고되었지만, 현실은 지난 반세기 이상의 일반적인 추세를 이어갔습니다. 매년 선박이 전년도보다 덜 안전하게 만들어지고 운영되었습니다. (Brander 1995)

오늘날 우리는 IT와 소프트웨어 엔지니어링 사이에서 이와 같은 문제가 발생하는 것을 봅니다. 안정성 문제(그것도 여전히 사실이지만)보다는 이제 보안 문제에서, 이는 올림픽스의 맥락에서 안전과 유사하게 볼 수 있습니다. 보안은 지난 10년간 기술 울타리 양쪽에서 가장 중요한 주제 중 하나가 되었으며, 업계는 두 측 모두 보안 관행을 철저히 실행해야 하는 필요성에서 비롯되는 도전에 직면합니다. 어느 한쪽도 혼자서는 진정으로 안전한 시스템을 구현할 수 없습니다. 안전이나 보안을 계획하는 것은 운영 중 절차적으로 시행하는 것의 대체물이 될 수 없습니다.

오늘날 훌륭한 비교 사례는 British Airways가 대서양을 횡단하는 모든 항공편을 어떻게 감독하는가입니다. 북대서양 상공의 주요 항공 운송업체인 British Airways는, 올림픽스가 횡단하려 했던 바로 그 경로를 지나며 안전에 대한 탁월한 평판을 유지해야 합니다. 2017년에도 북대서양 상공을 비행하는 것은 불안하고 복잡한 여정입니다.

British Airways의 어떤 항공편도 이륙하기 전에 조종사와 승무원은 항공기, 승무원, 날씨 등 모든 상황에 대한 세부 정보를 포함한 300페이지 분량의 임무 매뉴얼을 검토해야 합니다. 이 과정은 너무 강도 높아서 British Airways는 이를 항공편으로 인정하기를 거부하고, 대서양 횡단의 모든 단독 여행을 공식적으로 “미션”이라고 부릅니다. 이는 관련된 모든 사람에게 그러한 노력에 수반되는 심각성과 위험을 강조하기 위한 것입니다. 그들은 사람들이 이러한 여행에 대해 생각하는 방식을 바꾸는 것의 중요성을 명확히 이해하고 있으며, 사람들이 다른 사람들이 자신의 일을 잘 해냈다고 가정하기 시작하거나 자신의 일에서 지름길을 택할 수 있다고 느낄 때 어떤 일이 생길 수 있는지 알고 있습니다. 그들은 아무도 부주의해지거나 매일 여러 번 완료되더라도 비행이 결코 일상적인 일로 느껴지지 않도록 하고 싶어 합니다. (Winchester)

타이타닉에 British Airways의 접근 방식이 사용되었다면 재앙이 그렇게 닥치지 않았을 가능성이 매우 높습니다. 운영 측면만으로도 재앙을 막을 수 있었을 것입니다. 마찬가지로, 선박 엔지니어들이 오늘날의 Boeing이나 Airbus와 같은 기준으로 적용되었다면, 관리진의 압박으로 프로젝트 작업 중 안전 요건을 그렇게 쉽게 수정하지 않았을 것입니다.

올림픽스에 실질적으로 영향을 미친 것은 여러 면에서 제어되지 않은 범위 확장(scope creep)의 한 형태였습니다. 프로젝트는 안전이 중요한 역할을 하는 “큰 설계를 먼저”(big design up front)하는 전통적인 워터폴 접근 방식으로 시작되었으며, 초기 요건은 좋았습니다. 원래의 프로젝트 요건과 심지어 많은 원래 설계가 사용되었다면 선박은 실제보다 훨씬 더 안전했을 것입니다. 하지만 더 큰 식당이나 더 고급스러운 인테리어에 대한 새로운 요건이 우선시되었고, 프로젝트의 범위와 파라미터가 이러한 변경 사항을 수용하기 위해 변경되었습니다. 어떤 프로젝트와 마찬가지로, 어떤 변경도 진공 상태에서 일어나지 않으며 비용, 안전 또는 납기일과 같은 다른 요소에 영향을 미칩니다. (Sadur)

타이타닉의 범위 확장은 극적이었지만, 숨겨져 있었고 대부분 명백하지 않았습니다. 식당 크기의 변화와 같은 작은 변화를 지적하기는 쉽지만, 훨씬 더 중요한 것은 선박을 납품해야 하는 시간 프레임의 변경이었습니다. 범위를 실제로 변경한 것은 초기 마감 기한과 프로젝트가 비교적 엄격하게 유지되어야 했다는 것이었습니다. 이것은 타이타닉의 드라이 도크 작업 도중 나중에 계류 작업 중에 언니 격인 올림픽이 대규모 수리를 위해 여러 번 입항하여 원래 일정에서 타이타닉 자체 작업에 사용 가능한 시간에 매우 큰 영향을 미쳤기 때문에 특히 문제가 되었습니다. 이러한 유형의 범위 수정은 특히 사후적으로 간과하거나 무시하기 쉽습니다. 물리적 결과물과 원래 날짜가 극적인 방식으로 변경되지 않았기 때문입니다. 모든 의도와 목적에서 타이타닉은 원래 계획보다 훨씬 빠르게 생산을 서둘렀습니다.

현대 소프트웨어 엔지니어링에서 설계 작업이 얼마나 걸릴지는 해당 작업을 수행할 엔지니어(들) 자신만큼 잘 추정할 수 있는 사람은 없다는 것이 일반적으로 인정됩니다. 또한 관리 압박을 통해 엔지니어링 및 설계 노력을 크게 가속화할 수 있는 수단은 없다는 것도 일반적으로 인정됩니다. 프로젝트가 최대 속도로 진행되면, 더 빠르게 진행될 수 없습니다. 더 빠르게 진행하려는 시도는 종종 실수, 누락 또는 미스로 이어집니다. 우리는 이것이 소프트웨어에서 사실임을 알고 있으며, 원칙이 동일하기 때문에 선박 설계에서도 사실이었을 것이라고 가정할 수 있습니다. 타이타닉에게 이 과정에 적절한 시간이 주어졌다면, 안전 조치가 더 철저하게 고려되거나 적어도 인계 시 운영 팀에게 제대로 전달되었을 수도 있습니다. 서두르는 팀은 타협을 강요받으며, 제약이기 때문에 시간은 조정할 수 없으므로 어딘가에서 코너를 잘라야 하며, 거의 항상 그것은 품질과 철저함에서 옵니다. 이것은 실수로 나타날 수도 있고, 설계의 한 부분을 변경할 때 관련된 모든 요소를 완전히 검토하지 못하는 것으로 나타날 수도 있습니다.

이것은 전체적인 설계 사고(holistic design thinking)로 이어집니다. 프로젝트 초반에 올림픽스는 안전을 염두에 두고 설계되었습니다. 함께 고도로 신뢰할 수 있는 선박을 만들기 위해 의도된 많은 별개의 시스템들의 신중한 상호 작용에서 비롯되는 안전이었습니다. 이 규모의 선박 구성 요소를 개별적으로 볼 수 없습니다. 그것들은 의미가 없습니다. 선체 설계, 갑판 스타일, 화물의 무게, 사용된 재료, 격벽 스타일은 모두 상호 연관되어 있으며 함께 기능해야 합니다.

프로젝트가 더 빠르게 완료하거나 파라미터를 변경하도록 압박받았을 때, 이 전체적인 사고와 이전 결정에 대한 명확한 재검토는 이루어지지 않았거나 적절하게 이루어지지 않았습니다. 오히려 개별 구성 요소는 전체 선박 내에서 그 역할에 어떤 영향을 미치는지, 그로 인한 전체 안전에 대한 영향을 고려하지 않고 변경되었습니다. 사소한 변화처럼 보일 수 있는 것이 전체적인 프로젝트 관리가 포기되었기 때문에 예상치 못한 의도하지 않은 결과를 낳았습니다. (Kozak-Holland)

엔지니어링에 대한 이 변화는 물론 운영에서도 반영되었습니다. 쌍안경을 사용하지 않거나 얼음 버킷 판독을 하지 않는 것과 같은 각 변화는 개별적으로 다소 사소했지만, 합쳐 놓으면 엄청난 영향을 미쳤습니다. 아마도, 하지만 확실히 알 수는 없지만, 응집력 있는 프로젝트 관리나 적어도 프로세스 개선 시스템이 사용되지 않았을 것입니다. 쌍안경이 사용되었는지, 수질 검사가 정확했는지 등을 감독하는 사람이 누구였습니까? 어떤 확인이라도 했다면 해당 작업에 필요한 도구가 전혀 존재하지 않는다는 것이 밝혀졌을 것입니다. 절차의 간단한 시험 운행도 이루어졌을 리 없으며, 정기적인 확인과 프로세스 개선은 더욱 그렇습니다. 프로세스 개선은 특히 Smith 선장이 RMS 올림픽에서 연습했고, 다섯 번째 항해에서 해상 충돌을 일으켰으며, 타이타닉의 초기 출항에서 거의 같은 실수를 반복할 뻔했다는 사실에 의해 강조됩니다. 올림픽 선박의 모든 선장과 조종사들에게 중요한 교훈이 되었어야 할 것이 대신 무시되고 거의 즉시 반복되었습니다. (“Olympic”)

물론 조선과 소프트웨어는 매우 다른 것들이지만, 많은 교훈을 공유할 수 있습니다. 가장 중요한 교훈 중 하나는 조선이 직면한 한계를 보고 소프트웨어로 작업할 때 이러한 동일한 한계를 반드시 유지할 필요는 없다는 것을 인식하는 것입니다. 올림픽과 타이타닉은 거의 동시에 건조되었으며, 올림픽의 건조에서 얻은 엔지니어링 지식이 타이타닉의 건조에 적용될 시간이 전혀 없었습니다. 하물며 운영에서 얻은 지식은 더욱 그렇습니다. 현대 소프트웨어에서는 그러한 제약을 기대하지 않을 것이며, 실제 코드에서나 개념적으로라도 그것을 기반으로 하는 추가 소프트웨어로 넘어가기 전에 최소한 어느 정도 소프트웨어를 테스트할 수 있을 것입니다. 오늘날 프로젝트 관리는 더 현대적인 시대와 우리의 다른 산업에서 존재하는 차이를 최대한 활용해야 합니다. 일부 소프트웨어 프로젝트는 여전히 이와 같은 프로세스를 필요로 하지만, 이는 시간이 지남에 따라 점점 더 드물어졌으며 오늘날에는 불과 20년 전보다 훨씬 덜 일반적입니다.

Harland-Wolff가 올림픽스 작업에서 그들의 권한 내에서 가능한 피드백 루프를 통합하려고 노력한 것을 평가하는 것은 충분히 가치 있는 일입니다. 그들은 이전 선박의 건조를 통해 나중 선박에 대해 더 많이 배우려 했을 뿐만 아니라, 선박들이 대부분 동시에 건조 중이었고 대부분의 교훈이 적용될 시간이 없었기 때문에 이것은 매우 제한적이었지만, 훨씬 더 중요하게는 “보증 그룹”(guarantee group)이 선박에 탑승하게 하는 특별한 조치를 취했습니다. 이 보증 그룹은 모든 종류의 지원 직종에서 온 모든 종류의 견습 및 숙련 조선 기술자로 구성되었습니다. (“Guarantee Group”)

직접 피드백을 위한 보증 그룹의 사용은 전례가 없었으며 지금도 그렇게 남아 있으며, 조선사들이 대서양을 왕복하는 고급 여행에 수많은 귀중한 작업자를 희생하는 막대한 비용과 시간 투자였습니다. 그룹은 자신들의 작업을 직접 검사하고, 실제 상황에서 그것이 작동하는 것을 보고, 작동 중인 선박의 맥락 내에서 사용에 대한 이해를 얻고, 팀 빌딩, 지식 이전 등을 함께 작업할 수 있었습니다. 이것은 선박들이 건조에서 겹쳤던 선착장에서의 피드백보다 훨씬 더 가치 있었습니다. 이것은 그들의 조선 사업의 미래에 대한 강한 투자였습니다. 수십 년 동안 그들에게 이익을 주었을 산업 교육에 대한 헌신이었습니다.

현대 배포 스타일, 도구 및 교육은 소프트웨어의 대다수가 지난 세기 초 조선에서 사용된 것과 크게 다르지 않은 워터폴 방법론 아래 만들어지던 것에서, 대부분이 신속한 테스트, 평가, 변경 및 배포를 허용하는 어느 정도의 애자일(Agile) 방법론을 활용하는 것으로 이끌었습니다. 범위 확장은 완화하거나 크게 관리해야 하는 것에서 개발 프로세스 내에서 예상되고 가정될 수 있는 것으로, 심지어 거의 활용할 수 있는 것으로 변화했습니다. 큰 설계를 먼저 하는 것의 근본적인 문제 중 하나는 고객 또는 고객 역할의 이해관계자가 엔지니어에게 설계보다 훨씬 더 어려운 경우가 많은 “큰 결정을 먼저” 해야 한다는 것입니다. 이러한 초기 결정들은 종종 범위 확장이나 나중의 변경 요청에 주요 기여자이며, 요건에 지속적인 변경이 발생하는 것을 예상하고 그것을 프로세스에 구축하는 애자일 프로세스에 의해 종종 줄이거나 피할 수 있습니다.

조선사 Harland and Wolff는 어느 정도 유용한 올림픽의 15피트 모델을 제작하여 테스트했지만, 물론 실물 크기 선박이 나중에 생산할 수력학적 작용을 모방하지 못했으며, 다른 선박들 근처에 있을 때 새 선박의 크기의 더 위험한 부작용 중 일부를 예측하지 못했습니다. 이것이 그룹의 첫 번째 사고로 이어졌고, 거의 두 번째 사고로 이어질 뻔했습니다. 건설자들은 설계와 건설 과정의 모든 단계에서 가능한 한 테스트하고 배우려는 모든 노력을 기울인 것 같습니다. (Kozak-Holland)

현대 프로젝트 관리와 비교하면 이것은 예상치 못한 이유로 막다른 길이 될 수 있는 것에 더 많은 노력을 투자하기 전에 개발자나 심지어 고객이 실제로 경험할 수 있는 빠른 목업이나 와이어프레임을 제작하는 것에 비유할 수 있습니다. 이것은 실제 사용자가 시스템을 물리적으로 조작하고 그것이 그들이 찾는 경험을 제공하는지 스스로 판단할 기회를 제공하지 않으면 유용성이나 만족도 점수를 제대로 예측할 능력이 종종 거의 없는 사용자 인터페이스 설계에서 특히 중요합니다. (Esposito)

물론 우리는 올림픽스가 재정 동향과 힘에 관한 역사적 병치의 맥락 내에서 감수한 위험을 고려해야 합니다. 당시 지난 세기 중반부터 시작하여 지배적인 재정적 사고는 인명, 화물 또는 선박의 손실 측면에서 안전보다는 위험한 방향으로 기울어지는 것이 최선이며, 보험 수단을 통해 차이를 극복하는 것이 최선이라는 것이었습니다. 선박이 지나치게 인명에 관해 주의하는 것보다 위험한 방식으로 운영하는 것이 재정적으로 훨씬 유리했습니다. 올림픽스 시대에 이 추세는 거의 60년 동안 잘 확립되어 있었으며, “침몰하지 않는” 선박이 그렇게 많은 영혼을 태우고 그토록 장엄한 방식으로 침몰하기까지 대중에게 시장 영향이 존재하지 않았습니다.

위험과 그 재정적 트레이드오프에 대한 이 접근 방식은 오늘날 프로젝트 관리자들이 100년 이상 전과 마찬가지로 이해해야 하는 것입니다. 위험이 너무 중요하여 없애기 위해 어떤 비용도 가치 있다고 믿게 되기 쉽지만, 프로젝트는 이렇게 생각할 수 없습니다. 위험 감소를 추구하는 데 무제한의 자원을 소비하는 것이 가능합니다. 실제 세계에서는 위험과 위험 완화 비용의 균형을 맞추는 것이 필요합니다. 소프트웨어 개발 외부이지만 현대의 훌륭한 예는 미국의 신용카드 사기 처리입니다. 불과 몇 년 전까지만 해도, 미국 신용카드 업계는 일반적으로 도난을 방지하기 위한 신용카드의 더 큰 보안 조치 비용이 그것이 없는 위험에 비해 너무 높다는 견해를 가지고 있었습니다. 본질적으로 가짜 거래를 보상하는 데 돈을 쓰는 것이 그 가짜 거래를 방지하는 것보다 더 비용 효율적이었습니다. 이 비용 대 위험 비율은 때때로 반직관적이고 심지어 좌절스러울 수 있지만, 논리적이고 계산적인 방식으로 프로젝트 결정을 이끌어야 하는 것입니다.

유사하게, IT에서는 다운타임이 본질적으로 무제한적인 비용이라고 믿으며 시스템을 설계하고, 실제로 발생했을 경우 실제 중단 사건 자체의 비용보다 훨씬 더 많이 다운타임 위험을 완화하려는 것이 일반적입니다. 이것은 분명히 어리석지만, 이러한 유형의 비용 분석이 실행되거나 올바르게 실행되는 경우가 거의 없어 이러한 사고방식에 빠지기가 너무 쉽습니다. 소프트웨어 엔지니어링 프로젝트에서 우리는 위험에 유사한 방식으로 접근해야 합니다. 어떤 종류의 위험이 있다는 것을 받아들이고, 실제 위험, 해당 위험의 영향 규모를 결정하고 이를 완화 전략의 비용과 비교하는 것은 위험에 관한 적절한 프로젝트 관리 결정을 내리는 데 중요합니다. (Brander 1995)

또한 올림픽스가 확실히 해당되는 매우 큰 프로젝트에서 특히 흥미로운 것은 “대마불사”(too big to fail)라는 추가 개념입니다. 이것은 물론 지난 10년간의 금융 위기 동안 나온 현대적인 문구이지만, 이 개념과 현실은 훨씬 오래되었으며, 프로젝트가 완전히 실패했을 경우 “국가적 재정 재앙”으로 등록될 규모에 해당하는 모든 프로젝트에 대한 귀중한 고려 사항입니다. 올림픽스의 경우 영국 정부는 결국 투자자들을 완전한 재앙으로부터 보호했습니다. 가장 큰 승객 노선 중 하나의 붕괴는 당시 국가에 치명적이었을 것이기 때문입니다.

White Star Lines는 단순히 “대마불사”였으며, 말하자면 정부에 의해 떠받쳐졌고 몇 년 후 Cunard에 강제 합병되었습니다. 이 개념, 즉 정부가 회사의 실패 위험을 받아들이고 싶지 않을 것이라는 것을 알고 있다는 것이 당시 계산되거나 고려되었을 수도 있습니다, 우리는 모릅니다. 그러나 우리는 오늘날 매우 큰 프로젝트에서 이것이 고려된다는 것을 알고 있습니다. 현재 이런 일이 일어나고 있는 예는 Lockheed Martin의 F-35 전투기로, 대폭 예산 초과에 납기일을 넘겼으며 더 이상 유용할 것으로 여겨지지 않지만, 국가 경제에 너무 중요한 프로젝트로 보아 완전히 붕괴시킬 수 없다고 여기는 다른 정부 스폰서들에 의해 몇 년간 지원되고 있습니다. 이 현상이 점점 더 잘 알려질수록, 더 많은 프로젝트가 위험 분석 단계에서 이것을 고려하는 것을 볼 가능성이 높습니다. (Ellis)

운영 측면으로 넘어가면 타이타닉 침몰로 이어진 잘못된 수많은 측면을 검토할 수 있지만, 핵심에서 제가 가장 명백하다고 생각하는 것은 전체 과정에 걸쳐 표준 운영 절차(Standard Operating Procedure)의 부재였습니다. 이것은 선박이 처녀 항해 중이었고 프로세스 문서화와 개선에 거의 시간이 없었기 때문에 어느 정도 이해할 수 있습니다. 그러나 이것은 지켜야 할 평판과 이러한 문제에 대한 많은 경험을 가진 오래된 해운 노선의 기함이었습니다. 또한 타이타닉이 첫 번째 항해를 시도할 당시에는 이미 올림픽이 만족스러운 표준 운영 절차 세트를 개발하기에 충분히 오랫동안 운항되었다는 사실도 간과해서는 안 됩니다.

기본 문서화는 처녀 항해에서도 예상되었을 것입니다. 그러한 규모의 선박이 승무원들 간의 조정과 소통 없이 전혀 기능할 것을 기대하는 것은 합리적이지 않습니다. 첫 번째 선박이 출항하기 전에 기본적인 승무원 운영 절차를 만들고 준비할 수 있는 충분한 시간, 실제로는 수년이 있었으며, 물론 이것은 이러한 성격의 모든 선박을 위해 이루어져야 했을 것이지만, 타이타닉의 경우 그러한 운영 절차가 부족하고, 없으며, 테스트되지 않았다는 것이 명백했습니다.

운영 절차를 담당하는 당사자는 프로젝트 방정식의 운영 측에서 확인될 가능성이 높지만, 엔지니어링 및 건설 팀에서도 어느 정도의 문서를 제공하거나 조정할 필요가 있었을 것입니다. 타이타닉에서 무너진 절차 중 많은 것들은 압박 하에서 지휘 체계 실패, 회사 디렉터가 함교를 인수하고 선장이 이를 허용한 것, 무선 교신사들이 빙산 경고보다 승객 메시지 중계를 우선시하도록 지시받은 것, 다른 선박들이 경고를 보내려 할 때 무선 교신사들에게 방송을 멈추라고 지시한 것, 중요한 메시지가 함교에 전달되지 않은 것, 중요한 작업에 필요한 도구가 제공되지 않은 것 등을 포함했습니다. (Kuntz)

선박의 엔지니어링 및 설계와 마찬가지로, 선박 운영에도 선박과 그 승무원이 개별 단위가 아닌 전체로 작동하도록 보장하는 강력하고 전체적인 지도가 필요했습니다. Marconi 무선 교신사들을 개별 단위로 보는 것과 같은 방식으로 말입니다. 그 예에서, 그들은 공식적으로 선박의 승무원이 아니라 유료 승객의 통신을 처리하고 시간이 허락할 때만 선박 비상 통신을 처리하기 위해 탑승한 Marconi 직원이었습니다. 그들이 외부 계약자로서도 전체적인 운영 관리 시스템의 일부로 감독되었다면, 그들의 절차가 훨씬 더 안전에 집중되었거나, 적어도 임기응변적이고 자의적이 아닌 명확하게 정의된 서비스 수준 협약(SLA)으로 함교에 메시지를 전달하는 것이 이루어졌을 가능성이 높습니다.

어떤 프로젝트와 프로젝트 구성 요소에서든, 프로젝트 목표, 결과물, 절차 등의 좋은 문서화는 중요하며, 우리가 하는 모든 것의 핵심에 좋은 의사소통과 문서화가 없다면 프로젝트 관리는 성공할 가능성이 거의 없습니다. 내부적으로는 프로젝트 내에서, 외부적으로는 이해관계자들과 함께 말입니다.

오늘날 우리는 올림픽, 타이타닉, 브리태닉의 프로젝트 관리 교훈이 오늘날도 여전히 가치 있음을 알게 됩니다. 가능한 경우 반복적 프로젝트 설계를 추진하거나, 부족 지식(tribal knowledge)에 투자하거나, 위험을 계산하거나, 시스템 엔지니어링과 시스템 운영의 역할 또는 제품 비용에 대한 외부 보호 세력의 상호 작용을 이해하는 시대의 맥락은 여전히 관련이 있습니다. 프로젝트에 영향을 미치는 요소들은 사이클로 오고 가며, 오늘날 우리는 올림픽스와 달리기보다는 유사한 모델로의 추세를 봅니다. 미래에는 아마도 추가 이동이 다시 있을 것입니다. 기본적인 교훈은 매우 관련이 있으며 계속 그렇게 될 것입니다. 우리 자신의 프로젝트가 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.