Gerenciamento de Projetos do RMS Titanic e dos Navios da Classe Olympic

A ideia de construir o R.M.S. Titanic e suas irmãs, o R.M.S. Olympic e o H.M.H.S. Britanic, começou a tomar forma pela primeira vez em 1907. Esses três navios, juntos, eram os transatlânticos da Classe Olympic da White Star Line . (Usarei Olympic(s) em referência à classe de embarcações ao longo deste texto, em nome da clareza.) Poucas embarcações na história da humanidade tornaram-se tão conhecidas e infames quanto o R.M.S. Titanic.

Ao examinar o R.M.S. Titanic sob a perspectiva do gerenciamento de projetos, é importante primeiro identificar que tipo de produto este projeto se propunha a produzir. Diferentemente de muitos projetos em que o cliente final será o proprietário do produto final, o Titanic foi projetado para entregar um serviço, particularmente um serviço de travessia, aos seus clientes finais. Isso cria um desafio interessante ao discutir o “Projeto Titanic”, já que a maioria das visões de gerenciamento de projetos enxerga um projeto como tendo um início e um fim discretos, bem como partes interessadas claras e bem definidas.

No caso de um projeto como o R.M.S. Titanic, podemos adotar duas visões e abordar a questão por dois lados. Em um caso, temos o projeto pelo qual os três navios da classe Olympic foram concebidos, projetados, construídos e entregues à White Star Lines. No outro caso, temos o R.M.S. Titanic tal como foi personalizado além do alcance de seu irmão mais velho, o R.M.S. Olympic, concluído em sua produção inicial e entregue, como um serviço, aos passageiros que ele deveria transportar entre Southampton e Nova York. Para manter o escopo, não discutirei o projeto ainda maior de testes, correções de falhas, reparos, mudanças de escopo e melhorias que foram aplicados aos dois navios irmãos após o naufrágio do R.M.S. Titanic. Tanto o R.M.S. Olympic quanto o H.M.H.S. Britanic passaram por muitas mudanças durante seus anos de serviço, incluindo a redefinição de escopo do Britanic, do papel de transatlântico para o de principal navio-hospital da Marinha de Sua Majestade durante a Primeira Guerra Mundial, e o equipamento do Olympic com um casco duplo e botes salva-vidas adicionais, já que a tripulação se recusou a navegar nele até que tivesse sido tornado mais seguro. (“Olympic”)

Meu objetivo aqui é examinar o Titanic como um serviço, desde a concepção até a entrega do serviço e, em última instância, a falha do serviço. Sob essa perspectiva, o Titanic pode ser tratado de forma muito semelhante a como se trataria um moderno projeto de Software como Serviço (SaaS). Por causa da natureza de um navio como o Titanic ou de produtos SaaS como o Salesforce.com ou o SugarCRM, precisamos considerar a vida útil pretendida do produto e as atualizações e a manutenção contínuas que serão necessárias para mantê-lo em operação. O Titanic exige uma enorme equipe de pilotos, marinheiros, chefs, carregadores, comissários e muitos outros enquanto está no mar, e exigiu reequipamento, reparos e, caso tivesse sobrevivido, teria precisado de um novo casco duplo como o que o R.M.S. Olympic recebeu. Um projeto SaaS exigirá, de maneira semelhante, uma equipe para manter o datacenter e a rede, atualizações e correções de falhas contínuas, novos recursos, etc. Tanto no caso do Titanic quanto no de um projeto SaaS, existe um potencial real de uma interrupção de serviço que poderia revelar-se extremamente custosa. Manter operações estáveis e confiáveis é um fator importante para o sucesso de qualquer um desses planos de negócios.

Vamos começar nossa análise do projeto de concretização do Titanic examinando as partes interessadas. Podemos identificar facilmente os passageiros e a tripulação do Titanic como partes interessadas, a White Star Lines como empresa, bem como os engenheiros do projeto, a Harland-Wolff como construtora, Alexander Carlisle e Thomas Andrews como construtores navais e projetistas na Harland-Wolff, o Capitão Edward John Smith, que era responsável pela entrega do serviço, e, por fim, o diretor da White Star, Joseph Bruce Ismay, e sua equipe executiva, que desempenhavam o papel de patrocinadores do projeto. Em qualquer projeto deste porte, haverá muitos atores importantes, todos com algum interesse no projeto. Focaremos apenas nessas pessoas-chave como as partes interessadas mais proeminentes no projeto do Titanic.

O projeto do Titanic assemelhava-se mais de perto a um Modelo em Cascata, no jargão do Gerenciamento de Projetos de TI. O processo começou com um conceito de alto nível, proveniente conjuntamente de Joseph Bruce Ismay, representando a White Star Lines, e de Lord James Pirrie, representando seu parceiro de construção naval, a Harland-Wolff. O projeto foi concebido conjuntamente entre as duas empresas. O Titanic ofereceria grande prestígio e potencial de lucro para ambas as firmas e exigiria um grande investimento de ambas. Embora não pareçamos dispor hoje do termo de abertura original do projeto, podemos enxergar a reunião entre Ismay e Lord Pirrie como o termo de abertura não oficial do projeto e a iniciação do projeto. (Sadur)

O projeto técnico dos navios da classe Olympic foi conduzido pelo construtor naval-chefe da Harland-Wolff, Alexander Carlisle, depois que os planos de alto nível haviam sido elaborados por Ismay e Lord Pirrie. Carlisle foi o projetista líder do projeto desde sua concepção até 1910, quando se aposentou e transferiu o papel de projetista líder para Thomas Andrews, o diretor-gerente da Harland-Wolff (Brander 1998). Andrews seria responsável pelos estágios finais do projeto do Titanic. O Olympic, lançado no outono de 1910, teria sido muito provavelmente projetado por completo sob a direção de Carlisle. Como o Titanic compartilhava quase toda a infraestrutura do Olympic (projeto do casco, posicionamento da bússola, botes salva-vidas, ponte de comando, etc.), podemos presumir com segurança que as contribuições de Andrews ao projeto do Titanic foram majoritariamente estéticas ou, em termos de desenvolvimento de software, relacionadas à “interface”. (Thinkquest)

Por causa da natureza semelhante à da construção civil que tem a construção naval, e especialmente com navios colossais como os Olympics, o processo de projeto envolve um pesado projeto inicial com ciclos de feedback muito limitados posteriormente, uma vez que os projetistas possam inspecionar fisicamente o navio. Em termos de software, isso é chamado de “Big Design Up Front” ou BDUF. Em software, onde requisitos mutáveis são comuns, isso é geralmente considerado uma prática muito ruim, mas em engenharia mecânica e estrutural essa é simplesmente a única solução razoável.

À medida que o trabalho avançava nos Olympics, várias decisões foram tomadas a respeito do projeto da infraestrutura central dos navios. Isso é especialmente perigoso, pois a metodologia em vigor para esse tipo de projeto não foi concebida para permitir mudanças dessa natureza uma vez que os planos fossem aprovados. Um navio é projetado como um sistema holístico, com sistemas de segurança interdependentes e um alto grau de complexidade. Diferentemente da maioria dos softwares, é muito difícil fazer a prototipagem rápida de um navio com o grau de precisão necessário para garantir a segurança. Fazer mudanças importantes nos sistemas de segurança teria exigido uma reformulação em larga escala das especificações para ser feito corretamente. Mas como as mudanças foram feitas por causa de economia de custos, questões de cronograma e acabamentos de luxo, pouco pensamento holístico foi dedicado às mudanças. (Kozak-Holland)

O projeto e a intenção originais dos Olympics eram que eles incorporassem as mais recentes tecnologias de segurança. Após a conclusão do projeto inicial, pressões de negócio por parte da White Star Lines, e especialmente de J.B. Ismay, foram exercidas sobre os arquitetos e engenheiros para remover recursos de segurança em favor de luxos de primeira classe. As duas mudanças mais famosas foram, é claro, a remoção dos botes salva-vidas para que as vistas das cabines não fossem desnecessariamente obstruídas e a modificação de várias das anteparas para que não mais se vedassem e se elevassem apenas três metros acima do nível da água, a fim de permitir uma instalação ampliada de grande salão de baile. Assim como nos projetos de TI, as decisões de engenharia para sistemas centrais geralmente estão além do alcance dos executivos de negócios. Permitir que decisões do lado do negócio influenciem decisões que, de outra forma, seriam técnicas é perigoso, pois as precauções e os processos de raciocínio habituais são contornados e a expertise é ignorada. Neste caso, tratava-se de questões relativas ao cuidado e à preservação da vida humana. Em software, raramente temos uma tarefa tão importante em mãos, mas permitir que gestores de negócios sem compreensão dos sistemas-chave se envolvam em seu projeto pode ser extremamente prejudicial, mesmo que o resultado seja algo tão benigno quanto a perda de negócios ou um maior custo de operações.

Um dos problemas mais dramáticos que surgiram a partir das mudanças tardias nos projetos dos Olympics foi que as mudanças, cada uma pequena por si só, muito provavelmente nunca foram tomadas em conjunto e examinadas como um todo da mesma maneira que o projeto original do navio foi considerado. Quando os botes salva-vidas foram removidos, os engenheiros envolvidos pensavam que o navio fora projetado para ser uma balsa salva-vidas flutuante e que o propósito dos botes salva-vidas era simplesmente transportar passageiros de um transatlântico imóvel para outro navio no “pior cenário possível”, caso o Titanic ou o Olympic perdessem energia. Esperava-se que até mesmo uma colisão apenas os fizesse flutuar mais baixos na água, e não afundar. Os botes salva-vidas foram removidos até que restasse apenas o número mínimo exigido por lei, a pedido do comitê executivo da White Star Line. Para os engenheiros, isso teria sido uma troca de segurança aceitável, embora não recomendada. O projeto do navio era tal que ter botes salva-vidas adicionais não era uma exigência legal, nem havia qualquer necessidade premente de mantê-los, já que se acreditava que a utilidade dos botes adicionais fosse mínima. No fim, não teria sido a decisão dos engenheiros, mas sim da White Star, que era o cliente final dos construtores navais e cujas decisões lhes proporcionavam o sustento.

Por si só, a decisão de remover os botes salva-vidas teria sido, muito provavelmente, de menor importância. Mas, adicionalmente, a decisão de mudar o projeto estrutural-chave dos Olympics, de ter todas as anteparas altas para ter quatro delas significativamente rebaixadas para apenas três metros acima da linha d'água, significou que o conceito do navio como uma balsa salva-vidas flutuante ficou comprometido. As anteparas nunca foram verdadeiramente estanques, como os materiais de marketing nos levariam a crer, mas eram bastante altas e muito “resistentes” à água, e muito provavelmente teriam sido capazes de impedir que a água se deslocasse entre elas mesmo sob uma brecha muito grave no casco. Como o projeto inicial do navio era repleto de recursos de segurança, isso teria sido considerado, assim como os botes salva-vidas, um recurso redundante, e sua remoção apenas rebaixaria o navio a critérios de segurança mais comuns. Tomadas individualmente, as mudanças eram em sua maioria inócuas, mas, tomadas em conjunto, as mudanças tornaram-se um reprojeto completo do navio e completamente desastrosas. Em nenhum momento os engenheiros qualificados retornaram e fizeram uma reavaliação completa dos recursos de segurança do navio com todas as mudanças implementadas.

Em alguns aspectos, poderíamos enxergar J.B. Ismay como um microgerente. Ele não confiava nas decisões daqueles que contratou em razão de sua expertise técnica e sobrepunha-se, seja diretamente, seja por meio de pressões indiretas, às decisões deles. O microgerenciamento tem muitos resultados negativos. O mais óbvio é o de gestores não treinados e não qualificados influenciando decisões que outros acreditam ter vindo de profissionais qualificados. Outros incluem corroer o valor gerado pela equipe do projeto e degradar a lealdade e o moral dos funcionários.

Na construção naval, em situações em que navios são construídos como uma classe, como o Titanic, precisamos considerar três fases principais do projeto – projeto e construção do protótipo, o Olympic; refinamento do projeto e construção do Titanic; e, por fim, entrega do serviço e operações. No caso do Titanic em particular, vemos que o projeto principal e quaisquer mudanças estruturais foram feitos antes da conclusão do Olympic. Thomas Andrews navegou no Olympic, mas isso foi principalmente para que ele pudesse fazer modificações estéticas para o Titanic, já que era tarde demais para que o trabalho estrutural fosse alterado àquela altura. Pela mesma razão, Andrews estava navegando no Titanic para que pudesse fazer o mesmo em relação ao Britanic, prestes a ser lançado (conhecido por Andrews como Gigantic).

Em termos de escopo do projeto, podemos ver que o projeto aderiu de perto ao plano inicialmente estabelecido. A construção foi feita com base em planos previamente aprovados, com pouca alteração. As mudanças mais dramáticas no escopo ocorreram durante a construção do Titanic, quando o projeto teve que ser interrompido para acomodar os reparos do Olympic. Ambas as partes, Harland-Wolff e White Star Lines, compreenderam que o Titanic seria atrasado, mas que a operacionalidade do Olympic tinha precedência. Um fator importante em qualquer tipo de projeto de construção de capital é a necessidade de acordos em nível de contrato entre as fases de construção, já que mudanças de escopo são quase impossíveis de acomodar uma vez que a construção tenha começado. (“Olympic”)

É difícil encontrar projetos de software que sigam de perto esse tipo de modelo, com um protótipo de produção seguido por uma série de implementações de produção baseadas no protótipo, mas não idênticas a ele. O exemplo mais próximo disso que consigo postular é o pacote de planejamento de recursos empresariais (ERP) SAP. Com esse pacote, e outros de sua espécie, os clientes compram o pacote com base em seu desempenho e em seus recursos prototípicos e, então, por conta própria ou por meio de uma empresa de consultoria ou do fornecedor original, modificam fortemente o pacote de acordo com suas próprias necessidades. Geralmente, a vantagem de tal abordagem é que o núcleo do pacote de software, a infraestrutura, é muito estável e bem testado, e frequentemente usado em uma ampla gama de situações, conferindo-lhe testes tanto do lado do projeto quanto do lado do cliente. É preciso ter cuidado, é claro, pois as modificações iniciadas pelo cliente não terão o benefício dos testes aprofundados que se espera terem sido realizados na infraestrutura central, nem as mudanças têm o benefício dos “muitos olhos” da comunidade mais ampla de clientes.

No caso dos navios da classe Olympic, foram feitos testes sérios no modelo de cinco metros do navio, e foram feitos testes no Olympic após sua conclusão. Com um navio da complexidade do Olympic, é fundamental que sejam realizados testes em condições reais, além dos testes unitários de sistemas individuais. O Olympic foi submetido às medidas de teste habituais, que eram padrão para um navio desse tipo. No entanto, quando o Titanic foi construído, os construtores e a companhia de cruzeiros decidiram que, como o Titanic era essencialmente uma cópia do Olympic, os testes realizados e o uso contínuo e bem-sucedido do Olympic eram teste suficiente para o Titanic, e o Titanic recebeu muito poucos testes adicionais. Isso, contudo, não é uma boa prática, pois os marítimos sabem que todos os navios, mesmo cópias, comportam-se de maneira diferente, e cada embarcação é única e deve ser testada por si só. (Kozak-Holland)

O Titanic recebeu quase nenhum tempo para testes ou ensaios de desempenho. Isso ocorreu em parte porque o Olympic havia sofrido um acidente grave e teve que ser levado aos estaleiros em Belfast e reparado. Enquanto o Olympic estava em reparos, o Titanic teve que esperar, já que apenas um navio daquele porte podia receber trabalho de cada vez. Isso impôs restrições de tempo de negócio ao Titanic, pois ele estava programado para serviço regular na rota transatlântica e era necessário imediatamente. Por causa disso, alguns testes adicionais que provavelmente teriam ocorrido foram pulados, e o Titanic foi enviado tendo como teste principal a viagem de Belfast a Southampton e, mesmo nesse trecho de sua jornada, havia pelo menos um passageiro pagante, tornando-a mais uma verdadeira viagem de baixa capacidade do que um teste apropriado. (Kozak-Holland)

Aparentemente, a White Star Lines e J. B. Ismay estavam bastante dispostos a assumir um risco de projeto excepcional para colocar o navio em serviço regular o mais rápido possível. Por meio do procedimento marítimo padrão, eles mitigaram boa parte de seu risco de capital por meio de seguro marítimo. Isso os protegeria contra muitas incógnitas potenciais.

Durante a segunda metade do século XIX, tornava-se cada vez mais comum que tanto as companhias de navegação quanto os governos enxergassem o risco como uma questão de baixa prioridade. O S.S. Great Eastern, construído em 1858, é considerado como tendo sido, e provou ser em casos reais, muito mais seguro do que os projetos das embarcações oceânicas cada vez menos seguras que se seguiram a ele ao longo dos cinquenta e quatro anos seguintes. As condições continuariam a declinar até que as empresas e os governos reavaliaram a situação na esteira do naufrágio do Titanic. Argumenta-se que as companhias de navegação enxergavam históricos aceitáveis de segurança como justificativa para sua atitude negligente em relação à segurança ao longo de décadas de navegação relativamente livre de incidentes. As pressões do mercado financeiro prevaleceram, favorecendo empresas com padrões de segurança frouxos e incentivando a indústria como um todo a afastar-se do oneroso gerenciamento de riscos. (Brander 1995)

Sob o pretexto de mitigar ainda mais os riscos decorrentes da falta de testes e treinamento, vários membros da tripulação, mais notavelmente o Capitão Smith, foram trazidos do Olympus para navegar no Titanic em sua viagem inaugural pelo Atlântico. Isso poderia ser visto como Ismay buscando experiência, o que pareceria diminuir as “incógnitas” derivadas de navegar um navio sem testá-lo diretamente, mas tendo ao menos o máximo de experiência da embarcação-protótipo. No entanto, essa pode não ser a razão subjacente para a decisão, e é muito possível que o Capitão Smith tenha sido escolhido porque sua posição na White Star Lines estava bastante questionável depois de ele ter, havia pouco tempo, causado um acidente grave envolvendo o H.M.S. Hawke, que fizera o Olympic precisar de reparos de emergência e atrasara a partida do Titanic. O Capitão Smith provavelmente estava nervoso, preocupado com sua carreira e em pouca disposição ou posição para atuar como o nível final de responsabilidade a bordo do navio, caso pressões da firma o direcionassem contra seu próprio bom senso. Essa pode ter sido exatamente a brecha operacional que a White Star Lines estava buscando. Essa situação foi provavelmente agravada pelo Capitão Smith ter se aproximado demais ou rápido demais do S.S. City of New York, quando atracado em Southampton, fazendo com que ele rompesse suas amarras e quase colidisse com o Titanic. (Kozak-Holland)

Sob a lei marítima consuetudinária, um capitão é o comandante absoluto do navio e tem jurisdição completa enquanto está no mar, mesmo que autoridades de patente superior, militares ou civis, estejam a bordo. O capitão tem responsabilidades morais e legais, primeiro para com as vidas e a segurança dos passageiros e da tripulação e, depois, para com a carga e o navio. (Kuntz)

Uma vez que o Titanic foi construído, equipado e disponível para navegar, vemos uma mudança de estágio e passamos para a fase de entrega do serviço do projeto geral do Titanic. Nesse estágio, estamos além dos estágios tradicionais do gerenciamento de projetos. Na maioria dos cenários, um cliente já teria, a essa altura, tomado posse do produto acabado. Mas, no caso do Titanic, isso se torna a fase de entrega do serviço.

Sob a entrega do serviço, a White Star Lines assumiu a responsabilidade por quaisquer novas questões que viessem a surgir com o navio. Nesse ponto, o sistema tradicional de projetar – construir – testar não seria mais usado e, em vez disso, a entrega do serviço seria supervisionada por um procedimento operacional padrão ou POP. Modificações contínuas no navio, reparos, ajustes e afins ainda continuariam, mas estes seriam concebidos para não estar no nível de exigir uma interrupção de serviço, sendo menores e feitos sem o conhecimento dos clientes finais – os passageiros. É nesse estágio que os passageiros surgem como nossas partes interessadas mais críticas, porque, nesse cenário, eles não são apenas partes interessadas financeiras, mas estão literalmente apostando suas próprias vidas na confiabilidade do navio e nas operações da tripulação.

Na comunidade de Gerenciamento Ágil de Projetos, há uma fábula frequentemente usada para denotar os papéis dentro das partes interessadas. Esses papéis são conhecidos como os porcos e as galinhas. A fábula nos conta sobre uma galinha e um porco que estão interessados em abrir um restaurante juntos. O porco pergunta à galinha o que eles vão servir. A galinha responde: “Bem, bacon e ovos, é claro.” A isso o porco responde: “Não acho que eu esteja interessado. Você estará envolvida, mas eu estarei totalmente comprometido.” (Schwaber 7)

A metáfora do porco e da galinha é normalmente usada para expressar a diferença entre partes interessadas que têm dinheiro real ou a carreira em jogo e partes interessadas que têm um interesse legítimo, mas não crítico, no projeto. As galinhas preferiram não ver um projeto fracassar, mas o fracasso não é necessariamente devastador para elas. No caso do Titanic, vemos que as partes interessadas financeiras, Harland-Wolff e White Star Lines, eram efetivamente galinhas. Elas tinham muito a perder, mas seu investimento estava segurado e, mais tarde, veremos, o governo estava até disposto a proteger empresas dessa natureza naquela época, em razão da iminente guerra com a Áustria e a Alemanha. Nem a White Star nem a Harland-Wolff estavam “totalmente comprometidas” – elas tinham um interesse definido, e o sucesso do Titanic era extremamente importante para elas, mas os passageiros e a tripulação do Titanic eram verdadeiramente os porcos aqui, dispostos a colocar suas próprias vidas em jogo. Raramente a metáfora da galinha e do porco é mais apropriada.

A fim de garantir uma maior qualidade de serviço contínuo, um grupo de garantia da Harland-Wolff esteve presente na viagem inaugural. Essa equipe incluía muitos membros importantes da equipe de projeto e construção da Harland-Wolff, incluindo o projetista líder, Thomas Andrews. Esse grupo de garantia era costumeiro em todos os grandes projetos da Harland-Wolff. Essa equipe usaria o tempo da viagem para avaliar a construção sob condições diferentes das de seus testes, aferir a satisfação do cliente e procurar oportunidades de melhoria. Thomas Andrews já havia navegado no Olympic com esse mesmo propósito e fizera muitas pequenas mudanças para aprimorar o Titanic. Ele passaria parte dessa jornada, por exemplo, projetando ganchos de roupa mais baratos para os quartos dos passageiros. (“Guarantee Group”)

O Grupo de Garantia compreendia especialistas de muitas práticas técnicas diferentes dentro da Harland-Wolff. Vemos representação dos montadores, eletricistas, marceneiros, desenhistas técnicos, equipe de projeto e muito mais. Esse grupo, com suas variadas áreas de especialização e seus diferentes níveis de experiência, incluindo tanto seniores quanto aprendizes, teria sido uma seção transversal excepcional da equipe de projeto que construiu o navio. A presença deles a bordo, com o cuidado dedicado a avaliar a qualidade da execução, o projeto e outros componentes finais, pode ser vista de duas maneiras principais.

Na primeira maneira, podemos enxergar isso como um “post-mortem” realizado no Projeto Titanic. Era o papel dessa equipe avaliar o sucesso técnico do projeto e procurar áreas de melhoria, bem como gerar “lições aprendidas”, para que projetos futuros pudessem se beneficiar da experiência aqui adquirida. Considerando o custo da viagem transatlântica e o tempo passado longe de suas funções regulares, esse foi um investimento sério em conhecimento de projeto por parte da Harland-Wolff e extremamente louvável.

Visto sob outra ótica, esse grupo de garantia poderia ser visto como provedor de feedback sobre uma iteração de construção. A construção do Olympic sendo a primeira iteração, a do Titanic sendo a segunda e a do Britanic sendo a terceira. Nessa abordagem, vemos um tipo de ciclo de feedback Ágil sendo utilizado, na medida do possível, para permitir a contribuição do cliente mesmo em um projeto de construção de capital tão extremo. As iterações são muito longas, mas isso ocorre por necessidade. Dessa forma, podemos enxergar o Titanic tanto como um projeto em si, sendo uma entrega discreta, quanto como parte do projeto contínuo de entregar serviço de passageiros por meio da família de embarcações Olympic.

O grupo de garantia estar a bordo do navio teria apresentado a oportunidade para que as equipes técnicas obtivessem uma apreciação em primeira mão da aplicação no mundo real de seu produto. Raramente um especialista técnico estaria em posição, em 1912, de viajar em um navio desse nível de luxo. Sem o patrocínio da Harland-Wolff ao proporcionar essa chance para sua equipe testemunhar sua própria execução em funcionamento, eles talvez nunca compreendessem seus próprios papéis na prestação de serviços aos seus clientes finais.

Ter aprendizes incluídos no grupo de garantia significava que um treinamento informal direto, individual ou em pequenos grupos, podia ser realizado. Os aprendizes e os técnicos seniores teriam tido muitos dias para trabalhar juntos, e os aprendizes teriam tido uma grande oportunidade de aprender com seus seniores em um ambiente propício à construção de equipe e à transferência de conhecimento. De muitas maneiras, podemos enxergar esse tempo como semelhante às sessões de construção de equipe fora da sede ou aos retiros populares em muitas empresas e grupos de projeto hoje em dia.

Onde encontramos a maior surpresa em nossa análise do Titanic é na quase total ausência de procedimento operacional padrão em uso a bordo do navio. Alguns processos e procedimentos estavam documentados, mas muitos não. Exemplos de processos que não eram padronizados incluíam processos de comunicação fundamentais, como mover mensagens da sala do telégrafo sem fio para a ponte de comando, alertar os passageiros sobre o naufrágio do navio e alertar a ponte de comando de que o ninho de corvo havia avistado um iceberg. (Kozak-Holland)

Os Procedimentos Operacionais Padrão são absolutamente fundamentais em qualquer situação de entrega de serviço. Em algumas empresas, estes podem até ser considerados tão valiosos a ponto de serem a propriedade intelectual central da empresa. Sem o POP, uma empresa não é mais coesa do que o “espírito de equipe” inerente da equipe, o que, no caso de novos funcionários, pode ser nominal. A equipe terá que confiar totalmente em boas práticas, convenção, instrução informal da equipe ou, espera-se, treinamento para aprender suas funções e processos. Mas estes não serão padronizados se não forem escritos, e o treinamento inevitavelmente variará de instrutor para instrutor, e nenhum funcionário consegue reter todas as instruções para todos os cenários possíveis.

Sob condições normais, a falta de procedimentos operacionais padrão pode ser de importância relativamente menor. A equipe consegue desempenhar a maioria das funções de trabalho de forma adequada, especialmente se treinada, sem precisar de um POP. Se precisasse, teria que carregar o POP consigo o tempo todo. O momento em que o POP se torna extremamente crítico é quando os “procedimentos operacionais normais” não estão mais disponíveis ou, em termos mais modernos, quando as operações não estão mais sob condições de BAU (Business as Usual, ou Negócios como de Costume). Para o Titanic, as condições de BAU foram rompidas várias horas antes do incidente com o iceberg.

No caso do Titanic, é difícil discutir procedimentos operacionais padrão sem também discutir comunicações. Então, começaremos com as comunicações sob condições de BAU e, em seguida, veremos como a falta de um POP fez com que a situação se deteriorasse rapidamente.

O Titanic foi assolado por falhas de projeto de comunicação desde o início. A sala do telégrafo sem fio, responsável por todas as comunicações de entrada e saída do Titanic, não era operada pela White Star Lines, mas sim composta por pessoal da Marconi, que era pago para se comunicar, antes de tudo e acima de tudo, para os passageiros, e para o navio apenas se o tempo permitisse. Os operadores do telégrafo sem fio estavam sobrecarregados e subvalorizados e, com frequência, não repassavam mensagens à ponte de comando porque tinham outras tarefas consideradas de maior prioridade pela Marconi, sua empregadora. Pelo menos oito avisos de iceberg foram enviados à sala do telégrafo sem fio do Titanic, mas apenas alguns deles foram repassados à ponte de comando. (Kozak-Holland)

Neste caso, é importante enfatizar a importância de gerenciar contratados terceirizados por meio de um acordo de nível de serviço. A White Star Lines, ao permitir que a Marconi Company compusesse a equipe de sua sala do telégrafo sem fio, deveria ter tido um SLA claro exigindo que as comunicações de segurança e emergência do navio tivessem prioridade absoluta sobre as mensagens pessoais da tripulação. Eles também não deveriam ter permitido que a Marconi obtivesse lucro adicional ou fosse financeiramente beneficiada por não seguir o SLA. Como contratada externa, a Marconi deveria ter tido um contrato concebido para benefício mútuo – ou seja, que, quando executado conforme estabelecido, fosse do interesse mútuo de todas as partes agir corretamente. Contratos entre fornecedores que dão incentivos financeiros para um fornecedor trabalhar contra o bem de seu cliente são muito imprudentes.

O incidente isolado mais importante envolvendo os operadores da Marconi foi o último aviso de iceberg enviado pelo SS California, que estava extremamente próximo do Titanic – tão próximo que, mais tarde, seria o navio a avistar os foguetes de emergência do Titanic. O California transmitiu por rádio ao Titanic um aviso de que havia ficado preso em gelo compactado e não podia prosseguir, a velocidade alguma, devido às condições perigosas. O operador da Marconi respondeu: “Cale a boca, cale a boca, estou ocupado. Estou operando com Cape Race e você está me interferindo.” Dificilmente poderia ficar mais claro onde estavam as prioridades da sala do telégrafo sem fio, mesmo com tamanho perigo se avizinhando tão de perto. A sala do telégrafo sem fio não apenas deixou de manter as comunicações abertas com o California, como também se recusou a informar a ponte de comando desse último aviso externo. Em frustração, o operador de rádio do California desistiu de suas tentativas de avisar o Titanic, desligou seu telégrafo sem fio e foi dormir. Os operadores da Marconi não apenas deixaram de atender aos avisos, como também alienaram canais externos, de tal modo que o único navio próximo o suficiente para resgatá-los não respondeu quando o Titanic começou a afundar. (Kuntz)

As comunicações da ponte de comando para a tripulação em geral e os passageiros não tinham processo oficial, eram manuais e eram, na melhor das hipóteses, feitas de maneira de melhor esforço, se é que eram tentadas. A ponte de comando não notificou ninguém de que uma colisão era iminente, e ninguém estava preparado para o que poderia ter sido um impacto muito grave. Uma vez que o navio começou a afundar, levou mais de uma hora até que a ponte de comando começasse a informar o restante do navio de que estavam afundando. Informações fundamentais que afetavam as vidas dos passageiros e da tripulação foram mantidas longe deles e retidas por apenas alguns poucos integrantes da ponte de comando, que muito provavelmente esperavam manter o incidente em segredo ou minimizar a publicidade do risco óbvio à vida humana. Como não havia sistema ou processo para comunicar da ponte de comando para o navio em geral, isso era uma questão simples, já que era preciso um esforço concertado para informar os passageiros de qualquer notícia que fosse. (Kozak-Holland)

As comunicações entre a tripulação eram pouco melhores. O Oficial de Quarto, por exemplo, ficava localizado fora da ponte de comando, mas seus enlaces de comunicação fundamentais ficavam localizados dentro da casa da ponte de comando. Assim, o quarto era incapaz de se comunicar rapidamente com qualquer outro integrante da ponte de comando ou de se coordenar com o ninho de corvo e outras áreas funcionais relacionadas. O ninho de corvo e o quarto eram conectados por um sistema de sino unidirecional que não lhes permitia comunicar-se em duplex e era muito lento, e o quarto não tinha meios de retorno por parte do timoneiro ao leme quando um comando de emergência era dado. Os comandos eram dados por gritos do ar livre em direção à ponte de comando fechada. O quarto só podia esperar que o timoneiro, dentro da ponte de comando, tivesse ouvido, compreendido e estivesse agindo de acordo com esses comandos. As comunicações da bússola padrão eram igualmente ruins. A bússola, em vez de estar localizada acima ou perto da ponte de comando, foi colocada bem à ré, e a ponte de comando era forçada a se coordenar com a bússola regularmente, o que causava muita confusão e atrasos. Pouco, se é que algum, pensamento foi dedicado a tornar a ponte de comando eficaz ou segura. Essa falta de projeto para a comunicação certamente em nada ajudou o Titanic quando comunicações rápidas e precisas foram necessárias. (Brown)

Quando as comunicações externas para o escritório da White Star em Boston foram finalmente enviadas, a informação repassada era de que não havia dano grave e que o incidente era muito pequeno. Diferentemente da informação ponto a ponto que é comum hoje, contudo, essa informação era difundida por broadcast e podia facilmente ser interceptada por outros navios e estações de retransmissão. As comunicações navio-terra eram frequentemente usadas para, na prática, divulgar informações à imprensa sob o pretexto de um comunicado interno. Então, em vez de repassar informação honesta e fundamental, o telégrafo sem fio foi usado como uma ferramenta de marketing. O que foi enviado não foi um sinal de socorro, mas era, na prática, nada mais do que um comunicado à imprensa concebido para dar uma versão tendenciosa à situação. (Kozak-Holland)

As comunicações são fundamentais em qualquer estágio de qualquer projeto. No caso do Titanic, a situação catastrófica destaca questões que ocorreram por causa das comunicações, mas isso é simplesmente um pior cenário possível. Os projetos precisam ter o máximo de dados atualizados e precisos possível ao tomar decisões. Sem isso, as decisões são tomadas usando apenas um quadro parcial disponível e, quanto menos informação correta disponível, menos provável é que uma boa decisão possa ser tomada.

Talvez a maior questão de gerenciamento de projetos a afetar o Titanic, contudo, tenha sido sua falta de procedimentos operacionais padrão. O POP deveria ter sido produzido como uma entrega essencial do projeto durante os estágios posteriores do processo de construção. Que um navio tenha sido considerado apto a navegar quando não havia um POP para operá-lo é verdadeiramente inconcebível. Mesmo a mais ágil das metodologias de desenvolvimento não deixa de reconhecer a necessidade de documentação para o usuário final.

Como as porções de projeto e construção do projeto haviam falhado em fornecer à tripulação do Titanic um POP ou, ao menos, um POP razoável (havia alguns procedimentos padrão genéricos no próprio manual da White Star Lines), não havia regras ou processos claramente definidos para lidar com comunicações, rastrear alertas, fornecer avisos, etc. Não havia procedimento de emergência a ser seguido, e assim a tripulação foi forçada a agir com base em nada além da experiência e do conhecimento marítimo geral.

É neste ponto, ao examinar as ações da tripulação sob condições de emergência, que testemunhamos o colapso completo da estrutura de comando. Em uma empresa tradicional, os executivos de negócios são geralmente aceitos como detentores do poder final de tomada de decisão sobre qualquer ação corporativa, desde que esteja dentro dos limites legais, e frequentemente mesmo quando não está. Na empresa média, uma má decisão operacional resulta em perda de receita, não na perda de vidas. Um executivo sábio compreenderá a necessidade de não se sobrepor às decisões daqueles especialistas contratados para tomar decisões operacionais, ou possivelmente um conselho exigirá que um executivo escute sua equipe. Não obstante, a ideia de executivos do lado do negócio interferirem nas operações do projeto é contrária às boas práticas e é amplamente aceita como sendo um mau curso de ação.

No caso do Titanic, o Capitão Smith estava no comando da embarcação no mar e era pessoalmente responsável pelo navio e pelas almas a bordo. Seu chefe, J.B. Ismay, pode ter tido a capacidade de mandar destituir Smith do comando ao retornar ao porto, mas no mar ele não tinha, nem, sob a lei marítima britânica, tinha o direito de dar comandos a partir da ponte de comando, já que não era um marítimo licenciado. (Kuntz)

Durante o período que antecedeu a colisão com o iceberg, J. B. Ismay vinha pressionando o Capitão Smith a conduzir o navio a uma velocidade irresponsável – superior a vinte e quatro nós, ou setenta e cinco rotações. O Olympic, sendo considerado o “teste” para o Titanic, jamais havia cruzado o Atlântico nessa velocidade, e o Titanic operava agora até mesmo fora da faixa de testes realizados no Olympic, sem nem ao menos tempo suficiente para ter realizado uma única travessia do Atlântico sob condições normais. Ismay e Smith conduziram o Titanic para além de seus parâmetros de desempenho conhecidos e, mais importante, para além dos parâmetros operacionais conhecidos da tripulação. Era simplesmente desconhecido quais riscos operacionais estariam envolvidos com o navio nessa velocidade. Manter o que deveria ter sido considerada uma velocidade insegura, ao mesmo tempo em que se adentrava em águas sabidamente repletas de icebergs, foi extremamente tolo.

Seja por pânico, confusão, insegurança, etc., não sabemos, mas quando o Titanic atingiu o iceberg, o Capitão Smith permitiu que um leigo, J.B. Ismay, subisse à ponte de comando e começasse a dar ordens executivas como comandante interino do navio, em relação ao qual o Capitão Smith tinha o direito e a obrigação de mandar destituir Ismay. Ismay tomou decisões operacionais fundamentais, incluindo as comunicações de emergência, a notificação dos passageiros e, o mais importante, mover o Titanic para a frente, para fora da plataforma de gelo, o que se acredita ser a verdadeira causa da ruptura principal do navio, e então continuar movendo o navio para a frente em baixa velocidade, separando o casco, mesmo depois de informações adicionais estarem disponíveis de que o navio iria afundar. (Kozak-Holland)

Dada a distância no tempo em que nos encontramos agora do Titanic, pode ser difícil avaliar os processos seguidos e saber o que deu certo no projeto quando sabemos tanto do que deu errado. O naufrágio do Titanic é tão icônico em nossas mentes que enxergá-lo como qualquer coisa que não seja um desastre de marketing e organizacional é difícil, na melhor das hipóteses.

No fim, o projeto do Titanic foi imenso, mas bem gerenciado. O escopo foi controlado e as mudanças acomodadas quando necessário. Um grande projeto inicial, com uma interface contratual bem estabelecida com a fase de construção, foi usado, e essa cimentação das especificações permitiu um agendamento cuidadoso e preciso. Os processos pelos quais os navios foram construídos eram padrão e bem conhecidos. Usando dados históricos de construção, a Harland-Wolff foi capaz de prever com precisão o tempo necessário para a construção, permitindo que a White Star Lines começasse o marketing e as vendas com muita antecedência em relação à navegação efetiva dos navios. O Titanic, sendo uma cópia quase idêntica do Olympic, teve ainda menos surpresas. A única verdadeira surpresa resultou da mudança de prioridades por parte da White Star Lines, que resultou na suspensão do projeto do Titanic por aproximadamente um mês.

Nas palavras de J. Bruce Ismay: “Ele [o Titanic] não foi construído por contrato. Foi simplesmente construído sob encomenda.” Isso indica que uma autoridade excepcional foi concedida à Harland-Wolff para usar seus próprios processos e supervisão a fim de garantir a entrega do Titanic. As duas empresas operavam mais como parceiras do que numa relação fornecedor-cliente. (Kuntz)

O risco do projeto para o Titanic foi tratado de forma deficiente, apoiando-se fortemente em seguradoras externas e, no fim, no governo britânico para proteger a empresa de ações de responsabilidade civil, às custas dos passageiros primordialmente britânicos e americanos. O risco era considerado muito baixo e, por causa disso, muitas decisões descuidadas foram tomadas, primeiro com o Olympic e, depois, quando os desastres operacionais foram mínimos, ainda mais com o Titanic. Uma avaliação cuidadosa de riscos não foi feita. Marítimos especialistas poderiam fácil e rapidamente ter definido muitas áreas de risco que precisavam ser tratadas. Questões como a falta de um Procedimento Operacional Padrão completo teriam sido sinalizadas e poderiam facilmente ter sido tratadas, já que os recursos para isso não teriam precisado vir da equipe então alocada ao Titanic e não teriam impactado a data de entrega ou qualquer uma das variáveis que hoje entendemos terem sido de preocupação primordial para a White Star Lines.

A comunicação no projeto parece ter sido tratada muito bem até que a entrega do serviço começou. Nesse ponto, falhas de projeto, decisões questionáveis e a falta de POP recaíram sobre a rede de comunicação a bordo do navio. Essa comunicação poderia ser considerada operacional, e não baseada no projeto, mas o argumento é semântico. As questões com o Titanic eram holísticas e, com metodologias de projeto adequadas sendo seguidas, a análise de riscos não teria sido omitida, o que teria forçado a criação do POP, que teria destacado ou, quem sabe, até corrigido as questões de comunicação.

Em seu cerne, a questão era de qualidade. O Titanic foi proposto e vendido como a opção de viagem transatlântica da mais alta qualidade. A qualidade era anunciada, direta ou indiretamente, em quase todo suspiro proferido sobre o Titanic. A interface com o cliente foi mantida tão limpa e concisa quanto possível. Nenhuma despesa foi poupada se os resultados fossem testemunhados por um cliente. Mas o núcleo subjacente ou infraestrutura do projeto (requisitos não funcionais, segundo Kozak-Holland – embora eu não concorde com o uso desse termo por eles neste contexto), sobre o qual essa “qualidade” deveria se apoiar, foi ignorado, e a verdadeira qualidade do Titanic e a qualidade das operações da White Star Lines viriam, em última instância, a tornar-se evidentes.

Bibliografia e Fontes Citadas:

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. Edição em áudio via Audible.

Kozak-Holland, Mark. “IT Project Lessons from Titanic.” Gantthead.com the Online Community for IT Project Managers. (2003): 22 de fevereiro de 2008

Brown, David G. “Titanic.” Professional Mariner: The Journal of the Maritime Industry. (2005): 23 de fevereiro de 2008

Sadur, James E. Página inicial. “Jim’s Titanic Website: Titanic History Timeline.” (2005): 23 de fevereiro de 2008.

ThinkQuest Library. “Designing the Titanic.” (Data Desconhecida): 25 de fevereiro de 2008.

Titanic-Titanic. “Olympic.” (Data Desconhecida): 25 de fevereiro de 2008.

Titanic-Titanic. “Guarantee Group.” (Data Desconhecida): 25 de fevereiro de 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 de fevereiro de 2008.

Brander, Roy. P. Eng. “The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management.” (1995): 25 de fevereiro de 2008.

Notas Adicionais:

Mark Kozak-Holland republicou seus artigos de 2003 do Gantthead sobre o Titanic em um livro:

Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.

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 do inquérito do Senado dos EUA e do governo britânico de 1912, no Titanic Inquiry Project.

Publicado pela primeira vez no SheepGuardingLlama.