Um tsunami de desastres de projetos de TI está no horizonte | CIO
Por John Belden
Nunca é a posição popular a tomar na organização para ser o prognosticador de desastre e fracasso, por isso escrevo esta missiva com a plena compreensão de que o conteúdo cairá em ouvidos surdos e os potenciais benefícios dos meus conselhos serão encontrados na pilha de "Quem me dera que tivéssemos." Há um tsunami de desastres de projetos a deslocar-se rapidamente em direção à linha costeira da empresa e não há muito que possa ser feito para o impedir.
O tipo de desastres de projetos de que falo não são aqueles que estão acima do orçamento e atrasados, mas sim as falhas espetaculares que perturbam as cadeias de abastecimento, atrasam a comunicação de informações financeiras e fazem explodir as carreiras de executivos aparentemente competentes. Estes são os tipos de falhas que são criadas quando as empresas "sobrevivem" com uma implementação que, em retrospetiva, será considerada feita de forma imprudente.
Quatro arautos da desgraça
Porque estou tão convencido de que muitos projetos estão em rota de colisão com o fracasso?
Duplicar o volume. Há o dobro do número de grandes projetos em voo programados para entrar em funcionamento entre maio e setembro deste ano, em comparação com um ano normal. Quando a COVID encerrou as coisas no início de 2020, muitas empresas suspenderam os seus grandes programas de transformação de TI. No início de 2021, a barragem quebrou-se, e os grandes programas programados para começar em 2020 foram lançados em 2021. Ao mesmo tempo, as empresas que tinham inicialmente planeado lançar programas em 2021, fizeram-no. Voilà! Isso significa o dobro do número de potenciais desastres de projetos. Com prazos de entrega iniciais de 12-18 meses em média para as grandes iniciativas, o quadro foi estabelecido.
Viés de Recência. Quando foi a última vez que leu sobre um fracasso de um grande projeto em curso? Projetos, nos EUA, como Select Comfort, National Grid, Cover Oregon, ou Los Angeles Department of Water and Power (LADWP) têm estado fora do radar durante alguns anos – o tempo suficiente para que desapareçam da memória da suite C. A arrogância organizacional é uma força poderosa que muitas vezes contrabalança a realidade da possibilidade real de desastres. Quando não há notícias de catástrofes, a ameaça potencial desvanece-se. Há uma razão pela qual todos nós conduzimos com mais cuidado depois de vermos um acidente de automóvel.
Vazios de talento. Quase todos os grandes desastres podem ser atribuídos à falta de experiência por parte dos membros seniores da equipa do projeto. A capacidade de verificar e comunicar os riscos é obviamente primordial para os mitigar. Com o dobro do número de projetos em jogo, a capacidade dos Integradores de Sistemas (SIs) de trazer talento altamente qualificado a todos os programas tem sido grandemente diminuída. A juntar a isto a "grande resignação" e as taxas de desgaste que duplicaram nos últimos 6 meses, e verá que o nível de consciência situacional nestes programas foi drasticamente reduzido.
Métodos não testados. Temos visto muitos projetos lutarem nas áreas de testes de sistemas integrados durante a pandemia. A origem do golpe de produtividade é frequentemente atribuída à falta de colocação das equipas de projeto. Sem estarem juntos, os membros das equipas não são tão rápidos a aprender com os seus vizinhos e as gorjetas e os obstáculos não são transmitidos com tanta facilidade. Agora, avançam rapidamente para depois do destacamento e consideram o impacto potencial em milhares de utilizadores que podem não ter os "experts" na cadeira ao lado para os orientar durante o arranque. Não há razão para acreditar que as mesmas lutas que vimos nos testes seriam miraculosamente curadas após a colocação em funcionamento.
Como evitar desastres informáticos
Existem formas de evitar o tsunami das catástrofes? A resposta em conjunto é, infelizmente, não. Os dados foram lançados. Existem táticas que possam ser implementadas em programas individuais para prevenir uma catástrofe? Felizmente, essa resposta é sim. Aqui estão algumas recomendações simples:
Torne-o real. Peça ao seu SI para fazer uma apresentação sobre as lições aprendidas com os grandes desastres dos programas. Não há necessidade de ser o 'mensageiro que leva um tiro na praia'. Faça esta apresentação ao comité diretivo mais cedo em vez de mais tarde para demonstrar que está a tomar as medidas apropriadas para proteger o negócio.
Estabeleça os critérios para a vida precoce. Demasiados programas constituem os critérios de porta de entrada 2-3 meses antes da data de entrada em funcionamento. Quando este é o caso, o critério torna-se então, "O que podemos alcançar antes de entrarmos em funcionamento" em vez de, "Onde devem estar? Isto é particularmente verdade para projetos que estão sob tensão orçamental.
Visão independente. "Go-live" ou "febre do cume" é real – basta perguntar a qualquer uma das famílias daqueles que perecem ao tentar alcançar o cume de uma montanha. O bom senso é facilmente obscurecido pelas avaliações de custos afundados e pelo planeamento injustificado do melhor cenário. Uma visão independente pode ser muito sóbria.
Percebo que este artigo é provavelmente um pouco mais desanimador ou pode ser visto como simplesmente sensacionalismo, mas se o motivar a colocar as rodas em movimento, para um projeto evitar a catástrofe, já valeu a pena!