O MS Project como fonte da verdade

Fonte da verdade é o arquivo que ganha quando dois números brigam.

Na obra, a briga aparece assim. O cronograma diz que a alvenaria do 9º pavimento está em 70%. A planilha do estagiário diz 50%. O app de medição diz 60%. O engenheiro tem uma reunião com o cliente às dez e precisa escolher um.

Os três percentuais são de exemplo, e a situação é a que este texto quer evitar. Se ninguém combinou qual arquivo vale, cada pessoa escolhe o seu, e o cronograma que vai para o cliente pode ser o menos atualizado dos três.

Dois cronogramas viram três

Um caminho comum ao adotar Lean é trocar de sistema. A obra importa o .mpp para a ferramenta nova, e a partir daí o planejamento passa a viver lá.

O .mpp, porém, costuma sobreviver. Quando o contrato pede cronograma em Project, ou quando a diretoria compara obras pelo mesmo arquivo, alguém continua mexendo no arquivo antigo. Em poucas semanas, a ferramenta nova e o .mpp contam histórias diferentes, e a planilha de campo conta uma terceira.

A tese deste artigo é simples. Se o .mpp vai continuar existindo, ele deveria continuar sendo o plano oficial. As ferramentas de campo leem dele e escrevem de volta nele.

O Project já tem lugar para o avanço

O MS Project guarda as tarefas, com suas datas, e as ligações entre elas. A vista padrão de um projeto novo é o Gráfico de Gantt, segundo o suporte da Microsoft.

O mesmo suporte descreve o campo de percentual concluído. Ele recebe valores de 0, para tarefa não iniciada, a 100, para tarefa terminada, e serve para comparar o avanço planejado com o real. A página também explica que as datas da linha de base não são afetadas quando se lançam datas reais. O plano contratado fica guardado, e o avanço medido fica ao lado dele.

Ou seja, o arquivo tem onde receber a medição de campo. O que falta ao Project numa obra Lean está em volta dele: a linha de balanço, o lookahead com restrições, o PPC com causa e um jeito de o encarregado medir pelo celular.

A linha de balanço pode sair do .mpp

Mendes Júnior e Heineck (1998) observam que o método do caminho crítico é a base de muitos pacotes populares de gerenciamento de projetos. Também registram que a linha de balanço, muito adequada a edifícios com pavimentos repetidos, não ganhou popularidade duradoura principalmente por causa da oferta ampla de software comercial de caminho crítico.

Esse histórico explica por que a linha de balanço costuma aparecer como desenho separado, refeito à mão. Só que um cronograma com uma tarefa por serviço e por pavimento já contém tudo o que a linha precisa: a data de início e de fim de cada serviço em cada andar. Uma ferramenta que lê o .mpp consegue desenhar a linha sem que ninguém redigite a obra.

O lookahead mora fora do arquivo

Há um limite honesto nessa abordagem. Ballard (2000), na tese que descreve o Last Planner System, avisa que o lookahead não sai como um simples recorte do cronograma mestre. Ao entrar na janela de médio prazo, as atividades são quebradas em pacotes de trabalho menores, e é nesse nível que as restrições são analisadas.

A lista de restrições e o plano da semana pertencem a esse nível de detalhe. Colocar tudo isso no .mpp encheria o cronograma de tarefas que mudam toda semana.

Uma divisão possível: o .mpp guarda as datas do plano e o percentual medido de cada tarefa. A ferramenta Lean guarda o detalhe semanal e devolve ao .mpp só o que é do plano: o avanço.

O que pedir da ferramenta de campo

Para o .mpp continuar sendo a fonte, a ferramenta precisa cumprir quatro condições:

1. Ler tarefas e ligações direto do arquivo, sem cadastro manual da obra.
2. Saber em que pavimento e em que torre está cada tarefa, para levar a medição ao lugar certo.
3. Escrever o percentual medido de volta no campo de percentual concluído das tarefas certas.
4. Aceitar que o planejador mude o .mpp depois, sem perder as medições já feitas.

A quarta é a que mais separa as ferramentas. Se cada reimportação apaga o que o campo mediu, o planejador para de reimportar, e o arquivo volta a envelhecer.

Exemplos dessa abordagem

Algumas ferramentas de mercado descrevem o Project como base. A página de integração do Agilean diz que a construtora mantém o Project como base e que o MS Project recebe automaticamente as atualizações medidas em campo.

O PlanoLean, ferramenta da Caramelo Tech, empresa que mantém este portal, também parte dessa premissa: um add-in no MS Project exporta a obra, e o comando Importar medições leva o percentual medido em campo de volta para as tarefas do .mpp (planolean.com.br).

Antes de escolher qualquer uma, vale testar a quarta condição com um arquivo da sua obra.

Onde a abordagem aperta

O .mpp precisa estar bem montado. Um cronograma com uma única tarefa “Alvenaria torre A” não recebe medição por pavimento, porque não há onde guardar 60% do 9º andar. Quem quer o Project como fonte da verdade geralmente começa quebrando as tarefas por local.

Também é preciso combinar quem mexe em quê. Uma regra que costuma bastar tem duas linhas: data muda no Project, pelo planejador; percentual muda no campo, pela ferramenta. Escreva as duas na primeira semana da obra, com o nome de quem responde por cada uma.

Se o .mpp circula por e-mail em versões com data no nome, nenhuma ferramenta resolve. O primeiro passo é uma pasta compartilhada com um arquivo só e o histórico de versões ligado.