Управление проектом «Титаник» и параллели с проектами в сфере программного обеспечения

Немногие проекты снискали такую же известность и популярность, как «Титаник» и его корабли-собратья класса Olympic — «Олимпик» и «Британик», проектирование которых началось сто десять лет назад. Разумеется, судьба кораблей класса Olympic преподносит нам множество уроков в области управления проектами, и целый ряд аспектов этой темы заслуживает детального рассмотрения.

(Говоря о кораблях как о группе, я буду именовать их просто The Olympics, поскольку все три вместе являлись кораблями класса Olympic компании White Star Line. Индивидуальная и более поздняя слава «Титаника» здесь не имеет значения. Кроме того, я исхожу из того, что общие сведения о кораблях класса Olympic, их истории и судьбе являются общеизвестными для читателя, и не буду повторять их.)

Принимая во внимание, как часто рассматривалось управление проектом The Olympics, я считаю более целесообразным обратиться к нескольким современным параллелям, позволяющим взглянуть на сегодняшнее управление проектами через ценный исторический объектив. Безусловно, управление проектами — это дисциплина, существующая тысячелетиями, и многие из её вызовов, навыков и техник не претерпели существенных изменений; ловушки прошлого по-прежнему актуальны для нас сегодня. Применима старая истина: если мы не учимся на прошлом, мы обречены его повторить.

Моя цель — рассмотреть анализ рисков, восприятие и профиль проекта и применить их к современному управлению проектами.

Прежде всего необходимо определить заинтересованные стороны проекта The Olympics. Это сама компания White Star Lines (компания-спонсор и основной инвестор) и её директор Джозеф Брюс Исмей; Harland-Wolff (судостроительный подрядчик) с главными проектировщиками Александром Карлайлом и Томасом Эндрюсом; экипажи кораблей, включая капитана Эдварда Джона Смита; британское правительство, о роли которого будет сказано далее; и, что наиболее важно, пассажиры.

Как и в любой группе заинтересованных сторон, здесь присутствуют различные роли. White Star с одной стороны — спонсор и инвестор; в современном программном проекте её аналогом был бы заказывающий заказчик, менеджер или департамент. Harland-Wolff — проектировщики и строители, ближайший аналог “членов команды” в современной команде разработки программного обеспечения, то есть самих разработчиков. Экипажи кораблей отвечали за эксплуатацию после завершения проекта и сопоставимы с ИТ-командой эксплуатации, принимающей готовое программное обеспечение в работу. Пассажиры были подобны современным конечным пользователям, рассчитывающим извлечь пользу как из инженерного продукта (корабль или программное обеспечение), так и из сервиса, выстроенного на его основе (паромная переправа или управляемые ИТ-услуги). (“Olympic”)

Ещё одна ось анализа проекта — концепция stakeholders типа “chicken and pig” (“курица и свинья”), где “куры” вовлечены и несут риск, а “свиньи” полностью погружены в проект и несут конечный риск. В обычном программном проекте эти сравнения описывают степень участия заинтересованных сторон — тех, кто вовлечён, против тех, кто по-настоящему обязался. Но в случае кораблей класса Olympic эти термины обретают новый и ужасающий смысл: экипаж и пассажиры в буквальном смысле рисковали жизнью на операционном этапе, тогда как инвесторы и строители несли только финансовые риски. (Schwaber)

Во-вторых, я считаю полезным разграничить различные проекты, существовавшие в контексте The Olympics. Был, конечно же, проект проектирования и строительства трёх кораблей физически — единый проект с двумя чёткими составляющими: проектированием и строительством, а также тремя дискретными результатами — тремя судами класса Olympic. По завершении строительной фазы существовал предельно чёткий рубеж, где проектные менеджеры и команды, занимавшиеся сборкой корабля, прекращали работу, а экипаж, эксплуатировавший судно, принимал управление.

Здесь уже прослеживается важная аналогия с современным миром технологий: программные продукты проектируются и разрабатываются инженерами-программистами, а по завершении передаются ИТ-команде эксплуатации, которая берёт на себя непосредственное использование конечного продукта. Эти две команды могут находиться внутри единой организации или представлять две и более совершенно разные структуры. Однако разграничение между инженерным и операционным департаментами оставалось столь же чётким и выраженным в большинстве современных компаний, как и в судостроении и паромном сообщении более века назад.

Можно пойти ещё дальше и сравнить трансатлантическую паромную службу White Star с многими современными поставщиками программного обеспечения как услуги — такими как Microsoft Office 365, Salesforce или G Suite. В этих случаях компания располагает инженерной или продуктовой командой, создающей основной продукт, и второй командой, которая берёт этот внутренний продукт и предоставляет его как услугу. Это всё более значимая бизнес-модель в сфере разработки программного обеспечения, где компания-создатель ПО сама же является его конечным оператором — но для внешних клиентов. Во многих отношениях актуальность кораблей класса Olympic для современного программного обеспечения и ИТ возрастает, а не снижается.

Это подводит нас к важному аспекту взаимодействия на стыке передачи проекта, который был упущен в случае The Olympics и нередко упускается сегодня: каждая из сторон считала, что конечная ответственность за безопасность лежит на другой. Инженеры превозносили безопасность конструкции, однако под давлением были готовы идти на компромисс, полагая, что операционные процедуры нивелируют риски и их собственные усилия во многом избыточны. В свою очередь, операционная команда, испытывая давление с требованием ускорить движение и не опаздывать, была готова поступиться процедурами, поскольку считала, что инженеры зашли столь далеко в обеспечении безопасности, что их собственные усилия практически излишни: корабль настолько безопасен, что операционные меры предосторожности просто не нужны. Это недопонимание привело к тому, что вместо двух систем исключительной безопасности не осталось практически ни одной. Знай каждая из сторон, как действует другая, это можно было бы учесть. В итоге обе стороны в той или иной мере считали безопасность “чужой задачей”. При том что корабль активно рекламировался как безопасный, в действительности он продолжал общую тенденцию последних полувека: с каждым годом корабли строились и эксплуатировались всё менее безопасно. (Brander 1995)

Сегодня мы наблюдаем аналогичную проблему на стыке ИТ и инженерии программного обеспечения — уже не столько в части стабильности (хотя эта тема тоже остаётся актуальной), сколько в части безопасности, которую в данном контексте можно рассматривать аналогично понятию безопасности в случае The Olympics. Безопасность стала одной из важнейших тем последнего десятилетия по обе стороны технологического забора, и отрасль сталкивается с вызовами, которые возникают из необходимости для обеих сторон в полной мере применять практики информационной безопасности — ни одна из них в одиночку не способна построить по-настоящему защищённые системы. Планирование безопасности просто не является заменой её процедурного соблюдения в ходе эксплуатации.

Превосходным примером в наши дни служит British Airways и её подход к каждому рейсу через Атлантику. Будучи основным перевозчиком воздушного трафика над Северной Атлантикой — тем самым маршрутом, который The Olympics были призваны преодолевать, — British Airways вынуждена поддерживать репутацию отличника безопасности. Даже в 2017 году перелёт над Северной Атлантикой остаётся сложным и ответственным предприятием.

Перед каждым рейсом British Airways пилоты и экипаж обязаны изучить трёхсотстраничное руководство по миссии, в котором содержится вся необходимая информация: о самолёте, экипаже, погодных условиях и многом другом. Этот процесс настолько серьёзен, что British Airways отказывается называть полёт просто полётом и официально именует каждый трансатлантический перелёт “миссией” — специально для того, чтобы донести до всех участников серьёзность и рискованность подобного предприятия. Авиакомпания явно осознаёт важность изменения отношения людей к такому маршруту и понимает, что произойдёт, если люди начнут считать само собой разумеющимся, что все остальные сделали свою работу и можно срезать углы на своём участке. Они не хотят, чтобы кто-то становился беспечным или воспринимал полёт — пусть и выполняемый несколько раз в день — как нечто обыденное. (Winchester)

Если бы подход British Airways был применён на «Титанике», катастрофа, вероятнее всего, не случилась бы в тот момент. Одной лишь операционной стороны было бы достаточно для её предотвращения. Точно так же, будь инженеры-корабелы обязаны соответствовать нынешним стандартам Boeing или Airbus, они вряд ли так легко поддались бы давлению менеджмента с целью пересмотра требований безопасности в ходе работы над проектом.

Во многом то, что определило судьбу The Olympics, было формой неконтролируемого расширения охвата (scope creep). Проект изначально строился по традиционной каскадной методологии с “масштабным проектированием на старте”, и первоначальные требования были хороши — безопасность играла в них ключевую роль. Если бы исходные требования и даже большая часть оригинального проекта были сохранены, корабли оказались бы значительно безопаснее. Однако новые требования — более просторные обеденные залы или более роскошная отделка — взяли верх, и охват и параметры проекта были изменены для их выполнения. Как и в любом проекте, ни одно изменение не происходит в вакууме: оно неизбежно влечёт последствия для других факторов — стоимости, безопасности или сроков сдачи. (Sadur)

Расширение охвата непосредственно «Титаника» было значительным, однако скрытым и в основном не очевидным. Легко указать на мелкие изменения вроде увеличения площади обеденного зала, но куда важнее оказалось изменение сроков, в которые корабль должен был быть сдан. Настоящей причиной изменения охвата стало то, что первоначальные дедлайны и планы необходимо было соблюдать относительно строго. Это было особенно проблематично потому, что в период работ «Титаника» в сухом и затем мокром доке старший собрат — «Олимпик» — несколько раз поступал на масштабный ремонт, что существенно сокращало время, отведённое в оригинальном графике на достройку «Титаника». Такое изменение охвата очень легко проглядеть или проигнорировать — особенно в ретроспективе, поскольку физические результаты и первоначальные даты внешне не претерпели кардинальных изменений. Тем не менее фактически «Титаник» был построен значительно быстрее, чем изначально планировалось.

В современной инженерии программного обеспечения общепризнано, что никто не способен оценить время выполнения проектной задачи лучше, чем сам инженер (или инженеры), который будет её выполнять. Также принято считать, что никакое управленческое давление не позволяет существенно ускорить инженерные и проектные работы. Когда проект движется с максимальной скоростью, он не пойдёт быстрее. Попытки ускорить его нередко приводят к ошибкам, упущениям и промахам. Мы знаем, что это справедливо для программного обеспечения, и можно предположить, что то же самое было верно для судостроения — принципы одинаковы. Если бы «Титанику» было отведено надлежащее время, вполне возможно, меры безопасности были бы более тщательно проработаны или по меньшей мере надлежащим образом переданы операционной команде при передаче проекта. Команды под давлением вынуждены идти на компромиссы, а поскольку время является ограничивающим фактором, “срезать углы” приходится в чём-то другом — почти всегда за счёт качества и тщательности. Это может проявляться как в виде ошибки, так и в виде неполного учёта всех факторов при изменении одного из элементов конструкции.

Это подводит нас к холистическому проектному мышлению. В начале проекта The Olympics создавались с учётом безопасности: такой, которая обеспечивается тщательным взаимодействием множества отдельных систем, призванных в совокупности обеспечить высокую надёжность корабля. Мы не можем рассматривать компоненты корабля такого масштаба по отдельности — они теряют смысл: конструкция корпуса, форма палуб, вес груза, используемые материалы, конструкция переборок — всё это взаимосвязано и должно работать вместе.

Когда проект был вынужден двигаться быстрее или менять параметры, это холистическое мышление и чёткий пересмотр ранее принятых решений не применялись или применялись в недостаточной мере. Вместо этого отдельные компоненты изменялись без учёта их роли внутри корабля в целом и влияния на общую безопасность. То, что казалось незначительным изменением, повлекло непредвиденные последствия — именно потому, что от холистического управления проектом отказались. (Kozak-Holland)

Это изменение в инженерии нашло отражение, конечно же, и в эксплуатации. Каждое отдельное изменение — например, отказ от биноклей или отсутствие измерений температуры воды вблизи льда — было само по себе относительно незначительным, но в совокупности они имели колоссальные последствия. По всей видимости (хотя мы не можем утверждать это с уверенностью), целостная система управления проектами или хотя бы совершенствования процессов не применялась. Кто контролировал использование биноклей, достоверность измерений воды и т.д.? Любая проверка выявила бы, что необходимые инструменты для выполнения этих задач попросту отсутствовали. Невозможно провести даже простейший прогон процедур, не говоря уже о регулярных проверках и совершенствовании процессов. Необходимость совершенствования процессов особенно наглядно подчёркивается тем фактом, что капитан Смит уже имел опыт управления RMS Olympic, спровоцировал столкновение в море во время её пятого рейса и едва не повторил ту же ошибку при первом выходе «Титаника». То, что должно было стать важным уроком для всех капитанов и лоцманов кораблей класса Olympic, было проигнорировано и немедленно повторилось. (“Olympic”)

Разумеется, судостроение и разработка программного обеспечения — совершенно разные вещи, однако между ними можно провести множество поучительных параллелей. Один из важнейших уроков — увидеть ограничения, с которыми сталкивалось судостроение, и понять, когда мы не обязаны сохранять эти же ограничения при работе с программным обеспечением. «Олимпик» и «Титаник» строились почти одновременно, так что инженерные знания, накопленные в ходе строительства «Олимпика», практически не успели быть применены к строительству «Титаника» — ни тем более из опыта её эксплуатации. В современном программном обеспечении мы никогда не ожидали бы подобного ограничения и могли бы хоть в какой-то мере тестировать ПО до того, как переходить к дальнейшему — будь то в реальном коде или хотя бы концептуально. Сегодняшнее управление проектами должно по максимуму использовать различия, существующие как в силу более современной эпохи, так и в силу специфики нашей отрасли. Некоторые программные проекты по-прежнему требуют подобных процессов, но они становятся всё более редкими и сегодня встречаются значительно реже, чем двадцать лет назад.

Безусловно, стоит оценить работу Harland-Wolff над The Olympics: они очевидно стремились внедрить все возможные в то время петли обратной связи. Они не только пытались использовать опыт строительства более ранних кораблей для последующих — хотя это было весьма ограничено, поскольку суда строились в основном параллельно и большинство уроков просто не успевали быть применены, — но, что гораздо важнее, сделали экстраординарный шаг: отправили в плавание с кораблями “группу гарантийного обслуживания”. В неё входили ученики и мастера-судостроители самых разных специальностей. (“Guarantee Group”)

Использование гарантийной группы для прямой обратной связи было и по сей день остаётся беспрецедентным — это были огромные инвестиции в живой труд и время: судостроители пожертвовали многими ценными работниками, отправив их в роскошные круизы через Атлантику. Группа имела возможность осмотреть свою работу непосредственно, увидеть её в действии, понять, как она используется в контексте действующего корабля, обменяться знаниями внутри команды и многое другое. Это было несравнимо ценнее, чем обратная связь с корабельных верфей, где суда строились параллельно; это было серьёзным вложением в будущее их судостроительного предприятия — обязательством перед производственным образованием, которое, вероятно, приносило бы плоды на протяжении десятилетий.

Современные стили, инструменты и культура развёртывания привели к тому, что от преобладающей каскадной методологии разработки программного обеспечения — не слишком отличавшейся от той, что применялась в судостроении на рубеже [прошлого] века — большинство перешло к различным степеням гибких (Agile) методологий, допускающих быстрое тестирование, оценку, внесение изменений и развёртывание. Расширение охвата перестало быть тем, что нужно лишь минимизировать или жёстко контролировать, и превратилось в нечто ожидаемое и предполагаемое в процессе разработки — вплоть до того, что им можно управлять. Одна из фундаментальных проблем масштабного проектирования на старте состоит в том, что оно всегда требует от заказчика или стейкхолдера в роли заказчика “принимать масштабные решения заранее”, а это нередко значительно труднее для них, чем само проектирование для инженеров. Именно эти ранние решения зачастую являются основным источником расширения охвата или поздних запросов на изменения, и их можно сократить или избежать с помощью гибких процессов, которые изначально предполагают непрерывное изменение требований и встраивают его в процесс.

Судостроители, Harland and Wolff, действительно создали полутораметровую модель «Олимпика» для тестирования, что в определённой мере было полезно, однако не воспроизводило гидродинамическое воздействие, которое впоследствии производило судно полного размера, и не позволило предсказать ряд более опасных побочных эффектов нового размера корабля при его сближении с другими судами — что и стало причиной первой аварии в группе и едва не привело ко второй. Строители, судя по всему, прилагали все усилия для тестирования и извлечения уроков на каждом доступном им этапе проектирования и строительства. (Kozak-Holland)

В сравнении с современным управлением проектами это сопоставимо с созданием быстрого макета или вайрфрейма для разработчиков или даже заказчиков, чтобы получить практический опыт взаимодействия с продуктом до того, как вкладывать дальнейшие усилия в то, что может оказаться тупиком по непредвиденным причинам. Это особенно важно при проектировании пользовательских интерфейсов, где зачастую практически невозможно корректно предсказать удобство использования или уровень удовлетворённости, не предоставив реальным пользователям возможности физически взаимодействовать с системой и самостоятельно оценить, обеспечивает ли она ожидаемый опыт. (Esposito)

Разумеется, необходимо рассмотреть риски, которые несли The Olympics, в контексте их исторического положения относительно финансовых тенденций и сил того времени. В то время, начиная с середины предыдущего века, господствующее финансовое мышление склонялось скорее к рискованному, нежели к безопасному поведению — с точки зрения потерь жизней, грузов или кораблей, — и разрыв предполагалось покрывать с помощью страховых инструментов. Кораблям было попросту финансово выгоднее работать в условиях повышенного риска, нежели проявлять чрезмерную осторожность ради человеческих жизней. К моменту строительства The Olympics эта тенденция успела укорениться почти на шестьдесят лет и не начала меняться вплоть до масштабной огласки гибели «Титаника». Рыночное воздействие на общественное мнение не возникло до тех пор, пока “непотопляемый” корабль с таким огромным числом людей на борту не был потерян столь впечатляющим образом.

Этот подход к риску и его финансовым компромиссам — то, что менеджеры проектов должны понимать сегодня в той же мере, что и сто лет назад. Легко поддаться убеждению, что риск настолько важен, что его устранение оправдывает любые затраты, однако проекты не могут мыслить подобным образом. На снижение рисков можно тратить неограниченные ресурсы. В реальном мире необходимо соотносить риски со стоимостью мер по их снижению. Прекрасным примером из наших дней, пусть и за пределами разработки программного обеспечения, служит подход к мошенничеству с кредитными картами в США. Ещё несколько лет назад американская индустрия кредитных карт в целом придерживалась мнения, что стоимость более строгих мер защиты для предотвращения кражи данных слишком высока по сравнению с рисками их отсутствия; иными словами, компенсировать мошеннические транзакции было экономически выгоднее, чем их предотвращать. Это соотношение цены и риска порой бывает контринтуитивным и даже обескураживающим, однако именно оно должно лежать в основе проектных решений — логически и расчётно.

В схожем ключе в ИТ нередко встречается проектирование систем с расчётом на то, что простой несёт практически безграничные издержки, и компании тратят на снижение риска простоя несравнимо больше, чем составляли бы реальные потери от самого инцидента. Это очевидно неразумно, однако подобный анализ затрат так редко проводится или проводится корректно, что поддаться этому менталитету очень легко. В проектах по разработке программного обеспечения следует придерживаться аналогичного подхода к рискам. Признание наличия риска любого рода, определение его реальной вероятности, масштаба последствий и сопоставление этого со стоимостью стратегий снижения — критически важно для принятия обоснованных решений в рамках управления проектом. (Brander 1995)

Отдельного внимания в контексте крупных проектов — а The Olympics, безусловно, были таковыми — заслуживает концепция “слишком большой, чтобы рухнуть”. Это, конечно, современное выражение, появившееся в период финансового кризиса прошлого десятилетия, однако сама концепция и её реальность значительно старше и является ценным соображением для любого проекта, который по своему масштабу мог бы квалифицироваться как “национальная финансовая катастрофа” в случае полного провала. В случае The Olympics британское правительство в конечном счёте защитило инвесторов от полного краха, поскольку крушение одной из крупнейших пассажирских судоходных компаний было бы катастрофой для страны.

White Star Lines была просто “слишком большой, чтобы рухнуть” и была поддержана на плаву — в буквальном смысле — государством, прежде чем несколько лет спустя её принудительно объединили с Cunard. Принималась ли эта концепция в расчёт или рассматривалась в то время — неизвестно. Однако мы знаем, что сегодня это учитывается при реализации очень крупных проектов. Наглядный пример — истребитель F-35 компании Lockheed Martin, который значительно превысил бюджет, отстаёт от графика поставок и более не считается вероятно полезным, однако на протяжении многих лет поддерживается различными государственными спонсорами, которые видят в нём проект, слишком важный для национальной экономики, чтобы позволить ему полностью свернуться — даже в условиях неспособности выполнить взятые обязательства. По мере того как это явление становится всё более известным, вероятно, всё больше проектов будет учитывать его в своих фазах анализа рисков. (Ellis)

Обратившись к операционной стороне, можно рассмотреть любое число аспектов, которые привели к гибели «Титаника», однако, по моему убеждению, наиболее очевидным была нехватка стандартных операционных процедур на протяжении всего процесса. Это в определённой мере объяснимо, поскольку корабль находился на своём первом рейсе и времени на документирование и совершенствование процессов практически не было. Однако речь шла о флагмане судоходной компании с многолетней историей и репутацией, которую нужно было поддерживать, и с большим опытом в подобных делах. Кроме того, это упускало бы из виду тот факт, что к моменту первого рейса «Титаника» «Олимпик» уже находился в эксплуатации более чем достаточно, чтобы разработать удовлетворительный набор стандартных операционных процедур.

Базовая документация ожидалась бы даже на первом рейсе: неразумно рассчитывать, что корабль такого масштаба вообще способен функционировать без координации и взаимодействия между экипажем. Были годы — буквально годы — для создания и подготовки базовых операционных процедур для экипажа до отхода первого судна; конечно, это требовалось бы для всех кораблей подобного рода. Однако очевидно, что такие операционные процедуры в случае «Титаника» были недостаточными, отсутствовали и не были проверены.

Ответственной за разработку операционных процедур, по всей видимости, должна была быть операционная сторона проекта, однако определённая часть такой документации должна была быть предоставлена или согласована с инженерно-строительными командами. Многие процедуры, которые дали сбой на «Титанике», включали сбои в командной вертикали под давлением: директор компании взял управление на себя, а капитан позволил это; операторов беспроводной связи инструктировали отдавать приоритет передаче пассажирских сообщений перед предупреждениями о ледяных полях; операторы разрешали другим судам, пытавшимся предупредить их, прекратить передачу; критически важные сообщения не доставлялись на мостик; инструменты для выполнения критически важных задач не были предоставлены и т.д. (Kuntz)

Так же, как в случае с инженерным проектированием кораблей, их эксплуатация нуждалась в сильном холистическом руководстве, обеспечивающем работу корабля и экипажа как единого целого, а не рассмотрение отдельных департаментов — например, операторов беспроводной связи Marconi — в качестве самостоятельных подразделений. В данном примере операторы не были официальными членами экипажа корабля, а являлись сотрудниками Marconi, находившимися на борту для обслуживания платных пассажирских переговоров, и лишь при наличии времени — аварийных судовых переговоров. Будь они включены в систему холистического операционного управления — даже как внешние подрядчики, — их процедуры, вероятно, имели бы значительно более выраженный акцент на безопасности или, как минимум, соглашения об уровне обслуживания по доставке сообщений на мостик были бы чётко определены, а не носили бы ситуативный и дискреционный характер.

В любом проекте и его компонентах надлежащая документация — будь то проектные цели, результаты, процедуры и т.д. — критически важна; управление проектами едва ли имеет шансы на успех без качественных коммуникаций и документации, лежащих в основе всего, что мы делаем, — как внутри проекта, так и во взаимодействии с заинтересованными сторонами.

В итоге мы обнаруживаем, что уроки управления проектом «Олимпик», «Титаник» и «Британик» сохраняют свою ценность по сей день. В контексте той эпохи — будь то стремление к итеративному проектированию там, где это возможно, инвестиции в командные знания, расчёт рисков, понимание ролей системной инженерии и системной эксплуатации или взаимодействие внешних защитных сил с затратами на продукт — все эти уроки по-прежнему актуальны. Факторы, влияющие на проекты, приходят и уходят циклично; сегодня мы наблюдаем тенденции, скорее напоминающие модели The Olympics, нежели противоположные им. В будущем маятник, вероятно, качнётся в другую сторону. Основополагающие уроки весьма актуальны и будут оставаться таковыми. Можно многому научиться как анализируя, в чём наши собственные проекты схожи с проектами 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.

Дополнительные примечания:

Марк Козак-Холланд первоначально опубликовал свою книгу в 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.