Como Evitar o Fracasso de um Projeto em 3 Passos + 4 Estudos de Caso
Há muitas razões pelas quais os projetos falham, mas praticamente todas se resumem a uma de duas coisas (por vezes, a ambas):
- Havia um risco que ninguém reconheceu e/ou
- Não respondemos adequadamente quando surgiu um problema
Neste artigo, quero centrar-me na visão geral para ajudar a abordar a principal causa do fracasso dos projetos — e, muitas vezes, da gestão de projetos.
Eis como evitar o fracasso de um projeto e o que fazer se esse problema catastrófico que não previu vier a acontecer (ainda pode conseguir resolver a situação se agir de forma rápida e ponderada!).
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
O que é o fracasso de um projeto?
É exatamente o que parece — sempre que um projeto não cumpre os objetivos definidos pela equipa no início, não corresponde às expectativas do cliente ou das principais partes interessadas, ou não respeita o prazo, o orçamento ou o âmbito.
Porque falham os projetos?
Como mencionei na introdução, existem várias razões comuns pelas quais os projetos podem falhar. Normalmente, tal deve-se a um risco que não foi devidamente avaliado e/ou ao facto de a equipa (incluindo o gestor de projeto) não ter respondido adequadamente ao risco.
Outras causas comuns do fracasso de um projeto podem incluir uma comunicação deficiente sobre o estado, os problemas ou os riscos; membros da equipa que não cumprem o âmbito do projeto (ou que não o compreendem devidamente), os resultados do projeto (ou seja, o alargamento descontrolado do âmbito) ou o prazo; a falta de recursos; ou o não cumprimento dos processos ou metodologias definidos.
Como evitar o fracasso de um projeto: 3 passos
A gestão de riscos é uma atividade essencial da gestão de projetos. É tão importante que a incapacidade de gerir os riscos equivale muitas vezes ao fracasso da gestão do projeto. A gestão de riscos tem três componentes importantes:
- Identificar os riscos.
- Avaliar o que identificou: Qual é a probabilidade de acontecer e quão graves serão as consequências se acontecer? Qual é a probabilidade e qual será o impacto?
- Preparar planos de mitigação e de contingência para os riscos que poderiam comprometer o seu projeto, que de outro modo seria bem-sucedido. Os registos de riscos são úteis para acompanhar aquilo que fez.
1. Identificar os riscos
Em primeiro lugar, identifique os riscos. Fazê-lo bem aumentará significativamente as suas probabilidades de sucesso do projeto. E, embora seja difícil detetá-los todos, se analisar o projeto de forma sistemática, geralmente conseguirá identificar os maiores riscos. Normalmente, esta é uma parte do processo de criação de um plano de projeto.
A minha experiência é em desenvolvimento de software, tanto de produtos como de tecnologias de informação, e nos processos associados. Os projetos de software são complexos e frágeis e, salvo em alguns casos raros, não têm o tipo de mecanismos de segurança e inspeções integrados que existem, por exemplo, na construção ou na produção de dispositivos médicos.
Deve definir objetivos do projeto para cada um dos quatro indicadores:
- Calendário
- Conteúdo
- Custo
- Qualidade
Se não souber quais são, esse é o seu ponto de partida. Normalmente, verifico que dois dos quatro variam um pouco, mas quanto mais compreender para onde se dirige, mais fácil será identificar os obstáculos.
Compreender qual dos quatro indicadores é prioritário ajudá-lo-á a reduzir os riscos, fazendo compromissos adequados em pequenos aspetos.
É fácil ficar demasiado concentrado no indicador do calendário do projeto e não detetar riscos que possam afetar os outros indicadores, mas todos estão relacionados e é importante identificar todos eles.
Cumprir os objetivos do calendário com um produto cheio de erros geralmente não é uma boa opção — mesmo que o lance, acabará por ter de fazer versões de correção que irão atrasar o calendário de um produto adequado mais do que teria acontecido se tivesse resolvido o problema desde o início.
Para além dos 4 indicadores
Para além dos quatro indicadores, há três aspetos do seu projeto que deve equilibrar:
- Produto, que normalmente é abrangido pelos indicadores
- Processo
- Pessoas
Os riscos relacionados com os processos assumem duas formas: uma inadequação de um processo existente, que não responde às necessidades do seu projeto, e a falta de um processo para algo crítico para o trabalho da sua equipa. Os riscos relacionados com os processos são relativamente fáceis de mitigar, criando ou corrigindo o processo.
A componente humana é frequentemente ignorada, mas a sua equipa e as equipas com as quais interage farão com que o seu projeto seja bem-sucedido ou fracasse. Partes interessadas no projeto difíceis ou desinteressadas tornarão mais difícil obter aquilo de que precisa para avançar.
Membros da equipa sobrecarregados, stressados ou descontentes não conseguirão realizar o trabalho. Alguns dos potenciais problemas relacionados com as pessoas podem ser identificados publicamente; outros poderá querer abordar em privado, mas não cometa o erro de os ignorar.
2. Avalie os riscos que identificou
Depois de identificar os riscos, determine a probabilidade de o risco ocorrer. Normalmente, utilizo uma percentagem — 100% significa que tenho a certeza de que irá ocorrer. Também é importante determinar a gravidade das consequências caso o risco ocorra. A forma mais fácil de o fazer é categorizar os riscos como elevados, médios ou baixos.
Depois de concluir esta análise, é altura de envolver a sua equipa. Pergunte a cada membro da equipa do projeto ou colaborador aquilo que o preocupa, acrescente esses aspetos à lista de riscos e apresente-a para análise:
- A equipa consegue identificar outros riscos que não tenha abordado?
- O que pensa da análise da probabilidade e do impacto?
Com base nesta reunião, pode fazer ajustes ao seu plano de riscos. As partes um e dois estão concluídas — por agora. Terá de rever os riscos pelo menos semanalmente para verificar se existem novos riscos, se há alguns que já não são aplicáveis e se alguma probabilidade ou impacto se alterou.
3. Prepare planos de mitigação e contingência
Por fim, se a combinação da probabilidade e do impacto de algum risco tiver potencial para fazer descarrilar o seu projeto, trabalhe com a sua equipa para elaborar planos documentados de mitigação e contingência.
A mitigação consiste em tornar o risco menos provável ou em reduzir o seu impacto caso ocorra. A contingência centra-se nas medidas que irá tomar se o risco for inevitável e ocorrer.
Certifique-se de que os planos estão documentados e de que todos têm conhecimento deles. Também é boa ideia planear potenciais problemas relacionados com as pessoas, para além dos 4 mostradores e do processo, mas provavelmente deverá fazer essa análise sozinho e mantê-la confidencial.
Como sobreviver ao fracasso de um projeto
A segunda razão para os fracassos na gestão de projetos é uma resposta inadequada à concretização de um risco do projeto, previsto ou não. Isto depende sobretudo de si enquanto gestor de projeto. Antes de executar qualquer uma das etapas abaixo, comece por estas 2 dicas:
- Não entre em pânico. Lembre-se de respirar.
- Não culpe ninguém e não deixe que mais ninguém enverede pelo caminho da culpabilização.
1. Consulte o seu plano de contingência
Se tiver um plano de contingência implementado, convoque imediatamente uma reunião ou, pelo menos, envie um e-mail a ativar o plano de contingência. Recorde às pessoas qual é o plano e diga a todos quando e como devem comunicar o estado.
Se ignorar esta etapa ou a adiar, descobrirá que as pessoas ansiosas por ajudar já começaram a intervir em modo de pânico; quando isso acontece, perde o controlo sobre o que foi feito e, muitas vezes, o problema agrava-se.
Se não tiver um plano de contingência, reúna imediatamente a equipa através de um aviso de reunião e de instruções rigorosas para NÃO FAZEREM MAIS NADA até depois da reunião.
Caso contrário, todos tentarão ajudar e não fará ideia do que foi feito. Na reunião, exponha claramente o problema — é sempre surpreendente verificar quantas ideias diferentes as pessoas têm sobre aquilo que é o problema.
Faça uma análise consolidada da causa-raiz para compreender a origem do problema e elaborar o plano — quem, o quê e como — para recuperar a situação. Ao trabalhar numa análise da causa-raiz, precisa de compreender quem fez o quê antes de o problema ocorrer, mas mantenha a discussão nesse nível.
Por outras palavras, apenas os factos. Não atribua culpas, pois apontar o dedo é uma distração. Se a sua equipa não conseguir encontrar a solução, tem algumas opções.
A primeira é chamar alguém que conheça o assunto em geral, mas que não esteja neste projeto específico — por exemplo, se o problema parecer estar relacionado com a base de dados, chame um administrador de bases de dados que não esteja atualmente no projeto, para obter uma perspetiva diferente.
Outra técnica consiste em chamar alguém sem qualquer conhecimento prático do projeto. Por vezes, ter de explicar explicitamente cada etapa revela pressupostos inadequados ou algo que as pessoas não estavam a considerar.
2. Resolva o problema
Certifique-se de que todos estão de acordo com o seu plano de ação e atribua tarefas. Peça às pessoas que lhe comuniquem os progressos e diga-lhes com que frequência devem enviar relatórios de progresso — de hora a hora, quando concluírem uma tarefa, no final do dia ou com qualquer outra periodicidade adequada à situação.
A comunicação de progresso pode parecer-lhe óbvia, mas não o será para todos. As atualizações regulares ajudarão a manter a equipa focada. Comunique regularmente o progresso consolidado a toda a equipa.
Os membros da equipa que não tenham tarefas imediatas começarão a ficar impacientes e, eventualmente, tentarão intervir e ajudar, a menos que lhes forneça atualizações sobre o estado e outras informações.
Também é muito importante manter a gestão informada. Use o seu discernimento para determinar quem precisa de atualizações e em que momento, mas comunique regularmente o progresso consolidado a toda a equipa.
3. Dê o trabalho por concluído
Quando estiver realmente concluído, claro. Elabore um relatório final e avance para a etapa seguinte. Dê à equipa algum tempo para recuperar.
4. Realizar uma autópsia ou retrospectiva
É importante concluir uma avaliação do projeto para recolher as lições aprendidas. Eis como estruturá-la:
- Exponha o problema para que todos estejam alinhados
- Comece pelo que correu bem. Mesmo na situação mais difícil, algo correu bem. Isto dá à reunião um tom completamente diferente desde o início.
- Fale sobre o que precisa de ser melhorado. Se houver tempo, pensem em conjunto em formas de implementar as melhorias; caso contrário, atribua tarefas e prazos e acompanhe essas datas.
Se a culpa tiver sido realmente de alguém, trate do assunto com essa pessoa — em privado. Se o fizer em público, toda a sua equipa ficará a perguntar-se quem será o próximo a ser humilhado publicamente.
Se a ignorar completamente, a sua equipa sentirá que alguém escapou impune e que o problema não foi resolvido. Seja factual e acompanhe quaisquer alterações aos processos pessoais que alguém precise de fazer. Tudo se resume a responsabilização e melhoria, não a encontrar alguém para culpar.
3 exemplos reais de falhas de projetos
Também já tive a minha quota-parte de falhas em projetos de TI, embora, felizmente — mas com muito esforço —, tenham sido recuperadas.
Eis alguns dos meus próprios projetos de TI e de desenvolvimento que falharam, bem como um exemplo de um projeto famoso que falhou.
Estes exemplos de falhas de projetos e estudos de caso de projetos que falharam também deverão dar-lhe uma ideia concreta das formas como os projetos podem falhar e de como lidar com essas situações.
1. O sistema de contabilidade
No início da minha carreira, trabalhei na IBM. O meu primeiro emprego a sério consistiu em assumir um sistema relativamente pequeno que alimentava os sistemas de contabilidade da empresa. Alguém na IBM tinha escrito esse sistema numa linguagem de programação obscura chamada RPG, num sistema de pequenas dimensões.
Não me limitei a gerir o projeto — geri todo o sistema (embora houvesse um administrador), incluindo a recolha dos requisitos do projeto, a resolução de problemas e a programação.
Um belo dia, instalei um novo programa, executei-o e encontrei um erro. Corrigi o erro e voltei a executar o programa. Na manhã seguinte, recebi uma chamada do pessoal da Contabilidade a informar-me de que havia lançamentos duplicados (isto é uma notícia muito má no mundo da contabilidade).
Em primeiro lugar, ninguém reviu o meu trabalho. Em segundo, não envolvi as pessoas responsáveis pelos sistemas subsequentes para verificarem os lançamentos antes de estes serem processados. E, em terceiro, não dediquei tempo a analisar alguns dos programas antigos que ainda estavam a ser executados e a criar lançamentos duplicados. Também não existia qualquer processo, exceto aquilo que eu ia improvisando à medida que avançava.
E depois veio a minha reação — pânico. Meu Deus, saído da universidade há pouco tempo e estou a arruinar o sistema de contabilidade da IBM. Não envolvi as pessoas certas — o administrador não sabia o que se estava a passar — e gerou ainda outro conjunto de lançamentos sem se aperceber. No final, trabalhei 48 horas seguidas para chegar à causa principal, corrigir o problema e escrever e executar programas para corrigir os erros de contabilidade.
E aprendi a lição — analisar cuidadosamente, obter revisões, pensar no que poderia correr mal e parar para pensar antes de avançar para tentar corrigir as coisas (tudo aspetos em que o software de gestão de projetos de contabilidade pode ajudar). Agora imagine que eu estava a gerir uma equipa de 10 pessoas e que todos faziam a mesma coisa ao tentar resolver o problema. Teria sido realmente impossível recuperar a situação sem desligar os sistemas de contabilidade da IBM para conseguir resolver o problema.
2. O novo produto interno
Enquanto consultor, estava a gerir um projeto novo e de grandes dimensões, com muitas pessoas a contribuírem para os requisitos, o que provocava alterações intermináveis nas prioridades funcionais. Estávamos a utilizar um processo ágil de gestão de projetos, que esta empresa nunca tinha utilizado. A garantia de qualidade era muito competente nos testes, mas ainda não compreendia a perspetiva e o fluxo de trabalho do utilizador final.
Eu tinha consciência de tudo isto e, ocasionalmente, explicava-o, mas não tinha um registo de riscos, nem uma avaliação do impacto/probabilidade, nem planos de contingência ou de mitigação. Também não era o principal canal de informação para a patrocinadora do projeto, embora me reunisse ocasionalmente com ela.
Acrescentámos um sprint. Depois, outro. E, quando se tornou claro que ainda não estávamos exatamente no ponto necessário para realizar um teste beta, acrescentámos um terceiro sprint.
Como não era eu quem fornecia informações à patrocinadora do projeto, não fazia ideia de que ela desconhecia tudo isto. A pessoa responsável cometeu o erro crítico de não informar a patrocinadora, na esperança de que conseguíssemos fazê-lo.
E, para ser justo, embora eu tivesse falado sobre os riscos, não lhe forneci um conjunto concreto de riscos para apresentar, de modo a preparar a patrocinadora para a possibilidade de um atraso no calendário.
No meio de tudo isto, tive uma reunião com a patrocinadora e fiz uma referência casual ao sprint final que iríamos acrescentar. Ela interrompeu-me. Não sabia nada sobre isso e não ficou nada satisfeita.
Como se veio a verificar, ficou mais aborrecida com a surpresa do que com o atraso no calendário. Houve repercussões públicas e, eventualmente, a pessoa responsável pelo projeto foi trabalhar para outra área da empresa, porque a confiança tinha desaparecido.
Mais uma vez, aprendi lições importantes com o fracasso. Conhecer os riscos não é suficiente; é preciso reuni-los, avaliá-los, ter planos de mitigação e de contingência e torná-los públicos e constantemente visíveis.
Nunca fui apologista de esconder riscos e problemas, mas a importância da transparência nos projetos tornou-se inequivocamente clara.
3. Lembra-se do OS2?
Não, ninguém se lembra. É um dos muitos projetos de desenvolvimento de sistemas que falharam. Estava a trabalhar na IBM quando surgiu o OS2 original—um concorrente do Windows. Nem sequer experimentei essa primeira versão, porque na IBM todos sabíamos que tinha muitos erros. O resto do mundo descobriu imediatamente que tinha demasiadas falhas para valer a pena.
Tinha erros suficientes para que a equipa do projeto não pudesse pensar que estava completamente pronto, mas, de alguma forma, não fez a escolha certa e não adiou o lançamento. Se não tiver em consideração o elemento humano, tanto a sua equipa como os seus clientes destruirão rapidamente um plano excelente.
No software, há várias alternativas para esta situação—fazer um lançamento limitado para pessoas dispostas a tolerar os erros para poderem utilizar software novo e de vanguarda, tornar público que está a aguardar até que a fiabilidade esteja à altura dos seus elevados padrões, etc.
Ainda estava numa fase suficientemente inicial da minha carreira para poder tirar lições valiosas do facto de um produto de que gostava ter chegado a um beco sem saída logo na segunda versão.
Seja claro quanto às suas prioridades—há alguns casos em que lançar numa determinada data é mais importante do que a qualidade do produto, mas não são muitos.
Utilize os seus 4 controlos e admita os seus erros; torne visíveis as correções para que as pessoas confiem que compreende o problema e que não cometerá o mesmo erro duas vezes.
Considere o elemento humano—é tão crítico como a tecnologia. A partir desse momento, levei estas lições para os projetos de software e de TI, e foram inestimáveis.
O essencial
De um modo geral, lembre-se de que, embora a responsabilidade final seja sua, não precisa de fazer todo o trabalho. Na verdade, não deve mesmo tentar fazê-lo sozinho. Pode beneficiar da vasta experiência e conhecimento da sua equipa. É o líder, mas não tem de ser toda a equipa.
O software de gestão de projetos e outras ferramentas de gestão de projetos podem ajudá-lo a acompanhar riscos, marcos, alocação de recursos e outros indicadores críticos que mostram se está no caminho certo para um projeto bem-sucedido.
