Gerenciamento de Projetos do Titanic e Comparação com Projetos de Software

Poucos projetos alcançaram a fama e a notoriedade obtidas pelo Titanic e seus navios irmãos da classe Olympic, o Olympic e o Britannic, cujo projeto começou há cento e dez anos neste ano. Existem, é claro, muitas lições que podemos aprender com o destino dos navios da classe Olympic no que diz respeito ao gerenciamento de projetos e, de fato, há muitos aspectos do gerenciamento de projetos que vale a pena abordar.

(Ao me referir aos navios como um todo, vou simplesmente chamá-los de Os Olympic, já que os três juntos eram os navios da classe Olympic da White Star Line. A fama individual e posterior do Titanic é irrelevante aqui. Além disso, parto aqui do princípio de que as informações gerais relativas aos navios da classe Olympic, sua história e seu destino são de conhecimento comum do leitor e não as abordarei novamente.)

Dada a frequência com que o gerenciamento de projetos dos navios da classe Olympic já foi abordado, acho mais prudente examinar alguns paralelos modernos em que podemos ver o gerenciamento de projetos atual no mundo de hoje através de uma valiosa lente histórica. É bem verdade que o gerenciamento de projetos é uma disciplina que perdura há milênios, e muitos dos desafios, habilidades e técnicas não mudaram tanto, e as armadilhas do passado ainda se aplicam muito a nós hoje. Vale o velho ditado: se não aprendemos com o passado, estamos condenados a repeti-lo.

Meu objetivo aqui, então, é examinar a análise de risco, a percepção e o perfil do projeto e aplicar isso ao gerenciamento de projetos moderno.

Primeiro, devemos identificar as partes interessadas no projeto dos navios da classe Olympic. A própria White Star Line (empresa patrocinadora e principal investidora) e seu diretor Joseph Bruce Ismay, a Harland-Wolff (construtora naval contratada) com seus principais projetistas Alexander Carlisle e Thomas Andrews, a tripulação dos navios, que inclui o capitão Edward John Smith, o governo britânico, como veremos mais adiante, e, o mais importante, os passageiros.

Como em qualquer grupo de partes interessadas, há diferentes papéis que são desempenhados. A White Star, de um lado, é a patrocinadora e investidora e, em um projeto de software moderno, seria análoga a um cliente patrocinador, gerente ou departamento. A Harland-Wolff eram os projetistas e construtores e estavam mais intimamente relacionados aos “membros da equipe” de engenharia de software em uma equipe de software moderna, os próprios desenvolvedores. A tripulação dos navios era responsável pelas operações após a conclusão do projeto e seria comparável a uma equipe de operações de TI que assume a execução do software final após sua conclusão. Os passageiros eram muito parecidos com os usuários finais de hoje, esperando se beneficiar tanto do produto de engenharia entregue (navio ou software) quanto do serviço construído sobre esse produto (serviço de travessia ou serviços gerenciados de TI). (“Olympic”)

Outro eixo de análise do projeto é o das partes interessadas “galinhas e porcos”, em que as galinhas estão envolvidas e carregam risco, enquanto os porcos estão totalmente comprometidos e carregam o risco final. No software comum, usamos essas comparações para falar sobre graus das partes interessadas – aquelas que estão envolvidas versus aquelas que estão comprometidas, mas, no caso dos navios da classe Olympic, esses termos assumem um significado novo e horrível, já que a tripulação e os passageiros literalmente colocaram suas vidas em risco na fase operacional dos navios, ao passo que os investidores e construtores estavam apenas financeiramente em risco. (Schwaber)

Segundo, acredito que seja útil distinguir entre os diferentes projetos que existem dentro do contexto dos navios da classe Olympic. Havia, é claro, o projeto e a construção física dos três navios. Esse é um único projeto, com dois componentes claros – um de projeto e um de construção. E três entregas distintas, a saber, as três embarcações da classe Olympic. Há, ao final da fase de construção, um ponto de delimitação extremamente claro em que os gerentes de projeto e as equipes envolvidas na montagem do navio parariam o trabalho e a tripulação que operava o navio assumiria.

Aqui já podemos traçar um importante paralelo com o mundo moderno da tecnologia, em que produtos de software são projetados e desenvolvidos por engenheiros de software e, quando estão concluídos, são entregues à equipe operacional de TI, que assume o uso pretendido do produto final. Essas duas equipes podem ser internas, sob um único guarda-chuva organizacional, ou provenientes de duas ou mais organizações bem distintas. Mas a separação entre os departamentos de engenharia e os de operações permaneceu tão clara e distinta na maioria das empresas hoje quanto era para a construção naval e o serviço de travessia há mais de um século.

Podemos ir um passo além e comparar o serviço transatlântico de travessia da White Star a muitos fornecedores modernos de software como serviço, como o Microsoft Office 365, o Salesforce ou o G Suite. Nesses casos, a empresa em questão tem uma equipe de engenharia ou de desenvolvimento de produto que cria o produto central e, em seguida, uma segunda equipe que pega esse produto interno e o opera como um serviço. Esse é cada vez mais um importante modelo de negócios no espaço de desenvolvimento de software, em que a mesma empresa que cria o software será a operadora final dele, mas para clientes externos. De muitas maneiras, a relevância dos navios da classe Olympic para o software e a TI modernos está aumentando, e não diminuindo.

Isso traz à tona uma importante compreensão de interface que foi negligenciada nos navios da classe Olympic e que frequentemente é negligenciada hoje: cada lado da transferência acreditava que o outro lado era, em última instância, o responsável pela segurança. Os engenheiros propagandeavam a segurança de seu projeto, mas, quando pressionados, estavam dispostos a fazer concessões, presumindo que os procedimentos operacionais mitigariam os riscos e que seus próprios esforços eram em grande parte redundantes. Da mesma forma, quando pressionada a manter as coisas em andamento e a fazer bom tempo, a equipe de operações estava disposta a fazer concessões nos procedimentos porque acreditava que a equipe de engenharia tinha ido tão longe que tornava seus esforços essencialmente desnecessários, sendo o navio tão seguro que precauções operacionais simplesmente não se justificavam. Essa falha de comunicação levou o empreendimento de ter dois tipos de sistemas de extrema segurança a basicamente nenhum. Se qualquer um dos lados tivesse compreendido como o outro operaria ou de fato operava, poderiam ter levado isso em conta. No fim, ambos os lados presumiram, ao menos em certa medida, que a segurança era “trabalho da outra equipe”. Embora o navio tenha sido fortemente anunciado com base na segurança, a realidade era que ele dava continuidade à tendência geral de mais de meio século, em que a cada ano os navios eram fabricados e operados de forma menos segura do que no ano anterior. (Brander 1995)

Hoje vemos esse mesmo problema surgir entre a TI e a engenharia de software – menos em torno da estabilidade (embora isso certamente permaneça verdadeiro), mas agora em torno da segurança, que pode ser vista de forma semelhante à segurança física no contexto dos navios da classe Olympic. A segurança tornou-se um dos temas mais importantes da última década em ambos os lados da cerca tecnológica, e o setor enfrenta os desafios criados pela necessidade de ambos os lados colocarem práticas de segurança em ação de forma completa – nenhum deles é capaz de implementar verdadeiramente sistemas seguros sozinho. Planejar a segurança simplesmente não substitui aplicá-la de forma procedimental durante as operações.

Uma excelente comparação hoje é a British Airways e a forma como ela aborda cada voo que supervisiona ao cruzar o Atlântico. Como a principal transportadora de tráfego aéreo sobre o Atlântico Norte, a mesma rota que os navios da classe Olympic pretendiam percorrer, a British Airways precisa manter uma reputação de excelência em segurança. Mesmo em 2017, voar sobre o Atlântico Norte é uma jornada precária e complicada.

Antes de qualquer voo da British Airways decolar, os pilotos e a tripulação devem revisar um manual de missão de trezentas páginas que lhes informa tudo o que está acontecendo, incluindo detalhes sobre o avião, a tripulação, o clima e assim por diante. Esse processo é tão intenso que a British Airways se recusa até a reconhecer que se trata de um voo, mas oficialmente se refere a cada viagem sobre o Atlântico como uma “missão”; especificamente para deixar claro a todos os envolvidos a gravidade e o risco envolvidos em tal empreendimento. Eles claramente compreendem a importância de mudar a forma como as pessoas pensam sobre uma viagem como esta e estão cientes do que pode acontecer caso as pessoas comecem a presumir que todos os outros terão feito bem o seu trabalho e que elas podem cortar caminho no seu próprio trabalho. Eles não querem que ninguém se torne descuidado ou comece a sentir que o voo, mesmo realizado várias vezes por dia, seja em algum momento rotineiro. (Winchester)

Se a abordagem da British Airways tivesse sido usada com o Titanic, é muito provável que o desastre não tivesse ocorrido quando ocorreu. O lado operacional, por si só, poderia ter evitado o desastre. Da mesma forma, se os engenheiros do navio tivessem sido submetidos aos mesmos padrões que a Boeing ou a AirBus hoje, eles provavelmente não teriam sido tão facilmente pressionados pela gestão a modificar os requisitos de segurança enquanto trabalhavam no projeto.

O que realmente afetou os navios da classe Olympic, de muitas maneiras, foi uma forma de ampliação de escopo descontrolada. O projeto começou como uma abordagem cascata tradicional, com “grande projeto antecipado”, e os requisitos iniciais eram bons, com a segurança desempenhando um papel fundamental. Se os requisitos originais do projeto e mesmo grande parte do projeto original tivessem sido usados, os navios teriam sido muito mais seguros do que foram. Mas novos requisitos para salas de jantar maiores ou acabamentos mais luxuosos tiveram precedência, e o escopo e os parâmetros do projeto foram alterados para acomodar essas novas mudanças. Como em qualquer projeto, nenhuma mudança acontece no vácuo, mas terá ramificações para outros fatores, como custo, segurança ou data de entrega. (Sadur)

A ampliação de escopo no Titanic especificamente foi dramática, mas oculta e não necessariamente óbvia na maior parte. É fácil apontar pequenas mudanças, como uma alteração no tamanho da sala de jantar, mas de importância muito maior foi a mudança no prazo em que o navio tinha de ser entregue. O que realmente alterou o escopo foi, na verdade, o fato de os prazos e cronogramas iniciais terem de ser mantidos, de forma relativamente rígida. Isso foi especificamente problemático porque, em meio ao trabalho do Titanic em dique seco e, posteriormente, atracado, o irmão mais velho, o Olympic, foi trazido para reparos extensos em várias ocasiões, o que teve um impacto muito grande na quantidade de tempo disponível no cronograma original para a conclusão do próprio trabalho do Titanic. Esse tipo de modificação de escopo é muito fácil de ignorar ou desconsiderar, especialmente em retrospecto, já que as entregas físicas e as datas originais não mudaram de forma dramática. Para todos os efeitos, no entanto, o Titanic foi apressado pela produção muito mais rapidamente do que havia sido originalmente planejado.

Na engenharia de software moderna, é amplamente aceito que ninguém consegue estimar a quantidade de tempo que uma tarefa de projeto levará tão bem quanto o(s) próprio(s) engenheiro(s) que executará(ão) a tarefa. Também é geralmente aceito que não há meio de acelerar significativamente os esforços de engenharia e projeto por meio de pressão da gestão. Uma vez que um projeto esteja funcionando na velocidade máxima, ele não vai mais rápido. Tentativas de ir mais rápido frequentemente levam a erros, descuidos ou falhas. Sabemos que isso é verdade em software e podemos presumir que deve ter sido verdade também para o projeto de navios, já que os princípios são os mesmos. Se o Titanic tivesse recebido a quantidade apropriada de tempo para esse processo, é possível que as medidas de segurança tivessem sido consideradas de forma mais completa ou, ao menos, comunicadas adequadamente à equipe operacional no momento da transferência. Equipes que são apressadas são forçadas a fazer concessões e, como o tempo não pode ser ajustado, por ser ele a restrição, os cortes têm de ser feitos em outro lugar e, quase sempre, isso vem da qualidade e da minúcia. Isso pode se manifestar como um erro ou talvez como a falha em revisar plenamente todos os fatores envolvidos ao alterar uma parte de um projeto.

Isso nos leva ao pensamento de projeto holístico. No início do projeto, os navios da classe Olympic foram projetados com a segurança em mente: uma segurança que resulta da cuidadosa interação de muitos sistemas separados que, juntos, têm como objetivo formar um navio altamente confiável. Não podemos olhar para os componentes de um navio dessa magnitude individualmente, eles não fazem sentido – o projeto do casco, o estilo dos conveses, o peso da carga, os materiais utilizados, o estilo das anteparas estão todos inter-relacionados e devem funcionar em conjunto.

Quando o projeto foi pressionado a ser concluído mais rapidamente ou a mudar parâmetros, esse pensamento holístico e uma clara reavaliação das decisões anteriores não foram feitos ou não foram feitos adequadamente. Em vez disso, componentes individuais foram alterados sem levar em conta como isso impactaria seu papel dentro do todo do navio e o consequente impacto sobre a segurança geral. O que pode ter parecido uma mudança menor teve consequências não intencionais que não foram previstas porque o gerenciamento de projetos holístico foi abandonado. (Kozak-Holland)

Essa mudança na engenharia se refletiu, é claro, nas operações. Cada mudança, como não usar binóculos ou não fazer leituras com o balde de gelo, era individualmente um tanto menor, mas, tomadas em conjunto, foram incrivelmente impactantes. Provavelmente, mas não podemos ter certeza, um sistema coeso de gerenciamento de projetos ou, ao menos, de melhoria de processos não estava sendo usado. Quem estava supervisionando se os binóculos eram usados, se os testes de água eram precisos e assim por diante? Qualquer verificação que fosse teria revelado que as ferramentas necessárias para essas tarefas não existiam, de forma alguma. Não há como sequer uma simples execução de teste dos procedimentos pudesse ter sido realizada, quanto mais uma verificação regular e melhoria de processos. A melhoria de processos é especialmente destacada pelo fato de que o capitão Smith já tinha tido prática no RMS Olympic, causou uma colisão no mar em sua quinta viagem e, então, quase repetiu o mesmo erro no lançamento inicial do Titanic. O que deveria ter sido uma importante lição aprendida por todos os capitães e pilotos dos navios da classe Olympic, em vez disso, foi ignorado e repetido, quase imediatamente. (“Olympic”)

É claro que a construção naval e o software são coisas muito diferentes, mas muitas lições podem ser compartilhadas. Uma das lições mais importantes é enxergar as limitações enfrentadas pela construção naval e reconhecer quando não somos forçados a manter essas mesmas limitações ao trabalhar com software. O Olympic e o Titanic foram construídos quase ao mesmo tempo, sem absolutamente nenhum tempo para que o conhecimento de engenharia colhido da construção do Olympic, sem falar de sua operação, pudesse ser aplicado à construção do Titanic. No software moderno, nunca esperaríamos tal restrição e seríamos capazes de testar o software, ao menos em alguma pequena medida, antes de passar para software adicional que se baseia nele, seja em código real, seja mesmo conceitualmente. O gerenciamento de projetos hoje precisa aproveitar as diferenças que existem tanto em tempos mais modernos quanto em nosso setor distinto, da melhor forma possível, em seu favor. Alguns projetos de software ainda exigem processos como esse, mas estes se tornaram cada vez mais raros ao longo do tempo e, hoje, são dramaticamente menos comuns do que eram há apenas vinte anos.

Vale muito a pena avaliar o trabalho que foi feito pela Harland-Wolff com os navios da classe Olympic, já que eles se esforçaram, de forma muito evidente, para incorporar quaisquer ciclos de feedback que fossem possíveis dentro de seu alcance na época. Não apenas eles tentaram usar a construção de navios anteriores para aprender mais para os posteriores, embora isso tenha sido muito limitado, já que os navios estavam, em sua maior parte, em construção simultaneamente e a maioria das lições não teria tido tempo de ser aplicada, mas, muito mais importante, eles deram o passo extraordinário de fazer com que um “grupo de garantia” navegasse com os navios. Esse grupo de garantia consistia em todo tipo de aprendiz e mestre construtor naval de todo tipo de ofício de apoio. (“Guarantee Group”)

O uso do grupo de garantia para feedback direto foi, e verdadeiramente continua sendo, sem precedentes e representou um enorme investimento em custo direto e tempo para os construtores navais, que sacrificaram tantos trabalhadores valiosos para navegar com luxo de um lado para o outro do Atlântico. O grupo pôde inspecionar seu trabalho em primeira mão, vê-lo em ação, obter uma compreensão de seu uso dentro do contexto do navio em operação, trabalhar em conjunto na formação de equipe, na transferência de conhecimento e muito mais. Isso foi muito mais valioso do que o feedback dos estaleiros, onde os navios se sobrepunham na construção; isso foi um forte investimento no futuro de seu empreendimento de construção naval: um compromisso com a educação industrial que provavelmente os teria beneficiado por décadas.

Os estilos, ferramentas e a educação de implantação modernos levaram da grande maioria do software sendo criado sob uma metodologia cascata não tão distinta da utilizada na construção naval da virada do século [passado], para a maior parte aproveitando algum grau de metodologias ágeis, permitindo testes, avaliações, mudanças e implantações rápidas. A ampliação de escopo deixou de ser algo que precisa ser mitigado ou fortemente gerenciado para se tornar algo que pode ser tratado como esperado e presumido dentro do processo de desenvolvimento, a ponto de quase ser aproveitado. Um dos problemas fundamentais do grande projeto antecipado é que ele sempre exige que o cliente ou a parte interessada no papel de cliente tome “grandes decisões antecipadas”, que muitas vezes são muito mais difíceis para eles tomarem do que o projeto é para os engenheiros. Essas decisões iniciais são frequentemente um contribuinte primário para a ampliação de escopo ou para solicitações de mudança posteriores e podem muitas vezes ser reduzidas ou evitadas por processos ágeis que esperam que ocorram mudanças contínuas nos requisitos e incorporam isso ao processo.

Os construtores navais, a Harland e Wolff, de fato construíram um modelo de quatro metros e meio do Olympic para testes, o que é útil em certa medida, mas, é claro, deixou de imitar a ação hidrológica que o navio em tamanho real produziria mais tarde e deixou de prever alguns dos efeitos colaterais mais perigosos do tamanho da nova embarcação quando próxima de outros navios, o que levou ao primeiro acidente do grupo e ao que quase foi um segundo. Os construtores parecem ter feito todo o esforço para testar e aprender em cada etapa disponível para eles ao longo do processo de projeto e construção. (Kozak-Holland)

Em comparação com o gerenciamento de projetos moderno, isso seria comparável a produzir um protótipo rápido ou um wireframe para que os desenvolvedores ou mesmo os clientes tenham experiência prática antes de investir mais esforço no que pode ser um caminho sem saída por razões imprevistas. Isso é especialmente importante no design de interface de usuário, em que muitas vezes há pouca capacidade de prever adequadamente a usabilidade ou os índices de satisfação sem proporcionar uma chance de os usuários reais manipularem fisicamente o sistema e julgarem por si mesmos se ele oferece a experiência que estão buscando. (Esposito)

Devemos, é claro, considerar o risco que os navios da classe Olympic assumiram dentro do contexto de sua justaposição histórica no que diz respeito às tendências e forças financeiras. Na época, a partir de meados do século anterior, o pensamento financeiro predominante era de que o melhor era inclinar-se para o arriscado, em vez de para o seguro – em termos de perda de vidas, de carga ou de navios; e superar a diferença por meio de instrumentos de seguro. Era simplesmente vantajoso demais do ponto de vista financeiro que os navios operassem de maneira arriscada do que serem excessivamente cautelosos com a vida humana. Essa tendência, à época dos navios da classe Olympic, estava bem estabelecida havia quase sessenta anos e não começaria a mudar até a forte publicidade do naufrágio do Titanic. O impacto de mercado sobre o público não existiu até que o navio “inafundável”, com tantas almas a bordo, fosse perdido de forma tão espetacular.

Essa abordagem ao risco e suas compensações financeiras é uma que os gerentes de projeto precisam compreender hoje da mesma forma que compreendiam há mais de cem anos. É fácil cair na crença de que o risco é tão importante que vale qualquer custo eliminá-lo, mas os projetos não podem pensar dessa forma. É possível gastar recursos ilimitados na busca da redução de risco. No mundo real, é necessário que equilibremos os riscos com o custo da mitigação de riscos. Um ótimo exemplo disso nos tempos modernos, mas fora do desenvolvimento de software especificamente, está no tratamento da fraude com cartões de crédito nos Estados Unidos. Até apenas os últimos anos, foi geralmente a opinião do setor de cartões de crédito dos EUA que o custo de maiores medidas de segurança nos cartões de crédito para evitar roubo era alto demais em comparação com os riscos de não tê-las; essencialmente, foi mais econômico gastar dinheiro reembolsando transações falsas do que prevenir essas transações falsas. Essa relação custo-risco pode às vezes ser contraintuitiva e até frustrante, mas é uma que tem de orientar as decisões de projeto de maneira lógica e calculada.

De forma semelhante, é comum em TI projetar sistemas acreditando que o tempo de inatividade é um custo essencialmente ilimitado e gastar muito mais tentando mitigar um risco de tempo de inatividade do que provavelmente seria o custo do próprio evento de interrupção, caso ele viesse a ocorrer. Isso é obviamente tolo, mas tão raramente análises de custo desse tipo são feitas, ou feitas corretamente, que se torna fácil demais cair vítima dessa mentalidade. Em projetos de engenharia de software, devemos abordar os riscos de forma semelhante. Aceitar que há risco, de qualquer tipo, e determinar o risco real, a magnitude do impacto desse risco e compará-la com o custo das estratégias de mitigação é fundamental para tomar uma decisão apropriada de gerenciamento de projetos no que diz respeito ao risco. (Brander 1995)

Também de particular interesse para projetos extremamente grandes, dos quais os navios da classe Olympic certamente se qualificavam, há um conceito adicional de ser “grande demais para falir”. Esta, é claro, é uma expressão moderna que surgiu durante a crise financeira da última década, mas o conceito e a realidade disso são muito mais antigos e uma valiosa consideração para qualquer projeto que se enquadre em uma escala que registraria um “desastre financeiro nacional” caso o projeto fracassasse totalmente. No caso dos navios da classe Olympic, o governo britânico, em última análise, protegeu os investidores de um desastre total, já que o colapso de uma das maiores linhas de passageiros teria sido devastador para o país na época.

A White Star Line era simplesmente “grande demais para falir” e foi mantida à tona, por assim dizer, pelo governo, antes de ser forçosamente fundida à Cunard alguns anos depois. Esse conceito, saber que o governo não iria querer aceitar os riscos do fracasso da empresa, pode ter sido calculado ou considerado na época, não sabemos. Sabemos, no entanto, que isso é levado em consideração hoje em projetos muito grandes. Um exemplo disso acontecendo atualmente é o do caça F-35 da Lockheed Martin, que está dramaticamente acima do orçamento, atrasado em relação à sua data de entrega e nem sequer mais considerado provavelmente útil, e que foi sustentado por anos por diferentes patrocinadores governamentais que veem o projeto como importante demais, mesmo em um estado de incapacidade de entrega, para a economia nacional permitir que o projeto entre em colapso total. À medida que esse fenômeno se torna cada vez mais conhecido, é provável que vejamos mais projetos levarem isso em consideração em suas fases de análise de risco. (Ellis)

Passando para o lado operacional da equação, poderíamos examinar uma série de aspectos que deram errado e levaram ao naufrágio do Titanic, mas, no cerne, acredito que o que ficou mais evidente foi a falta de procedimentos operacionais padrão ao longo de todo o processo. Isso é compreensível em certa medida, já que o navio estava em sua viagem inaugural e havia pouco tempo para a documentação e a melhoria de processos. No entanto, este era o navio principal de uma linha de navegação de longa data que tinha uma reputação a manter e uma grande quantidade de experiência nesses assuntos. Também ignoraria o fato de que, no momento em que o Titanic tentava sua primeira viagem, o Olympic já estava em serviço por muito mais do que tempo suficiente para ter desenvolvido um conjunto satisfatório de procedimentos operacionais padrão.

Documentação de base teria sido esperada mesmo em uma viagem inaugural; é irrazoável esperar que um navio de tal escala funcione de alguma forma a menos que haja coordenação e comunicação entre a tripulação. Houve tempo de sobra, anos, na verdade, para que procedimentos operacionais básicos da tripulação fossem criados e preparados antes de o primeiro navio zarpar e, é claro, isso teria de ser feito para todos os navios dessa natureza, mas era evidente que tais procedimentos operacionais estavam ausentes, faltando e não testados no caso do Titanic.

A parte responsável pelos procedimentos operacionais provavelmente seria identificada como sendo do lado das operações da equação do projeto, mas seria necessário algum grau de tal documentação fornecida pelas equipes de engenharia e construção ou coordenada com elas também. Muitos dos procedimentos que falharam no Titanic incluíram falhas na cadeia de comando sob pressão, com o diretor da empresa assumindo o comando da ponte e o capitão permitindo isso, operadores de telegrafia sem fio sendo instruídos a transmitir mensagens de passageiros como prioridade sobre os avisos de icebergs, operadores de telegrafia sem fio sendo autorizados a dizer a outros navios que tentavam avisá-los para parar de transmitir, mensagens críticas não sendo levadas à ponte, ferramentas necessárias para tarefas críticas não sendo fornecidas e assim por diante. (Kuntz)

Assim como era necessário com a engenharia e o projeto dos navios, as operações dos navios precisavam de orientação forte e holística, garantindo que o navio e sua tripulação funcionassem como um todo, em vez de olhar para departamentos, como os operadores de telegrafia sem fio da Marconi, como uma unidade individual. Naquele exemplo, eles não eram oficialmente tripulação do navio, mas funcionários da Marconi que estavam a bordo para lidar com as comunicações pagas dos passageiros e para tratar do tráfego de emergência do navio apenas se o tempo permitisse. Se eles tivessem sido supervisionados como parte de um sistema holístico de gestão operacional, mesmo como contratados externos, é provável que seus procedimentos tivessem sido muito mais focados em segurança ou, no mínimo, que os acordos de nível de serviço em torno de levar mensagens à ponte tivessem sido claramente definidos, em vez de improvisados e discricionários.

Em qualquer projeto e componente de projeto, uma boa documentação, seja de objetivos do projeto, entregas, procedimentos e assim por diante, é fundamental, e o gerenciamento de projetos tem pouca esperança de sucesso se boas comunicações e documentação não estiverem no cerne de tudo o que fazemos, tanto internamente dentro do projeto quanto externamente com as partes interessadas.

O que constatamos hoje é que as lições de gerenciamento de projetos do Olympic, do Titanic e do Britannic continuam valiosas para nós hoje, e o contexto da época, seja na busca por um design de projeto iterativo sempre que possível, no investimento em conhecimento tribal, no cálculo de risco, na compreensão dos papéis da engenharia de sistemas e das operações de sistemas ou nas interações de forças externas protetoras sobre os custos do produto, ainda é relevante. Os fatores que afetam os projetos vão e vêm em ciclos; hoje vemos tendências inclinando-se para modelos mais parecidos com os dos navios da classe Olympic do que diferentes deles. No futuro, provavelmente, o pêndulo voltará a oscilar. As lições subjacentes são muito relevantes e continuarão a ser. Podemos aprender muito tanto avaliando como nossos próprios projetos são semelhantes aos da White Star quanto como são diferentes deles.

Bibliografia e Fontes Citadas:

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.

Notas Adicionais:

Mark Kozak-Holland publicou originalmente seu livro em 2003 como uma série de artigos do Gantthead sobre o Titanic:

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.

Leitura Adicional:

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.

Transcrições oficiais das audiências e inquéritos do Senado dos EUA e do governo britânico de 1912 no Titanic Inquiry Project.