Por que os Projetos Falham? Uma Visão Geral dos Fatores e Soluções Eficazes

“É o Jim da Gerência de Projetos – mas não como você conhece”

Nossa intenção com esse artigo é fornecer uma visão geral dos principais fatores que contribuem para a falha dos projetos e uma sugestão de soluções eficazes. Em seguida, lançaremos uma série de artigos detalhando essas soluções e fornecendo orientação para melhorar seus processos atuais.

Vários estudos sobre o sucesso da Gestão de Projetos em diferentes setores demonstraram um problema em comum: os projetos normalmente têm taxas de falha muito maiores do que as taxas de sucesso. Como já mostraram estudos após estudos, bem mais de metade das vezes os projetos falham em entregar seus resultados no prazo, com a qualidade esperada e dentro do orçamento, devido à Gestão de Projetos ineficaz (1). Assim, as empresas estão começando a perceber a necessidade de investir mais tempo e esforços na melhoria de seus padrões de Gestão de Projetos. A filosofia Lean oferece a plataforma para tais melhorias e, mais importante, traz a significância de desenvolver uma cultura adequada (com o comportamento correto) para dar suporte a elas.

Há vários problemas que podem impactar negativamente o resultado de um projeto; estes são os mais relevantes (e críticos):

1. O desenvolvimento de um Business Case não é uma opção – é uma necessidade!

A termo de abertura (Project Charter) do projeto é um produto de uma análise de negócios, também chamada de Business Case. Um Business Case é normalmente realizado para determinar, de um ponto de vista do negócio, se o projeto vale ou não o investimento exigido. Geralmente, o Business Case inclui o resultado de um negócio e uma análise de custo-benefício. Esses resultados ajudam não apenas a tomada de decisões dos executivos, mas também ajudam a estipular limites para o projeto e objetivos relevantes.

Muitas empresas apenas dão uma pincelada sobre essa etapa do processo, pulando diretamente para o desenvolvimento do Project Charter com objetivos arbitrários; outras desenvolvem Business Cases vagos com base em informações que podem ser enganosas e resultarem em decisões incorretas. Sem uma avaliação profunda do cenário atual do negócio, riscos e oportunidades, é muito difícil estabelecer o potencial real do projeto e a viabilidade de alcançar os objetivos.

O potencial do projeto e os limites são normalmente determinados através de investigação de dados (análise de perdas ou valor agregado) ou desempenho comparável (análise comparativa), dependendo do cenário do projeto. “A lacuna entre os estados atual e futuro desejado precisa ser claramente identificada, assim como razões”, diz Gert Haar-Jorgensen da Lean Coaching, “Isso mostrará o que pode ser alcançado e como, em um prazo pré-definido.” Por último, ele acrescenta, “É importante dizer que uma análise de projeto não pode ser concluída atrás de uma mesa ou em uma sala; você precisa ir e ver os processos, confirmar os dados e conversar com as pessoas envolvidas. É isso que dará validade ao Project Charter e também criará apoio em um estágio inicial”.

2. Um Project Charter mal desenvolvido leva a um Plano de Gestão de Projeto fraco.

Um Project Charter é mais do que um documento autorizando a existência de um projeto, é um documento que define a direção, expectativas e limites para o projeto através da definição de:

  • Requisitos de projeto de alto nível (propósito, requisitos de negócios)

  • Objetivos de projetos SMART

  • Breve resumo do cronograma de etapas

  • Organização do projeto – a lista de todos os interessados, incluindo Patrocinador(es) principal(is) e Gerente de Projetos com funções e responsabilidades claras

  • Mecanismo de relatórios e ferramentas de Gestão visual (estrutura de reuniões, agenda, entradas e saídas)

  • Processo de escalonamento

  • Comportamento da equipe

Esse documento fornece ao Gerente de projetos a autoridade para aplicar recursos organizacionais às tarefas do projeto e funciona como uma linha de base para a criação do Cronograma Mestre do Projeto. Um Project Charter bem definido fornece as informações necessárias para o desenvolvimento do Plano de nível 1 (Cronograma Mestre do Projeto ou Plano de Implementação Sumarizado) e Plano de nível 2 (Plano de Implementação Funcional).

As organizações frequentemente não dão a importância devida ao estabelecimento de um Project Charter claro. A maioria das organizações não tem um procedimento padrão para criar um Project Charter, por isso, é comum ver:

  • Um documento vago, difícil de ser usado como referência para o planejamento

  • O mesmo conteúdo do Project Charter para tamanhos diferentes de projetos (sem escalabilidade)

  • Projetos sem controle devido a uma configuração pobre da Organização do Projeto e seu nível de autoridade

Do Business Case ao Project Charter, os projetos devem ser primeiramente classificados com base em seu tamanho, e então comparados a uma Matriz de escalabilidade pré-definida. A Matriz de escalabilidade define, de acordo com o tamanho do projeto, as ferramentas de Gestão Visual, o nível de Organização do Projeto e o tempo necessário para a equipe em um projeto. “Isso é desenvolvido com o objetivo de definir um padrão “Lean” (evitando desperdício) para os projetos, com base em seu tamanho”, diz Gert Haar-Jorgensen da Lean Coaching, “Isso proporciona orientação clara para o desenvolvimento do Project Charter e o planejamento inicial do projeto”, acrescenta.

Um Project Charter robusto ajuda no desenvolvimento de um Plano de projeto forte. “O Project Charter estabelece os principais marcos do projeto dentre os objetivos do projeto”, diz Gert, ”Estes marcos ajudam não apenas a impulsionar o progresso, mas também a colocar a solução antecipada de problemas no projeto”.

3. Todos os projetos têm marcos, eles apenas não são levados tão a sério como deveriam.

Um objetivo fundamental dos projetos é tornar os problemas visíveis e resolvê-los no início – enquanto ainda estão “no papel” e são mais baratos e mais rápidos de consertar – e não no final do projeto. No entanto, é comum ver o acúmulo de problemas não resolvidos nos marcos relevantes, e eles só são resolvidos (de forma subotimizada), quando a despesa ou manifestação física inevitavelmente se tornar clara perto do prazo de entrega. No pior caso, os problemas apenas aparecem com o feedback do cliente. “Esse “deslize” é normalmente devido a um ou mais dos seguintes motivos: 1) falta de resolução/disciplina, 2) falta de capacidade na Gestão Lean de Projetos, por exemplo, inexistência de um processo do tipo pare a linha/Andon, para apontar e agir com contramedidas em relação aos problemas e/ou 3) Falta de transparência do status do projeto, através de atualizações frequentes”, diz Gert Haar-Jorgensen da Lean Coaching.

Assim, os objetivos definidos no Project Charter devem ser traduzidos em marcos agressivos no Cronograma/Plano de projeto e o progresso revisado frequentemente, o status visualizado e monitorado através de KPI’s, juntamente com o uso da abordagem PDCA-R (Planejar, Fazer, Verificar, Agir e Refletir). “Os back-spikes (2) para desvios do planejamento e dos objetivos dos KPI’s, impulsionam a solução de problemas”, diz Gert. “O uso de miniciclos de PDCA” durante o projeto suporta a identificação antecipada de desvios e eliminação da causa raiz dos problemas, resultando no atingimento de seus objetivos e identificando antecipadamente o potencial do negócio”.

4. A função dos PM’s frequentemente vai além de sua obrigação – A culpa não é dele/dela!

Em muitas organizações atualmente, a função de PM (Project Manager) não é mais considerada muito desejável. Geralmente, os PM’s são culpados por muito mais do que eles são responsáveis; eles lideram projetos e logo estão sobrecarregados com responsabilidades que idealmente devem ser compartilhadas em uma organização de projetos pré-estipulados. Essa situação não apenas define as expectativas erradas para os acionistas (especialmente para patrocinadores de projetos), mas também cria estresse desnecessário e as condições ideais para o PM fracassar e, assim, o projeto.

Apesar de os PM’s terem responsabilidade geral pelo projeto, eles não podem ser os únicos responsáveis por seu sucesso ou fracasso. O PM gerencia o projeto em nome dos patrocinadores do projeto, comumente representados pelo Comitê de Direção. Ele/ela é responsável pela coordenação do projeto e pela execução e transparência – as direções gerais de trabalho do projeto, o alinhamento e a sincronização das atividades para as funções primária e de suporte, o relatório periódico do status do projeto e o escalonamento dos problemas relevantes para o Comitê de Direção. Portanto, o PM compartilha a responsabilidade pelo projeto com seu Comitê de Direção, gerenciando a organização do projeto e a execução de atividades. “Os patrocinadores, através do PM, delegam responsabilidade para as funções organizacionais (para um “Representante”) pelo qual ele/ela é responsável, então eles se tornam responsáveis por atingir seus objetivos e plano funcional. Ele/ela compartilha a responsabilidade com o PM pelo que será entregue”, diz David Hurst da Lean Coaching.

Juntamente com a definição da função do PM, a organização de um projeto deve também ser definida (e documentada no Project Charter). O estabelecimento da organização de um projeto baseia-se em seu tamanho e escopo; no entanto, é geralmente composto por um Comitê de Direção, um PM, funções primárias (responsáveis pela entrega do projeto como um todo) e funções de suporte (provedores de serviço para as funções primárias). Individualmente, todas essas funções têm suas responsabilidades no projeto, auxiliando a conclusão de cada marco e o atingimento dos objetivos gerais.

5. Nenhum local para a realização das reuniões = Nenhuma visibilidade + Nenhuma responsabilidade = Falta de controle

Frequentemente, os planos de um projeto são preparados em MS Project e mantidos eletronicamente para consulta de status, atualizações e alterações. O principal problema com isso é a falta de visibilidade e transparência que isso dá ao projeto. “É impossível manter a equipe inteira engajada e envolvida com o andamento do projeto, alterações, problemas e ações sem um local para a realização das reuniões”, diz Gert. A Obeya, também chamada de War Room é onde os planos de nível 1 e nível 2 são exibidos regularmente pelo representante da função primária e pelo PM. Isso fornece visibilidade de todas as atividades ligadas aos objetivos gerais do projeto. Idealmente, qualquer um na organização deveria ser capaz de entender o status de um projeto em 30 segundos e em 3 minutos identificar o desvio, as contramedidas e quando ele estará dentro do cronograma novamente”, diz Gert.

Em um Projeto Lean, os planos de níveis 1 e 2 são criados no formato de um Plano de Implementação Tático (TIP) criado eletronicamente, mas impresso quando concluído e atualizado manualmente em intervalos regulares. “O processo de revisão manual cria senso de dono e visibilidade para os problemas através de back-spicks”, diz David Hurst, que vem usando essa abordagem há mais de 20 anos como Gerente Geral da Toyota, “Os back-spikes mostram todos os desvios do plano e exigem ações, antes que os prazos sejam impossíveis de serem recuperados.”

Revisões regulares e estruturadas (no Obeya) estabelecem o controle necessário para o projeto. A frequência é definida de acordo com o tamanho do projeto e a prioridade. Normalmente, grandes projetos são revisados semanalmente entre o PM e os Representantes, mensalmente entre o PM e o Comitê de Direção e trimestralmente entre o patrocinador, o PM e o Conselho (para todos os grandes projetos). “Estas revisões frequentes criam responsabilidade pela execução das tarefas do projeto e mais pressão na implementação de ações corretivas”, diz David, “Isso evita que aconteça “a síndrome do aluno” no projeto, isto é, deixar ações/progresso para a última hora”. Estas revisões também são usadas para o critério claro de escalonamento para que problemas relevantes possam ser priorizados.

6. Lições Aprendidas com o projeto devem ir além de serem documentadas.

A abordagem PDCA não está completa sem o estágio de “Reflexão”, também chamado de Lições Aprendidas. Nesta etapa, a equipe do projeto deve identificar e refletir sobre os pontos fracos e fortes (gerencial, sistêmico e funcional) que impactaram o sucesso do projeto. “O principal objetivo deste processo é capturar e formalizar as ações de monitoramento exigidas para melhorar os padrões “o melhor de hoje” no projeto”, diz Danielle Browne da Lean Coaching. Uma parte crucial da Reflexão é gerenciar as alterações identificadas de maneira estruturada, considerando seu impacto geral em outras atividades e confirmar seu resultado através da revisão dos KPI’s e Genchi Genbutsu (abordagem de Vá & Veja). “Esse processo é chamado Keshikomi e é usado para gerenciar mudanças de maneira eficiente com foco na melhoria do desempenho do projeto, ao invés de deteriorá-lo”, diz Danielle, “Keshikomi é parte do padrão da organização para os tipos individuais de projetos”, acrescenta.

O processo de Reflexão é frequentemente subvalorizado pelas organizações. Muitas delas documentam as lições aprendidas no final dos projetos apenas como parte do processo padrão formal e sem perceber as oportunidades que a atividade tem para oferecer. “Quando apenas documentadas, as lições aprendidas perdem seu poder de ajudar a proteger a eficácia e se tornam apenas história”, diz Danielle. “Sem colocá-las de volta nos padrões do projeto, o processo não tem validade”.

Resumo

O sucesso de um projeto depende da execução detalhada e disciplinada de várias atividades antes, durante e depois de sua conclusão. Essas atividades devem funcionar em harmonia para atingir sucesso; a realização precária de uma atividade coloca todo o projeto em risco de fracasso. O pensamento Lean oferece a abordagem de referência (e estrutura) para os projetos, focando não apenas nas ferramentas e métodos fundamentais, mas também nos comportamentos necessários para atingir desempenho máximo e sucesso. A abordagem PDCA-R ajuda a estruturar projetos através do uso de padrões, forte resolução de problemas e práticas de melhoria contínuas. Esses princípios básicos beneficiam não apenas projetos atuais, mas também futuros, melhorando continuamente as atividades do projeto e a eficiência geral, entregando o impacto dos negócios de maneira consistente.

(1) Back-spike é uma representação visual de um atraso de uma tarefa ou marco em um plano.

(2) Matta, N. F. & Ashkenas, R. N. (Set, 2003). ‘Por que bons projetos falham’. De The Magazine – Harvard Business Review. Recuperado de http://hbr.org/2003/09/why-good-projects-fail-anyway/ar/1#disqus_thread