O que é o Gestor de Projeto

O Gestor de Projeto é um app para acompanhar um projeto do cronograma até a entrega. ^[1] Você cadastra as tarefas com datas, responsáveis e dependências, registra o andamento nas reuniões de follow-up, e o app calcula o desvio do plano, o fluxo de entregas, o desempenho da equipe e os riscos. Tudo fica em um único arquivo HTML, que abre no navegador, sem instalação, sem conta e sem servidor.

Abrir o Gestor de Projeto →

O app responde às perguntas que todo gerente de projeto ouve: estamos no prazo? O que está travando? Quem precisa de ajuda? Quando vamos terminar, e com que chance? Ele não substitui a conversa com a equipe. Ele prepara a conversa, porque mostra onde olhar.

Como o app trata os seus dados

• Os dados ficam no próprio arquivo. Ao clicar em Salvar, o app grava o projeto dentro do HTML. Guarde o arquivo onde quiser.
• Nada é enviado para a rede. O app não usa servidor nem biblioteca externa.
• Há cópia de segurança. Enquanto você não salva, o navegador guarda as alterações e oferece restaurá-las se a janela fechar.
• Quatro idiomas. A interface está em português, inglês, italiano e espanhol: troque no seletor do topo. Um link que termina em #en, #it ou #es já abre no idioma, e o app lembra a última escolha.

Uma breve história

Cada tela do app vem de uma ideia com mais de meio século. Conhecer a origem ajuda a usar cada ferramenta para o que ela foi feita.

O cronograma em barras (1896–1915)

O engenheiro polonês Karol Adamiecki criou em 1896 um diagrama de barras para coordenar a produção, que chamou de harmonograma. ^{[2] [3]} Ele publicou em polonês e russo, e o trabalho ficou pouco conhecido no Ocidente. Entre 1910 e 1915, o americano Henry Gantt desenvolveu e divulgou em inglês o gráfico que leva o seu nome. É o que você vê na aba Timeline. As fontes divergem sobre quando Adamiecki apresentou o método: há registros de 1903, 1909 e 1931. ^[3]

Caminho crítico e PERT (1957–1959)

No fim dos anos 1950 surgiram, de forma independente, dois métodos de rede. James Kelley, da Remington Rand, e Morgan Walker, da DuPont, criaram o método do caminho crítico (CPM) e o publicaram em 1959. ^{[4] [5]} A Marinha dos Estados Unidos desenvolveu o PERT para o programa de mísseis Polaris. As fontes datam o início do PERT entre 1957 e 1958. ^[4] A ideia central dos dois métodos é a mesma do app: algumas tarefas não têm folga, e qualquer atraso nelas atrasa o projeto inteiro.

Valor agregado e o SPI (1967)

Em 1967, o Departamento de Defesa dos Estados Unidos passou a exigir dos fornecedores critérios de controle de custo e prazo (C/SCSC), a origem da gestão do valor agregado (EVM). ^[6] Os critérios viraram a norma ANSI/EIA-748 no fim dos anos 1990. Dela vem o índice de desempenho de prazo, o SPI, que o app mostra na Visão geral.

Kanban e fluxo (anos 1950 a 2010)

Na Toyota, Taiichi Ohno inverteu a lógica da fábrica: o processo seguinte busca as peças no anterior, sinalizado por um cartão, o kanban. ^[7] As fontes divergem sobre a data: algumas falam dos anos 1940, outras dos anos 1950; o método chegou a todas as fábricas da Toyota em 1963. Em 2010, David J. Anderson publicou o método Kanban para trabalho de conhecimento, com limite de trabalho em andamento (WIP) e diagrama de fluxo cumulativo (CFD). ^[8] É a base da aba CFD & Métricas.

Filas, simulação e risco (1949–2015)

Em 1961, John Little publicou a prova de que, em um sistema estável, o número médio de itens é a taxa de chegada vezes o tempo médio no sistema. ^[9] O método de Monte Carlo nasceu em Los Alamos nos anos 1940, com Stanislaw Ulam, John von Neumann e Nicholas Metropolis, e foi publicado com esse nome em 1949. ^{[10] [11]} Quem deu o nome é discutido: a história mais citada atribui a Metropolis, inspirado em um tio de Ulam que jogava em Monte Carlo. Daniel Vacanti juntou as duas ideias para prever entregas a partir da vazão histórica. ^[12] Já a matriz de probabilidade × impacto é usada há décadas, e em 2008 Tony Cox mostrou os seus limites matemáticos. ^[13]

A teoria por trás das métricas

Cada número do app tem uma fórmula simples. Saber a fórmula evita a armadilha mais comum: tratar um indicador como verdade, quando ele é só uma forma de olhar os dados que você registrou.

Progresso ponderado, planejado e real

Cada tarefa pesa a sua duração planejada em dias; um marco pesa 1. O progresso real é a média dos percentuais concluídos, ponderada por esse peso. O progresso planejado para hoje supõe que cada tarefa avança em linha reta do início ao fim. A diferença entre os dois, em pontos percentuais (p.p.), é o desvio.

progresso real      = Σ (duração × % concluído) ÷ Σ duração
progresso planejado = Σ (duração × % que deveria estar pronto hoje) ÷ Σ duração
SPI                 = progresso real ÷ progresso planejado

No valor agregado clássico, o SPI é o valor agregado dividido pelo valor planejado, em dinheiro. ^[6] O app não tem custos: usa a duração como valor de cada tarefa. É uma aproximação útil, mas não é o SPI de um contrato com EVM. SPI 1 significa no plano; abaixo de 1, atrasado. O app só calcula o SPI quando o planejado passa de 0,5%, para não dividir por quase zero.

Dependências, caminho crítico e folga

Uma dependência diz que uma tarefa precisa esperar outra. O app tem três tipos, com defasagem em dias.

A folga de uma tarefa é quantos dias ela pode atrasar sem empurrar o fim do plano. O app calcula do fim para o começo, como no CPM: a última data permitida de cada tarefa sai das sucessoras. ^[5] Tarefas com folga zero ou negativa formam o caminho crítico. Atenção: a folga é medida contra a última data do plano, não contra o prazo do projeto. A diferença entre os dois aparece como reserva de prazo.

Fluxo: WIP, vazão, tempo de ciclo e Lei de Little

• WIP (trabalho em andamento): tarefas em andamento, em revisão ou bloqueadas.
• Vazão: tarefas concluídas por período.
• Tempo de ciclo: dias entre começar uma tarefa e concluí-la.
• Lead time: dias entre cadastrar a tarefa e concluí-la.

A Lei de Little liga os três: em um sistema estável, tempo médio de ciclo = WIP médio ÷ vazão média. ^[9] A consequência prática é a regra do Kanban: começar menos coisas ao mesmo tempo encurta o tempo de cada uma. ^[8] A lei vale para médias de um sistema estável. Em um projeto curto, que começa e termina, use o resultado como sinal, não como previsão.

Previsão por Monte Carlo

Prever com uma única data esconde a incerteza. A simulação de Monte Carlo do app sorteia, muitas vezes, uma das semanas reais do projeto e desconta as entregas daquela semana das tarefas pendentes, até zerar. ^{[10] [12]} Cada rodada dá uma data de término; as 5.000 rodadas formam uma distribuição. Daí saem a chance de cumprir o prazo e as datas P50 (metade das rodadas termina até ela) e P85 (85% terminam até ela).

Matriz de risco

Cada tarefa aberta recebe uma probabilidade e um impacto de 1 a 3, a partir do que está registrado. O nível é o produto, de 1 a 9.

Cox mostrou que matrizes assim podem dar a mesma nota a riscos muito diferentes, e até inverter a ordem entre dois riscos. ^[13] Por isso a matriz do app serve para ordenar a conversa, e cada linha mostra os fatores que geraram a nota. Leia os fatores, não só a cor.

Passo a passo

O trabalho com o app é um ciclo: planejar uma vez, depois acompanhar, analisar e decidir a cada reunião.

1. Conheça o app pelo exemplo

1. Abra o Gestor de Projeto e clique em Carregar projeto de exemplo.
2. Percorra as abas. O exemplo é a implantação de um CRM com 18 tarefas, 6 pessoas, dependências e três follow-ups.
3. Quando terminar, vá em Projeto e use Apagar todos os dados, ou abra uma cópia nova do arquivo.

2. Crie o projeto

1. Na tela inicial, preencha Nome do projeto, Início, Término previsto e o gerente.
2. Clique em Criar projeto.
3. Na aba Projeto, ajuste o Limite de WIP (quantas tarefas a equipe consegue tocar ao mesmo tempo) e os Dias sem atualização p/ alerta.
4. Clique em 💾 Salvar. No Chrome e no Edge, escolha o próprio arquivo HTML para sobrescrever.

3. Monte a timeline

Você pode cadastrar tarefa por tarefa em + Tarefa ou colar da planilha. Para colar, vá em Tarefas → ⬆ Colar timeline. Para trazer um projeto do MS Project, do ProjectLibre ou do GanttProject, veja Salvar, exportar e importar. As colunas são:

Tarefa ; Fase ; Responsável ; Início ; Fim ; Status ; % ; Marco ; Predecessoras

Só as cinco primeiras são obrigatórias. Teste com estas três linhas:

Kick-off;Descoberta;Ana;01/12/2026;01/12/2026;;;sim
Levantamento de requisitos;Descoberta;Ana;02/12/2026;12/12/2026;;;;1
Protótipos;Design;Diego;14/12/2026;23/12/2026;;;;2TI+1

Na coluna de predecessoras, 1 é a primeira linha colada, 2TI+1 quer dizer “término da linha 2 mais 1 dia” e #12 aponta uma tarefa que já existe. Escolha Adicionar ou Substituir todas as tarefas e clique em Importar.

4. Ajuste dependências e datas

1. Abra a Timeline. Marque Dependências e Caminho crítico.
2. Se uma tarefa começa antes do que a predecessora permite, o app mostra o alerta Conflito de dependência.
3. Clique em ⇥ Reagendar. O app propõe empurrar as tarefas ainda não iniciadas, mantendo a duração; ele nunca puxa datas para trás. Revise e clique em Aplicar reagendamento.
4. Para ajustar uma tarefa só, abra-a e use ↦ Encaixar após predecessoras.

5. Conduza o follow-up

1. Na aba Follow-ups, clique em + Nova. Confira título, data e participantes.
2. Comece pela Pauta sugerida: o app lista bloqueios, atrasos, entregas e inícios próximos e ações pendentes.
3. Em Atualização das tarefas, mude o status, o % e escreva a observação de cada tarefa discutida. A atualização fica no histórico na data da reunião, com a hora do registro. A lista mostra as tarefas relevantes para a data; marque Mostrar todas para ver as outras.
4. Registre Anotações, Decisões (uma por linha) e Ações com responsável e prazo.
5. Clique em 📝 Gerar ata para copiar ou baixar o texto, ou em 📄 Gerar PDF para o relatório completo.
6. Clique em 💾 Salvar e, se quiser um histórico de versões, em ⬇ Exportar → JSON.

As abas do app

No topo ficam também o seletor de idioma, ⬇ Exportar, ⬆ Importar, Salvar como… e 💾 Salvar.

Os status de uma tarefa são Backlog, A fazer, Em andamento, Bloqueado, Em revisão e Concluído. Em andamento, Bloqueado e Em revisão contam como WIP.

Como realizar a análise

Analisar é responder a seis perguntas, nesta ordem. Cada uma tem uma aba e um número principal. Os exemplos abaixo são do projeto de exemplo aberto em 12/11/2026; como o exemplo é montado a partir da data de hoje, as datas mudam em outro dia.

1. Estamos no prazo?

Na Visão geral, compare progresso real e planejado e olhe o SPI. No exemplo: 42% real contra 56% planejado, SPI 0,75. O app marca a saúde como Crítico quando o SPI fica abaixo de 0,85, a previsão passa do prazo em mais de 7 dias ou há 3 ou mais alertas altos; como Atenção com SPI abaixo de 0,95 ou previsão após o prazo.

2. Onde o fluxo trava?

No CFD & Métricas, procure faixas que se alargam e a faixa de concluídas plana. Compare Chegada × saída: no exemplo, 1,5 tarefa iniciada contra 0,8 concluída por semana, ou seja, o WIP está crescendo. A tabela Idade do trabalho em andamento destaca tarefas abertas há mais de 1,5 vez o ciclo médio.

3. O plano ainda é viável?

Na Timeline, ligue o caminho crítico e veja se alguma tarefa crítica está atrasada. Na aba Riscos, o cartão Reserva de prazo compara o fim do plano com o prazo. No exemplo, a reserva é zero e, pelo ritmo atual, faltam 4 dias.

4. Quem precisa de ajuda?

Na aba Equipe, olhe a tabela por pessoa: atrasadas, SPI, dias bloqueados, ações vencidas e a última atualização. Uma pessoa com SPI baixo e muitos dias bloqueados provavelmente precisa que alguém remova um impedimento, não de cobrança.

5. O que pode dar errado?

Na aba Riscos, comece pela matriz: clique na célula vermelha para filtrar os críticos e leia as etiquetas de cada um. No exemplo há 8 riscos altos ou críticos entre 11 tarefas abertas, e 80% do trabalho pendente está neles. O cartão Dependências em risco mostra atrasos que vão se propagar.

6. Quando termina, e com que chance?

Compare duas previsões. A da Visão geral projeta o ritmo de avanço em p.p. por semana: 05/01/2027 no exemplo. A da aba Riscos simula a vazão de tarefas: no exemplo, 11% de chance de terminar no prazo, metade das simulações até 28/01/2027 e 85% até 25/02/2027. As duas divergem porque medem coisas diferentes. Quando a distância é grande, comunique a faixa de datas, não uma data só.

Da análise à decisão

Boas práticas e erros comuns

Boas práticas

• Quebre o trabalho em tarefas de até duas semanas. Tarefas longas escondem o atraso até o fim e distorcem o progresso ponderado.
• Atualize em toda reunião. As métricas de fluxo dependem das datas de mudança de status. Uma tarefa que muda de status só no fim não tem ciclo confiável.
• Escreva a causa do bloqueio. A observação aparece no alerta e na pauta, e evita a pergunta “por que está parado?”.
• Use marcos para entregas e aprovações. Marcos sobem o impacto no risco e aparecem em destaque.
• Cadastre as dependências reais. Sem elas não há caminho crítico nem atraso propagado.
• Defina o limite de WIP com a equipe. Um bom começo é o número de pessoas.
• Exporte o JSON após cada follow-up. O arquivo leva data e hora e vira um histórico de versões.
• Mostre as métricas da equipe para a equipe. Elas existem para achar gargalos, não para ranquear pessoas.

Erros comuns

• “O SPI está em 1, então está tudo bem.”

  O SPI é uma média. Ele pode estar em 1 com uma tarefa crítica bloqueada. Confira sempre o caminho crítico e os alertas.

• “Vou marcar 90% para mostrar avanço.”

  Percentuais otimistas inflam o progresso e escondem o atraso até a última semana. Prefira status honestos e tarefas menores.

• “A matriz deu verde, então não há risco.”

  A matriz só vê o que foi registrado. Riscos externos, como a saída de um fornecedor, precisam ser discutidos na reunião.

• “A simulação garante a data P85.”

  Ela supõe que o futuro repete as últimas semanas. Se a equipe ou o escopo mudarem, a previsão perde a validade.

• “Reagendar resolve o atraso.”

  Reagendar só torna o plano coerente com as dependências. O atraso continua; agora ele está visível.

• “Quem tem SPI baixo é o problema.”

  SPI baixo costuma vir de bloqueios, dependências e estimativas ruins. Pergunte o que está impedindo antes de concluir.

Prompts para acelerar o trabalho

Uma IA ajuda a transformar escopo em timeline, revisar o plano, preparar a pauta e escrever relatórios. Ela também erra com segurança: inventa durações e explica números que não leu. Trate a saída como rascunho de um colega apressado e confira os números no app. Para escrever prompts melhores, veja o tutorial de prompts. ^[14]

Antes de colar: o JSON e as atas podem conter nomes, clientes e valores sigilosos. Troque por dados fictícios e siga a política da sua organização para uso de IA. O app não envia nada para a rede, mas o serviço de IA recebe o que você colar.

Troque os trechos entre colchetes e cole na ferramenta de IA que você usa.

1. Transformar o escopo em timeline

Gera as linhas no formato da importação, prontas para colar.

Você é um gerente de projetos experiente.
Projeto: [descreva em poucas frases o objetivo e as entregas].
Equipe: [nomes e papéis]. Início: [dd/mm/aaaa]. Prazo: [dd/mm/aaaa].

Monte a timeline em fases, com tarefas de no máximo 10 dias úteis e marcos para aprovações e entregas.
Antes de responder, me faça até 5 perguntas sobre o que faltar. Não invente durações: quando não souber, marque [estimar] na observação ao final.

Entregue só linhas de texto no formato, separadas por ponto e vírgula, sem cabeçalho:
Tarefa;Fase;Responsável;Início (dd/mm/aaaa);Fim (dd/mm/aaaa);Status;%;Marco (sim ou vazio);Predecessoras
Em Predecessoras use o número da linha (1 = primeira linha), com tipo e defasagem opcionais: 2, 2TI+3, 4II, 5TT-1. Deixe Status e % vazios.
Depois das linhas, liste as premissas que você assumiu.

2. Revisar o plano antes de começar

Revise esta timeline como um gerente de projetos cético.
[cole as linhas da timeline ou o CSV exportado pelo app]

Aponte, em tabela (problema, tarefas envolvidas, por que importa, sugestão):
- dependências que parecem faltar ou estar invertidas;
- tarefas longas demais para acompanhar semanalmente;
- durações que parecem otimistas, dizendo em que você se baseia;
- pessoas com tarefas sobrepostas no mesmo período;
- entregas sem marco de aprovação;
- riscos que não aparecem no plano.
Não reescreva o plano inteiro. Se não tiver base para um ponto, diga que é uma hipótese.

3. Preparar a pauta do follow-up

Abaixo está o JSON exportado do Gestor de Projeto (dados anonimizados).
[cole o JSON]

Hoje é [dd/mm/aaaa]. Prepare a pauta da reunião de follow-up de [30] minutos:
1. Itens em ordem de prioridade: bloqueios, tarefas atrasadas do caminho crítico, ações vencidas, entregas dos próximos 14 dias.
2. Para cada item: a pergunta a fazer, quem responde e o tempo sugerido.
3. Ao final, as decisões que a reunião precisa tomar.
Use apenas dados do JSON. Cite o número da tarefa (#n). Não calcule métricas que o JSON não traz; se precisar delas, diga em que aba do app olhar.

4. Escrever o relatório de status

Escreva um relatório de status para [diretoria / cliente / equipe], em até 250 palavras.
Números do app nesta data (copie das abas Visão geral e Riscos):
- Progresso real [x]% vs planejado [y]%; SPI [z]
- Previsão de término [data]; chance de cumprir o prazo [p]%; P85 [data]
- Bloqueios: [lista]; riscos críticos: [lista]
- Decisões da última reunião: [lista]

Estrutura: situação em uma frase (verde, amarelo ou vermelho e por quê), o que avançou, o que preocupa, o que precisamos de quem lê, próximos passos.
Use só os números informados. Não arredonde para melhor e não suavize o vermelho.

5. Planejar a resposta aos riscos

Este é o registro de riscos do meu projeto, copiado da aba Riscos do app (nível, tarefa, responsável, fim, status, fatores):
[cole a tabela]
Contexto: [prazo, restrições, o que pode e o que não pode mudar].

Para os riscos de nível alto e crítico, proponha respostas classificadas como evitar, mitigar, transferir ou aceitar.
Para cada uma: ação concreta, responsável sugerido, prazo, custo ou esforço aproximado e o sinal no app que mostra se funcionou.
Diga quais riscos dependem de decisão do patrocinador. Não proponha mais de 3 ações por risco.

6. Transformar anotações em decisões e ações

Estas são minhas anotações soltas da reunião de follow-up:
[cole as anotações]

Separe em:
1. Decisões: uma por linha, no infinitivo, sem justificativa.
2. Ações: uma por linha, no formato "O que será feito | Responsável | dd/mm/aaaa".
3. Atualizações de tarefas: "#n | novo status | % | observação curta".
4. Dúvidas: o que ficou ambíguo e precisa ser confirmado.
Não invente responsáveis nem prazos: deixe [definir] quando não estiverem nas anotações.

7. Fazer uma retrospectiva sem culpados

Vou facilitar uma retrospectiva com a equipe. Métricas da aba Equipe do app:
[cole os cartões e a tabela por pessoa, com nomes trocados por Pessoa A, B, C]

Proponha um roteiro de 45 minutos:
1. Três observações sobre o sistema de trabalho (fluxo, estimativas, bloqueios), sem atribuir culpa a pessoas.
2. Para cada observação, uma pergunta aberta para a equipe.
3. Dois experimentos pequenos para as próximas duas semanas, com o indicador do app que vamos acompanhar.
Lembre que as métricas medem o que foi registrado, não o esforço das pessoas.

Salvar, exportar e importar

Trocar arquivos com MS Project, ProjectLibre e GanttProject

O Microsoft Project abre e salva um formato XML de troca, o MSPDI, descrito num esquema publicado pela Microsoft. ^{[15] [16]} Segundo um comparativo e o fórum do ProjectLibre, o ProjectLibre abre arquivos .mpp e salva no próprio formato ou em MS Project XML, mas não grava .mpp. ^[17] O GanttProject tem formato próprio, o .gan, e exporta MSPDI. ^[18] Por isso o app troca dados com esses programas por dois formatos: MS Project XML e .gan.

Do MS Project ou ProjectLibre para o app

1. No MS Project, use Arquivo → Salvar como e escolha o tipo Formato XML (*.xml). ^[15] No ProjectLibre, salve como MS Project XML.
2. No app, clique em ⬆ Importar e escolha o arquivo .xml (ou o .gan do GanttProject).
3. Confira o resumo: projeto, tarefas, fases, dependências, responsáveis e avisos.
4. Escolha Substituir o projeto atual ou Adicionar tarefas ao projeto atual, e depois clique em 💾 Salvar.

Do app para o MS Project, ProjectLibre ou GanttProject

Clique em ⬇ Exportar e baixe MS Project XML ou GanttProject. No MS Project, para ver o arquivo na janela Abrir, escolha o tipo Formato XML ou Todos os arquivos. ^[15]

Arquivos .mpp (MS Project) e .pod (ProjectLibre) são binários e o navegador não os lê. Se você escolher um deles, o app explica como salvar em XML.

Como foi verificado. O XML exportado do projeto de exemplo foi validado contra o esquema oficial mspdi_pj12.xsd ^[16] e lido pela biblioteca independente MPXJ, ^[19] que encontrou as mesmas datas, dependências, defasagens e responsáveis. O .gan foi comparado com um arquivo de exemplo do próprio GanttProject ^[20] e lido pela MPXJ. Exportar e importar de volta deu o mesmo projeto nos dois formatos. Os arquivos não foram abertos no MS Project, no ProjectLibre nem no GanttProject: antes de migrar um projeto importante, teste com um pequeno.

Compartilhar

Para compartilhar, envie o HTML salvo: quem abrir vê o projeto. Se o arquivo for aberto direto de uma pasta do SharePoint ou do OneDrive no navegador, o app bloqueia o salvamento, porque a gravação não chegaria ao arquivo da biblioteca. Baixe uma cópia local, edite e faça o upload de volta.

Limitações e solução de problemas

Limitações

• Dias corridos. Durações e folgas contam todos os dias do calendário, sem fins de semana nem feriados.
• Sem custo nem horas. O SPI usa a duração como valor; não há CPI nem capacidade em horas por pessoa.
• Um arquivo, uma pessoa por vez. Não há edição simultânea. Se duas pessoas salvarem cópias diferentes, uma sobrescreve a outra.
• Métricas dependem do registro. Sem atualizações frequentes, ciclo, vazão e Monte Carlo ficam pobres.
• Monte Carlo trata as tarefas como iguais. Precisa de pelo menos 2 semanas de histórico e de alguma entrega.
• Troca com outros apps só leva o plano. MS Project XML e GanttProject não levam histórico, reuniões nem ações; um responsável por tarefa; dependências Início → Término e ligadas a fases ficam de fora.
• Sem .mpp nem .pod. Esses formatos binários precisam ser salvos como XML no programa de origem.

Solução de problemas

Glossário

Os termos de projeto usados no app e neste tutorial, em ordem alfabética.

Revisão rápida

Tente responder antes de abrir cada pergunta.

Referências

1. Giovani Perotto Mesquita, “Gestor de Projeto”, aplicativo em um único arquivo HTML, giovanipm.github.io/gestor-projeto.html.
2. Wikipedia (em inglês), “Gantt chart”, acesso em 12/11/2026, en.wikipedia.org/wiki/Gantt_chart.
3. Rework, “Karol Adamiecki and the Harmonogram”, acesso em 12/11/2026, resources.rework.com. As fontes divergem sobre a data em que Adamiecki apresentou o método: 1903, 1909 ou 1931.
4. Project Management Institute, “They wrote the book: the early literature of modern project management”, acesso em 12/11/2026, pmi.org. As fontes datam o início do PERT em 1957 ou em 1958.
5. James E. Kelley Jr., Morgan R. Walker, “Critical-Path Planning and Scheduling”, Proceedings of the Eastern Joint Computer Conference, 1959.
6. Wikipedia (em inglês), “Earned value management”, acesso em 12/11/2026, en.wikipedia.org/wiki/Earned_value_management.
7. Rework, “The History of Kanban”, acesso em 12/11/2026, resources.rework.com. As fontes divergem entre os anos 1940 e 1950 para a origem do kanban na Toyota.
8. David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, livro, Blue Hole Press, 2010, ISBN 978-0-9845214-0-1.
9. John D. C. Little, “A Proof for the Queuing Formula: L = λW”, Operations Research, v. 9, n. 3, p. 383–387, 1961, doi.org/10.1287/opre.9.3.383.
10. Nicholas Metropolis, Stanislaw Ulam, “The Monte Carlo Method”, Journal of the American Statistical Association, v. 44, p. 335–341, 1949.
11. Los Alamos National Laboratory, “Hitting the jackpot: the birth of the Monte Carlo method”, acesso em 12/11/2026, discover.lanl.gov. As fontes divergem sobre quem deu o nome ao método, Metropolis ou Ulam.
12. Daniel S. Vacanti, Actionable Agile Metrics for Predictability, livro, Leanpub, leanpub.com/actionableagilemetrics. A edição consultada tem copyright de 2015–2016; a biografia do autor no Leanpub diz que o livro foi publicado em 2014.
13. Louis Anthony (Tony) Cox Jr., “What’s Wrong with Risk Matrices?”, Risk Analysis, v. 28, n. 2, p. 497–512, 2008.
14. Giovani Perotto Mesquita, “O prompt completo para um tutorial”, tutorial deste site, giovanipm.github.io/PromptTutorial.html.
15. Microsoft, “Saving and Opening Projects in XML Format”, documentação do Project 2007, acesso em 12/11/2026, learn.microsoft.com.
16. Microsoft, “Microsoft Office Project 2007 XML Data Interchange Schema” (mspdi_pj12.xsd), acesso em 12/11/2026, schemas.microsoft.com/project/2007/mspdi_pj12.xsd.
17. ProjectManager, “What Is ProjectLibre? Pros, Cons & Alternatives”, acesso em 12/11/2026, projectmanager.com; ProjectLibre, fórum, “Export to MPP or save as MPP”, acesso em 12/11/2026, projectlibre.com/node/680. Fontes secundárias (comparativo comercial e fórum de usuários); não há documentação oficial consultada.
18. GanttProject, “From email: exporting to MS project”, acesso em 12/11/2026, help.ganttproject.biz. Fórum de usuários do GanttProject.
19. MPXJ, pacote 16.10.0, acesso em 12/11/2026, pypi.org/project/mpxj.
20. GanttProject, “HouseBuildingSample.gan”, acesso em 12/11/2026, github.com/bardsoftware/ganttproject.

What the Project Manager is

The Project Manager is an app to track a project from the schedule to delivery. ^[1] You enter tasks with dates, owners and dependencies, record progress in follow-up meetings, and the app computes the deviation from the plan, the delivery flow, team performance and risks. Everything lives in a single HTML file that opens in the browser, with no installation, no account and no server.

Open the Project Manager →

The app answers the questions every project manager hears: are we on schedule? What is stuck? Who needs help? When will we finish, and how likely is that? It does not replace the conversation with the team. It prepares the conversation, because it shows where to look.

How the app handles your data

• The data lives in the file itself. When you click Save, the app writes the project into the HTML. Keep the file wherever you like.
• Nothing is sent over the network. The app uses no server and no external library.
• There is a backup copy. Until you save, the browser keeps your changes and offers to restore them if the window closes.
• Four languages. The interface comes in Portuguese, English, Italian and Spanish: switch in the selector at the top. A link ending in #en, #it or #es already opens in that language.

A brief history

Every screen of the app comes from an idea more than half a century old. Knowing the origin helps you use each tool for what it was made for.

The bar schedule (1896–1915)

Polish engineer Karol Adamiecki created a bar diagram in 1896 to coordinate production and called it a harmonogram. ^{[2] [3]} He published in Polish and Russian, and the work remained little known in the West. Between 1910 and 1915, the American Henry Gantt developed and popularised in English the chart that bears his name. It is what you see in the Timeline tab. Sources disagree on when Adamiecki presented the method: there are records of 1903, 1909 and 1931. ^[3]

Critical path and PERT (1957–1959)

In the late 1950s two network methods appeared independently. James Kelley, of Remington Rand, and Morgan Walker, of DuPont, created the critical path method (CPM) and published it in 1959. ^{[4] [5]} The US Navy developed PERT for the Polaris missile programme. Sources date the start of PERT to 1957 or 1958. ^[4] The core idea of both is the same as in the app: some tasks have no slack, and any delay in them delays the whole project.

Earned value and SPI (1967)

In 1967 the US Department of Defense started requiring cost and schedule control criteria (C/SCSC) from its contractors, the origin of earned value management (EVM). ^[6] The criteria became the ANSI/EIA-748 standard in the late 1990s. From it comes the schedule performance index, SPI, which the app shows in the Overview.

Kanban and flow (1950s to 2010)

At Toyota, Taiichi Ohno reversed the factory logic: the next process fetches parts from the previous one, signalled by a card, the kanban. ^[7] Sources disagree on the date: some say the 1940s, others the 1950s; the method reached all Toyota plants in 1963. In 2010, David J. Anderson published the Kanban method for knowledge work, with work-in-progress (WIP) limits and the cumulative flow diagram (CFD). ^[8] It is the basis of the CFD & Metrics tab.

Queues, simulation and risk (1949–2015)

In 1961 John Little published the proof that, in a stable system, the average number of items equals the arrival rate times the average time in the system. ^[9] The Monte Carlo method was born at Los Alamos in the 1940s, with Stanislaw Ulam, John von Neumann and Nicholas Metropolis, and was published under that name in 1949. ^{[10] [11]} Who coined the name is disputed: the most cited story credits Metropolis, inspired by an uncle of Ulam who gambled in Monte Carlo. Daniel Vacanti combined both ideas to forecast deliveries from historical throughput. ^[12] The probability × impact matrix has been used for decades, and in 2008 Tony Cox showed its mathematical limits. ^[13]

The theory behind the metrics

Every number in the app has a simple formula. Knowing it avoids the most common trap: treating an indicator as truth, when it is only a way of looking at the data you recorded.

Weighted progress, planned and actual

Each task weighs its planned duration in days; a milestone weighs 1. Actual progress is the average of the completion percentages, weighted by that weight. Planned progress for today assumes each task advances in a straight line from start to finish. The difference between the two, in percentage points (p.p.), is the deviation.

actual progress  = Σ (duration × % complete) ÷ Σ duration
planned progress = Σ (duration × % that should be done today) ÷ Σ duration
SPI              = actual progress ÷ planned progress

In classic earned value, SPI is earned value divided by planned value, in money. ^[6] The app has no costs: it uses duration as the value of each task. It is a useful approximation, but it is not the SPI of an EVM contract. SPI 1 means on plan; below 1, behind. The app only computes SPI when planned progress is above 0.5%, to avoid dividing by almost zero.

Dependencies, critical path and slack

A dependency says a task must wait for another. The app has three types, with a lag in days.

A task’s slack is how many days it can slip without pushing the end of the plan. The app computes it backwards, as in CPM: each task’s latest allowed date comes from its successors. ^[5] Tasks with zero or negative slack form the critical path. Note: slack is measured against the last date of the plan, not against the project deadline. The difference between the two appears as schedule reserve.

Flow: WIP, throughput, cycle time and Little’s Law

• WIP (work in progress): tasks in progress, in review or blocked.
• Throughput: tasks finished per period.
• Cycle time: days between starting a task and finishing it.
• Lead time: days between entering the task and finishing it.

Little’s Law ties the three together: in a stable system, average cycle time = average WIP ÷ average throughput. ^[9] The practical consequence is the Kanban rule: starting fewer things at once shortens the time of each. ^[8] The law holds for averages of a stable system. In a short project that starts and ends, use the result as a signal, not as a forecast.

Monte Carlo forecast

Forecasting a single date hides uncertainty. The app’s Monte Carlo simulation repeatedly draws one of the project’s real weeks and subtracts that week’s deliveries from the pending tasks, until none are left. ^{[10] [12]} Each run gives an end date; the 5,000 runs form a distribution. From it come the chance of meeting the deadline and the P50 date (half of the runs finish by it) and P85 date (85% finish by it).

Risk matrix

Each open task gets a probability and an impact from 1 to 3, based on what has been recorded. The level is the product, from 1 to 9.

Cox showed that such matrices can give the same score to very different risks, and can even reverse the order of two risks. ^[13] That is why the app’s matrix serves to order the conversation, and each row shows the factors behind the score. Read the factors, not just the colour.

Step by step

Working with the app is a cycle: plan once, then follow up, analyse and decide at every meeting.

1. Get to know the app with the sample

1. Open the Project Manager and click Load sample project.
2. Go through the tabs. The sample is a CRM rollout with 18 tasks, 6 people, dependencies and three follow-ups.
3. When you are done, go to Project and use Delete all data, or open a fresh copy of the file.

2. Create the project

1. On the start screen, fill in Project name, Start, Planned end and the manager.
2. Click Create project.
3. In the Project tab, set the WIP limit (how many tasks the team can handle at once) and the Days without update before alert.
4. Click 💾 Save. In Chrome and Edge, choose the HTML file itself to overwrite it.

3. Build the timeline

You can add one task at a time with + Task or paste from a spreadsheet. To paste, go to Tasks → ⬆ Paste timeline. To bring in a project from MS Project, ProjectLibre or GanttProject, see Save, export and import. The columns are:

Task ; Phase ; Owner ; Start ; End ; Status ; % ; Milestone ; Predecessors

Only the first five are required. Dates are dd/mm/yyyy or yyyy-mm-dd. Try these three lines (write yes in the milestone column):

Kick-off;Discovery;Ana;01/12/2026;01/12/2026;;;yes
Requirements gathering;Discovery;Ana;02/12/2026;12/12/2026;;;;1
Prototypes;Design;Diego;14/12/2026;23/12/2026;;;;2FS+1

In the predecessors column, 1 is the first pasted line, 2FS+1 means “finish of line 2 plus 1 day” and #12 points to an existing task. The app accepts FS/SS/FF and the Portuguese TI/II/TT. Choose Add to existing tasks or Replace all tasks and click Import.

4. Adjust dependencies and dates

1. Open the Timeline. Tick Dependencies and Critical path.
2. If a task starts earlier than its predecessor allows, the app shows the alert Dependency conflict.
3. Click ⇥ Reschedule. The app proposes pushing tasks not yet started, keeping their duration; it never pulls dates earlier. Review and click Apply rescheduling.
4. To adjust a single task, open it and use ↦ Fit after predecessors.

5. Run the follow-up

1. In the Follow-ups tab, click + New. Check the title, date and participants.
2. Start with the Suggested agenda: the app lists blockers, delays, upcoming deliveries and starts, and pending actions.
3. In Task update, change the status, the % and write a note for each task discussed. The update is stored in the history on the meeting date, with the time it was recorded. The list shows the tasks relevant to the date; tick Show all to see the rest.
4. Record Notes, Decisions (one per line) and Actions with owner and due date.
5. Click 📝 Generate minutes to copy or download the text, or 📄 Generate PDF for the full report.
6. Click 💾 Save and, if you want a version history, ⬇ Export → JSON.

The app tabs

The interface comes in Portuguese, English, Italian and Spanish. Choose the language in the selector at the top; a link ending in #en, #it or #es already opens in that language, and the app remembers the last choice.

At the top there are also the language selector, ⬇ Export, ⬆ Import, Save as… and 💾 Save. A task’s statuses are Backlog, To do, In progress, Blocked, In review and Done; In progress, Blocked and In review count as WIP.

How to analyse

Analysing means answering six questions, in this order. Each has a tab and a main number. The examples below come from the sample project opened on 12 November 2026; since the sample is built from today’s date, the dates change on another day.

1. Are we on schedule?

In Overview, compare actual and planned progress and look at SPI. In the sample: 42% actual against 56% planned, SPI 0.75. The app marks health as Critical when SPI is below 0.85, the forecast is more than 7 days past the deadline or there are 3 or more high alerts; as Attention with SPI below 0.95 or a forecast after the deadline.

2. Where does the flow get stuck?

In CFD & Metrics, look for widening bands and a flat done band. Compare Arrivals × departures: in the sample, 1.5 tasks started against 0.8 finished per week, so WIP is growing. The table Age of work in progress highlights tasks open for more than 1.5 times the average cycle.

3. Is the plan still feasible?

In the Timeline, turn on the critical path and check whether a critical task is late. In the Risks tab, the Schedule reserve card compares the end of the plan with the deadline. In the sample, the reserve is zero and, at the current pace, 4 days are missing.

4. Who needs help?

In the Team tab, look at the per-person table: late tasks, SPI, blocked days, overdue actions and last update. A person with low SPI and many blocked days probably needs someone to remove an impediment, not pressure.

5. What can go wrong?

In the Risks tab, start with the matrix: click the red cell to filter the critical ones and read each one’s tags. In the sample there are 8 high or critical risks among 11 open tasks, and 80% of the pending work is in them. The Dependencies at risk card shows delays that will propagate.

6. When does it end, and how likely is that?

Compare two forecasts. The Overview one projects the pace of progress in p.p. per week: 05/01/2027 in the sample (5 January). The Risks one simulates task throughput: in the sample, an 11% chance of finishing on time, half of the simulations by 28/01/2027 and 85% by 25/02/2027. They differ because they measure different things. When the gap is large, communicate the date range, not a single date.

From analysis to decision

Good practices and common mistakes

Good practices

• Break work into tasks of up to two weeks. Long tasks hide delays until the end and distort weighted progress.
• Update at every meeting. Flow metrics depend on the dates of status changes. A task that only changes status at the end has no reliable cycle.
• Write the cause of the blocker. The note appears in the alert and in the agenda, and saves the question “why is it stuck?”.
• Use milestones for deliveries and approvals. Milestones raise the risk impact and stand out.
• Enter the real dependencies. Without them there is no critical path and no propagated delay.
• Set the WIP limit with the team. A good start is the number of people.
• Export the JSON after each follow-up. The file carries date and time and becomes a version history.
• Show team metrics to the team. They exist to find bottlenecks, not to rank people.

Common mistakes

• “SPI is 1, so all is well.”

  SPI is an average. It can be 1 with a critical task blocked. Always check the critical path and the alerts.

• “I’ll mark 90% to show progress.”

  Optimistic percentages inflate progress and hide delays until the last week. Prefer honest statuses and smaller tasks.

• “The matrix is green, so there is no risk.”

  The matrix only sees what was recorded. External risks, such as a supplier leaving, must be discussed in the meeting.

• “The simulation guarantees the P85 date.”

  It assumes the future repeats the last weeks. If the team or the scope change, the forecast no longer holds.

• “Rescheduling fixes the delay.”

  Rescheduling only makes the plan consistent with the dependencies. The delay remains; now it is visible.

• “Whoever has low SPI is the problem.”

  Low SPI usually comes from blockers, dependencies and poor estimates. Ask what is in the way before concluding.

Prompts to speed up the work

An AI helps turn scope into a timeline, review the plan, prepare the agenda and write reports. It also makes confident mistakes: it invents durations and explains numbers it did not read. Treat the output as a draft from a hurried colleague and check the numbers in the app. To write better prompts, see the prompt tutorial. ^[14]

Before pasting: the JSON and the minutes may contain names, clients and confidential figures. Replace them with fictitious data and follow your organisation’s AI policy. The app sends nothing over the network, but the AI service receives whatever you paste.

Replace the parts in square brackets and paste into the AI tool you use.

1. Turn the scope into a timeline

Produces lines in the import format, ready to paste.

You are an experienced project manager.
Project: [describe the goal and deliverables in a few sentences].
Team: [names and roles]. Start: [dd/mm/yyyy]. Deadline: [dd/mm/yyyy].

Build the timeline in phases, with tasks of at most 10 working days and milestones for approvals and deliveries.
Before answering, ask me up to 5 questions about whatever is missing. Do not invent durations: when you do not know, mark [estimate] in the notes at the end.

Deliver only text lines in this format, separated by semicolons, without a header:
Task;Phase;Owner;Start (dd/mm/yyyy);End (dd/mm/yyyy);Status;%;Milestone ("sim" or empty);Predecessors
In Predecessors use the line number (1 = first line), with optional type and lag: 2, 2FS+3, 4SS, 5FF-1. Leave Status and % empty.
After the lines, list the assumptions you made.

2. Review the plan before starting

Review this timeline as a sceptical project manager.
[paste the timeline lines or the CSV exported by the app]

Point out, in a table (problem, tasks involved, why it matters, suggestion):
- dependencies that seem missing or reversed;
- tasks too long to track weekly;
- durations that look optimistic, saying what you base it on;
- people with overlapping tasks in the same period;
- deliveries without an approval milestone;
- risks that do not appear in the plan.
Do not rewrite the whole plan. If you have no basis for a point, say it is a hypothesis.

3. Prepare the follow-up agenda

Below is the JSON exported from the Project Manager app (anonymised data).
[paste the JSON]

Today is [dd/mm/yyyy]. Prepare the agenda for a [30]-minute follow-up meeting:
1. Items in priority order: blockers, late tasks on the critical path, overdue actions, deliveries in the next 14 days.
2. For each item: the question to ask, who answers and the suggested time.
3. At the end, the decisions the meeting needs to make.
Use only data from the JSON. Cite the task number (#n). Do not compute metrics the JSON does not contain; if you need them, say which tab of the app to check.

4. Write the status report

Write a status report for [the board / the client / the team], in up to 250 words.
Numbers from the app on this date (copy them from the Overview and Risks tabs):
- Actual progress [x]% vs planned [y]%; SPI [z]
- Completion forecast [date]; chance of meeting the deadline [p]%; P85 [date]
- Blockers: [list]; critical risks: [list]
- Decisions from the last meeting: [list]

Structure: status in one sentence (green, amber or red and why), what moved forward, what worries us, what we need from the reader, next steps.
Use only the numbers given. Do not round in our favour and do not soften the red.

5. Plan the risk response

This is my project's risk register, copied from the app's Risks tab (level, task, owner, end, status, factors):
[paste the table]
Context: [deadline, constraints, what can and cannot change].

For high and critical risks, propose responses classified as avoid, mitigate, transfer or accept.
For each: concrete action, suggested owner, due date, approximate cost or effort and the signal in the app that shows whether it worked.
Say which risks depend on a sponsor decision. Propose no more than 3 actions per risk.

6. Turn notes into decisions and actions

These are my rough notes from the follow-up meeting:
[paste the notes]

Split them into:
1. Decisions: one per line, in the imperative, without justification.
2. Actions: one per line, in the format "What will be done | Owner | dd/mm/yyyy".
3. Task updates: "#n | new status | % | short note".
4. Open questions: what was ambiguous and needs confirming.
Do not invent owners or dates: write [to define] when they are not in the notes.

7. Run a blameless retrospective

I will facilitate a retrospective with the team. Metrics from the app's Team tab:
[paste the cards and the per-person table, with names replaced by Person A, B, C]

Propose a 45-minute plan:
1. Three observations about the work system (flow, estimates, blockers), without blaming people.
2. For each observation, an open question for the team.
3. Two small experiments for the next two weeks, with the app indicator we will track.
Remember that the metrics measure what was recorded, not people's effort.

Save, export and import

Exchange files with MS Project, ProjectLibre and GanttProject

Microsoft Project opens and saves an XML interchange format, MSPDI, described in a schema published by Microsoft. ^{[15] [16]} According to a comparison and to the ProjectLibre forum, ProjectLibre opens .mpp files and saves in its own format or as MS Project XML, but does not write .mpp. ^[17] GanttProject has its own format, .gan, and exports MSPDI. ^[18] That is why the app exchanges data with these programs through two formats: MS Project XML and .gan.

From MS Project or ProjectLibre to the app

1. In MS Project, use File → Save As and choose the XML Format (*.xml) type. ^[15] In ProjectLibre, save as MS Project XML.
2. In the app, click ⬆ Import and choose the .xml file (or GanttProject’s .gan).
3. Check the summary: project, tasks, phases, dependencies, owners and warnings.
4. Choose Replace the current project or Add tasks to the current project, then click 💾 Save.

From the app to MS Project, ProjectLibre or GanttProject

Click ⬇ Export and download MS Project XML or GanttProject. In MS Project, to see the file in the Open dialog, choose the XML Format or All Files type. ^[15]

.mpp (MS Project) and .pod (ProjectLibre) files are binary and the browser cannot read them. If you choose one, the app explains how to save it as XML.

How it was checked. The XML exported from the sample project was validated against the official mspdi_pj12.xsd schema ^[16] and read by the independent MPXJ library, ^[19] which found the same dates, dependencies, lags and owners. The .gan was compared with a sample file from GanttProject itself ^[20] and read by MPXJ. Exporting and importing back gave the same project in both formats. The files were not opened in MS Project, ProjectLibre or GanttProject: before migrating an important project, test with a small one.

Share

To share, send the saved HTML: whoever opens it sees the project. If the file is opened straight from a SharePoint or OneDrive folder in the browser, the app blocks saving, because the write would not reach the library file. Download a local copy, edit it and upload it back.

Limitations and troubleshooting

Limitations

• Calendar days. Durations and slack count every calendar day, with no weekends or holidays.
• No cost or hours. SPI uses duration as value; there is no CPI and no capacity in hours per person.
• One file, one person at a time. There is no simultaneous editing. If two people save different copies, one overwrites the other.
• Metrics depend on the records. Without frequent updates, cycle time, throughput and Monte Carlo are poor.
• Monte Carlo treats tasks as equal. It needs at least 2 weeks of history and some delivery.
• Exchange with other apps carries only the plan. MS Project XML and GanttProject carry no history, meetings or actions; one owner per task; Start → Finish dependencies and links attached to phases are left out.
• No .mpp or .pod. These binary formats must be saved as XML in the source program.

Troubleshooting

Glossary

The project terms used in the app and in this tutorial, in alphabetical order.

Quick review

Try to answer before opening each question.

References

1. Giovani Perotto Mesquita, “Gestor de Projeto” (Project Manager), single-file HTML app, giovanipm.github.io/gestor-projeto.html.
2. Wikipedia, “Gantt chart”, accessed 12 November 2026, en.wikipedia.org/wiki/Gantt_chart.
3. Rework, “Karol Adamiecki and the Harmonogram”, accessed 12 November 2026, resources.rework.com. Sources disagree on when Adamiecki presented the method: 1903, 1909 or 1931.
4. Project Management Institute, “They wrote the book: the early literature of modern project management”, accessed 12 November 2026, pmi.org. Sources date the start of PERT to 1957 or 1958.
5. James E. Kelley Jr., Morgan R. Walker, “Critical-Path Planning and Scheduling”, Proceedings of the Eastern Joint Computer Conference, 1959.
6. Wikipedia, “Earned value management”, accessed 12 November 2026, en.wikipedia.org/wiki/Earned_value_management.
7. Rework, “The History of Kanban”, accessed 12 November 2026, resources.rework.com. Sources disagree between the 1940s and the 1950s for the origin of kanban at Toyota.
8. David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, book, Blue Hole Press, 2010, ISBN 978-0-9845214-0-1.
9. John D. C. Little, “A Proof for the Queuing Formula: L = λW”, Operations Research, vol. 9, no. 3, pp. 383–387, 1961, doi.org/10.1287/opre.9.3.383.
10. Nicholas Metropolis, Stanislaw Ulam, “The Monte Carlo Method”, Journal of the American Statistical Association, vol. 44, pp. 335–341, 1949.
11. Los Alamos National Laboratory, “Hitting the jackpot: the birth of the Monte Carlo method”, accessed 12 November 2026, discover.lanl.gov. Sources disagree on who named the method, Metropolis or Ulam.
12. Daniel S. Vacanti, Actionable Agile Metrics for Predictability, book, Leanpub, leanpub.com/actionableagilemetrics. The edition consulted carries a 2015–2016 copyright; the author’s Leanpub biography says the book was published in 2014.
13. Louis Anthony (Tony) Cox Jr., “What’s Wrong with Risk Matrices?”, Risk Analysis, vol. 28, no. 2, pp. 497–512, 2008.
14. Giovani Perotto Mesquita, “The complete prompt for a tutorial”, tutorial on this site, giovanipm.github.io/PromptTutorial.html.
15. Microsoft, “Saving and Opening Projects in XML Format”, Project 2007 documentation, accessed 12 November 2026, learn.microsoft.com.
16. Microsoft, “Microsoft Office Project 2007 XML Data Interchange Schema” (mspdi_pj12.xsd), accessed 12 November 2026, schemas.microsoft.com/project/2007/mspdi_pj12.xsd.
17. ProjectManager, “What Is ProjectLibre? Pros, Cons & Alternatives”, accessed 12 November 2026, projectmanager.com; ProjectLibre, forum, “Export to MPP or save as MPP”, accessed 12 November 2026, projectlibre.com/node/680. Secondary sources (commercial comparison and user forum); no official documentation was consulted.
18. GanttProject, “From email: exporting to MS project”, accessed 12 November 2026, help.ganttproject.biz. GanttProject user forum.
19. MPXJ, package 16.10.0, accessed 12 November 2026, pypi.org/project/mpxj.
20. GanttProject, “HouseBuildingSample.gan”, accessed 12 November 2026, github.com/bardsoftware/ganttproject.

Che cos’è il Gestore di progetto

Il Gestore di progetto è un’app per seguire un progetto dal cronoprogramma alla consegna. ^[1] Inserisci le attività con date, responsabili e dipendenze, registri l’avanzamento nelle riunioni di follow-up, e l’app calcola lo scostamento dal piano, il flusso delle consegne, le prestazioni del team e i rischi. Tutto sta in un unico file HTML che si apre nel browser, senza installazione, senza account e senza server.

Apri il Gestore di progetto →

L’app risponde alle domande che ogni project manager si sente fare: siamo nei tempi? Che cosa è bloccato? Chi ha bisogno di aiuto? Quando finiremo, e con che probabilità? Non sostituisce il confronto con il team. Lo prepara, perché mostra dove guardare.

Come l’app tratta i tuoi dati

• I dati stanno nel file stesso. Quando clicchi Salva, l’app scrive il progetto dentro l’HTML. Conserva il file dove vuoi.
• Niente viene inviato in rete. L’app non usa server né librerie esterne.
• C’è una copia di sicurezza. Finché non salvi, il browser conserva le modifiche e propone di ripristinarle se la finestra si chiude.
• Quattro lingue. L’interfaccia è in portoghese, inglese, italiano e spagnolo: cambia nel selettore in alto. Un link che termina con #en, #it o #es si apre già in quella lingua.

Una breve storia

Ogni schermata dell’app nasce da un’idea con più di mezzo secolo. Conoscerne l’origine aiuta a usare ogni strumento per ciò per cui è stato pensato.

Il cronoprogramma a barre (1896–1915)

L’ingegnere polacco Karol Adamiecki creò nel 1896 un diagramma a barre per coordinare la produzione e lo chiamò armonogramma. ^{[2] [3]} Pubblicò in polacco e in russo, e il lavoro restò poco noto in Occidente. Tra il 1910 e il 1915 l’americano Henry Gantt sviluppò e diffuse in inglese il diagramma che porta il suo nome. È ciò che vedi nella scheda Timeline. Le fonti divergono su quando Adamiecki presentò il metodo: ci sono riferimenti al 1903, al 1909 e al 1931. ^[3]

Percorso critico e PERT (1957–1959)

Alla fine degli anni Cinquanta nacquero, in modo indipendente, due metodi reticolari. James Kelley, della Remington Rand, e Morgan Walker, della DuPont, crearono il metodo del percorso critico (CPM) e lo pubblicarono nel 1959. ^{[4] [5]} La Marina degli Stati Uniti sviluppò il PERT per il programma missilistico Polaris. Le fonti datano l’avvio del PERT al 1957 o al 1958. ^[4] L’idea centrale dei due metodi è la stessa dell’app: alcune attività non hanno margine, e qualsiasi ritardo su di esse ritarda l’intero progetto.

Valore guadagnato e SPI (1967)

Nel 1967 il Dipartimento della Difesa degli Stati Uniti iniziò a chiedere ai fornitori criteri di controllo di costi e tempi (C/SCSC), l’origine della gestione del valore guadagnato (EVM). ^[6] I criteri divennero lo standard ANSI/EIA-748 alla fine degli anni Novanta. Da lì viene l’indice di prestazione dei tempi, lo SPI, che l’app mostra nella Panoramica.

Kanban e flusso (dagli anni Cinquanta al 2010)

Alla Toyota, Taiichi Ohno rovesciò la logica della fabbrica: il processo successivo va a prendere i pezzi dal precedente, segnalato da un cartellino, il kanban. ^[7] Le fonti divergono sulla data: alcune parlano degli anni Quaranta, altre degli anni Cinquanta; il metodo arrivò in tutti gli stabilimenti Toyota nel 1963. Nel 2010 David J. Anderson pubblicò il metodo Kanban per il lavoro della conoscenza, con il limite di lavoro in corso (WIP) e il diagramma di flusso cumulativo (CFD). ^[8] È la base della scheda CFD e metriche.

Code, simulazione e rischio (1949–2015)

Nel 1961 John Little pubblicò la dimostrazione che, in un sistema stabile, il numero medio di elementi è pari al tasso di arrivo per il tempo medio nel sistema. ^[9] Il metodo Monte Carlo nacque a Los Alamos negli anni Quaranta, con Stanislaw Ulam, John von Neumann e Nicholas Metropolis, e fu pubblicato con questo nome nel 1949. ^{[10] [11]} Chi abbia dato il nome è discusso: la versione più citata lo attribuisce a Metropolis, ispirato da uno zio di Ulam che giocava a Monte Carlo. Daniel Vacanti ha unito le due idee per prevedere le consegne a partire dal throughput storico. ^[12] La matrice probabilità × impatto si usa da decenni, e nel 2008 Tony Cox ne ha mostrato i limiti matematici. ^[13]

La teoria dietro le metriche

Ogni numero dell’app ha una formula semplice. Conoscerla evita la trappola più comune: prendere un indicatore per verità, quando è solo un modo di guardare i dati che hai registrato.

Avanzamento ponderato, pianificato e reale

Ogni attività pesa la sua durata pianificata in giorni; una milestone pesa 1. L’avanzamento reale è la media delle percentuali completate, ponderata da quel peso. L’avanzamento pianificato per oggi suppone che ogni attività avanzi in linea retta dall’inizio alla fine. La differenza tra i due, in punti percentuali (p.p.), è lo scostamento.

avanzamento reale      = Σ (durata × % completata) ÷ Σ durata
avanzamento pianificato = Σ (durata × % che dovrebbe essere pronta oggi) ÷ Σ durata
SPI                    = avanzamento reale ÷ avanzamento pianificato

Nel valore guadagnato classico, lo SPI è il valore guadagnato diviso il valore pianificato, in denaro. ^[6] L’app non ha costi: usa la durata come valore di ogni attività. È un’approssimazione utile, ma non è lo SPI di un contratto con EVM. SPI 1 significa in linea con il piano; sotto 1, in ritardo. L’app calcola lo SPI solo quando il pianificato supera lo 0,5%, per non dividere per quasi zero.

Dipendenze, percorso critico e margine

Una dipendenza dice che un’attività deve aspettarne un’altra. L’app ha tre tipi, con un ritardo in giorni.

Il margine (slack) di un’attività è quanti giorni può slittare senza spostare la fine del piano. L’app lo calcola a ritroso, come nel CPM: l’ultima data ammessa di ogni attività deriva dalle successive. ^[5] Le attività con margine zero o negativo formano il percorso critico. Attenzione: il margine si misura rispetto all’ultima data del piano, non alla scadenza del progetto. La differenza tra le due compare come riserva di tempo.

Flusso: WIP, throughput, tempo di ciclo e legge di Little

• WIP (lavoro in corso): attività in corso, in revisione o bloccate.
• Throughput: attività completate per periodo.
• Tempo di ciclo: giorni tra l’inizio di un’attività e il suo completamento.
• Lead time: giorni tra l’inserimento dell’attività e il suo completamento.

La legge di Little lega i tre: in un sistema stabile, tempo di ciclo medio = WIP medio ÷ throughput medio. ^[9] La conseguenza pratica è la regola del Kanban: iniziare meno cose insieme accorcia il tempo di ciascuna. ^[8] La legge vale per le medie di un sistema stabile. In un progetto breve, che inizia e finisce, usa il risultato come segnale, non come previsione.

Previsione con Monte Carlo

Prevedere una sola data nasconde l’incertezza. La simulazione Monte Carlo dell’app estrae, molte volte, una delle settimane reali del progetto e sottrae le consegne di quella settimana dalle attività in sospeso, fino ad azzerarle. ^{[10] [12]} Ogni giro dà una data di fine; i 5.000 giri formano una distribuzione. Da qui escono la probabilità di rispettare la scadenza e le date P50 (metà dei giri finisce entro quella data) e P85 (l’85% finisce entro quella data).

Matrice di rischio

Ogni attività aperta riceve una probabilità e un impatto da 1 a 3, in base a quanto registrato. Il livello è il prodotto, da 1 a 9.

Cox ha mostrato che matrici di questo tipo possono dare lo stesso punteggio a rischi molto diversi, e perfino invertire l’ordine tra due rischi. ^[13] Per questo la matrice dell’app serve a ordinare la discussione, e ogni riga mostra i fattori che hanno generato il punteggio. Leggi i fattori, non solo il colore.

Passo passo

Il lavoro con l’app è un ciclo: pianificare una volta, poi seguire, analizzare e decidere a ogni riunione.

1. Conosci l’app con l’esempio

1. Apri il Gestore di progetto e clicca Carica progetto di esempio.
2. Passa in rassegna le schede. L’esempio è l’introduzione di un CRM con 18 attività, 6 persone, dipendenze e tre follow-up.
3. Alla fine, vai in Progetto e usa Cancella tutti i dati, oppure apri una copia nuova del file.

2. Crea il progetto

1. Nella schermata iniziale, compila Nome del progetto, Inizio, Fine prevista e il responsabile.
2. Clicca Crea progetto.
3. Nella scheda Progetto, imposta il Limite di WIP (quante attività il team riesce a seguire insieme) e i Giorni senza aggiornamento per l’avviso.
4. Clicca 💾 Salva. In Chrome ed Edge, scegli lo stesso file HTML per sovrascriverlo.

3. Costruisci la timeline

Puoi inserire un’attività alla volta con + Attività o incollare da un foglio di calcolo. Per incollare, vai in Attività → ⬆ Incolla timeline. Per portare un progetto da MS Project, ProjectLibre o GanttProject, vedi Salvare, esportare e importare. Le colonne sono:

Attività ; Fase ; Responsabile ; Inizio ; Fine ; Stato ; % ; Milestone ; Predecessori

Solo le prime cinque sono obbligatorie. Le date sono gg/mm/aaaa o aaaa-mm-gg. Prova queste tre righe (scrivi sì nella colonna della milestone):

Kick-off;Analisi;Ana;01/12/2026;01/12/2026;;;sì
Raccolta dei requisiti;Analisi;Ana;02/12/2026;12/12/2026;;;;1
Prototipi;Design;Diego;14/12/2026;23/12/2026;;;;2FS+1

Nella colonna dei predecessori, 1 è la prima riga incollata, 2FS+1 significa “fine della riga 2 più 1 giorno” e #12 indica un’attività già esistente. L’app accetta FS/SS/FF e i portoghesi TI/II/TT. Scegli Aggiungi alle attività esistenti o Sostituisci tutte le attività e clicca Importa.

4. Sistema dipendenze e date

1. Apri la Timeline. Spunta Dipendenze e Percorso critico.
2. Se un’attività inizia prima di quanto la predecessora consente, l’app mostra l’avviso Conflitto di dipendenza.
3. Clicca ⇥ Ripianifica. L’app propone di spostare in avanti le attività non ancora iniziate, mantenendone la durata; non anticipa mai le date. Controlla e clicca Applica ripianificazione.
4. Per sistemare una sola attività, aprila e usa ↦ Accoda dopo le predecessore.

5. Conduci il follow-up

1. Nella scheda Follow-up, clicca + Nuova. Controlla titolo, data e partecipanti.
2. Parti dalla Ordine del giorno suggerito: l’app elenca blocchi, ritardi, consegne e inizi imminenti e azioni in sospeso.
3. In Aggiornamento delle attività, cambia lo stato, la % e scrivi una nota per ogni attività discussa. L’aggiornamento resta nello storico alla data della riunione, con l’ora della registrazione. L’elenco mostra le attività rilevanti per la data; spunta Mostra tutte per vedere le altre.
4. Registra Note, Decisioni (una per riga) e Azioni con responsabile e scadenza.
5. Clicca 📝 Genera verbale per copiare o scaricare il testo, oppure 📄 Genera PDF per il report completo.
6. Clicca 💾 Salva e, se vuoi uno storico delle versioni, ⬇ Esporta → JSON.

Le schede dell’app

L’interfaccia è in portoghese, inglese, italiano e spagnolo. Scegli la lingua nel selettore in alto; un link che termina con #en, #it o #es si apre già in quella lingua, e l’app ricorda l’ultima scelta.

In alto ci sono anche il selettore della lingua, ⬇ Esporta, ⬆ Importa, Salva con nome… e 💾 Salva. Gli stati di un’attività sono Backlog, Da fare, In corso, Bloccata, In revisione e Completata; In corso, Bloccata e In revisione contano come WIP.

Come fare l’analisi

Analizzare significa rispondere a sei domande, in quest’ordine. Ognuna ha una scheda e un numero principale. Gli esempi qui sotto vengono dal progetto di esempio aperto il 12/11/2026; poiché l’esempio è costruito a partire dalla data di oggi, in un altro giorno le date cambiano.

1. Siamo nei tempi?

Nella Panoramica, confronta avanzamento reale e pianificato e guarda lo SPI. Nell’esempio: 42% reale contro 56% pianificato, SPI 0,75. L’app segna la salute come Critico quando lo SPI è sotto 0,85, la previsione supera la scadenza di più di 7 giorni o ci sono 3 o più avvisi alti; come Attenzione con SPI sotto 0,95 o previsione oltre la scadenza.

2. Dove si inceppa il flusso?

In CFD e metriche, cerca fasce che si allargano e una fascia dei completati piatta. Confronta Arrivi × uscite: nell’esempio, 1,5 attività iniziate contro 0,8 completate a settimana, quindi il WIP sta crescendo. La tabella Età del lavoro in corso evidenzia le attività aperte da più di 1,5 volte il ciclo medio.

3. Il piano è ancora fattibile?

Nella Timeline, attiva il percorso critico e verifica se un’attività critica è in ritardo. Nella scheda Rischi, la scheda Riserva di tempo confronta la fine del piano con la scadenza. Nell’esempio la riserva è zero e, al ritmo attuale, mancano 4 giorni.

4. Chi ha bisogno di aiuto?

Nella scheda Team, guarda la tabella per persona: attività in ritardo, SPI, giorni bloccati, azioni scadute e ultimo aggiornamento. Una persona con SPI basso e molti giorni bloccati probabilmente ha bisogno che qualcuno rimuova un impedimento, non di pressioni.

5. Che cosa può andare storto?

Nella scheda Rischi, parti dalla matrice: clicca la cella rossa per filtrare i critici e leggi le etichette di ognuno. Nell’esempio ci sono 8 rischi alti o critici su 11 attività aperte, e l’80% del lavoro in sospeso è in essi. La scheda Dipendenze a rischio mostra i ritardi che si propagheranno.

6. Quando finisce, e con che probabilità?

Confronta due previsioni. Quella della Panoramica proietta il ritmo di avanzamento in p.p. a settimana: 05/01/2027 nell’esempio. Quella della scheda Rischi simula il throughput delle attività: nell’esempio, l’11% di probabilità di finire in tempo, metà delle simulazioni entro il 28/01/2027 e l’85% entro il 25/02/2027. Divergono perché misurano cose diverse. Quando la distanza è grande, comunica l’intervallo di date, non una sola data.

Dall’analisi alla decisione

Buone pratiche ed errori comuni

Buone pratiche

• Dividi il lavoro in attività di massimo due settimane. Le attività lunghe nascondono il ritardo fino alla fine e distorcono l’avanzamento ponderato.
• Aggiorna a ogni riunione. Le metriche di flusso dipendono dalle date dei cambi di stato. Un’attività che cambia stato solo alla fine non ha un ciclo affidabile.
• Scrivi la causa del blocco. La nota compare nell’avviso e nell’ordine del giorno, ed evita la domanda “perché è ferma?”.
• Usa le milestone per consegne e approvazioni. Le milestone alzano l’impatto nel rischio e risaltano.
• Inserisci le dipendenze reali. Senza di esse non c’è percorso critico né ritardo propagato.
• Definisci il limite di WIP con il team. Un buon inizio è il numero di persone.
• Esporta il JSON dopo ogni follow-up. Il file porta data e ora e diventa uno storico delle versioni.
• Mostra le metriche del team al team. Servono a trovare colli di bottiglia, non a fare classifiche di persone.

Errori comuni

• “Lo SPI è 1, quindi va tutto bene.”

  Lo SPI è una media. Può essere 1 con un’attività critica bloccata. Controlla sempre il percorso critico e gli avvisi.

• “Segno 90% per mostrare avanzamento.”

  Percentuali ottimistiche gonfiano l’avanzamento e nascondono il ritardo fino all’ultima settimana. Preferisci stati onesti e attività più piccole.

• “La matrice è verde, quindi non c’è rischio.”

  La matrice vede solo ciò che è registrato. I rischi esterni, come l’uscita di un fornitore, vanno discussi in riunione.

• “La simulazione garantisce la data P85.”

  Suppone che il futuro ripeta le ultime settimane. Se cambiano il team o l’ambito, la previsione non vale più.

• “Ripianificare risolve il ritardo.”

  Ripianificare rende solo il piano coerente con le dipendenze. Il ritardo resta; adesso è visibile.

• “Chi ha lo SPI basso è il problema.”

  Uno SPI basso nasce di solito da blocchi, dipendenze e stime sbagliate. Chiedi che cosa sta ostacolando prima di concludere.

Prompt per accelerare il lavoro

Un’IA aiuta a trasformare l’ambito in timeline, rivedere il piano, preparare l’ordine del giorno e scrivere report. Sbaglia anche con sicurezza: inventa durate e spiega numeri che non ha letto. Tratta l’output come la bozza di un collega frettoloso e verifica i numeri nell’app. Per scrivere prompt migliori, vedi il tutorial sui prompt. ^[14]

Prima di incollare: il JSON e i verbali possono contenere nomi, clienti e cifre riservate. Sostituiscili con dati fittizi e segui la policy della tua organizzazione sull’uso dell’IA. L’app non invia nulla in rete, ma il servizio di IA riceve ciò che incolli.

Sostituisci le parti tra parentesi quadre e incolla nello strumento di IA che usi.

1. Trasformare l’ambito in timeline

Produce righe nel formato di importazione, pronte da incollare.

Sei un project manager esperto.
Progetto: [descrivi in poche frasi obiettivo e consegne].
Team: [nomi e ruoli]. Inizio: [gg/mm/aaaa]. Scadenza: [gg/mm/aaaa].

Costruisci la timeline per fasi, con attività di massimo 10 giorni lavorativi e milestone per approvazioni e consegne.
Prima di rispondere, fammi fino a 5 domande su ciò che manca. Non inventare durate: quando non lo sai, segna [stimare] nelle note finali.

Consegna solo righe di testo in questo formato, separate da punto e virgola, senza intestazione:
Attività;Fase;Responsabile;Inizio (gg/mm/aaaa);Fine (gg/mm/aaaa);Stato;%;Milestone ("sim" o vuoto);Predecessori
In Predecessori usa il numero di riga (1 = prima riga), con tipo e ritardo facoltativi: 2, 2FS+3, 4SS, 5FF-1. Lascia vuoti Stato e %.
Dopo le righe, elenca le ipotesi che hai fatto.

2. Rivedere il piano prima di iniziare

Rivedi questa timeline come un project manager scettico.
[incolla le righe della timeline o il CSV esportato dall'app]

Segnala, in una tabella (problema, attività coinvolte, perché conta, suggerimento):
- dipendenze che sembrano mancare o essere invertite;
- attività troppo lunghe da seguire settimanalmente;
- durate che sembrano ottimistiche, dicendo su cosa ti basi;
- persone con attività sovrapposte nello stesso periodo;
- consegne senza milestone di approvazione;
- rischi che non compaiono nel piano.
Non riscrivere tutto il piano. Se non hai basi per un punto, di' che è un'ipotesi.

3. Preparare l’ordine del giorno del follow-up

Qui sotto c'è il JSON esportato dal Gestore di progetto (dati anonimizzati).
[incolla il JSON]

Oggi è il [gg/mm/aaaa]. Prepara l'ordine del giorno di una riunione di follow-up di [30] minuti:
1. Punti in ordine di priorità: blocchi, attività in ritardo sul percorso critico, azioni scadute, consegne dei prossimi 14 giorni.
2. Per ogni punto: la domanda da fare, chi risponde e il tempo suggerito.
3. Alla fine, le decisioni che la riunione deve prendere.
Usa solo dati del JSON. Cita il numero dell'attività (#n). Non calcolare metriche che il JSON non contiene; se ti servono, di' in quale scheda dell'app guardare.

4. Scrivere il report di stato

Scrivi un report di stato per [la direzione / il cliente / il team], in massimo 250 parole.
Numeri dell'app a questa data (copiali dalle schede Panoramica e Rischi):
- Avanzamento reale [x]% vs pianificato [y]%; SPI [z]
- Previsione di fine [data]; probabilità di rispettare la scadenza [p]%; P85 [data]
- Blocchi: [elenco]; rischi critici: [elenco]
- Decisioni dell'ultima riunione: [elenco]

Struttura: situazione in una frase (verde, giallo o rosso e perché), cosa è avanzato, cosa preoccupa, cosa ci serve da chi legge, prossimi passi.
Usa solo i numeri forniti. Non arrotondare a nostro favore e non ammorbidire il rosso.

5. Pianificare la risposta ai rischi

Questo è il registro dei rischi del mio progetto, copiato dalla scheda Rischi dell'app (livello, attività, responsabile, fine, stato, fattori):
[incolla la tabella]
Contesto: [scadenza, vincoli, cosa può e cosa non può cambiare].

Per i rischi di livello alto e critico, proponi risposte classificate come evitare, mitigare, trasferire o accettare.
Per ognuna: azione concreta, responsabile suggerito, scadenza, costo o sforzo approssimativo e il segnale nell'app che mostra se ha funzionato.
Indica quali rischi dipendono da una decisione dello sponsor. Non proporre più di 3 azioni per rischio.

6. Trasformare le note in decisioni e azioni

Queste sono le mie note sparse della riunione di follow-up:
[incolla le note]

Separale in:
1. Decisioni: una per riga, all'infinito, senza giustificazione.
2. Azioni: una per riga, nel formato "Cosa verrà fatto | Responsabile | gg/mm/aaaa".
3. Aggiornamenti delle attività: "#n | nuovo stato | % | nota breve".
4. Dubbi: cosa è rimasto ambiguo e va confermato.
Non inventare responsabili né scadenze: scrivi [da definire] quando non sono nelle note.

7. Fare una retrospettiva senza colpevoli

Facilito una retrospettiva con il team. Metriche della scheda Team dell'app:
[incolla le schede e la tabella per persona, con i nomi sostituiti da Persona A, B, C]

Proponi una scaletta di 45 minuti:
1. Tre osservazioni sul sistema di lavoro (flusso, stime, blocchi), senza attribuire colpe alle persone.
2. Per ogni osservazione, una domanda aperta per il team.
3. Due piccoli esperimenti per le prossime due settimane, con l'indicatore dell'app che seguiremo.
Ricorda che le metriche misurano ciò che è stato registrato, non l'impegno delle persone.

Salvare, esportare e importare

Scambiare file con MS Project, ProjectLibre e GanttProject

Microsoft Project apre e salva un formato XML di scambio, MSPDI, descritto in uno schema pubblicato da Microsoft. ^{[15] [16]} Secondo un confronto e il forum di ProjectLibre, ProjectLibre apre i file .mpp e salva nel proprio formato o in MS Project XML, ma non scrive .mpp. ^[17] GanttProject ha un formato proprio, .gan, ed esporta MSPDI. ^[18] Per questo l’app scambia dati con questi programmi tramite due formati: MS Project XML e .gan.

Da MS Project o ProjectLibre all’app

1. In MS Project, usa File → Salva con nome e scegli il tipo Formato XML (*.xml). ^[15] In ProjectLibre, salva come MS Project XML.
2. Nell’app, clicca ⬆ Importa e scegli il file .xml (o il .gan di GanttProject).
3. Controlla il riepilogo: progetto, attività, fasi, dipendenze, responsabili e avvisi.
4. Scegli Sostituisci il progetto attuale o Aggiungi attività al progetto attuale, poi clicca 💾 Salva.

Dall’app a MS Project, ProjectLibre o GanttProject

Clicca ⬇ Esporta e scarica MS Project XML o GanttProject. In MS Project, per vedere il file nella finestra Apri, scegli il tipo Formato XML o Tutti i file. ^[15]

I file .mpp (MS Project) e .pod (ProjectLibre) sono binari e il browser non li legge. Se ne scegli uno, l’app spiega come salvarlo in XML.

Come è stato verificato. L’XML esportato dal progetto di esempio è stato validato con lo schema ufficiale mspdi_pj12.xsd ^[16] e letto dalla libreria indipendente MPXJ, ^[19] che ha trovato le stesse date, dipendenze, ritardi e responsabili. Il .gan è stato confrontato con un file di esempio dello stesso GanttProject ^[20] e letto da MPXJ. Esportare e reimportare ha dato lo stesso progetto in entrambi i formati. I file non sono stati aperti in MS Project, ProjectLibre o GanttProject: prima di migrare un progetto importante, prova con uno piccolo.

Condividere

Per condividere, invia l’HTML salvato: chi lo apre vede il progetto. Se il file viene aperto direttamente da una cartella di SharePoint o OneDrive nel browser, l’app blocca il salvataggio, perché la scrittura non arriverebbe al file della raccolta. Scarica una copia locale, modificala e ricaricala.

Limiti e soluzione dei problemi

Limiti

• Giorni di calendario. Durate e margini contano tutti i giorni del calendario, senza fine settimana né festivi.
• Niente costi né ore. Lo SPI usa la durata come valore; non c’è CPI né capacità in ore per persona.
• Un file, una persona alla volta. Non c’è modifica simultanea. Se due persone salvano copie diverse, una sovrascrive l’altra.
• Le metriche dipendono dalle registrazioni. Senza aggiornamenti frequenti, ciclo, throughput e Monte Carlo sono poveri.
• Monte Carlo tratta le attività come uguali. Servono almeno 2 settimane di storico e qualche consegna.
• Lo scambio con altre app porta solo il piano. MS Project XML e GanttProject non portano storico, riunioni né azioni; un responsabile per attività; le dipendenze Inizio → Fine e quelle collegate a fasi restano fuori.
• Niente .mpp né .pod. Questi formati binari vanno salvati in XML nel programma di origine.

Soluzione dei problemi

Glossario

I termini di progetto usati nell’app e in questo tutorial, in ordine alfabetico.

Ripasso veloce

Prova a rispondere prima di aprire ogni domanda.

Riferimenti

1. Giovani Perotto Mesquita, “Gestor de Projeto” (Gestore di progetto), app in un unico file HTML, giovanipm.github.io/gestor-projeto.html.
2. Wikipedia (in inglese), “Gantt chart”, consultato il 12/11/2026, en.wikipedia.org/wiki/Gantt_chart.
3. Rework, “Karol Adamiecki and the Harmonogram”, consultato il 12/11/2026, resources.rework.com. Le fonti divergono sulla data in cui Adamiecki presentò il metodo: 1903, 1909 o 1931.
4. Project Management Institute, “They wrote the book: the early literature of modern project management”, consultato il 12/11/2026, pmi.org. Le fonti datano l’avvio del PERT al 1957 o al 1958.
5. James E. Kelley Jr., Morgan R. Walker, “Critical-Path Planning and Scheduling”, Proceedings of the Eastern Joint Computer Conference, 1959.
6. Wikipedia (in inglese), “Earned value management”, consultato il 12/11/2026, en.wikipedia.org/wiki/Earned_value_management.
7. Rework, “The History of Kanban”, consultato il 12/11/2026, resources.rework.com. Le fonti divergono tra gli anni Quaranta e Cinquanta per l’origine del kanban alla Toyota.
8. David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, libro, Blue Hole Press, 2010, ISBN 978-0-9845214-0-1.
9. John D. C. Little, “A Proof for the Queuing Formula: L = λW”, Operations Research, vol. 9, n. 3, pp. 383–387, 1961, doi.org/10.1287/opre.9.3.383.
10. Nicholas Metropolis, Stanislaw Ulam, “The Monte Carlo Method”, Journal of the American Statistical Association, vol. 44, pp. 335–341, 1949.
11. Los Alamos National Laboratory, “Hitting the jackpot: the birth of the Monte Carlo method”, consultato il 12/11/2026, discover.lanl.gov. Le fonti divergono su chi diede il nome al metodo, Metropolis o Ulam.
12. Daniel S. Vacanti, Actionable Agile Metrics for Predictability, libro, Leanpub, leanpub.com/actionableagilemetrics. L’edizione consultata ha copyright 2015–2016; la biografia dell’autore su Leanpub dice che il libro è uscito nel 2014.
13. Louis Anthony (Tony) Cox Jr., “What’s Wrong with Risk Matrices?”, Risk Analysis, vol. 28, n. 2, pp. 497–512, 2008.
14. Giovani Perotto Mesquita, “Il prompt completo per un tutorial”, tutorial di questo sito, giovanipm.github.io/PromptTutorial.html.
15. Microsoft, “Saving and Opening Projects in XML Format”, documentazione di Project 2007, consultato il 12/11/2026, learn.microsoft.com.
16. Microsoft, “Microsoft Office Project 2007 XML Data Interchange Schema” (mspdi_pj12.xsd), consultato il 12/11/2026, schemas.microsoft.com/project/2007/mspdi_pj12.xsd.
17. ProjectManager, “What Is ProjectLibre? Pros, Cons & Alternatives”, consultato il 12/11/2026, projectmanager.com; ProjectLibre, forum, “Export to MPP or save as MPP”, consultato il 12/11/2026, projectlibre.com/node/680. Fonti secondarie (confronto commerciale e forum degli utenti); non è stata consultata documentazione ufficiale.
18. GanttProject, “From email: exporting to MS project”, consultato il 12/11/2026, help.ganttproject.biz. Forum degli utenti di GanttProject.
19. MPXJ, pacchetto 16.10.0, consultato il 12/11/2026, pypi.org/project/mpxj.
20. GanttProject, “HouseBuildingSample.gan”, consultato il 12/11/2026, github.com/bardsoftware/ganttproject.

Qué es el Gestor de proyecto

El Gestor de proyecto es un app para dar seguimiento a un proyecto desde el cronograma hasta la entrega. ^[1] Registras las tareas con fechas, responsables y dependencias, anotas el avance en las reuniones de seguimiento, y el app calcula la desviación del plan, el flujo de entregas, el desempeño del equipo y los riesgos. Todo está en un único archivo HTML que se abre en el navegador, sin instalación, sin cuenta y sin servidor.

Abrir el Gestor de proyecto →

El app responde a las preguntas que todo gerente de proyecto escucha: ¿vamos en plazo? ¿Qué está trabado? ¿Quién necesita ayuda? ¿Cuándo terminaremos, y con qué probabilidad? No reemplaza la conversación con el equipo. La prepara, porque muestra dónde mirar.

Cómo trata el app tus datos

• Los datos están en el propio archivo. Al hacer clic en Guardar, el app graba el proyecto dentro del HTML. Guarda el archivo donde quieras.
• No se envía nada por la red. El app no usa servidor ni bibliotecas externas.
• Hay copia de seguridad. Mientras no guardes, el navegador conserva los cambios y ofrece restaurarlos si la ventana se cierra.
• Cuatro idiomas. La interfaz está en portugués, inglés, italiano y español: cambia en el selector de arriba. Un enlace que termina en #en, #it o #es ya se abre en ese idioma.

Una breve historia

Cada pantalla del app viene de una idea con más de medio siglo. Conocer el origen ayuda a usar cada herramienta para lo que fue hecha.

El cronograma de barras (1896–1915)

El ingeniero polaco Karol Adamiecki creó en 1896 un diagrama de barras para coordinar la producción y lo llamó harmonograma. ^{[2] [3]} Publicó en polaco y en ruso, y el trabajo quedó poco conocido en Occidente. Entre 1910 y 1915, el estadounidense Henry Gantt desarrolló y difundió en inglés el diagrama que lleva su nombre. Es lo que ves en la pestaña Cronograma. Las fuentes discrepan sobre cuándo presentó Adamiecki el método: hay registros de 1903, 1909 y 1931. ^[3]

Ruta crítica y PERT (1957–1959)

A fines de los años cincuenta surgieron, de forma independiente, dos métodos de red. James Kelley, de Remington Rand, y Morgan Walker, de DuPont, crearon el método de la ruta crítica (CPM) y lo publicaron en 1959. ^{[4] [5]} La Marina de Estados Unidos desarrolló el PERT para el programa de misiles Polaris. Las fuentes fechan el inicio del PERT en 1957 o en 1958. ^[4] La idea central de ambos es la misma del app: algunas tareas no tienen holgura, y cualquier retraso en ellas retrasa todo el proyecto.

Valor ganado y SPI (1967)

En 1967, el Departamento de Defensa de Estados Unidos empezó a exigir a sus proveedores criterios de control de costo y plazo (C/SCSC), el origen de la gestión del valor ganado (EVM). ^[6] Los criterios se convirtieron en la norma ANSI/EIA-748 a fines de los años noventa. De ella viene el índice de desempeño del cronograma, el SPI, que el app muestra en la Visión general.

Kanban y flujo (de los años cincuenta a 2010)

En Toyota, Taiichi Ohno invirtió la lógica de la fábrica: el proceso siguiente busca las piezas en el anterior, señalado por una tarjeta, el kanban. ^[7] Las fuentes discrepan sobre la fecha: algunas hablan de los años cuarenta, otras de los cincuenta; el método llegó a todas las plantas de Toyota en 1963. En 2010, David J. Anderson publicó el método Kanban para el trabajo del conocimiento, con límite de trabajo en curso (WIP) y diagrama de flujo acumulado (CFD). ^[8] Es la base de la pestaña CFD y métricas.

Colas, simulación y riesgo (1949–2015)

En 1961, John Little publicó la prueba de que, en un sistema estable, el número medio de elementos es la tasa de llegada por el tiempo medio en el sistema. ^[9] El método de Montecarlo nació en Los Álamos en los años cuarenta, con Stanislaw Ulam, John von Neumann y Nicholas Metropolis, y se publicó con ese nombre en 1949. ^{[10] [11]} Quién le puso el nombre es discutido: la versión más citada lo atribuye a Metropolis, inspirado en un tío de Ulam que jugaba en Montecarlo. Daniel Vacanti unió ambas ideas para pronosticar entregas a partir del throughput histórico. ^[12] La matriz de probabilidad × impacto se usa desde hace décadas, y en 2008 Tony Cox mostró sus límites matemáticos. ^[13]

La teoría detrás de las métricas

Cada número del app tiene una fórmula sencilla. Conocerla evita la trampa más común: tomar un indicador como verdad, cuando es solo una forma de mirar los datos que registraste.

Avance ponderado, planificado y real

Cada tarea pesa su duración planificada en días; un hito pesa 1. El avance real es el promedio de los porcentajes completados, ponderado por ese peso. El avance planificado para hoy supone que cada tarea avanza en línea recta del inicio al fin. La diferencia entre ambos, en puntos porcentuales (p.p.), es la desviación.

avance real        = Σ (duración × % completado) ÷ Σ duración
avance planificado = Σ (duración × % que debería estar listo hoy) ÷ Σ duración
SPI                = avance real ÷ avance planificado

En el valor ganado clásico, el SPI es el valor ganado dividido entre el valor planificado, en dinero. ^[6] El app no tiene costos: usa la duración como valor de cada tarea. Es una aproximación útil, pero no es el SPI de un contrato con EVM. SPI 1 significa en plan; por debajo de 1, atrasado. El app solo calcula el SPI cuando el planificado supera el 0,5%, para no dividir entre casi cero.

Dependencias, ruta crítica y holgura

Una dependencia dice que una tarea debe esperar a otra. El app tiene tres tipos, con un desfase en días.

La holgura de una tarea es cuántos días puede retrasarse sin empujar el fin del plan. El app la calcula de atrás hacia adelante, como en el CPM: la última fecha permitida de cada tarea sale de sus sucesoras. ^[5] Las tareas con holgura cero o negativa forman la ruta crítica. Atención: la holgura se mide contra la última fecha del plan, no contra el plazo del proyecto. La diferencia entre ambas aparece como reserva de plazo.

Flujo: WIP, throughput, tiempo de ciclo y ley de Little

• WIP (trabajo en curso): tareas en curso, en revisión o bloqueadas.
• Throughput: tareas terminadas por período.
• Tiempo de ciclo: días entre empezar una tarea y terminarla.
• Lead time: días entre registrar la tarea y terminarla.

La ley de Little une las tres: en un sistema estable, tiempo de ciclo medio = WIP medio ÷ throughput medio. ^[9] La consecuencia práctica es la regla del Kanban: empezar menos cosas a la vez acorta el tiempo de cada una. ^[8] La ley vale para promedios de un sistema estable. En un proyecto corto, que empieza y termina, usa el resultado como señal, no como pronóstico.

Pronóstico con Montecarlo

Pronosticar una sola fecha esconde la incertidumbre. La simulación de Montecarlo del app sortea, muchas veces, una de las semanas reales del proyecto y descuenta las entregas de esa semana de las tareas pendientes, hasta dejarlas en cero. ^{[10] [12]} Cada corrida da una fecha de fin; las 5.000 corridas forman una distribución. De ahí salen la probabilidad de cumplir el plazo y las fechas P50 (la mitad de las corridas termina antes de ella) y P85 (el 85% termina antes de ella).

Matriz de riesgo

Cada tarea abierta recibe una probabilidad y un impacto de 1 a 3, a partir de lo registrado. El nivel es el producto, de 1 a 9.

Cox mostró que matrices así pueden dar la misma nota a riesgos muy distintos, e incluso invertir el orden entre dos riesgos. ^[13] Por eso la matriz del app sirve para ordenar la conversación, y cada fila muestra los factores que generaron la nota. Lee los factores, no solo el color.

Paso a paso

Trabajar con el app es un ciclo: planificar una vez y luego dar seguimiento, analizar y decidir en cada reunión.

1. Conoce el app con el ejemplo

1. Abre el Gestor de proyecto y haz clic en Cargar proyecto de ejemplo.
2. Recorre las pestañas. El ejemplo es la implantación de un CRM con 18 tareas, 6 personas, dependencias y tres seguimientos.
3. Al terminar, ve a Proyecto y usa Borrar todos los datos, o abre una copia nueva del archivo.

2. Crea el proyecto

1. En la pantalla inicial, completa Nombre del proyecto, Inicio, Fin previsto y el responsable.
2. Haz clic en Crear proyecto.
3. En la pestaña Proyecto, ajusta el Límite de WIP (cuántas tareas puede llevar el equipo a la vez) y los Días sin actualización para alerta.
4. Haz clic en 💾 Guardar. En Chrome y Edge, elige el propio archivo HTML para sobrescribirlo.

3. Arma el cronograma

Puedes registrar tarea por tarea con + Tarea o pegar desde una planilla. Para pegar, ve a Tareas → ⬆ Pegar cronograma. Para traer un proyecto de MS Project, ProjectLibre o GanttProject, ve Guardar, exportar e importar. Las columnas son:

Tarea ; Fase ; Responsable ; Inicio ; Fin ; Estado ; % ; Hito ; Predecesoras

Solo las cinco primeras son obligatorias. Las fechas son dd/mm/aaaa o aaaa-mm-dd. Prueba con estas tres líneas (escribe sí en la columna del hito):

Kick-off;Descubrimiento;Ana;01/12/2026;01/12/2026;;;sí
Relevamiento de requisitos;Descubrimiento;Ana;02/12/2026;12/12/2026;;;;1
Prototipos;Diseño;Diego;14/12/2026;23/12/2026;;;;2FS+1

En la columna de predecesoras, 1 es la primera línea pegada, 2FS+1 significa “fin de la línea 2 más 1 día” y #12 apunta a una tarea que ya existe. El app acepta FS/SS/FF y los portugueses TI/II/TT. Elige Añadir a las tareas existentes o Reemplazar todas las tareas y haz clic en Importar.

4. Ajusta dependencias y fechas

1. Abre el Cronograma. Marca Dependencias y Ruta crítica.
2. Si una tarea empieza antes de lo que la predecesora permite, el app muestra la alerta Conflicto de dependencia.
3. Haz clic en ⇥ Reprogramar. El app propone empujar las tareas aún no iniciadas, manteniendo su duración; nunca adelanta fechas. Revisa y haz clic en Aplicar reprogramación.
4. Para ajustar una sola tarea, ábrela y usa ↦ Encajar después de las predecesoras.

5. Conduce el seguimiento

1. En la pestaña Seguimientos, haz clic en + Nueva. Revisa título, fecha y participantes.
2. Empieza por la Agenda sugerida: el app lista bloqueos, retrasos, entregas e inicios próximos y acciones pendientes.
3. En Actualización de las tareas, cambia el estado, el % y escribe una nota para cada tarea discutida. La actualización queda en el historial en la fecha de la reunión, con la hora del registro. La lista muestra las tareas relevantes para la fecha; marca Mostrar todas para ver las demás.
4. Registra Notas, Decisiones (una por línea) y Acciones con responsable y plazo.
5. Haz clic en 📝 Generar acta para copiar o descargar el texto, o en 📄 Generar PDF para el informe completo.
6. Haz clic en 💾 Guardar y, si quieres un historial de versiones, en ⬇ Exportar → JSON.

Las pestañas del app

La interfaz está en portugués, inglés, italiano y español. Elige el idioma en el selector de arriba; un enlace que termina en #en, #it o #es ya se abre en ese idioma, y el app recuerda la última elección.

Arriba también están el selector de idioma, ⬇ Exportar, ⬆ Importar, Guardar como… y 💾 Guardar. Los estados de una tarea son Backlog, Por hacer, En curso, Bloqueada, En revisión y Terminada; En curso, Bloqueada y En revisión cuentan como WIP.

Cómo hacer el análisis

Analizar es responder seis preguntas, en este orden. Cada una tiene una pestaña y un número principal. Los ejemplos de abajo son del proyecto de ejemplo abierto el 12/11/2026; como el ejemplo se arma a partir de la fecha de hoy, otro día las fechas cambian.

1. ¿Vamos en plazo?

En Visión general, compara el avance real con el planificado y mira el SPI. En el ejemplo: 42% real contra 56% planificado, SPI 0,75. El app marca la salud como Crítico cuando el SPI está por debajo de 0,85, el pronóstico supera el plazo en más de 7 días o hay 3 o más alertas altas; como Atención con SPI por debajo de 0,95 o pronóstico después del plazo.

2. ¿Dónde se traba el flujo?

En CFD y métricas, busca franjas que se ensanchan y una franja de terminadas plana. Compara Llegadas × salidas: en el ejemplo, 1,5 tareas iniciadas contra 0,8 terminadas por semana, o sea, el WIP está creciendo. La tabla Edad del trabajo en curso destaca las tareas abiertas hace más de 1,5 veces el ciclo medio.

3. ¿El plan sigue siendo viable?

En el Cronograma, activa la ruta crítica y revisa si alguna tarea crítica está atrasada. En la pestaña Riesgos, la tarjeta Reserva de plazo compara el fin del plan con el plazo. En el ejemplo, la reserva es cero y, al ritmo actual, faltan 4 días.

4. ¿Quién necesita ayuda?

En la pestaña Equipo, mira la tabla por persona: tareas atrasadas, SPI, días bloqueados, acciones vencidas y última actualización. Una persona con SPI bajo y muchos días bloqueados probablemente necesita que alguien quite un impedimento, no presión.

5. ¿Qué puede salir mal?

En la pestaña Riesgos, empieza por la matriz: haz clic en la celda roja para filtrar los críticos y lee las etiquetas de cada uno. En el ejemplo hay 8 riesgos altos o críticos entre 11 tareas abiertas, y el 80% del trabajo pendiente está en ellos. La tarjeta Dependencias en riesgo muestra retrasos que se van a propagar.

6. ¿Cuándo termina, y con qué probabilidad?

Compara dos pronósticos. El de la Visión general proyecta el ritmo de avance en p.p. por semana: 05/01/2027 en el ejemplo. El de la pestaña Riesgos simula el throughput de tareas: en el ejemplo, 11% de probabilidad de terminar en plazo, la mitad de las simulaciones antes del 28/01/2027 y el 85% antes del 25/02/2027. Difieren porque miden cosas distintas. Cuando la distancia es grande, comunica el rango de fechas, no una sola fecha.

Del análisis a la decisión

Buenas prácticas y errores comunes

Buenas prácticas

• Divide el trabajo en tareas de hasta dos semanas. Las tareas largas esconden el retraso hasta el final y distorsionan el avance ponderado.
• Actualiza en cada reunión. Las métricas de flujo dependen de las fechas de cambio de estado. Una tarea que cambia de estado solo al final no tiene un ciclo confiable.
• Escribe la causa del bloqueo. La nota aparece en la alerta y en la agenda, y evita la pregunta “¿por qué está parada?”.
• Usa hitos para entregas y aprobaciones. Los hitos suben el impacto en el riesgo y se destacan.
• Registra las dependencias reales. Sin ellas no hay ruta crítica ni retraso propagado.
• Define el límite de WIP con el equipo. Un buen comienzo es el número de personas.
• Exporta el JSON después de cada seguimiento. El archivo lleva fecha y hora y se vuelve un historial de versiones.
• Muestra las métricas del equipo al equipo. Existen para encontrar cuellos de botella, no para hacer rankings de personas.

Errores comunes

• “El SPI está en 1, así que todo va bien.”

  El SPI es un promedio. Puede estar en 1 con una tarea crítica bloqueada. Revisa siempre la ruta crítica y las alertas.

• “Marco 90% para mostrar avance.”

  Los porcentajes optimistas inflan el avance y esconden el retraso hasta la última semana. Prefiere estados honestos y tareas más pequeñas.

• “La matriz dio verde, así que no hay riesgo.”

  La matriz solo ve lo registrado. Los riesgos externos, como la salida de un proveedor, hay que discutirlos en la reunión.

• “La simulación garantiza la fecha P85.”

  Supone que el futuro repite las últimas semanas. Si el equipo o el alcance cambian, el pronóstico deja de valer.

• “Reprogramar resuelve el retraso.”

  Reprogramar solo vuelve el plan coherente con las dependencias. El retraso sigue; ahora es visible.

• “Quien tiene SPI bajo es el problema.”

  Un SPI bajo suele venir de bloqueos, dependencias y malas estimaciones. Pregunta qué lo está impidiendo antes de concluir.

Prompts para acelerar el trabajo

Una IA ayuda a convertir el alcance en cronograma, revisar el plan, preparar la agenda y redactar informes. También se equivoca con seguridad: inventa duraciones y explica números que no leyó. Trata la salida como el borrador de un colega apurado y verifica los números en el app. Para escribir mejores prompts, ve el tutorial de prompts. ^[14]

Antes de pegar: el JSON y las actas pueden contener nombres, clientes y cifras confidenciales. Cámbialos por datos ficticios y sigue la política de tu organización para el uso de IA. El app no envía nada por la red, pero el servicio de IA recibe lo que pegues.

Reemplaza las partes entre corchetes y pega en la herramienta de IA que uses.

1. Convertir el alcance en cronograma

Genera las líneas en el formato de importación, listas para pegar.

Eres un gerente de proyectos con experiencia.
Proyecto: [describe en pocas frases el objetivo y las entregas].
Equipo: [nombres y roles]. Inicio: [dd/mm/aaaa]. Plazo: [dd/mm/aaaa].

Arma el cronograma por fases, con tareas de máximo 10 días hábiles e hitos para aprobaciones y entregas.
Antes de responder, hazme hasta 5 preguntas sobre lo que falte. No inventes duraciones: cuando no sepas, marca [estimar] en las notas del final.

Entrega solo líneas de texto en este formato, separadas por punto y coma, sin encabezado:
Tarea;Fase;Responsable;Inicio (dd/mm/aaaa);Fin (dd/mm/aaaa);Estado;%;Hito ("sim" o vacío);Predecesoras
En Predecesoras usa el número de línea (1 = primera línea), con tipo y desfase opcionales: 2, 2FS+3, 4SS, 5FF-1. Deja vacíos Estado y %.
Después de las líneas, lista los supuestos que asumiste.

2. Revisar el plan antes de empezar

Revisa este cronograma como un gerente de proyectos escéptico.
[pega las líneas del cronograma o el CSV exportado por el app]

Señala, en una tabla (problema, tareas involucradas, por qué importa, sugerencia):
- dependencias que parecen faltar o estar invertidas;
- tareas demasiado largas para seguir semanalmente;
- duraciones que parecen optimistas, diciendo en qué te basas;
- personas con tareas superpuestas en el mismo período;
- entregas sin hito de aprobación;
- riesgos que no aparecen en el plan.
No reescribas todo el plan. Si no tienes base para un punto, di que es una hipótesis.

3. Preparar la agenda del seguimiento

Abajo está el JSON exportado del Gestor de proyecto (datos anonimizados).
[pega el JSON]

Hoy es [dd/mm/aaaa]. Prepara la agenda de una reunión de seguimiento de [30] minutos:
1. Puntos en orden de prioridad: bloqueos, tareas atrasadas de la ruta crítica, acciones vencidas, entregas de los próximos 14 días.
2. Para cada punto: la pregunta a hacer, quién responde y el tiempo sugerido.
3. Al final, las decisiones que la reunión debe tomar.
Usa solo datos del JSON. Cita el número de la tarea (#n). No calcules métricas que el JSON no trae; si las necesitas, di en qué pestaña del app mirar.

4. Redactar el informe de estado

Escribe un informe de estado para [la dirección / el cliente / el equipo], de hasta 250 palabras.
Números del app en esta fecha (cópialos de las pestañas Visión general y Riesgos):
- Avance real [x]% vs planificado [y]%; SPI [z]
- Pronóstico de fin [fecha]; probabilidad de cumplir el plazo [p]%; P85 [fecha]
- Bloqueos: [lista]; riesgos críticos: [lista]
- Decisiones de la última reunión: [lista]

Estructura: situación en una frase (verde, amarillo o rojo y por qué), qué avanzó, qué preocupa, qué necesitamos de quien lee, próximos pasos.
Usa solo los números informados. No redondees a nuestro favor y no suavices el rojo.

5. Planificar la respuesta a los riesgos

Este es el registro de riesgos de mi proyecto, copiado de la pestaña Riesgos del app (nivel, tarea, responsable, fin, estado, factores):
[pega la tabla]
Contexto: [plazo, restricciones, qué puede y qué no puede cambiar].

Para los riesgos de nivel alto y crítico, propone respuestas clasificadas como evitar, mitigar, transferir o aceptar.
Para cada una: acción concreta, responsable sugerido, plazo, costo o esfuerzo aproximado y la señal en el app que muestra si funcionó.
Indica qué riesgos dependen de una decisión del patrocinador. No propongas más de 3 acciones por riesgo.

6. Convertir notas en decisiones y acciones

Estas son mis notas sueltas de la reunión de seguimiento:
[pega las notas]

Sepáralas en:
1. Decisiones: una por línea, en infinitivo, sin justificación.
2. Acciones: una por línea, en el formato "Qué se hará | Responsable | dd/mm/aaaa".
3. Actualizaciones de tareas: "#n | nuevo estado | % | nota breve".
4. Dudas: lo que quedó ambiguo y hay que confirmar.
No inventes responsables ni plazos: escribe [definir] cuando no estén en las notas.

7. Hacer una retrospectiva sin culpables

Voy a facilitar una retrospectiva con el equipo. Métricas de la pestaña Equipo del app:
[pega las tarjetas y la tabla por persona, con los nombres cambiados por Persona A, B, C]

Propone un guion de 45 minutos:
1. Tres observaciones sobre el sistema de trabajo (flujo, estimaciones, bloqueos), sin culpar a personas.
2. Para cada observación, una pregunta abierta para el equipo.
3. Dos experimentos pequeños para las próximas dos semanas, con el indicador del app que vamos a seguir.
Recuerda que las métricas miden lo que se registró, no el esfuerzo de las personas.

Guardar, exportar e importar

Intercambiar archivos con MS Project, ProjectLibre y GanttProject

Microsoft Project abre y guarda un formato XML de intercambio, MSPDI, descrito en un esquema publicado por Microsoft. ^{[15] [16]} Según una comparación y el foro de ProjectLibre, ProjectLibre abre archivos .mpp y guarda en su propio formato o en MS Project XML, pero no graba .mpp. ^[17] GanttProject tiene un formato propio, el .gan, y exporta MSPDI. ^[18] Por eso el app intercambia datos con estos programas mediante dos formatos: MS Project XML y .gan.

De MS Project o ProjectLibre al app

1. En MS Project, usa Archivo → Guardar como y elige el tipo Formato XML (*.xml). ^[15] En ProjectLibre, guarda como MS Project XML.
2. En el app, haz clic en ⬆ Importar y elige el archivo .xml (o el .gan de GanttProject).
3. Revisa el resumen: proyecto, tareas, fases, dependencias, responsables y avisos.
4. Elige Reemplazar el proyecto actual o Añadir tareas al proyecto actual, y luego haz clic en 💾 Guardar.

Del app a MS Project, ProjectLibre o GanttProject

Haz clic en ⬇ Exportar y descarga MS Project XML o GanttProject. En MS Project, para ver el archivo en la ventana Abrir, elige el tipo Formato XML o Todos los archivos. ^[15]

Los archivos .mpp (MS Project) y .pod (ProjectLibre) son binarios y el navegador no los lee. Si eliges uno, el app explica cómo guardarlo en XML.

Cómo se verificó. El XML exportado del proyecto de ejemplo se validó contra el esquema oficial mspdi_pj12.xsd ^[16] y lo leyó la biblioteca independiente MPXJ, ^[19] que encontró las mismas fechas, dependencias, desfases y responsables. El .gan se comparó con un archivo de ejemplo del propio GanttProject ^[20] y lo leyó MPXJ. Exportar e importar de vuelta dio el mismo proyecto en los dos formatos. Los archivos no se abrieron en MS Project, ProjectLibre ni GanttProject: antes de migrar un proyecto importante, prueba con uno pequeño.

Compartir

Para compartir, envía el HTML guardado: quien lo abra ve el proyecto. Si el archivo se abre directamente desde una carpeta de SharePoint u OneDrive en el navegador, el app bloquea el guardado, porque la grabación no llegaría al archivo de la biblioteca. Descarga una copia local, edítala y súbela de nuevo.

Limitaciones y solución de problemas

Limitaciones

• Días corridos. Duraciones y holguras cuentan todos los días del calendario, sin fines de semana ni feriados.
• Sin costos ni horas. El SPI usa la duración como valor; no hay CPI ni capacidad en horas por persona.
• Un archivo, una persona a la vez. No hay edición simultánea. Si dos personas guardan copias distintas, una sobrescribe a la otra.
• Las métricas dependen del registro. Sin actualizaciones frecuentes, ciclo, throughput y Montecarlo quedan pobres.
• Montecarlo trata las tareas como iguales. Necesita al menos 2 semanas de historial y alguna entrega.
• El intercambio con otros apps solo lleva el plan. MS Project XML y GanttProject no llevan historial, reuniones ni acciones; un responsable por tarea; las dependencias Inicio → Fin y las vinculadas a fases quedan fuera.
• Sin .mpp ni .pod. Esos formatos binarios hay que guardarlos como XML en el programa de origen.

Solución de problemas

Glosario

Los términos de proyecto usados en el app y en este tutorial, en orden alfabético.

Repaso rápido

Intenta responder antes de abrir cada pregunta.

Referencias

1. Giovani Perotto Mesquita, “Gestor de Projeto” (Gestor de proyecto), app en un único archivo HTML, giovanipm.github.io/gestor-projeto.html.
2. Wikipedia (en inglés), “Gantt chart”, consultado el 12/11/2026, en.wikipedia.org/wiki/Gantt_chart.
3. Rework, “Karol Adamiecki and the Harmonogram”, consultado el 12/11/2026, resources.rework.com. Las fuentes discrepan sobre la fecha en que Adamiecki presentó el método: 1903, 1909 o 1931.
4. Project Management Institute, “They wrote the book: the early literature of modern project management”, consultado el 12/11/2026, pmi.org. Las fuentes fechan el inicio del PERT en 1957 o en 1958.
5. James E. Kelley Jr., Morgan R. Walker, “Critical-Path Planning and Scheduling”, Proceedings of the Eastern Joint Computer Conference, 1959.
6. Wikipedia (en inglés), “Earned value management”, consultado el 12/11/2026, en.wikipedia.org/wiki/Earned_value_management.
7. Rework, “The History of Kanban”, consultado el 12/11/2026, resources.rework.com. Las fuentes discrepan entre los años cuarenta y cincuenta para el origen del kanban en Toyota.
8. David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, libro, Blue Hole Press, 2010, ISBN 978-0-9845214-0-1.
9. John D. C. Little, “A Proof for the Queuing Formula: L = λW”, Operations Research, vol. 9, n.º 3, pp. 383–387, 1961, doi.org/10.1287/opre.9.3.383.
10. Nicholas Metropolis, Stanislaw Ulam, “The Monte Carlo Method”, Journal of the American Statistical Association, vol. 44, pp. 335–341, 1949.
11. Los Alamos National Laboratory, “Hitting the jackpot: the birth of the Monte Carlo method”, consultado el 12/11/2026, discover.lanl.gov. Las fuentes discrepan sobre quién puso el nombre al método, Metropolis o Ulam.
12. Daniel S. Vacanti, Actionable Agile Metrics for Predictability, libro, Leanpub, leanpub.com/actionableagilemetrics. La edición consultada tiene copyright 2015–2016; la biografía del autor en Leanpub dice que el libro se publicó en 2014.
13. Louis Anthony (Tony) Cox Jr., “What’s Wrong with Risk Matrices?”, Risk Analysis, vol. 28, n.º 2, pp. 497–512, 2008.
14. Giovani Perotto Mesquita, “El prompt completo para un tutorial”, tutorial de este sitio, giovanipm.github.io/PromptTutorial.html.
15. Microsoft, “Saving and Opening Projects in XML Format”, documentación de Project 2007, consultado el 12/11/2026, learn.microsoft.com.
16. Microsoft, “Microsoft Office Project 2007 XML Data Interchange Schema” (mspdi_pj12.xsd), consultado el 12/11/2026, schemas.microsoft.com/project/2007/mspdi_pj12.xsd.
17. ProjectManager, “What Is ProjectLibre? Pros, Cons & Alternatives”, consultado el 12/11/2026, projectmanager.com; ProjectLibre, foro, “Export to MPP or save as MPP”, consultado el 12/11/2026, projectlibre.com/node/680. Fuentes secundarias (comparación comercial y foro de usuarios); no se consultó documentación oficial.
18. GanttProject, “From email: exporting to MS project”, consultado el 12/11/2026, help.ganttproject.biz. Foro de usuarios de GanttProject.
19. MPXJ, paquete 16.10.0, consultado el 12/11/2026, pypi.org/project/mpxj.
20. GanttProject, “HouseBuildingSample.gan”, consultado el 12/11/2026, github.com/bardsoftware/ganttproject.