A importância do controle em um projeto

O plano foi aprovado em março, na reunião do comitê gestor. Ninguém discutiu as datas, o escopo nem o orçamento. Três semanas depois, na primeira reunião de acompanhamento, alguém faz a pergunta óbvia: ainda estamos dentro do plano?

As respostas chegam em forma de impressão. A equipe de desenvolvimento acha que está apertada. O fornecedor garante que os equipamentos saem no prazo. O gasto parece estar mais ou menos onde deveria. Ninguém está mentindo e ninguém responde, porque não existe nada concreto com que comparar.

Essa lacuna é o que o controle de projetos existe para fechar. Não é um ritual mensal nem um slide: é a engrenagem que transforma um plano aprovado em informação com a qual alguém pode agir enquanto ainda há margem para agir.

O que o controle realmente significa

Três palavras são usadas como se fossem intercambiáveis, e essa confusão explica por que tanto esforço de acompanhamento rende tão pouco.

O monitoramento observa. Ele recolhe o que está acontecendo: horas lançadas, tarefas fechadas, notas fiscais recebidas. O relatório comunica: empacota esse material bruto para um destinatário concreto. O controle é o passo que fica no meio, e é justamente ele que se pula.

O controle compara o que acontece com algo que foi acordado, mede a diferença e coloca alguém diante de uma decisão. Observar sem um ponto de referência não é controle: é coleta de dados.

Um painel cheio de números em tempo real parece controle e não é, porque nada do que ele mostra diz quanto esses números deveriam valer. Um único número ao lado do valor aprovado vale mais do que vinte números soltos.

Isso marca também o limite do que o controle consegue fazer. O controle não faz um projeto dar certo, e não recupera o tempo já perdido. O que ele faz é encurtar a distância entre o momento em que um desvio aparece e o momento em que alguém com poder de decisão fica sabendo, o que em uma implantação de um ano é a diferença entre um ajuste e um resgate.

Sem linha de base não existe controle

O controle precisa de uma referência, e ela tem que ser fixa. É aqui que mais equipes se perdem: comparam o plano de hoje com a realidade de hoje, e os dois sempre combinam, porque o plano foi sendo ajustado em silêncio toda vez que a realidade se mexeu.

Uma linha de base é uma fotografia do plano, salva no momento em que ele foi aprovado. Ela deixa de ser editável, e é exatamente isso que a torna útil. Três delas sustentam quase todo o peso:

• Linha de base de custos. O que se espera gastar, distribuído no tempo conforme o trabalho acontece. Sem essa distribuição você só consegue comparar totais no final, quando já não dá para decidir nada.
• Linha de base de cronograma. As datas assumidas para cada fase e cada entrega. Ela responde se o projeto está atrasado, que é uma pergunta diferente de saber se alguém está trabalhando muito.
• Linha de base de escopo. As atividades que produzem as entregas, como foram aprovadas na estrutura analítica do projeto. É o que faz o progresso por atividade significar alguma coisa, porque cada item tem uma definição de pronto acordada.

Uma condição vale para as três: o plano precisa estar formalmente aprovado antes de virar linha de base, pelo comitê gestor, pela assembleia de acionistas ou pelo patrocinador, dependendo de como a organização governa seus projetos. Uma linha de base que ninguém assinou é uma opinião particular sobre o futuro, e não convence ninguém em uma discussão.

No ITM Platform você salva quantas linhas de base quiser e marca uma delas como ativa, que é a comparada com a situação atual. Ao definir uma, ficam registradas as datas do projeto e das tarefas, as horas orçadas e estimadas, os custos e a receita prevista daquele momento. Esses valores passam a aparecer ao lado dos números atuais nas abas Geral, Orçamento e Gantt, nas listas, nos relatórios e na API. Linhas de base do projeto explica como uma linha de base é criada e como se troca a ativa.

As quatro coisas que vale a pena controlar

Com uma referência definida, o controle tem quatro objetos. Eles não são igualmente fáceis, e falham de maneiras diferentes.

Escopo. Se o trabalho que está sendo feito é o que foi acordado, e se o resultado atende aos requisitos definidos no começo. A regra útil é binária: uma tarefa que não cumpre seus requisitos não está parcialmente concluída, está incompleta. Uma equipe que deixa uma tarefa em 90% de progresso por três semanas perdeu o controle do escopo sem perceber.

Prazo. Se as datas acordadas continuam de pé. Um detalhe merece mais atenção do que costuma receber: o primeiro cronograma quase sempre é desenhado sem margem para riscos, e isso é proposital. Uma margem declarada no plano original acaba absorvida por tudo menos por risco, porque qualquer atraso encontra um motivo para usá-la. Mantenha a reserva separada das datas assumidas e libere-a de propósito, não por inércia.

Custo. Há duas coisas para vigiar: o custo total do projeto e a posição de caixa, ou seja, quando o dinheiro sai de fato. Um projeto pode estar dentro do orçamento e criar um problema de caixa por concentrar todas as compras em um único trimestre.

Riscos. O controle de riscos é o que se paga sozinho, porque um imprevisto atinge os objetivos na hora, enquanto os outros desvios se acumulam aos poucos. A disciplina está em identificar os riscos, planejar a resposta antes do evento e não durante, e revisar a lista conforme o projeto muda de forma. As 6 fases para controlar riscos percorrem esse ciclo em ordem.

O progresso não é a mesma coisa que as horas gastas

A substituição mais comum no acompanhamento de projetos é tratar o esforço consumido como se fosse progresso. Metade das horas estimadas já foi, então a tarefa deve estar na metade do caminho.

Horas consumidas ≠ progresso alcançado.

As duas coisas descrevem realidades diferentes. O progresso é a proporção do trabalho realmente feito, e alguém precisa avaliá-la. As horas são uma entrada, e uma tarefa consegue queimar a estimativa inteira sem produzir nada aproveitável. Manter as duas separadas é o que torna um desvio visível: uma tarefa com 30% de progresso e 80% das horas gastas é um problema que se enxerga, e um número único misturado esconde.

A avaliação cabe a quem está perto o bastante do trabalho para julgá-lo, normalmente o responsável pela tarefa ou o gerente do projeto.

A comparação é aritmética simples. O progresso previsto para a data de hoje sai da linha de base, o progresso real é informado por quem faz o trabalho, e a diferença é o desvio de cronograma que você absorve ou escala. Agregar o progresso das tarefas nas tarefas resumo e no total do projeto dá essa comparação em todos os níveis do plano.

O ITM Platform mantém o progresso separado das horas consumidas e aceita o reporte de progresso pela folha de horas, pela seção de progresso da tarefa, pelo gráfico de Gantt ou pela API, e depois agrega esse progresso nas tarefas resumo e no total do projeto. Acompanhamento de projetos em cascata descreve cada um desses pontos de entrada.

Controle de custos antes de a fatura chegar

Com dinheiro, o controle quase sempre encolhe para uma única comparação: orçado contra realizado. Dois números não conseguem dizer se um desvio veio de uma estimativa ruim ou de uma execução ruim. Três conseguem.

Número	O que é	A que pergunta responde	Quando se mexe
Orçamento top-down	O valor alocado ao projeto, definido à mão na aprovação	Quanto foi aprovado gastar?	Poucas vezes, e só por uma mudança formal
Estimativa bottom-up	O custo calculado a partir das tarefas e alocações de recursos do plano	Quanto custa o plano como ele está agora?	Toda vez que o plano é estimado de novo ou troca de equipe
Valores realizados	Horas lançadas ao custo do recurso, mais compras e notas fiscais	Quanto já saiu ou foi firmado?	De forma contínua, conforme as horas entram e as faturas chegam

Lidos aos pares, os três números separam os dois modos de falha. A estimativa contra o orçamento diz se o plano era viável, e está disponível antes de gastar um real. Os valores realizados contra a estimativa dizem se o trabalho está custando o que deveria. Um projeto cuja estimativa já passava do orçamento na primeira semana tem um problema de estimativa que disciplina de execução nenhuma vai resolver.

O ITM Platform mostra os três números na aba Orçamento do projeto: o orçamento top-down que você define à mão, a estimativa bottom-up calculada a partir das tarefas e das alocações de recursos, e os valores realizados que vêm das horas lançadas e das compras e faturas registradas, com a opção de definir ali mesmo uma nova linha de base. Orçamento do projeto explica como esses blocos se relacionam.

Transformar o controle em decisão

Controle que para na medição é um hobby caro. O que sai dele precisa chegar a alguém que possa mudar alguma coisa, num momento em que mudar ainda seja barato.

Isso significa fechar três pontos antes de o projeto começar, não durante a primeira crise. De quanto em quanto tempo a comparação é feita, o que na maioria dos projetos quer dizer semanal no nível da tarefa e mensal no nível do comitê. Quem lê o resultado: pessoas com nome, não uma lista de distribuição. E o que dispara uma escalada: um desvio acima de um percentual acordado, um marco em risco, uma projeção de estouro acima de um valor definido.

Limites acordados de antemão mantêm a conversa sobre o projeto em vez de sobre o mensageiro. Quando a regra foi escrita antes de alguém saber qual projeto iria descumpri-la, informar um desvio é cumprir uma norma e não confessar uma culpa, e mais problemas aparecem enquanto ainda são pequenos.

O relatório é o veículo, e vale mais quando carrega uma projeção do que quando recita história: qual é o status, o que mudou, o que a estimativa atual diz sobre a data de término e o custo final, e qual decisão está sendo pedida. Tudo o que deve entrar em um relatório de status de projeto percorre esse conteúdo em detalhe.

Próximos passos

• Experimente o ITM Platform e defina uma linha de base em um projeto que você já tem em andamento; depois compare o progresso e o custo desta semana com ela.
• Veja o que o planejamento e seguimento cobre no ITM Platform, da estrutura analítica do projeto e do Gantt até o reporte de progresso e o desvio em relação à linha de base.