Vemos muitas discussões em torno da tripla restrição (escopo – tempo – custo). O fato é que ninguém quer ter seus projetos atrasados ou acima do orçamento. Fomos condicionados a essa mentalidade. É algo difícil de quebrar.

Nas últimas semanas, estive revendo os livros e artigos de Eliyahu Goldratt, cuja leitura recomendo fortemente a todos os gestores, de projetos ou não. Os livros A Meta, Corrente Crítica e Não é Sorte deveriam ser livros de cabeceira de todo gerente. Goldratt combate a “mentalidade de custos”, pregando que ela deve ser substituída por uma “mentalidade de ganhos”.

Os ganhos precisam ser vistos globalmente, do ponto de vista da organização. Buscar um ótimo global, não ótimos locais. Pequenas melhorias que tragam eficiência para partes de um sistema não necessariamente se traduzem em um sistema mais eficiente. Já tratamos disso em outros posts. A corrente crítica é uma maneira poderosa de tratar o gerenciamento de projetos. O grande problema é que a maioria das pessoas não aplica corretamente.

Toda ferramenta ou técnica possui premissas, restrições e condições de contorno. Aplicar Corrente Crítica não é apenas cortar as tarefas em 50% e adicionar um buffer de 25%. Uma mudança cultural é necessária. Dê uma olhada nos posts a seguir, são uma introdução ao assunto:

• MÉTODO DA CORRENTE CRÍTICA – O QUE É?
• APLICANDO CORRENTE CRÍTICA

Mas, se você quer realmente aplicar corrente crítica, vá beber na fonte: leia os livros de Goldratt. Além disso, existem vários white papers e artigos sobre a aplicação da corrente crítica e estudos de caso. Veja os artigos abaixo:

• Corrente Crítica: Uma Alternativa à Gerência de Projetos Tradicional
• Teoria das Restrições Aplicada à Gerência de Projetos
• Corrente Crítica

Agora vamos ao grande dilema do gerente de projetos: quão detalhadas devem ser as tarefas no cronograma?

Eu vejo gerentes de projetos criando listas “infinitas” de tarefas todos os dias. Usualmente, o gerente começa pelas tarefas-resumo ou fases e depois vai criando uma hierarquia de pacotes de trabalho até que chegue às tarefas propriamente ditas. Um erro comum é colocar as predecessoras ao mesmo tempo em que estamos criando a lista de tarefas.

Vamos revisitar os processos para construir o cronograma:

1. Criar EAP (Escopo) – definir o trabalho do projeto em termos de uma estrutura hierarquizada orientada a entregas;
2. Definir Tarefas – listar tarefas necessárias para realizar o trabalho contido na EAP, indicando tarefas necessárias para cada pacote de trabalho;
3. Sequenciar Tarefas – por que não devemos listar e sequenciar ao mesmo tempo? Sequenciar tarefas exige avaliar a real necessidade das predecessoras.
4. Estimar Recursos – pessoas, materiais, equipamentos etc necessários à execução das tarefas;
5. Estimar Durações – estimar durações das tarefas baseadas na disponibilidade dos recursos, fazendo a atribuição dos recursos às tarefas;
6. Desenvolver Cronograma – já teremos o cronograma e o orçamento preliminares neste momento. Desenvolver o cronograma significa fazer adequações, simulações e definir o cronograma “final”.

O grande problema é que os cronogramas parecem ser “escritos em pedra”. Uma vez que você entrega um cronograma aos stakeholders, particularmente ao patrocinador e ao cliente, ele passa a ser visto como “imexível”. Se você mudar a sequência das tarefas, eles vão questionar você. Se as durações mudarem, vão questionar. Se tiver novas tarefas ou se eliminar tarefas existentes, vão questionar…

Todavia, a prática de gerenciamento de projetos é dinâmica. O objetivo não é executar tarefas. O objetivo é entregar resultados e benefícios. Muitas vezes, não vale a pena investir tempo precioso detalhando tarefas. O gerente do projeto e sua equipe podem ser mais efetivos detalhando ao máximo as entregas e benefícios esperados. Afinal, o que os stakeholders querem são os resultados do projeto.

Imagine você na reunião de status do projeto. Você inicia apresentando as tarefas concluídas, atrasadas, questões etc. O diretor da sua área, provavelmente, vai pedir para você rapidamente dizer o que você entregou, o que não entregou (por que não entregou?) e o que vai entregar! Ninguém quer saber das centenas ou milhares tarefas do seu cronograma, eles querem resultados tangíveis, entregas, outputs do projeto. Apenas a equipe usa tarefas, como um guia, um mapa para produzir entregas.

E se você encontrar atalhos no meio do caminho? Você muda as tarefas ou não? Sim! Foco nas entregas! Ao final do projeto, ninguém quer saber de planos, documentos, cronogramas etc. As pessoas querem resultados e benefícios. Hartman (2000) cita exemplos de projetos que tiveram atrasos e estouros de orçamento consideráveis, mas que são vistos como sucesso porque seus benefícios superam os custos. Por outro lado, existem projetos que terminaram abaixo do orçamento e antes da data prevista, mas que são vistos como fracassos.

Portanto, uma maneira mais efetiva de gerenciar os projetos é através das entregas. O nível das tarefas deve ser transparente para os stakeholders fora da equipe do projeto. Trace um cronograma de fases, marcos e entregas.

Figura 1 – Combinando PRINCE2™ e Scrum.

Figura 2 – Estágios e sprints.

As figuras anteriores mostram uma combinação do PRINCE2™ com o Scrum. Também é possível combinar o Guia PMBOK® com Scrum, como nosso amigo Fábio Cruz fez em seu livro. O fato é que as tarefas do projeto são dinâmicas. As entregas, quando bem definidas, são mais estáveis. Isto é, sabemos quais são os objetivos, critérios de sucesso e requisitos, depois vamos definir as especificações e construir o produto.

Será que existem ferramentas melhores para gerenciar os nossos projetos do que o onipresente Gráfico de Gantt? Como você gerencia os seus projetos?