Ferramentas de gerenciamento de projetos: a técnica vem antes do software

Pergunte a uma equipe quais ferramentas de gerenciamento de projetos ela usa e a resposta vem em nomes de software. Jira, Trello, Project, Asana, Monday. Ninguém cita EAP, caminho crítico ou matriz de riscos, que são as ferramentas de verdade do ofício.

Essa troca de sentido é a tese deste texto. Ferramenta virou sinônimo de licença, e é por isso que tanta empresa compra assinatura e continua entregando atrasado. O software executa o que a técnica já decidiu. Quando não há técnica, ele executa a confusão com mais eficiência.

A consequência é direta. Equipe que não sabe decompor escopo não vai aprender a decompor dentro de uma tela. Ela vai ter um quadro com escopo mal decomposto, um cronograma sem dependência real e uma fatura mensal nova para justificar no fim do ano.

O artigo está partido em duas metades. Primeiro as técnicas, uma a uma, com o que cada uma resolve, o insumo que exige e o erro típico. Depois o software, com as categorias, os critérios de escolha e o motivo de tantas migrações fracassarem. A visão geral da disciplina está em o que é gerenciamento de projetos.

As tabelas e os exemplos numéricos foram montados para este artigo, no formato do Kit de Gestão de Projetos da Voitto. Os valores são ilustrativos, foram conferidos em planilha, são internamente consistentes e não descrevem um cliente específico.

Ferramenta não é software: o erro que custa a licença inteira

Ferramenta de gerenciamento de projetos é um método que transforma informação dispersa em decisão defensável. A estrutura analítica é ferramenta. A rede de precedências é ferramenta. O registro de riscos com resposta atribuída é ferramenta. O sistema onde tudo isso é digitado é infraestrutura.

A distinção parece acadêmica até a primeira crise. Quando o projeto atrasa, ninguém pergunta qual plataforma a equipe usa. Perguntam qual atividade está no caminho crítico, quanta folga sobrou e quem aprovou a mudança de escopo. São perguntas de técnica, e a tela não responde nenhuma delas sozinha.

O teste é simples. Tire o software da equipe por uma semana e veja o que sobra. Se sobra a lógica do projeto em um papel, a técnica existe. Se não sobra nada, a empresa estava alugando a aparência de controle.

Este texto é o aprofundamento das ferramentas dentro da disciplina. As dez áreas de conhecimento estão em áreas do gerenciamento de projetos e a sequência temporal está em fases de um projeto. Nenhuma das duas será repetida aqui.

As dez técnicas que formam o ferramental, em uma tabela

Esta é a tabela de referência da primeira metade. A coluna que mais importa não é a do que a técnica resolve: é a do insumo que ela exige. Ferramenta aplicada sem insumo produz documento bonito e decisão errada.

As seções seguintes abrem uma por uma, na ordem em que aparecem na tabela.

EAP: decompor até o pacote caber na mão de alguém

A estrutura analítica quebra a entrega em pacotes de trabalho até o ponto em que dá para estimar, atribuir e verificar. Não é lista de tarefas. É decomposição de produto, do todo para as partes, sem que nada de fora entre e nada de dentro suma.

O insumo é o escopo escrito com critério de aceite. Sem isso a decomposição vira invenção. A diferença entre escopo verificável e objetivo genérico está em escopo do projeto, e ela decide se a EAP nasce útil ou decorativa.

A regra prática de parada é o pacote entre oito e oitenta horas de esforço. Acima disso não se estima com confiança. Abaixo disso o controle custa mais do que a informação vale. O método completo está em EAP, estrutura analítica do projeto.

O erro típico é decompor por área. Marketing, TI, Operações. O resultado é um organograma disfarçado que não serve de base para cronograma nem para orçamento, porque ninguém entrega um departamento ao cliente.

Nenhum software resolve isso. A tela aceita um nível só de tarefas com a mesma alegria com que aceita cinco níveis bem pensados, e cobra igual pelos dois.

Rede de precedências: a ordem antes da data

A rede liga os pacotes por dependência. Cada seta responde uma pergunta: esta atividade precisa que aquela termine, ou apenas foi colocada depois no calendário? A resposta separa dependência obrigatória de preferência de agenda.

O insumo é a lista de atividades com as dependências reais, levantadas com quem executa. Gerente sozinho não sabe que o teste depende do ambiente liberado pela infraestrutura. Quem monta rede na sala fechada monta ficção com setas.

O erro típico é encadear tudo em sequência. Fica um cronograma linear, longo e frágil, que ignora as atividades que poderiam rodar em paralelo. A base conceitual do instrumento está em o que é cronograma.

Quatro tipos de ligação cobrem quase tudo: término para início, início para início, término para término e início para término. A primeira resolve a maioria dos casos. As outras três existem para quando a primeira mente sobre a realidade da operação.

Caminho crítico: onde o atraso vira atraso do projeto

O caminho crítico é a sequência mais longa de atividades dependentes da rede. Ele define a duração do projeto. Atrasar uma atividade nele atrasa a entrega final no mesmo tanto, sem negociação possível.

A conta é mecânica. Some as durações de cada caminho fechado entre o início e o fim, e o maior valor é o crítico. Um projeto com dois caminhos de 14 e 12 dias dura 14 dias, e o segundo caminho tem dois dias de sobra.

O erro típico é confundir crítico com importante. A atividade de maior orçamento costuma chamar mais atenção, mas se ela tem folga, atrasá-la não move a data final. A crítica pode ser uma assinatura de duas horas presa há três semanas.

O valor gerencial disso é brutal. Ele diz onde colocar a pessoa mais experiente, onde vale pagar hora extra e onde o gerente pode simplesmente não olhar por duas semanas. Sem caminho crítico, a atenção é distribuída por volume de reclamação.

Folga total e folga livre: as duas sobras que ninguém distingue

Folga total é quanto uma atividade pode atrasar sem empurrar a data final do projeto. Folga livre é quanto ela pode atrasar sem empurrar a atividade seguinte. São números diferentes, e a confusão entre eles gera promessa quebrada.

Um exemplo com números fecha a diferença. Uma atividade de seis dias começa mais cedo no dia 10 e termina no dia 16. O cálculo de trás para frente dá início mais tarde no dia 12 e término mais tarde no dia 18. A folga total é de dois dias.

Agora a sucessora. Se ela só pode começar no dia 17 por outra restrição, a folga livre é de um dia apenas. Atrasar dois dias não muda a entrega final, mas rouba o pulmão de quem vem depois e transfere a pressão para a próxima equipe.

O erro típico é consumir folga sem registrar. Cada atividade que come a sobra deixa o projeto mais rígido, e ninguém percebe até o dia em que qualquer imprevisto vira atraso direto na data prometida ao cliente.

Estimativa em três pontos: por que o prazo único sempre mente

Estimativa de ponto único esconde incerteza. Quando alguém responde doze dias, entrega um número que pode significar doze se tudo der certo ou vinte e oito se der errado. A técnica dos três pontos obriga a separar os cenários.

Pergunte três valores por atividade. O otimista, com tudo fluindo. O mais provável, com o dia normal da operação. O pessimista, com o que costuma dar errado. A fórmula PERT pondera os três, dando peso quatro ao mais provável.

A conta é a esperada igual a otimista mais quatro vezes o provável mais pessimista, tudo dividido por seis. O desvio padrão é o pessimista menos o otimista, dividido por seis. O corpo de conhecimento que formalizou esse uso está em gerenciamento de projetos pelo PMI.

O erro típico é pedir os três valores e usar só o otimista, porque ele cabe na data que o cliente quer ouvir. A técnica foi aplicada, o resultado foi descartado, e a reunião de replanejamento já está marcada sem ninguém saber.

O exemplo numérico: três atividades, PERT e o efeito no cronograma

Três atividades em sequência, todas no caminho crítico, com os três valores levantados junto de quem executa. Os números são ilustrativos e foram conferidos em planilha.

A primeira leitura já muda a conversa. A soma dos valores mais prováveis dá 41 dias, e é esse o número que costuma virar promessa. A soma das esperadas dá 46 dias, cinco a mais, ou 12,2 por cento acima do que a equipe diria de cabeça.

O desvio padrão do caminho não é a soma dos desvios. É a raiz da soma das variâncias, que aqui dá exatamente 30, com raiz de 5,48 dias. É esse número que transforma um prazo em uma faixa de probabilidade.

Com esperada de 46 e desvio de 5,48, a distribuição normal dá as chances de cumprir cada data prometida.

O que a faixa de probabilidade faz com a promessa de prazo

A tabela reescreve a negociação inteira. Prometer 41 dias não é ser ambicioso, é aceitar 82 por cento de chance de descumprir. Prometer a esperada de 46 é jogar cara ou coroa com o cliente e chamar isso de plano.

Os 90 por cento de confiança custam sete dias de reserva sobre a esperada. Esse é o preço explícito da segurança, e a decisão de pagá-lo ou não passa a ser do patrocinador, não do gerente sozinho na véspera.

Repare no que aconteceu. A mesma informação que a equipe já tinha na cabeça virou um número negociável. Nenhum software fez isso. Uma planilha com três colunas e duas fórmulas fez, e a técnica é que decidiu quais colunas existiriam.

RACI: a ferramenta que acaba com o dono difuso

A matriz de responsabilidade cruza atividades com pessoas e marca quem executa, quem responde, quem é consultado e quem é informado. O ganho não está no documento: está na reunião em que ele é preenchido, quando as omissões aparecem.

O insumo é a lista de atividades da EAP e nomes de pessoas, não de áreas. Área não executa, não aprova e não pode ser cobrada em reunião de status. O método completo está em matriz de responsabilidade RACI.

• Erro típico um: dois responsáveis por aprovar a mesma entrega. Quando os dois discordam, a entrega para e ninguém tem autoridade para desempatar.
• Erro típico dois: linha sem executor. Aparece em toda matriz preenchida rápido, e sempre na atividade que ninguém quis assumir.
• Erro típico três: consultar meio mundo. Cada consultado adiciona dias de espera, e a matriz vira instrumento de lentidão.

Software de projeto tem campo de responsável e isso resolve parte do problema. O que ele não tem é a conversa que descobre que a atividade mais crítica do projeto não tem aprovador definido desde o início.

Poder e interesse: mapear quem pode parar o projeto

A matriz de poder e interesse classifica as partes interessadas em quatro quadrantes e define o tratamento de cada uma. Alto poder e alto interesse se gerencia de perto. Alto poder e baixo interesse se mantém satisfeito, porque o desinteresse pode virar veto.

O insumo é a lista de quem é afetado pelo projeto, incluindo quem só sofre o efeito colateral. O gerente de uma área que vai perder duas pessoas para o projeto tem poder real, mesmo sem cargo formal na iniciativa.

O erro típico é classificar por organograma. Diretor no quadrante alto, analista no baixo. Na prática, o analista que domina o sistema legado tem mais poder de travar a entrega do que o diretor que assinou o orçamento. O método está em mapa de stakeholders.

Essa ferramenta é a que mais economiza tempo depois. Resistência mapeada na semana dois custa uma conversa. A mesma resistência descoberta na semana vinte custa retrabalho e um pedido de prorrogação.

Registro de riscos: listar não é gerenciar

O registro de riscos é uma tabela viva com causa, evento, efeito, probabilidade, impacto, resposta escolhida e dono da resposta. Faltando qualquer uma dessas colunas, o documento vira lista de preocupações.

O insumo é a rodada de identificação com quem executa, e não a memória do gerente. Quem monta obra sabe quais riscos de obra existem. A disciplina completa está em gestão de riscos, com o ciclo de identificar, analisar, responder e monitorar.

A priorização usa probabilidade contra impacto, e o cruzamento dos dois dá a ordem de atenção. O funcionamento da matriz e as faixas de corte estão em matriz de risco. Sem corte definido, todo risco vira alto e a priorização some.

O erro típico é parar na avaliação. A planilha tem trinta riscos coloridos e nenhuma resposta atribuída. Risco sem resposta e sem dono não foi gerenciado, foi apenas anotado com esmero antes de acontecer.

Linha de base e valor agregado: medir avanço sem perguntar à equipe

Linha de base é o plano congelado de escopo, prazo e custo, contra o qual tudo será comparado. Sem congelar, não existe desvio, porque o plano se move junto com a realidade e o projeto nunca atrasa oficialmente.

O valor agregado compara três números na mesma data: o que estava planejado gastar, o que de fato foi entregue medido em orçamento, e o que foi realmente pago. A base de custo vem de orçamento do projeto.

Um exemplo fecha o conceito. Projeto de 400 mil reais, na semana dez. Planejado 180 mil, valor agregado 150 mil, custo real 170 mil. O desvio de prazo é de 30 mil negativos e o de custo é de 20 mil negativos.

Os índices traduzem isso em razão. O de prazo dá 0,833 e o de custo dá 0,882. A projeção do custo final, dividindo os 400 mil pelo índice de custo, aponta 453 mil. O estouro de 53 mil aparece na semana dez, não na entrega.

O erro típico é medir avanço perguntando à equipe. A resposta é sempre a mesma em todo projeto do mundo, e ela é noventa por cento pronto, durante três meses seguidos.

Curva S: a tendência que a planilha de status esconde

A curva S plota o acumulado planejado contra o acumulado realizado ao longo do tempo. O nome vem do formato: começa devagar, acelera no meio da execução e desacelera no fim, quando sobram as pendências difíceis.

No exemplo anterior, o planejado acumulado na semana dez era de 45 por cento do orçamento e o valor agregado ficou em 37,5 por cento. A distância entre as duas linhas é o atraso, visível em um gráfico antes de virar assunto de reunião.

O insumo é o acumulado das duas séries, semana a semana, desde o início. Curva S montada no meio do projeto não mostra tendência, mostra duas linhas soltas sem histórico para comparar.

O erro típico é plotar só o custo. Gasto acumulado sobe mesmo quando nada é entregue, e a curva fica bonita enquanto o projeto afunda. A seleção dos indicadores que acompanham a curva está em indicadores de desempenho em projetos.

O termo de abertura: a única ferramenta que autoriza

O termo de abertura é a ferramenta que dá existência formal ao projeto. Ele nomeia o patrocinador, declara o objetivo, fixa o critério de sucesso e define até onde o gerente decide sozinho. Sem ele, o projeto é uma boa intenção com reuniões.

O insumo é a decisão do patrocinador, e nada mais. Não precisa de cronograma, orçamento detalhado nem EAP, que virão depois. Exigir plano pronto para emitir o termo inverte a ordem e trava o começo.

O erro típico é tratá-lo como formalidade de arquivo. O documento é assinado, salvo em pasta e nunca mais aberto. Quando surge o conflito de prioridade, ninguém lembra que a autoridade já estava escrita e resolvida em duas páginas.

O rascunho aceita apoio de inteligência artificial, desde que a revisão campo a campo seja humana. O roteiro do que aceitar e do que recusar da primeira versão gerada está em IA no project charter.

O que o software resolve de verdade, e o que ele não resolve

Começa aqui a segunda metade. As ferramentas de gerenciamento de projetos vendidas como software resolvem quatro problemas reais, e vale pagar por eles quando o projeto tem tamanho para justificar.

• Visibilidade compartilhada: todo mundo vendo o mesmo estado ao mesmo tempo, sem versão de planilha circulando por e-mail.
• Histórico: quem mudou o quê e quando, que é a única defesa contra a discussão de memória na hora do problema.
• Notificação: o aviso automático de prazo e de mudança, que substitui a cobrança manual do gerente.
• Relatório: o status gerado do dado corrente, em vez de montado à mão na véspera da reunião.

E há o que ele não resolve, por natureza. Decisão de escopo continua humana: nenhuma tela decide se aquele pedido novo entra ou vira projeto seguinte. Prioridade entre dois projetos que disputam a mesma pessoa continua sendo conversa de gestor.

Conflito de recurso é o caso mais claro. O sistema mostra a superalocação em vermelho e para por aí. Quem decide qual projeto espera é alguém com autoridade, e essa autoridade não vem com a licença.

As quatro categorias de software e para que porte cada uma serve

Escolher plataforma sem saber a categoria é o que produz a compra errada. As quatro categorias resolvem problemas diferentes, e a mais cara não é a melhor para o projeto pequeno.

O quadro visual é a categoria mais adotada e a mais mal usada, porque parece simples. O funcionamento correto, com limite de trabalho em andamento, está em kanban.

A categoria de portfólio só faz sentido com uma estrutura que use o dado para decidir. Quando não há quem decida com ele, o investimento morre em painel bonito, e o papel dessa estrutura está em PMO, escritório de gerenciamento de projetos.

Critérios de escolha, o custo escondido e o mínimo viável

Os critérios que decidem são três, e nenhum deles é a lista de funcionalidades do site do fornecedor. A equipe vai usar no dia a dia? Integra com o que já existe? O custo escala por pessoa ou por projeto?

O terceiro critério é o que estoura orçamento no segundo ano. Preço por usuário multiplica com o crescimento do time, inclusive com quem só consulta. Preço por projeto cria o incentivo perverso de empilhar iniciativas diferentes no mesmo espaço.

Some o custo escondido de manter o dado atualizado. Quinze minutos por pessoa por dia, em uma equipe de doze, dão três horas por dia e 63 horas por mês. A 60 reais a hora, são 3.780 reais mensais, contra 600 de licença. O trabalho custa seis vezes a ferramenta.

É por isso que a maioria das migrações falha. A empresa troca de plataforma esperando resolver um problema de disciplina, leva o mesmo escopo mal decomposto para a tela nova, perde o histórico antigo e volta ao e-mail em três meses. A escolha entre cadência ágil e plano fechado é anterior a isso, e está em gestão ágil e gestão tradicional.

O roteiro de escolha, na ordem: aplique as técnicas por um ciclo em planilha, descubra onde dói de verdade, escolha a categoria que trata aquela dor, teste com um projeto real por trinta dias e só então compre. Para muita equipe o mínimo viável é uma planilha bem feita, e há um pronto em modelo de cronograma em Excel.