O pior tipo de projeto: o fracasso bem-sucedido

Projetos tecnológicos de alto nível são geralmente um dos elementos mais importantes das responsabilidades de um líder tecnológico. Esses projetos promovem a agenda estratégica mais ampla da organização, impulsionam mudanças, integram aquisições ou outras tarefas críticas. Eles também geralmente estão sujeitos a um escrutínio organizacional significativo. Os líderes e as suas equipas estão sob constante pressão para satisfazer a necessidade de entregar resultados atempadamente e dentro das restrições orçamentais e de âmbito.

Historicamente, as filosofias de gestão de projetos e programas resumiam-se a variações do modelo de “restrição tripla”, em que os líderes geriam, em última análise, a interação entre custo, prazo e âmbito do projeto. Geralmente, os líderes poderiam controlar um ou dois desses fatores. Por exemplo, se o âmbito fosse aumentado e o prazo encurtado, os custos provavelmente aumentariam. Da mesma forma, se um cronograma rápido e um orçamento limitado estivessem disponíveis, o escopo precisaria ser cuidadosamente controlado para atingir esse objetivo.

Esta linha de pensamento funcionou bem para entregar projetos que foram sucessos técnicos e orçamentários, onde o escopo planejado foi entregue dentro de um cronograma e orçamento aceitáveis. No entanto, um sucesso técnico nem sempre significa que um projeto seja um verdadeiro trunfo para a organização. A maioria dos líderes de TI experimentaram um “fracasso bem-sucedido” em algum momento de suas carreiras, onde “marcaram as caixas” do modelo de restrição tripla, mas entregaram algo que não atendeu aos objetivos estratégicos da organização ou não conseguiu obter a adoção pelo usuário final. .

Definindo o fracasso bem-sucedido

Assim como construir uma casa perfeita que os ocupantes odeiam devido ao design ou ao layout do cômodo, as falhas bem-sucedidas geram um resultado executado corretamente que, em última análise, não resolve o problema certo.

Essa quebra geralmente ocorre devido a alguma combinação dos seguintes fatores:

• O problema de negócios foi mal definido ou definido incorretamente, resultando na resolução do problema errado pelo projeto
• O ambiente e o mercado mudaram durante a implementação do projeto, fazendo com que o projeto entregasse uma resposta ao problema empresarial de ontem, mas não ao problema empresarial de hoje.
• As dificuldades com a adoção do resultado do projeto não foram consideradas adequadamente, geralmente devido ao treinamento deficiente ou a uma variedade de fatores agrupados no grupo de “gestão de mudanças”.
• Uma alternativa atraente para o projeto foi encontrada ou já existia, o que permitiu ao usuário final ignorar efetivamente os resultados do projeto
• O projeto estava muito focado em uma tecnologia nova ou “legal” e não resolveu um problema comercial útil
• O projeto perturba ou põe em risco a subsistência de alguém, por exemplo, ao remover um fluxo de receitas importante, criando oposição ativa

Esses fatores são complexos e cheios de nuances e exigem a maior parte do foco e da diligência de um líder. Presumir que ninguém se opõe ativamente a um slide de termo de abertura do projeto elaborado por seu analista júnior não é o mesmo que examinar minuciosamente o problema de negócios que seu projeto está resolvendo e garantir que você está construindo a solução certa para esse problema.

Evitando o pântano do gerenciamento de projetos

Indiscutivelmente, muito foco no gerenciamento de projetos está em seus aspectos técnicos, e as várias certificações e organizações de gerenciamento de projetos que desenvolvem diferentes metodologias concentram-se principalmente nesses detalhes. Muitos líderes de TI se destacaram no gerenciamento de programas complexos, e é fácil recorrer a preocupações com elementos da EAP, scrum masters e registros de problemas, em vez de enfrentar desafios mais difíceis em torno da compreensão da verdadeira natureza de um problema de negócios e tomar decisões difíceis se o ambiente muda e torna discutível o seu programa de outra forma bem-sucedido.

Os projetos de TI têm a complexidade adicional de lidar frequentemente com tecnologias ou fornecedores novos ou inovadores que apresentam seus produtos como uma “solução” sem verificar minuciosamente se a implementação está visando o problema certo.

Os modelos de desenvolvimento de software e gerenciamento de projetos tornaram-se em grande parte uma “ciência consolidada” e é mais fácil do que nunca encontrar funcionários, parceiros e fornecedores que executem projetos com proficiência, economia e dentro do prazo. Como líderes, deveríamos dedicar o nosso tempo a investigar o “porquê” de qualquer projecto que concordemos em abordar, independentemente de quão interessante seja a tecnologia ou quão próximo seja o orçamento.

Essa diligência em compreender o problema muitas vezes é ignorada, especialmente se a ideia do projeto foi válida em algum momento. Isto torna-se ainda mais agudo à medida que a sua organização avança do debate do problema para as discussões emocionantes e energizantes sobre “como” e “como o financiamos”. Embora não tenha sido declarado, é francamente muito divertido estar envolvido num esforço complexo, com muitas pessoas contribuindo avidamente para discussões sobre como avançar. Pode ser difícil pausar o impulso e examinar o terreno que já foi pisado. No entanto, é por isso que temos líderes.

Substitua a Carta por uma Declaração do Problema e Revisão Regular

Um termo de abertura de projeto eficaz pode, de facto, ajudar a identificar quando um projeto já não cumpre os seus objetivos. Ainda assim, muitas vezes são documentos vagamente redigidos, feitos para marcar uma caixa, em vez de servirem a uma função vital. Em vez de um estatuto, considere escrever uma declaração do problema que articule claramente qual problema de negócios o projeto pretende resolver. Para tornar este processo eficaz, são realizadas revisões regulares mensalmente, onde as partes interessadas devem defender se a declaração do problema ainda é válida.

Para tornar este processo ainda mais eficaz, considere articular potenciais mudanças ambientais ou de mercado que tornariam a declaração do problema inválida quando o documento fosse criado. Por exemplo, um grande projeto de consolidação tecnológica pode tornar-se inválido se a empresa for adquirida ou se os serviços em nuvem atingirem um determinado preço.

Avaliar o seu projeto em relação à definição do problema e a esses “modos de falha” identificará antecipadamente uma potencial “falha bem-sucedida”, enquanto ainda há tempo para redirecionar o projeto ou redistribuir os recursos para uma prioridade mais alta. Isso pode exigir muita maturidade por parte do líder, uma vez que você está efetivamente questionando e potencialmente interrompendo um esforço que parece atender a todos os critérios externos de sucesso. No entanto, se a declaração do seu problema foi bem elaborada e compartilhada, ela pode servir como um “indicador de tempo limite” em vez de exigir que você gaste capital de liderança para pausar e potencialmente encerrar um projeto.

Ter os processos de gestão e a liderança necessários para mitigar “fracassos bem-sucedidos” pode parecer derrotista, mas serve um propósito duplo. Você não apenas evitará gastar dinheiro em um esforço que, em última análise, não tem valor, mas também aliviará sua organização do suporte a novos sistemas ou processos que não estão entregando o retorno esperado.

Ninguém quer presidir a um fracasso, muito menos a um projeto executado com sucesso que acaba falhando na lentidão organizacional pós-implementação. No entanto, com premeditação e definição da definição do problema que você está tentando resolver, você pode evitar “fracassos bem-sucedidos” e dedicar sua energia e recursos onde eles são mais necessários.