Um plano de gestão de projeto é o guia-mestre para entregar um projeto com sucesso. Com a Trupeer, pode poupar horas na planificação ao começar com um modelo gratuito de plano de gestão de projeto, personalizá-lo com a sua identidade de marca e transformar o plano em resumos em vídeo que alinham as partes interessadas rapidamente.

O que é um modelo de plano de gestão de projeto?

Um plano de gestão de projeto é o documento que descreve como um projeto específico será gerido: o seu âmbito, calendário, custo, qualidade, recursos, comunicações, risco, contratação e abordagem às partes interessadas.

Em método formal, é o plano-mestre, que contém ou referencia planos subsidiários para cada uma dessas áreas. É isso que o distingue de um plano de projeto, que no uso comum muitas vezes significa apenas o calendário.

Um modelo para isso normalmente fornece o conjunto completo de secções subsidiárias, razão pela qual as versões concluídas chegam a sessenta páginas ou mais. Essa abrangência não é o problema, e esta página não é um argumento para ignorar a governação.

O problema é o que preenche as páginas.

O teste de destaque para qualquer plano de gestão de projeto

Pegue num plano de gestão de projeto concluído da sua própria organização. Destaque cada frase que seria diferente se este fosse um projeto diferente.

Não são frases que contenham o nome do projeto. São frases cujo conteúdo mudaria: uma restrição específica, uma dependência nomeada, uma decisão tomada para as circunstâncias deste projeto, uma data que não poderia ser alterada.

Depois, veja quanto do documento fica destacado.

Na maioria das organizações, fica entre quinze e trinta por cento. Os restantes setenta a oitenta e cinco por cento descrevem como a organização gere projetos em geral e apareceriam inalterados no plano seguinte e no que vem depois.

É por isso que ninguém lê estes documentos. Um leitor que procura o que é específico deste projeto tem de encontrá-lo dentro de quatro vezes mais material que não é.

Como personalizar este modelo na Trupeer

Passo 1: Abra a secção Modelos

Vá à secção Modelos no menu principal.

Passo 2: Selecione e abra um modelo

Clique em qualquer modelo com que queira trabalhar para o abrir.

Passo 3: Expanda a visualização do modelo

Se necessário, expanda a visualização do modelo para ver o layout completo e os detalhes com clareza.

Passo 4: Edite o modelo

Clique em Edit para começar a modificar o modelo selecionado.

No editor, pode:

• Adicionar novas secções

• Definir ou atualizar regras de formatação

• Adicionar um logótipo e ajustar a sua posição e definições relacionadas

Passo 5: Guarde o seu modelo personalizado

Depois de fazer todas as alterações necessárias, clique em Save para guardar o modelo atualizado como seu.

Passo 6: Pré-visualize e ajuste o modelo

Quando quiser ver como fica o seu modelo personalizado, abra a Pré-visualização.

A partir do ecrã de pré-visualização, pode continuar a fazer ajustes diretamente, se necessário, garantindo que o modelo aparece exatamente como o quer.

Com um modelo de plano de gestão de projeto, pode:

• Poupar horas na planificação: Ignore a página em branco com uma estrutura PM abrangente.

• Cobrir todas as áreas de conhecimento: Secções integradas para âmbito, calendário, custo, qualidade e risco.

• Manter-se alinhado com a marca: Aplique o seu logótipo, tipos de letra e cores usando o kit de marca da Trupeer.

• Alinhar as partes interessadas: Transforme planos densos em resumos em vídeo que todos conseguem absorver rapidamente.

• Uniformizar entre projetos: Use o mesmo modelo para cada iniciativa.

• Atingir equipas globais: Traduza planos para 65+ idiomas com um clique.

Por que razão a maior parte do documento se ajusta a qualquer projeto

O conteúdo genérico não está lá por preguiça. Está lá porque o modelo o exige e porque a governação espera que cada área subsidiária seja abordada.

Assim, a secção de gestão do âmbito diz que as alterações ao âmbito serão apresentadas como pedidos de alteração, avaliadas quanto ao impacto e aprovadas pelo comité de alterações. Isso é verdade e é assim que funciona cada projeto naquela organização, mas não diz nada ao leitor sobre este projeto.

A secção de gestão da qualidade descreve a abordagem padrão de revisão e testes. A secção de gestão das comunicações diz que as partes interessadas receberão um relatório semanal. A secção de controlo de alterações reafirma o processo de controlo de alterações. Tudo correto, tudo idêntico ao último plano, tudo a consumir a atenção do leitor.

Entretanto, o conteúdo genuinamente específico do projeto — aquilo que um plano existe para registar — fica espalhado lá dentro. Uma restrição de acesso ao local. Um fornecedor de fonte única. Uma janela que não pode ser alterada. Uma parte interessada que tem de aprovar pessoalmente. Cada um destes é uma ou duas frases, e cada uma fica enterrada.

A solução não é escrever menos. É mover o material genérico para um local onde possa ser escrito uma vez.

Como separar a metodologia do plano

Dois documentos em vez de um.

Um documento de metodologia em vigor. Como a sua organização gere projetos. Controlo de alterações, gates de qualidade, cadência de reporte, rotas de escalonamento, normas de documentos, funções e as suas responsabilidades. Escrito uma vez, propriedade do gabinete do projeto, referenciado por todos os planos, atualizado quando o método muda e não quando um projeto começa.

Um plano de gestão de projeto. Apenas o que é específico deste projeto. Cada secção coloca uma única pergunta: o que é diferente aqui?

A regra que mantém esta separação honesta é simples de aplicar. Qualquer frase que pudesse aparecer inalterada no plano de outro projeto é eliminada e substituída por uma referência à metodologia.

Ao aplicar essa regra a um plano existente com sessenta páginas, normalmente ficam oito a doze páginas. Essas páginas são o plano. E, pela primeira vez, valem a pena ser lidas.

Surge duas objeções e ambas têm resposta. Auditores e clientes por vezes exigem o conjunto completo de conteúdo subsidiário; nesse caso, o documento de metodologia satisfaz isso e o plano o referencia, o que os auditores geralmente aceitam porque a rastreabilidade é mais clara. E há quem se preocupe que o plano pareça “fino”, o que acontece — até ao momento em que alguém tem de o usar.

Modelo gratuito de plano de gestão de projeto: as secções a copiar

Copie a partir daqui. Oito secções, oito a doze páginas, cada uma respondendo ao que é diferente neste projeto.

Cabeçalho. Projeto, patrocinador, gestor de projeto, orçamento, datas, versão do documento de metodologia sob a qual este plano opera.

Objetivos e critérios de sucesso. O que este projeto tem de alcançar, como medidas em vez de entregáveis, retirado do project brief em vez de ser reinventado.

Âmbito e limites. O que está incluído, o que está excluído e, especificamente, o que está excluído que as pessoas pediram. Refira o processo de alteração em vez de o descrever.

Restrições imovíveis. Datas, janelas, congelamentos, prazos regulamentares, períodos de posse ou de acesso, datas de aviso contratual. Qualquer coisa que o projeto não possa mover, com o seu responsável. O nosso modelo de plano de projeto de TI cobre isto de forma adequada e é a secção que mais vale extrair para uma única página.

Recursos e capacidade. Quem está comprometido, com quanto do seu tempo, e o que não está a fazer em vez disso. Nomeie os indivíduos cuja disponibilidade o plano realmente depende.

Abordagem de contratação. O que está a ser comprado, com base em quê, com prazos de entrega. O nosso modelo de plano de gestão de contratação cobre isto como um plano subsidiário quando o projeto justifica um.

Riscos específicos do projeto. Apenas os riscos particulares deste projeto, cada um com um gatilho e um responsável. Os riscos genéricos pertencem à lista de riscos em vigor da metodologia.

Desvios face à metodologia. Onde este projeto fará algo de forma diferente da abordagem padrão e porquê foi acordado. Esta secção é curta e é a primeira que os auditores leem.

Copie até aqui. Os planos subsidiários são anexados quando a dimensão do projeto o justifica e referenciados quando não o justifica.

O engenheiro ferroviário cuja janela de posse estava na página 41

A Kelvedon Rail é uma empresa de engenharia de infraestruturas com cerca de mil e seiscentas pessoas, a gerir à volta de trinta e quatro projetos por ano acima do seu limiar de duzentos e cinquenta mil libras, e cada um deles exigia um plano de gestão de projeto.

O modelo incluía onze planos subsidiários e as versões concluídas tinham, em média, sessenta e oito páginas.

Alguém fez o teste de destaque em doze deles. Conteúdo destacado mediano: dezanove por cento.

As secções de âmbito, qualidade, comunicações e controlo de alterações eram quase idênticas em todos os doze e, em nove casos, palavra por palavra, porque cada autor tinha começado pelo plano anterior. Dois dos doze ainda continham o nome de outro projeto no corpo do texto.

O gabinete do projeto também registava as aberturas de documentos. Entre esses doze planos, o número mediano de vezes que alguém abriu o documento após a aprovação foi três. Dois nunca mais foram abertos por ninguém.

A consequência surgiu num projeto. Uma janela de posse de via — uma data genuinamente imovível, acordada meses antes com o proprietário da infraestrutura — foi registada na página quarenta e um do plano e em mais nenhum lugar. A equipa de entrega planeou trabalho para uma semana em que o acesso não estava disponível. Perderam-se três semanas, a um custo estimado de cento e oitenta e seis mil libras.

A informação tinha sido documentada. Tinha sido aprovada. Estava dentro de sessenta e oito páginas, quatro quintos das quais descreviam como a Kelvedon gere projetos em geral.

A reconstrução produziu dois documentos. Um documento de metodologia com cerca de quarenta páginas, escrito uma vez e propriedade do gabinete do projeto. E um modelo de plano de gestão de projeto com oito secções, direcionado para oito a doze páginas, em que cada secção pergunta apenas o que é diferente neste projeto.

Nos vinte e um projetos seguintes, a duração mediana do plano foi de onze páginas e as aberturas após aprovação foram de catorze. O teste de destaque em oito deles devolveu uma mediana de oitenta e um por cento de conteúdo específico do projeto.

As restrições imovíveis estão agora também num anexo de uma página, extraído do plano e distribuído separadamente, porque a lição da janela de posse foi que datas importantes não devem ser encontradas apenas lendo.

Os planos subsidiários e quais é que precisa mesmo

A posição honesta é que a maioria dos projetos precisa de dois ou três destes como documentos separados e de referir o resto. Produzir os dez porque o modelo lista dez é o que gera um plano com sessenta páginas que ninguém abre.

Como criar um plano de gestão de projeto, passo a passo

Comece pelo brief, para o plano servir um problema acordado em vez de voltar a enunciar uma abordagem.

Escreva primeiro as restrições imovíveis. Elas determinam o que é possível e são a secção que mais provavelmente terá de mudar o resto.

Preencha cada secção restante respondendo apenas ao que é diferente aqui. Se a resposta honesta for “nada”, escreva a referência e siga em frente.

Nomeie as pessoas sempre que o plano dependa da disponibilidade de alguém e confirme com elas.

Decida quais os planos subsidiários que justificam documentos separados usando a tabela acima e referencie os restantes.

Escreva a secção de desvios por último, depois de saber onde este projeto se afasta da abordagem padrão.

Em seguida, aplique o teste de destaque ao seu rascunho antes de o distribuir. Qualquer coisa não destacada é candidata a eliminação.

As fases-chave que um plano de gestão de projeto deve cobrir

O plano deve dizer algo específico do projeto sobre cada fase e, para a maioria dos projetos, isso deve ser breve.

Iniciação. O que autorizou isto e contra que critérios de sucesso.

Planeamento. As restrições, os recursos e as decisões de abordagem. É aqui que está a maior parte do conteúdo do plano.

Execução. O que é diferente na forma como este projeto será entregue, incluindo qualquer desvio face ao método padrão.

Monitorização e controlo. O que será observado que seja invulgar para este projeto, em vez da cadência de reporte padrão.

Encerramento e transição. Quem recebe o resultado e o que precisa para o aceitar, o que o nosso modelo de checklist de transição do projeto cobre, e vale a pena acordar no planeamento e não no encerramento.

A fase em que os planos são mais fracos é a última, porque está mais distante quando o plano é escrito. Nomear a equipa que recebe e os respetivos critérios de aceitação no planeamento é a coisa mais valiosa que a secção de encerramento pode conter.

Metodologias comuns de gestão de projeto e o que muda

A forma do plano muda com o método e o teste de destaque aplica-se a todos.

Cascata ou stage-gate. O conjunto completo de planos subsidiários é convencional aqui e a disciplina de separar a metodologia do plano é o que mais importa, porque os modelos são mais pesados.

Ágil. Grande parte do que um plano tradicional documenta vive na forma de trabalhar. O plano ainda precisa das restrições imovíveis, do compromisso de recursos, da abordagem de contratação e dos desvios. O que não precisa é de um plano de gestão do âmbito para um âmbito que é deliberadamente emergente.

PRINCE2. A documentação de iniciação do projeto desempenha este papel e a sua estrutura é prescrita. A separação da metodologia continua a aplicar-se, uma vez que o PRINCE2 espera explicitamente a adaptação e é essa adaptação que o leitor precisa de ver.

Híbrido. A realidade mais comum e aquela em que a secção de desvios ganha o seu lugar, porque um projeto híbrido, por definição, se afasta de um método padrão de formas específicas que precisam de ser registadas.

Independentemente do método, o trabalho do plano é o mesmo: registar o que é particular a este projeto. O método determina onde vive o material genérico, não se deve ou não pertencer ao plano.

Simples ou completo: quanto tempo deve ter o plano?

Os dois extremos aparecem no que as pessoas procuram, o que sugere que a questão está realmente por resolver: algumas querem um modelo simples de uma página, outras querem um documento de plano completo.

A resolução é que querem metades diferentes da mesma coisa. Um modelo simples de gestão de projeto é normalmente o calendário e a lista de tarefas, que é um artefacto operacional. Um plano completo de gestão de projeto é o documento de governação. Ambos são legítimos e nenhum é o outro.

Para o plano especificamente: oito a doze páginas para um projeto substancial, duas ou três para um pequeno, além de quaisquer planos subsidiários que justifiquem genuinamente documentos separados. Se a sua governação exigir mais, produza o documento de metodologia e referencie-o, o que satisfaz o requisito sem produzir um documento que ninguém lê.

O número que vale a pena acompanhar não são as páginas. É a abertura após aprovação, que a maioria dos sistemas de documentos lhe dirá e que quase ninguém consulta.

Plano de gestão de projeto ou plano de projeto?

Os termos são usados de forma intercambiável e a distinção vale a pena manter.

Um plano de gestão de projeto descreve como o projeto será gerido: a abordagem, as restrições, a governação, os planos subsidiários. É um documento de governação, aprovado uma vez e revisto em caso de alteração.

Um plano de projeto, no uso comum, geralmente significa o calendário: tarefas, dependências, durações e responsáveis. É um artefacto operacional, atualizado semanalmente.

Confundi-los produz duas falhas familiares. Um documento de governação com um gráfico de Gantt, que fica desatualizado em duas semanas. Ou um calendário apresentado como plano, que não contém restrições, compromisso de recursos nem critérios de aceitação.

Mantenha-os separados e deixe que cada um seja atualizado no seu próprio ciclo. O nosso modelo de plano de projeto de TI cobre o lado do planeamento, incluindo o calendário de restrições, e o nosso modelo de documentação do projeto cobre quais dos documentos resultantes valem a pena manter após o encerramento.

Posso obter um modelo de plano de gestão de projeto em Excel?

Excel para os artefactos que são tabelas e que são atualizados: o calendário, o compromisso de recursos por pessoa, o registo de riscos, a lista de restrições com responsáveis e datas, e a lista do pacote de contratação com prazos de entrega.

Word ou Google Docs para o próprio plano, que é um texto em prosa que descreve decisões e é aprovado em vez de ser acompanhado.

PDF para a versão aprovada, exportada e datada. Como o plano é o que as pessoas citam quando algo é contestado, uma versão aprovada “congelada” é importante.

A maioria das organizações acaba por ter o plano num documento e quatro ou cinco folhas de cálculo ligadas, que é a configuração correta. O que não funciona é qualquer um dos extremos: um plano totalmente numa folha de cálculo perde as decisões e um plano totalmente num documento faz com que as tabelas fiquem desatualizadas.

Como manter o conteúdo específico do projeto visível

A lição do exemplo trabalhado não é realmente sobre o tamanho. É que o conteúdo específico e importante do projeto fica invisível quando é rodeado por material genérico e nenhuma quantidade de boa escrita resolve isso.

Duas práticas ajudam. Extraia as restrições imovíveis para uma página e distribua-as separadamente, porque são os itens em que falhar é mais caro. E mantenha o documento de metodologia genuinamente atual, já que, no momento em que fica desatualizado, as pessoas começam a reescrevê-lo novamente nos planos.

A Trupeer AI é útil para a segunda dessas práticas. O documento de metodologia descreve processos e os processos mudam: uma nova ferramenta de controlo de alterações, uma rota de reporte diferente, um caminho de aprovação revisto. Registar o processo uma vez produz um procedimento escrito com os passos e ecrãs já capturados, para que a metodologia possa ser mantida com precisão de forma económica, em vez de ir ficando desfasada até ninguém confiar nela.

Registe. Dê marca. Traduza. Trupeer.

Isto importa porque toda a separação depende de a metodologia ser fiável. Um plano que referencia uma metodologia em que ninguém acredita e que está atualizada vai começar a reescrevê-la dentro de dois projetos. O SOP creator cobre esses procedimentos e eles vivem na sua knowledge base com uma marca consistente. As instruções de configuração estão no document template setup guide.

Perguntas frequentes

Existe um modelo gratuito de plano de gestão de projeto em Excel?

O Excel serve para as tabelas de que o plano depende: calendário, compromisso de recursos, registo de riscos, restrições com responsáveis, prazos de entrega da contratação. Não há download com validação nem formulário. Mantenha o próprio plano como documento e ligue as folhas, já que os dois são atualizados em ciclos diferentes.

Existe um modelo gratuito de plano de gestão de projeto em Word?

A estrutura de oito secções acima é colada diretamente no Word ou no Google Docs. Aplique o teste de destaque ao seu primeiro rascunho antes de o distribuir, porque o exercício normalmente remove mais do que adiciona e produz a versão que as pessoas vão mesmo abrir.

Existe um modelo gratuito de plano de gestão de projeto em PDF?

Exporte o plano aprovado e mantenha a versão de trabalho editável. O plano é o documento citado quando o âmbito ou a abordagem é contestado, por isso vale a pena ter uma versão congelada com data, ao lado da versão em direto.

Onde posso encontrar um plano completo de gestão de projeto em PDF?

Exemplos publicados com o conjunto completo de planos subsidiários são fáceis de encontrar, incluindo em entidades públicas e universidades, e são úteis para ver a estrutura convencional. Leia um e faça o teste de destaque: a maioria dos exemplos publicados é, substancialmente, uma reexposição da metodologia, e é exatamente por isso que são seguros para publicar.

Existe um modelo simples de gestão de projeto em Excel?

Sim, e normalmente é o calendário e a lista de tarefas, em vez do plano. Vale a pena ter ambos. O calendário acompanha o trabalho; o plano regista as restrições, o compromisso de recursos e as decisões de abordagem. Procurar o modelo simples quando precisa do plano é como os projetos acabam sem registo do que foi acordado.

Preciso de software de plano de projeto?

Não para escrever o plano, que é um documento. O software ganha o seu lugar para o calendário quando passa aproximadamente trinta tarefas em direto com dependências em mudança e mais do que meia dúzia de pessoas a atualizar o estado. Abaixo disso, uma folha de cálculo é mais rápida e toda a gente já tem uma.

Quem deve escrever o plano de gestão de projeto?

O gestor de projeto, com o patrocinador a aprovar e o gabinete do projeto a confirmar quais os planos subsidiários necessários. Quando um plano subsidiário cobre o trabalho de outra função, como a contratação, essa função deve escrevê-lo em vez de o gestor de projeto adivinhar os seus prazos de entrega.

Com que frequência deve ser atualizado o plano de gestão de projeto?

Em caso de alteração e não num ciclo. Quando uma restrição muda, quando os recursos mudam, quando a abordagem se desvia do que foi aprovado ou quando o âmbito muda. O calendário é atualizado semanalmente e o plano não, o que é a razão prática para os manter como documentos separados.