Tsunami de desastres de projectos de TI

Não há falhas de projecto “acima do orçamento e atrasados” aqui. Estamos falando de falhas espetaculares que interrompem as cadeias de suprimentos, atrasam os relatórios financeiros e explodem as carreiras de executivos aparentemente competentes.

John Belden, escreveu para o CIO, que nunca é a posição popular a ser adoptada na organização ser o prognosticador de desastres e fracassos, então escreve esta missiva com a plena compreensão de que o conteúdo cairá em ouvidos surdos e os benefícios potenciais de meus conselhos serão encontrados na pilha de “Eu gostaria que tivéssemos…” Há um tsunami de desastres de projeto se movendo rapidamente em direção à costa da empresa e não há muito que possa ser feito para detê-lo.  

O tipo de desastre de projecto de que estou falando não são aqueles que estão acima do orçamento e atrasados, mas sim os fracassos espetaculares que interrompem as cadeias de suprimentos, atrasam os relatórios financeiros e explodem as carreiras de executivos aparentemente competentes. Esses são os tipos de falhas que são criadas quando as empresas “go-live” com uma implementação que, em retrospectiva, será considerada feita de forma imprudente.  

4 prenúncios da desgraça

Por que estou tão convencido de que muitos projectos estão em rota de colisão com o fracasso? Considere o seguinte:

  • Dobre o volume . Há o dobro de grandes projectos em andamento programados para entrar em operação entre maio e setembro deste ano em comparação com um ano normal. Quando o COVID encerrou as coisas no início de 2020, muitas empresas suspenderam seus grandes programas de transformação habilitados para TI. No início de 2021, a barragem rompeu e grandes programas programados para começar em 2020 foram lançados em 2021. Ao mesmo tempo, as empresas que originalmente planejavam lançar programas em 2021 o fizeram. Voilá! Isso significa o dobro do número de desastres potenciais do projecto. Com cronogramas de entrega de implantação inicial em média de 12 a 18 meses para as principais iniciativas, a tabela foi definida.
  • Viés de recência. Quando foi a última vez que você leu sobre um grande fracasso no go-live de um projecto? Projectos como Select Comfort , National Grid , Cover Oregon ou Los Angeles Department of Water and Power (LADWP) estão fora do radar há alguns anos – tempo suficiente para desaparecer da memória do C-suite. 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 desastres, a ameaça potencial desaparece. Há uma razão pela qual todos nós dirigimos com mais cuidado depois de ver um acidente de carro.  
  • Vazios de talento Quase todos os grandes desastres de go-live podem ser atribuídos à falta de experiência por parte dos membros seniores da equipa do projecto. A capacidade de determinar e comunicar os riscos é obviamente fundamental para mitigá-los. Com o dobro de projectos em andamento, a capacidade dos Integradores de Sistemas (SIs) de trazer talentos altamente qualificados para todos os programas foi bastante reduzida. Junte isso com a “grande demissão” e as taxas de desgaste que dobraram nos últimos 6 meses, e você verá que o nível de consciência situacional nesses programas foi drasticamente reduzido.
  • Métodos não testados. Vimos muitos projectos lutando nas áreas de testes de sistemas integrados durante a pandemia. A fonte do impacto na produtividade é frequentemente rastreada até a falta de colocação das equipas de projecto. Sem estar juntos, os membros da equipa não são tão rápidos em aprender com seus vizinhos e dicas e truques não são transmitidos tão facilmente. Agora, avance rapidamente para após a implantação e considere o impacto potencial em milhares de usuários que podem não ter os superusuários na próxima cadeira para orientá-los durante a inicialização. Não há razão para acreditar que as mesmas dificuldades que vimos nos testes seriam milagrosamente curadas após a implantação.

Como evitar desastres de TI

Existem maneiras de evitar o tsunami de desastres? A resposta em conjunto é, infelizmente, não. O dado foi lançado. Existem táticas que podem ser implementadas em programas individuais para prevenir um desastre? Felizmente, essa resposta é sim. Aqui estão algumas recomendações simples:

  1. Torná-lo real. Peça ao seu SI para montar uma apresentação sobre as lições aprendidas com os principais desastres do programa . Não há necessidade de você ser o ‘mensageiro que leva um tiro na praia’. Leve esta apresentação ao comitê direcção o quanto antes para demonstrar que você está tomando as medidas apropriadas para proteger o negócio.  
  2. Estabeleça critérios de go-live com antecedência. Demasiados programas compõem os critérios de portão 2-3 meses antes do go-live pretendido. Quando esse é o caso, o critério passa a ser “O que podemos alcançar antes da entrada em operação” em vez de “Onde devemos estar?” Isso é particularmente verdadeiro para projetos que estão sob estresse orçamentário.
  3. Visão independente. ‘Go-live’ ou ‘febre do cume’ é real – basta perguntar a qualquer uma das famílias daqueles que perecem tentando alcançar o pico de uma montanha. O bom senso é facilmente obscurecido por avaliações de custos irrecuperáveis ​​e planeamento injustificado do melhor cenário. Uma visão independente pode ser muito preocupante.

Eu percebo que esta abordagem é provavelmente um pouco deprimente ou pode ser percebido como simplesmente sensacionalismo, mas se ele colocar as rodas em movimento para evitar o desastre, mesmo que seja um projecto, valeu a pena”, Disse.

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *